Andyt8

Danke für deine Antwort. Habe es selber rausgefunden. Da kein IPv6 Router vorhanden ist fehlt dieser Teil. Damit hat Windows 7 Probleme und reagiert nicht auf IPv6 Anfragen. Ich habe es nun so gelöst, dass ich beim DHCPv6 Server auch eine IPv6 Prefix aussenden lasse. Nach der Eingabe der IPv6 Prefix mit "publish=yes" einfach folgenden Befehl: netsh interface ipv6 set interface "LAN-Verbindung" advertise=enable routerdiscovery=enable managed=disable Nun haben die Windows 7 Rechner zwei Adressen. Die generierte aus dem IPv6 Prefix und die temporäre vom DHCPv6 Server. Damit funktioniert nun alles.

Kleiner Nachtrag von mir: wenn ich dem Windows 7 Client eine fixe IP-Adresse gebe, dann funktioniert der ping ganz normal. Komischerweise erhält auch dieser noch zusätzlich eine DHCP Adresse. Mmmh, aktuell vermute ich, dass der DHCPv6 Server im stateless Modus läuft. Könnte das die Erklärung sein?

Hallo an alle, Habe folgende Situation: 2 DC mit jeweils DNS und DHCP unter Windows Server 2008 R2 Core; beide Server mit fixer IPv4 und IPv6 Addresse; DHCP verteilt seit langem IPv4 Adressen; IPv6 wurde nun auch ein Bereich eingetragen. Neben Windows XP gibt es vor allem Windows 7 Clients, mit denen die IPv6 Situation getestet werden soll. Der Router beherrscht lediglich IPv4 und sollte hier nicht in die Quere mit eigenen Adressen kommen. Nach der Aktivierung des IPv6 Bereiches erhalten sofort die ersten Clients eine Adresse. Komischerweise auch ein Windows Server 2008 Datenserver, obwohl dort schon zuvor eine fixe IPv6 Adresse eingetragen wurde (hat nun zwei). Im DNS werden die Einträge auch angelegt. Bei dem Versuch einen ping abzusetzen erhalte ich ein komisches Phänomen. Bei den DCs und Datenserver habe ich keine Probleme. Zugriff geht und ping auf IPv4 und IPv6 geht. "ping Client1" ergibt keine Rückmeldung, DNS Auflösung funktioniert und zeigt auf IPv6 DHCP Adresse "ping Client2" ergibt keine Rückmeldung, DNS Auflösung funktioniert und zeigt auf IPv6 DHCP Adresse "ping -4 Client1" ergibt eine normale Rückmeldung "ping -4 Client2" ergibt eine normale Rückmeldung Prüfung Firewall ergibt, dass ICMPv4 und ICMPv6 eingehend zugelassen wird. Also nach Neustart nochmal... "ping Client1" ergibt keine Rückmeldung, DNS Auflösung funktioniert und zeigt auf IPv6 DHCP Adresse: 4000::60c:1e9f:8859:4ee5 Nun probiere ich mal was ganz anderes... "ping 4000::60c:1e9f:8859:4ee5" und da erhalte ich eine normale Rückmeldung. "nslookup Client1" gibt mir die richtige IP-Adresse zurück. Kann mir das jemand erklären? Wurde da auf eine Einstellung vergessen?

Hatte diese Meldung auch. Die Lösung dazu: "Im Sicherheitskontext des angemeldeten Benutzers ausführen (Benutzerrichtlinienoption)" aktivieren. Zu finden ist das im Register "Gemeinsam" bei der Druckereinstellung. Im Register "Allgemein" wurde ja der freigegebene Drucker angegeben. Hintergrundwissen: Diese Option ist standardmäßig nicht gesetzt und würde bewirken, dass der Computer versucht diese Option zu übernehmen. Weil dieser aber keine Rechte hat, die GPO zu übernehmen (=Drucker zuweisen), sondern der/die Benutzer kommt diese Meldung. Übrigens bei mir ist es auch ein Dell 3110cn und noch viele weitere...

Hallo, Habe hier zwei AD mit jeweils einer Gesamtstruktur und Domäne. Zwischen beiden AD ist eine Vertrauenstellung auf Gesamtstrukturebene. Beides vom Schema: Windows Server 2003 R2 Basis... In Domäne A befindet sich Exchange 2007. Somit ist da das Schema noch Mal erweitert worden. Benutzer von Domäne B können nun ohne Probleme ein Exchange Konto haben. Die Zuweisung ist ohne Probleme möglich... Jedoch mir geht es um etwas anders. Hab schon viel gesucht und gelesen, jedoch darauf ist noch nicht wirklich eingegangen worden. In der Domäne B gibt es ein Notebook mit allerlei Verwaltungsprogrammen, wie z.B. für ISA Server oder Forefront Security. Nun wäre es ideal auch da die Exchange Server Verwaltung zu installieren. Das klappte auch soweit. Nur wie kann ich jetzt von Domäne B auf die Domäne A (wo eben die Exchange Server stehen) zugreifen. Ich kann in der Verwaltungskonsole leider nur die eigene Domäne, die in diesem Fall Domäne B ist auswählen? Gibt es dafür eine Lösung oder ist das schlicht und ergreifend nicht möglich? Alle anderen Verwaltungstools gehen ohne Probleme auch über die Domäne B hinweg... Bitte um Hilfe mfg, Andreas

Du meintest wohl sich von einem Vista Rechner via MMC auf den Windows 2008 Server verbinden? Komisch, an das hatte ich noch gar nicht gedacht. Wahrscheinlich weil früher das Snap-in nur bei Server vorhanden war. Wie auch immer. Leider ergibt das bei Vista den Fehler: "Ein Treiber *Name*, Typ 3 - Benutzermodus, x64 konnte nicht installiert werden. Dieser Vorgang wird nicht unterstützt." Getestet mit Windows Vista SP1 x64 mit einem Domain-Admin. Druckoperatoren durften überhaupt nicht einen Treiber hinzufügen. Da war das Feld ausgegraut. Eigentlich sollte Vista SP1 gleich Windows 2008 sein. Jedoch so ähnlich wohl doch nicht. Denn ich habe es dann via MMC von einem Windows 2008 Server x64 probiert und siehe da: da war es ohne Problem möglich. Treiber konnte erfolgreich hinzugefügt werden.

Danke für die Antwort. Äh, was ist damit gemeint? Kannst du das bitte näher erläutern?

Hallo, Ich habe hier einen Windows 2008 Server (32-Bit), der als Rolle neben Datendiensten auch Druckserver hat. Beim Druckserver sind nun mehrere Drucker via IP-Adresse eingebunden. Diese funktionieren und können von jedem 32-Bit System genutzt werden. Für 64-Bit Systeme muss man natürlich einen 64-Bit Treiber hinterlegen. Das ist an sich nicht kompliziert. Einfach beim Register "Freigabe" -> "Treiberkomponenten" den jeweiligen hinzufügen. Jedoch kommt da nach der Angabe des Treibers die Meldung: "Pfad zu den Windows-Medien (x64-Prozessor)". Dabei wird nach einer "ntprint.inf" Datei gefragt. Wenn ich nun diese Datei von einem Windows 2008 Server (64-Bit) nehme (aus dem Pfad C:\Windows\inf), dann kommt die Fehlermeldung: "Ein Treiber *Name*, x64, Typ 3 - Benutzermodus konnte nicht installiert werden. Der Vorgang konnte nicht abgeschlossen werden (Fehler 0x00000002)." [edit]habe auch die Vista x64 Datei probiert. Da ist logischerweise das gleiche heraus gekommen[/edit] Leider kann ich damit nichts anfangen. Google & Co. waren auch nicht Hilfreich. Der Treiber kann bei einem 64-Bit System ohne Probleme installiert werden. Auch unter Windows Vista oder 2k8 Server. Da es mehrere Treiber (= mehrere Drucker) betrifft, nehme ich an, dass es an der "ntprint.inf" Datei liegt. Wie kann ich nun den Treiber ordnungsgemäß installieren. Bitte um Hilfe, da das manuelle Nachinstallieren bei Clients nicht wirklich eine Lösung ist. Vor allem wenn Benutzer keine Adminrechte haben.

Ok, ich glaub ich habe es gelöst. Einfach Authentifizierung beim ISA 2006 von NTLM auf Standard gewechselt. Komische daran, es ist NTLM erlaubt und wird beim ISA 2006 mittels Assistenten auch automatisch ausgewählt. Jetzt muss man mal eine Zeit lang den Dienst beobachten. Kann sein, dass das nicht alles war.

Niemand hat eine mögliche Lösung oder einen Tipp? Habe auch schon versucht die Regel im ISA neu zu erstellen. Leider vergebens. Ohne den ISA Server habe ich die Fehler nicht. Vor dem SP1 für Exchange Server 2007 hat es auch kein Problem gegeben.

Hallo, Wir haben kürzlich auf das erste Servicepack von Exchange 2007 Server aktualisiert. Die Aktualisierung von SP1 hat eigentlich prima geklappt. Nur einige Webdienste streiken. So auch beim OWA 2007. Der externe Zugriff erfolgt über einen ISA 2006 Server. Intern klar direkt mit dem Exchange 2007 Client Access Server. Wenn nun Benutzer über extern auf OWA zugreifen, dann kommen immer wieder folgende Fehler: "Microsoft Exchange hat eine unerwartete Antwort ausgegeben (405)." z.B. bei Wechsel auf öffentliche Ordner nach dem öffnen der Kalenderansicht und Wechsel auf Arbeitswoche erstellen eine neuen Email "Ihre Änderungen wurden aufgrund eines Microsoft Exchange-Fehlers nicht gespeichert." z.B. bei Ändern des Designs Verändern von Server gespeicherten Regeln. Das komische ist, dass es bei Verwendung der internen URL nicht auftritt. Am ISA Server wurde während dem SP1 Update bei Exchange nichts geändert. Frage ist nun, was kann es da haben? Muss wegen dem SP1 beim ISA Server etwas angepasst werden. In den Dokus konnte ich nichts finden. Bitte um Hilfe.

Nun ich glaub das mit den WM6 (=Windows Mobile 6) Geräten und der Synchronisation mit Exchange konnte gelöst werden. Da in Exchange 2007 SP1 die Richtlinien erweitert wurden, wird das WM6 Gerät jetzt auch nicht mehr vollständig unterstützt. Warum auch immer muss da "nicht verwaltete Geräte akzeptieren" aktiviert werden. Normalerweise werden dadurch WM5 Geräte zugelassen - wenn diese Option deaktivert wird, dann nur WM6. Durch die Erweiterung der Konfigurierbarkeit von mobilen Geräten via Richtlinien werden nun auch die WM6 Geräte nicht mehr vollständig verwaltbar. Ich glaub das es daran gelegen hat. Dazu habe ich aber auch einmal die ActiveSync Richtlinie bei den jeweiligen Teilnehmern gewechselt (von der eingestellten auf die default und wieder zurück - sonst werden diese nicht sauber übernommen). IIS wurde dazwischen auch mal neugestartet (nur das war es aber nicht). Vielleicht hat es mehrere Gründe gegeben. Also wenn das bei jemanden auch auftritt nach dem SP1 Update: ActiveSync deaktivieren, wieder aktivieren auf die Default Richtlinie und dann Wechsel auf die eigentliche Richtlinie (Option wie oben beschrieben vorher einstellen). Dann sollte es wieder gehen. Jetzt ist zumindest die Synchronisation wieder bei allen Clients möglich. Nun habe ich nur mehr Probleme bei OWA (Punkt B). Aber das in einem anderen Thread.

Hallo, Kleines Statusupdate von mir. Das Problem bei ActiveSync ist generell. Also auch wenn ich bei einem WM6 Gerät die interne URL angebe, geht nichts. Meine Vermutung ist somit, dass durch die Erweiterung der ActiveSync Richtlinien nun das Gerät nicht mehr kompatibel ist.

Hallo, Wie wahrscheinlich bekannt ist, ist seit kurzem das Exchange 2007 Servicepack 1 veröffentlich t worden. Daher nach einem Test, wurde das Update in die Produktivsysteme eingespielt. Bei den verschiedenen Installationen gab es keinen Fehlermeldung auszumachen. Die anschließende Versuche mit OWA und Outlook gingen wie gewohnt wieder ohne Probleme. Empfang und Versand von Emails dementsprechend ebenso. Heute nach einiger Zeit später, wurden weitere gewohnte Funktionen verwendet. Dabei gab es mehrfach Probleme. Es wird ein Windows 2003 Server SP2 mit Microsoft ISA 2006 verwendet Daneben ein Windows 2003 Server x64 SP2 mit Exchange 2007 SP1. Dort ist die Client Access, Hub Transport und Mailbox Rolle installiert. Edge Transport ist auf einen dritten Server mit ansonster gleicher Konfiguration. A.) Bei Verwendung von ActiveSync auf einem WM6 über einem ISA 2006 ergibt nun folgende Fehlermeldung: Ihr Konto auf Microsoft Exchange Server hat keine Berechtigung zur Synchronisierung mit den z. Zt. aktiven Einstellungen. Wenden Sie sich an den Exchange Server-Administrator, um dieses Feature zu aktivieren. Unterstützungscode: 0x85010004 Also das habe ich mehrfach überprüft. Für den Benutzer ist diese Funktion aktiv. Auch die ActiveSync Richtlinie habe ich überprüft. Beides mehrfach deaktiviert bzw. variiert. Immer mit dem selben Ergebnis. Habe auch schon Google bemüht, aber entweder passte es nicht oder das beschriebene hat nicht funktioniert bzw. war eh schon so eingestellt. Aktuell kann mit den WM6 Clients nur via externe URL probiert werden. Sobald im eigenen W-LAN, werde ich mal die URL bei meinem Gerät testweise umstellen. Warum, siehe weiter unten... B.) Bei Verwendung von OWA 2007 sind mir auch ein paar Ungereihmtheiten aufgefallen. Die Anmeldung ist normal via ISA 2006. Auch kann man wie gewohnt Emails versenden und empfangen. Jedoch sobald man bei den Optionen z.B. die neuen Design Vorlagen verwenden möchte erhalte ich eine Meldung, die besagt, dass die Einstellungen nicht gespeichert werden konnten. Nun hatte ich bei diesem Fall probiert über die "interne URL" auf den Exchange Server zuzugreifen und siehe da, da hat es geklappt. Was kann es da geben? Hängen beide Fälle vielleicht gar zusammen? Liegt es am IIS am Exchange? ISA 2006 schließe ich jetzt mal aus, weil da wurde ja überhaupt nichts geändert... Bitte um Hilfe.

Wir verwenden ebenfalls Outlook 2003 bzw. Outlook 2007 im Cached Mode. Was anderes hat meiner Meinung nach keinen wirklichen Sinn. Aktuell läuft alles über einen Exchange 2003 SP2 ab. Warum wird kein Wechsel auf Outlook 2007 gehen? Meinst wegen dem Exchange? Wenn du bei Outlook 2003 bleiben willst, dann benutz den WDS 2.6.6. Hat meiner Meinung nach sogar noch mehr Funktionen und ist ebenso via GPO konfigurierbar. Ich leider bei meinen Problem auch nicht. Siehe Detail hier: https://www.mcseboard.de/windows-forum-allgemein-28/wds-3-01-all-user-verzeichnis-gpo-109766.html Nach meinem Wissen setzen die meisten nach wie vor WDS 2.6.X ein. Daher auch die meisten Artikel dazu. Scheinbar nutzt Outlook 2007 praktisch keiner. Hier ist WDS 3.X Pflicht und damit haben wir extreme Probleme (GPO, Startvorgang, etc.).

Wir haben WDS 3.01 im Einsatz. Hierbei jedoch nur in einer (produktiven) Testumgebung hautpsächlich mit Outlook 2007. Outlook 2003 wurde auch schon mal probiert. Solche Fehler wurden bei uns nicht entdeckt. Welches Outlook verwendest du? Dafür haben wir andere ebenso gravierende Probleme. Sobald die Gruppenrichtlinie aktiviert bzw. eingestellt worden ist, dauert der Bootvorang unter Windows XP Prof. SP2 leicht um 1 bis 5 Minute länger. Bleibt dann bei Computereinstellungen "hängen". Wenn man Windows Vista nimmt merkt man vielleicht ein paar Sekunden Zeitverlängerung. Bei beiden Systemen wird jedoch die Einstellung normal übernommen. Wenn man die Gruppenrichtlinie wieder entfernt, dann ist der Bootvorgang wieder normal. Unabhängig dazu wurde entdeckt, dass es Probleme bei den Suchergebnissen gibt. Beispielweise werden Startmenü und Desktop Objekte unter "All User" bei normalen Benutzern nicht bei den Suchergebnissen angezeigt. Beides aktuell noch ohne Lösung.... ...Nehme an sowas ist bei euch nicht aufgetreten? [edit]Achja, wir setzten dies für den gleichen Zweck ein. Aktuell ist auf den normalen Rechner noch WDS 2.6.6 drauf. Das kann auch via GPO gesteuert werden. Hauptunterschied ist der Index. Bei WDS 2.6.6 liegt dieser im Benutzerverzeichnis und gilt nur für den jeweiligen Benutzer. Bei WDS 3.01 liegt dieser unter All Users und gilt für die gesamte Maschine. Für Office 2007 bzw. hauptsächlich Outlook 2007 ist WDS 3.x erforderlich - unser Wechselgrund[/edit]

Ich nehme mal an ja. Mir scheint, als ob das für die meisten sowieso naheliegender ist. Zumindest haben die meisten Graz befürwortet.

Hallo an alle, Vor kurzem ist ja Windows Desktop Search 3.01 erschienen. Hier wurde endlich für Unternehmen die Unterstützung der Konfiguration via GPO integriert. Nun habe ich WDS 3.01 auf vier Rechner (probeweise) installiert. Zwei reine Testrechner, zwei "produktive" Rechner für die IT Abteilung in unserem Unternehmen. Auf zwei ist auch Office 2007 zu finden. Alles unter XP Prof. SP2. Rechner ist in der Domäne integriert. Zwei DC, ein Forest. Nun gibt es folgende zwei Probleme: -) Sobald eine GPO Einstellung gesetzt ist, dauert das Hochfahren um 2 bis 3 Minuten länger als sonst. Hier bleibt der Rechner bei "Computereinstellungen werden übernommen" länger hängen. In den Logdateien u.a. Ereignisanzeige kann dazu aber nichts gefunden werden. Wenn man WDS 3.01 deinstalliert und z.B. WDS 2.66 + GPO verwendet, erscheint dieses Phänomen nicht. Sobald wieder auf WDS 3.01 gewechselt wird kommt der Hänger wieder zum erscheinen. -) Verknüpfungen im "All Users" Verzeichnis werde nicht angezeigt. Weder wenn man als lokaler Admin, noch wenn man als Domänbenutzer angemeldet ist. Wenn man neu indizieren lässt, dann geht es wieder für kurze Zeit. Nach aktuellen Erkenntnissen nur solange bis zum Index auch Outlook 2007 bzw. OneNote 2007 hinzukommt. Aktuell sind ~9000 Elemente im Index (nicht gerade viel). Verknüpfungen im Benutzerprofil werden die ganze Zeit über angezeigt. Hoffe das jemanden etwas dazu einfällt. Bitte um jede möglichen Hinweis zur Lösung des Falles. Dann noch ein paar Ungereihmtheiten. Als Benutzer kann man die Indizierung nicht mehr erzwingen? Als Benutzer kann man lokale Ordner nicht mehr einstellen?

Folgende Ausgangssituation: Windows 2k3 R2 x64 Server, auf dem bislang zwei IIS Seiten laufen. Eine davon ist für die kritische Aufgabe als Serverüberwachung tätig (z.B. Temperaturüberwachung). Beide Seiten benötigen den 32Bit Modus vom IIS. Es gibt auch kein Ersatzprodukt, noch eine Aktualisierung. WSS v3 soll hinzukommen. SQL läuft bislang schon auf einem anderen System. Für die es nicht wissen, der IIS kann entweder im 32Bit Modus oder im 64Bit Modus laufen. Jedoch nicht in beiden gleichzeitg. Nun soll, wie eigentlich geplant auf dem Rechner SharePoint installiert werden. .NET und andere notwendige Sachen sind im x64 Bit Modus installiert und funktionsfähig. **** ist halt nur, dass die x64 Version vom SharePoint eben den 64Bit Modus vom IIS braucht. Meine Frage ist nun, was Ihr empfehlen würdet? Soll die x32 Version des SharePoint installiert werden? Hat das überhaupt Sinn bei einer 64Bit Maschine? Macht es einen großen Leisungsunterschied (hat wer wirklich Erfahrung damit)? Bei Exchange 2007 soll es ja enorm viel bringen. Was wären die Vorzüge, was die Einschränkungen? Oder die obigen zwei IIS Seiten löschen und lieber komplett auf 64Bit setzen? Ist beim WSS x64 Bit eigentlich ein 64Bit SQL Server dabei? Den SQL Express gibt es ja nur für 32Bit. Warum kann man eigentlich den IIS nicht zweimal installieren? Dann eine Frage zu den iFiltern. Müssen diese auf den SQL Server oder beim WSS installiert werden (zwei unterschiedliche Rechner). Man beachte dabei, es kommt sowohl SQL 2k5 Express, sowie auch SQL 2k5 Standard zum Einsatz. Alles bislang mit WSS v3. SQL Server sind auf der gleichen Maschine. Braucht man bei den iFiltern eine spezielle Version wenn man diese auf 64Bit Systemen einsetzen will (SharePoint x64 bzw. SQL x64) oder ist dies dank Standardschnittstelle egal? Zeitweise habe ich schon speziell angepasste Versionen gesehen. CU, Andreas

Anscheinend geht das nicht. Warum? Keine Ahnung. Sobald der Port 80 bzw. 443 verwendet wird, läuft der komplette Traffic auch noch Mal über den Proxydienst beim ISA. Wenn aber ein Webserver den Port 9000 verwendet so wird das vom ISA direkt weitergeleitet. Abhilfe konnte ich nicht finden. Jedoch funktioniert jetzt der Zugriff von beiden Seiten auch über den Proxy ohne Probleme...

Danke dir, du hast den entscheidenden Hinweis gegeben. Den Microsoft Support Artikel kannte ich noch nicht, half in diesem Falle auch nicht. Jedoch war da ein Hinweis, der mir dann schlussendlich die Lösung brachte. Auf den ISA Server wird das Produkt WebMonitor von GFI eingesetzt. Dabei sollte Webinhalt gescannt werden, sobald dieser ins LAN gelangt. Soweit so gut. Jedoch wird hier auch jeder Traffic zwischen Außenstelle und Haupstelle gescannt. Und deshalb geht dann auch der Zugriff auf den WSUS nicht (hier muss eine CAB Datei runtergeladen werden). Leider weiß ich nicht wie man bei WebMonitor bzw. ISA Server dahingend die Einstellung verändern muss. Man kann zwar beim Webmonitor Ausnahmen für die Überprüfung angegeben, jedoch einen IP-Range als Ausnahme kann ich da nicht vergeben und jede einzelne IP-Adresse einfügen ist doch recht Mühsam. Ich verstehe sowieso nicht warum da immer über den Proxy vom ISA Server gegangen wird. Laut meiner Logik sollte der Zugriff zwischen beiden Außenstellen direkt sein. So wurde u.a. der IP-Bereich von der Außenstelle bzw. Hauptstelle so angelegt, dass die Rechner darauf direkt zugreifen sollen. Weiß hier jemand einen Rat? Das mit der Ausnahme umgeht das Problem etwas, lösen tut es das aber auch nicht sauber.

Wie schauts nun aus? Gibt es dazu schon neue Informationen?

Werde daraus einfach nicht schlau. Manueller Zugriff via http auf den WSUS vom anderen Standort aus geht ohne Probleme. Der Computer jedoch kann es nicht... ...glaub es ist nach wie vor die VPN Verbindung. Denn einige Rechner (Laptops) sind ab und zu in beiden Netzen. Wenn diese nun am Standort des WSUS sind, dann klappt der Download. Vom anderen Standort aus kommt jedoch wieder die Fehlermeldung. Eine Firewall wird zwischen beiden Standorten nicht eingesetzt. Hier ist alles offen. Immerhin werden beide Netze vom gleichem Team supportet. Daher dafür kein Bedarf. Was kann es nun sein? Gibt es da vielleicht einen Timeout?

Hallo, Ich habe folgende Situation. Zwei unterschiedliche Gesamtstrukuren mit jeweils einer Domänen ohne Vertrauenstellung. Dazwischen ist eine VPN Site-to-Site Verbindung eingerichtet. Es wurde dies mit einem ISA 2004 SP2 und Netgear FVS124G bewerkstelligt. Die Verbindung läuft. Auflösung mittels DNS und auch WINS laufen auch schon von beiden Richtungen. Zugriff auf verschiedene Dienste soweit ohne Probleme (Netzwerkfreigaben, http/https Dienste, etc.) Bei einem Ort soll der WSUS Server entfernt werden (u.a. weil Rechner alt -> ausscheiden). Nun hätte der WSUS vom anderen Standort diese FUnktion übernehmen sollen. Also Änderung der GPO Einstellungen und siehe da die Clients melden sich auch beim WSUS am anderen Ort. Leider bemerkte ich, das kein Statusbericht abgeliefert wird. Daher habe ich weitere Untersuchungen gemacht. Beispielweise habe ich mittels ClientDiag.exe eine genauere Untersuchung durchgeführt: WSUS Client Diagnostics Tool Checking Machine State Checking for admin rights to run tool . . . . . . . . . PASS Automatic Updates Service is running. . . . . . . . . . PASS Background Intelligent Transfer Service is not running. PASS Wuaueng.dll version 5.8.0.2607. . . . . . . . . . . . . PASS This version is WSUS 2.0 Checking AU Settings AU Option is 3 : Notify Prior to Install. . . . . . . . PASS Option is from Policy settings Checking Proxy Configuration Checking for winhttp local machine Proxy settings . . . PASS Winhttp local machine access type <Direct Connection> Winhttp local machine Proxy. . . . . . . . . . NONE Winhttp local machine ProxyBypass. . . . . . . NONE Checking User IE Proxy settings . . . . . . . . . . . . PASS User IE Proxy. . . . . . . . . . . . . . . . . NONE User IE ProxyByPass. . . . . . . . . . . . . . NONE User IE AutoConfig URL Proxy . . . . . . . . . NONE User IE AutoDetect AutoDetect not in use Checking Connection to WSUS/SUS Server WUServer = http://bs-wsus WUStatusServer = http://bs-wsus UseWuServer is enabled. . . . . . . . . . . . . . . . . PASS GetAUSettingsRegistry(false, TEXT("SusServerVersion"), &dwSusVersion) failed wit h hr=0x80070002 The system cannot find the file specified. Press Enter to Complete Wie zu sehen ist ist dabei eine Fehlermeldung herausgekommen. Ich nehme an es liegt an der VPN Verbindung (beispielweise das noch irgendwo was "hängt"). Leider habe ich auch durch Suchen mittels Google, Microsoft Support, etc. keine brauchbare Lösung gefunden. Weiß jemand was der Fehler bedeutet. Ich hoffe damit eine Lösung zu finden. Aktuell habe ich bereits mehrfach versucht mittels löschen des Inhaltes vom Downloadordners und Cacheordners in %windir%/SoftwareDistribution/ den Fehler zu beheben. Leider ohne brauchbaren Erfolg. Das Betriebssystem und auch die Gruppe (wird per GPO gesteuert) wird richtig erkannt und an den WSUS übermittelt. Bitte um Hilfe...

Also Empfängerrichtlinie gibt es schon. Die hat aber nur Berichterstattungsaufgabe für Elemente älter als 60 Tage. Und dies betrifft soweit ich weiß nur das lokale Postfach, jedoch nicht öffentliche Ordner.