Problem bei Netzwerkzugriff von Server 2012 auf Server 2011
Hallo Leute,
sorry für die sehr allgemeine Überschrift. Aber ich habe beim besten Willen keinen Plan, wie ich mein Problem beschreiben soll.
Nachdem mittlerweile 2 Microsoft Gold zertifizierte Techniker und ich am verzweifeln sind, schreibe ich jetzt mal hier und hoffe vlt. auf eine Lösung.
Meine Hardware:
Server 2011 Small Business (2008R2) als AD, DC,...
Server 2012 als Terminal Server
Drucker usw. sind am 2011er installiert und werden dort per GPO verteilt.
Das System lief jetzt einige Wochen im Betrieb immer ohne Probleme.
Letzte Woche starteten einige Programme nicht mehr korrekt und die Drucker wurden nicht mehr verteilt.
Dazu sei gesagt, dass es sich bei den Programmen um welche handelte die am Terminalserver abgerufen wurden, aber auf den DC installiert wurden.
Sowohl bei den Druckern als auch bei den Programmen war als Pfad nur "srv1" - also der Name vom DC hinterlegt.
Ich wechselte nun in dem Windows-Explorer und rief den Server mit "\\srv1" auf und versuchte so den Drucker per Doppelklick zu installieren.
Dort bekam ich die Fehlermeldung "Druckerverbindung kann nicht hergestellt werden. Der angegebene Anschluss ist unbekannt."
Also versuchte ich das selbe aber diesmal mit "\\IPADRESSE" sowie mit FQDN "\\srv1.test.local" und auf einmal ließen sich die Drucker installieren.
In der Ereignisanzeige waren weder am DC noch am Terminalserver Einträge zu finden.
Nach einem Neustart des TerminalServer funktionierte aber dann wieder alles wie gewohnt - also auch mit "\\srv1".
Ich stellte nun sämtliche Adressen im Unternehmen auf FQDN und so funktionierte nun alles perfekt bis auf heute.
Leider tauchte heute genau das gleiche Phänomen auf wie das letzte Mal nur diesmal umgekehrt: FQDN ging nicht, nur der Servername/IPAdresse funktionierte.
Das "witzige" dabei ist, dass dieses Problem nur auf dem Terminalserver auftritt. Auf den normalen Clients (Win 8) ging es bis jetzt immer ohne Probleme.
Recht viele Sachen dazu findet man leider nicht im Internet. Die Lösungen hier und hier treffen für mich nicht zu, da 1) es sich um einen virtuellen Server handelt - also chkdsk nichts bringt und 2) ich keinen Fehler im DNS finden konnte. Mittels nslookup konnte ich auch beim auftreten des Fehlers immer alles richtig auflösen.
Wäre dankbar, wenn irgendwer einen Lösungsansatz für mich hätte!
Grüße
Patrick
sorry für die sehr allgemeine Überschrift. Aber ich habe beim besten Willen keinen Plan, wie ich mein Problem beschreiben soll.
Nachdem mittlerweile 2 Microsoft Gold zertifizierte Techniker und ich am verzweifeln sind, schreibe ich jetzt mal hier und hoffe vlt. auf eine Lösung.
Meine Hardware:
Server 2011 Small Business (2008R2) als AD, DC,...
Server 2012 als Terminal Server
Drucker usw. sind am 2011er installiert und werden dort per GPO verteilt.
Das System lief jetzt einige Wochen im Betrieb immer ohne Probleme.
Letzte Woche starteten einige Programme nicht mehr korrekt und die Drucker wurden nicht mehr verteilt.
Dazu sei gesagt, dass es sich bei den Programmen um welche handelte die am Terminalserver abgerufen wurden, aber auf den DC installiert wurden.
Sowohl bei den Druckern als auch bei den Programmen war als Pfad nur "srv1" - also der Name vom DC hinterlegt.
Ich wechselte nun in dem Windows-Explorer und rief den Server mit "\\srv1" auf und versuchte so den Drucker per Doppelklick zu installieren.
Dort bekam ich die Fehlermeldung "Druckerverbindung kann nicht hergestellt werden. Der angegebene Anschluss ist unbekannt."
Also versuchte ich das selbe aber diesmal mit "\\IPADRESSE" sowie mit FQDN "\\srv1.test.local" und auf einmal ließen sich die Drucker installieren.
In der Ereignisanzeige waren weder am DC noch am Terminalserver Einträge zu finden.
Nach einem Neustart des TerminalServer funktionierte aber dann wieder alles wie gewohnt - also auch mit "\\srv1".
Ich stellte nun sämtliche Adressen im Unternehmen auf FQDN und so funktionierte nun alles perfekt bis auf heute.
Leider tauchte heute genau das gleiche Phänomen auf wie das letzte Mal nur diesmal umgekehrt: FQDN ging nicht, nur der Servername/IPAdresse funktionierte.
Das "witzige" dabei ist, dass dieses Problem nur auf dem Terminalserver auftritt. Auf den normalen Clients (Win 8) ging es bis jetzt immer ohne Probleme.
Recht viele Sachen dazu findet man leider nicht im Internet. Die Lösungen hier und hier treffen für mich nicht zu, da 1) es sich um einen virtuellen Server handelt - also chkdsk nichts bringt und 2) ich keinen Fehler im DNS finden konnte. Mittels nslookup konnte ich auch beim auftreten des Fehlers immer alles richtig auflösen.
Wäre dankbar, wenn irgendwer einen Lösungsansatz für mich hätte!
Grüße
Patrick
Please also mark the comments that contributed to the solution of the article
Content-ID: 222520
Url: https://administrator.de/contentid/222520
Printed on: October 11, 2024 at 14:10 o'clock
22 Comments
Latest comment
- Tritt das Problem mit allen Benutzerkonten auf oder nur mit "ausgewählten" Konten?
- Tritt das Problem mit einem neuen Benutzerprofil auf?
- Evt. hilft es bei einem bestehenden Profil mal die Keys HKCU\Printers, HKCU\Software\Microsoft\Windows NT\CurrentVersion\Printerports zu löschen, Spooler neustarten, nochmal versuchen.
- Kann ein Domänenadmin (Sicherheitsberechtigung vorausgesetzt) die Drucker problemlos manuell hinzufügen?
- Wurden die Berechtigungen für die freigegebenen Drucker eingeschränkt, z. B. dass der Netzwerkdienst nicht mehr zugreifen darf?
- Sind die SPNs am Druckserver richtig gesetzt, sprich: vorhanden? SPNs sind z. B. beim Zugriff mit Aliasnamen (sagen wir ich benutze den DNS-Alias fileserver anstatt SRV1 zum Zugriff) häufig eine Fehlerquelle. Lässt sich mit SetSPN prüfen.
- Sind Dateifreigaben auf dem Server problemlos mit einem Benutzer- und einem Administratorkonto erreichbar?
- Was passiert, wenn das Computerkonto des Terminals für eine Freigabe und Sicherheitsberechtigung berechtigt wird, anschließend mit "psexec -i -s cmd" eine Kommandozeilen-Sitzung mit Systemrechten, darin dann in der Systemsitzung eine Ausgabe für ein beliebiges Fileshare angefragt wird, a la "dir \\srv1\deinfreigabename"? Gibt's eine Ausgabe oder wird Benutzername/Kennwort angefragt?
- Der SRV1 als Domain Controller ist ja "sauber", evt. hilft die Neuaufnahme des Terminalservers.
- Was sagt GPResult zur Richtlinienübernahme?
- Was sagt nslookup bei der Abfrage nach dem Domänennamen?
- Stimmt Datum/Uhrzeit/Zeitzone bei DC/Druckserver/Terminalserver überein?
- Tritt das Problem mit einem neuen Benutzerprofil auf?
- Evt. hilft es bei einem bestehenden Profil mal die Keys HKCU\Printers, HKCU\Software\Microsoft\Windows NT\CurrentVersion\Printerports zu löschen, Spooler neustarten, nochmal versuchen.
- Kann ein Domänenadmin (Sicherheitsberechtigung vorausgesetzt) die Drucker problemlos manuell hinzufügen?
- Wurden die Berechtigungen für die freigegebenen Drucker eingeschränkt, z. B. dass der Netzwerkdienst nicht mehr zugreifen darf?
- Sind die SPNs am Druckserver richtig gesetzt, sprich: vorhanden? SPNs sind z. B. beim Zugriff mit Aliasnamen (sagen wir ich benutze den DNS-Alias fileserver anstatt SRV1 zum Zugriff) häufig eine Fehlerquelle. Lässt sich mit SetSPN prüfen.
- Sind Dateifreigaben auf dem Server problemlos mit einem Benutzer- und einem Administratorkonto erreichbar?
- Was passiert, wenn das Computerkonto des Terminals für eine Freigabe und Sicherheitsberechtigung berechtigt wird, anschließend mit "psexec -i -s cmd" eine Kommandozeilen-Sitzung mit Systemrechten, darin dann in der Systemsitzung eine Ausgabe für ein beliebiges Fileshare angefragt wird, a la "dir \\srv1\deinfreigabename"? Gibt's eine Ausgabe oder wird Benutzername/Kennwort angefragt?
- Der SRV1 als Domain Controller ist ja "sauber", evt. hilft die Neuaufnahme des Terminalservers.
- Was sagt GPResult zur Richtlinienübernahme?
- Was sagt nslookup bei der Abfrage nach dem Domänennamen?
- Stimmt Datum/Uhrzeit/Zeitzone bei DC/Druckserver/Terminalserver überein?
> - Evt. hilft es bei einem bestehenden Profil mal die Keys HKCU\Printers, HKCU\Software\Microsoft\Windows
> NT\CurrentVersion\Printerports zu löschen, Spooler neustarten, nochmal versuchen.
Hätte das einen Sinn? Denn wenn ich die Drucker über die IP oder FYDN installiere, geht es ja dann.
> NT\CurrentVersion\Printerports zu löschen, Spooler neustarten, nochmal versuchen.
Hätte das einen Sinn? Denn wenn ich die Drucker über die IP oder FYDN installiere, geht es ja dann.
Hatte zuletzt einen Fall, da konnte ein Benutzer keine Drucker hinzufügen oder einen Standarddrucker setzen, da hat das geholfen. Einmal war auch in HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon ein Eintrag "Load" für einen Virus gesetzt, bei dem zwar die exe gelöscht, aber der Eintrag noch da war, in dem Zweig steht übrigens auch der Standarddrucker des Benutzers.
> - Sind die SPNs am Druckserver richtig gesetzt, sprich: vorhanden? SPNs sind z. B. beim Zugriff mit Aliasnamen (sagen wir
ich
> benutze den DNS-Alias fileserver anstatt SRV1 zum Zugriff) häufig eine Fehlerquelle. Lässt sich mit SetSPN
prüfen.
Werde ich mir anschauen.
ich
> benutze den DNS-Alias fileserver anstatt SRV1 zum Zugriff) häufig eine Fehlerquelle. Lässt sich mit SetSPN
prüfen.
Werde ich mir anschauen.
Am besten vergleichen mit einem funktionierenden Printserver, z. B. bei einer anderen Umgebung..
Etwas OT, aber zum Thema Server-Alias gibts hier Infos.
Zum Thema gibts noch Infos hier: http://serverfault.com/questions/23823/how-to-configure-windows-machine ...
Zuletzt gabs dazu einen KB-Artikel von Microsoft, den ich auf meinem eigenen Printserver brauchte: http://support.microsoft.com/kb/2546625
Domänen-Neuaufnahme tut neben der Downtime auch nicht weh, da die Zuordnung SIDs zu Profilen erhalten bleibt, kostet nur eben 1 bis 2 Neustarts.
Was auch helfen kann ist z. B. DCDiag, das Dienstprogramm spuckt noch ein paar Daten zur AD-Gesundheit aus.
Bei meinem Printserver (angesprochen mit Alias und FQDN) brauche ich für meinen Alias folgende SPNs:
wsman/[FQDN-des-Alias]
wsman/[Netbiosname-des-Alias]
RestrictedKrbHost/[FQDN-des-Alias]
RestrictedKrbHost/[Netbios-Name-des-Alias]
host/[FQDN-des-Alias]
host/[Netbios-Name-des-Alias]
Für deinen Fall wäre das dann
wsman/SRV1.domäne.local
wsman/SRV1
RestrictedKrbHost/SRV1.domäne.local
RestrictedKrbHost/SRV1
host/SRV1.domäne.local
host/SRV1
Wichtig sind meines Wissens "nur" RestrictedKrbHost und host. Sofern du nur mit dem NetBios-Namen arbeiten willst dürften die SPNs mit dem NetBios-Namen ausreichen.
Edit:
Noch was vergessen, seit Server 2008 kann man an einem DC die SPNs nicht mehr einfach ändern. Nach ein paar Minuten wird das zurückgesetzt. Bei einem 2003er Server konnte ich noch SPNs manuell ändern.
wsman/[FQDN-des-Alias]
wsman/[Netbiosname-des-Alias]
RestrictedKrbHost/[FQDN-des-Alias]
RestrictedKrbHost/[Netbios-Name-des-Alias]
host/[FQDN-des-Alias]
host/[Netbios-Name-des-Alias]
Für deinen Fall wäre das dann
wsman/SRV1.domäne.local
wsman/SRV1
RestrictedKrbHost/SRV1.domäne.local
RestrictedKrbHost/SRV1
host/SRV1.domäne.local
host/SRV1
Wichtig sind meines Wissens "nur" RestrictedKrbHost und host. Sofern du nur mit dem NetBios-Namen arbeiten willst dürften die SPNs mit dem NetBios-Namen ausreichen.
Edit:
Noch was vergessen, seit Server 2008 kann man an einem DC die SPNs nicht mehr einfach ändern. Nach ein paar Minuten wird das zurückgesetzt. Bei einem 2003er Server konnte ich noch SPNs manuell ändern.
Was tun die Policies, deren Namen er nicht auflösen kann? Warum hast du als Domain-Admin keinen Zugriff bzw. haben alle benötigten Sicherheitsgruppen/Benutzerkonten Zugriff? Werden die evt. nicht richtig von einem anderen DC synchronisiert? Was steckt da in der Computerkonfiguration, deren Übernahme deaktiviert wurde?
- Du kannst den Inhalt der Policies am SRV01 mit den "Live-Daten" der Domäne vergleichen, indem du \\domänenname\sysvol\domänenname\Policies mit der lokalen Kopie c:\Windows\SYSVOL\domain\Policies vergleichst.
Die "schnelle Verbindung" ist in der Regel eine LAN-Verbindung. Eine "langsame Verbindung" ist zum Beispiel eine VPN-Verbindung von außen.
Dadurch wird sichergestellt, dass z. B. bei Zugriff von extern mit VPN-Login vor dem Anmelden einige Richtlinien nicht verarbeitet werden, die besonders viel Zeit bzw. Traficc brauchen würden. Ab wenn eine Verbindung "langsam" ist, kann glaube ich auch per Gruppenrichtlinie eingestellt werden. Welche Richtlinien da im einzelnen da nicht übernommen werden weiß ich ad hoc auch nicht, ich habe diese Unterscheidung bisher nicht gebraucht.
Nochmal zur Gruppenrichtlinie, die die Drucker verteilt:
- Verteilst du die Drucker per Computerkonfiguration oder Benutzerkonfiguration? Bei freigegebenen Druckern macht die Verteilung per Benutzerkonfiguration Sinn, bei lokalen Druckern die Verteilung per Computerkonfiguration.
- Welche Richtlinie verwendest du? Einstellungen -> Systemsteuerungseinstellungen -> Drucker oder Richtlinien -> Windows-Einstellungen -> Bereitgestellte Drucker?
- Falls über die Systemsteuerungseinstellungen, steht dort als Aktion "Erstellen" oder "Ersetzen"?
Nochmal zu den Ports:
- Wenn du auf dem Terminalserver die Druckverwaltung installierst, mit einem Domain-Admin-Konto die Druckverwaltungs-MMC öffnest und dich mit SRV01 verbindest, kannst du problemlos zugreifen?
- Stimmt in den Druckservereigenschaften der Port? Evt. mal verstellen, übernehmen, zurückstellen, übernehmen.
- Hast du schon einmal einen zusätzlichen Port für die Ziel-IP des Druckers angelegt und im Drucker eingestellt?
- Du kannst den Inhalt der Policies am SRV01 mit den "Live-Daten" der Domäne vergleichen, indem du \\domänenname\sysvol\domänenname\Policies mit der lokalen Kopie c:\Windows\SYSVOL\domain\Policies vergleichst.
Die "schnelle Verbindung" ist in der Regel eine LAN-Verbindung. Eine "langsame Verbindung" ist zum Beispiel eine VPN-Verbindung von außen.
Dadurch wird sichergestellt, dass z. B. bei Zugriff von extern mit VPN-Login vor dem Anmelden einige Richtlinien nicht verarbeitet werden, die besonders viel Zeit bzw. Traficc brauchen würden. Ab wenn eine Verbindung "langsam" ist, kann glaube ich auch per Gruppenrichtlinie eingestellt werden. Welche Richtlinien da im einzelnen da nicht übernommen werden weiß ich ad hoc auch nicht, ich habe diese Unterscheidung bisher nicht gebraucht.
Nochmal zur Gruppenrichtlinie, die die Drucker verteilt:
- Verteilst du die Drucker per Computerkonfiguration oder Benutzerkonfiguration? Bei freigegebenen Druckern macht die Verteilung per Benutzerkonfiguration Sinn, bei lokalen Druckern die Verteilung per Computerkonfiguration.
- Welche Richtlinie verwendest du? Einstellungen -> Systemsteuerungseinstellungen -> Drucker oder Richtlinien -> Windows-Einstellungen -> Bereitgestellte Drucker?
- Falls über die Systemsteuerungseinstellungen, steht dort als Aktion "Erstellen" oder "Ersetzen"?
Nochmal zu den Ports:
- Wenn du auf dem Terminalserver die Druckverwaltung installierst, mit einem Domain-Admin-Konto die Druckverwaltungs-MMC öffnest und dich mit SRV01 verbindest, kannst du problemlos zugreifen?
- Stimmt in den Druckservereigenschaften der Port? Evt. mal verstellen, übernehmen, zurückstellen, übernehmen.
- Hast du schon einmal einen zusätzlichen Port für die Ziel-IP des Druckers angelegt und im Drucker eingestellt?
{D4C2CD04-D924-486A-A9D8-90B5CB163B01}:
SharePoint Psconfig Notification Policy - automatisch erstellt vom SBS.
LogonScript mit dem Inhalt ""\\SRV1\C$\Program Files\Windows Small Business Server\Bin\NotificationUI.exe" %1 %2 %3"
SharePoint Psconfig Notification Policy - automatisch erstellt vom SBS.
LogonScript mit dem Inhalt ""\\SRV1\C$\Program Files\Windows Small Business Server\Bin\NotificationUI.exe" %1 %2 %3"
{13180A53-DB09-4719-9D2A-A8B40E5FC3B3}:
Windows SBS User Policy - automatisch erstellt vom SBS.
einige IE Settings
Windows SBS User Policy - automatisch erstellt vom SBS.
einige IE Settings
Windows SBS CSE Policy:
automatisch erstellt vom SBS.
führt einige exe (z.b. sbslogon.exe, clientagentx86.msi) aus sowie ClientAgent.vbs
automatisch erstellt vom SBS.
führt einige exe (z.b. sbslogon.exe, clientagentx86.msi) aus sowie ClientAgent.vbs
Achso, nur so'n Zeug Nur merkwürdig, dass er keinen Namen für die Policy finden kann.
Ich habe die Einstellungen Löschen bzw. aktualisieren gesetzt.
Wenn der Drucker noch nicht vorhanden ist, nimm Erstellen.
Wenn der Drucker bereits bei mind. 1 Benutzerprofil fehlerhaft verbunden, nimm für diesen Drucker Ersetzen. Das sorgt dann dafür, dass der Drucker erst getrennt, und anschließend neu verbunden wird. Solltest du nur so lange auf Ersetzen stehen lass, bis du sicher bist, dass keiner mehr eine fehlerhafte Verbindung hat, da sonst der Login pro Drucker etwas länger dauert.
Übrigens: fürs Löschen kannst du (zuletzt erfahren mit Win7) kannst du nicht \\Server\Freigabename benutzen, sondern musst \\Server\Druckername verwenden, so wie es in den Schlüsselnamen in HKCU\Printers\Connections steht ("," durch "\" ersetzen).
ABER:
Hab die Registry keys gelöscht und den Spooler (Druckerwarteschlange) neu gestartet und alles ging wieder.
Auf was kann dies alles hin deuten?
Korrupter Treiber??
Hab die Registry keys gelöscht und den Spooler (Druckerwarteschlange) neu gestartet und alles ging wieder.
Auf was kann dies alles hin deuten?
Korrupter Treiber??
Die Registry Keys löschen ja "nur" die benutzerspezifischen Verbindungen zu freigegebenen Druckern bzw. die Einstellungen, die in einem Benutzerkonto für einen Drucker vorgenommen wurden (z. B. Duplex, Farbe/SW, Papiersorte usw.). Evt. waren von einer vorherigen Verbindung falsche Standard- oder benutzerdefinierte Einstellungen in der Registry, die, nach den Änderungen am freigegebenen Drucker (z. B. Treiber) und dem Löschen aus der Registry, mit funktionierenden Standardeinstellungen neu geschrieben wurden.
Bei HP-Druckern wird z. B. gern mal die ID einer Papiersorte geändert, die mit dem neuen Treiber dann statt als Normalpapier z. B. als Hochglanz oder irgendwas anderes interpretiert wird. So etwas hatte ich mal, als ein Client mit altem Druckertreiber einen Druckauftrag an einen Druckserver mit neuerem Druckertreiber schickt.
DANKE dir recht, recht herzlich loonydeluxe für deine ganzen Mühen!
Gern geschehen!
Ich möchte diese Standard GPOs nicht komplett löschen sondern leer räumen.
Habe aber da das Problem, dass ich einige Werte nicht mehr ändern kann wie z.b. IE Maintenance. Kann ich die Einstellungen direkt aus dem
File im entsprechenden Policies Ordner löschen oder ist sowas tödlich?
Habe aber da das Problem, dass ich einige Werte nicht mehr ändern kann wie z.b. IE Maintenance. Kann ich die Einstellungen direkt aus dem
File im entsprechenden Policies Ordner löschen oder ist sowas tödlich?
Mh... prinzipiell nicht. Aber falls aus irgendeinem Grund dann doch mal wieder das Standardverhalten des SBS benötigt wird, sind die natürlich weg.
Du kannst auch die Verknüpfungen der Gruppenrichtlinien in den einzelnen OUs einfach deaktivieren. Genauso mit der Default Domain Policy oder mit der Default Domain Controller Policy. Kannst du deaktivieren, eine Kopie mit deinen bevorzugten Einstellungen erzeugen und an die entsprechenden OUs verlinken.
Bei meinem Printserver (angesprochen mit Alias und FQDN)
FQDN geht bei mir da gar nicht.
"FindDomainForAccount: Fehler beim Aufrufen von DsGetDcNameWithAccountW mit dem Rückgabewert 0x00000525.
Konto SRV1.domäne.local wurde nicht gefunden."
FQDN geht bei mir da gar nicht.
"FindDomainForAccount: Fehler beim Aufrufen von DsGetDcNameWithAccountW mit dem Rückgabewert 0x00000525.
Konto SRV1.domäne.local wurde nicht gefunden."
Hab das auch gerade nochmal probiert, abfragen kann ich einen beliebigen DC oder Nicht-DC auch nur mit dem NetBIOS-Namen des Computers, beim FQDN der Server erhalte ich die gleiche Fehlermeldung.
Du kannst am SBS auch dieses Update-Rollup installieren, wenns gar nicht weiter geht: http://support.microsoft.com/kb/2775511/de
KB2775511 enthält einen ganzen Sack voll Fehlerbehebungen für verschiedene Probleme. Ist mir nicht gleich eingefallen, da ich dass in den von mir betreuten Umgebungen in den WSUS importiere und für Win7/2008R2-Computer freigebe und automatisch installieren lasse.
Aber wie alle Tipps wie immer auf eigene Gefahr Bei mir hats bisher aber nur geholfen und nicht geschadet. Das Update wird übrigens NICHT per Windows Update angeboten, kann aber per Update-Katalog in den WSUS importiert werden.
Für mich war dieses "Netzwerk-Alles-Update" mal DIE Lösung, als in einem kleinen Unternehmen zwei Windows-Laptops mit Office 2010 in Verbindung mit Offlinesynchronisierung (beide waren im internen GBit-LAN online!) an einem Fileserver permanent Konflikte und temporäre Dateien erzeugt haben. Genau dieses Verhalten war auch in meinem eigenen Netzwerk mit zwei VMs mit 10Gbit-Verbindung am selben Hyper-V nachvollziehbar - dabei musste die zweite VM nicht mal die Datei öffnen, geschweige denn auf den Ordner zugreifen - die aktive Offline-Sync reichte aus. "Eigentlich" war dieses Problem bloß für Office-Anwendungen in besonders langsamen VPN-Umgebungen beschrieben...
KB2775511 enthält einen ganzen Sack voll Fehlerbehebungen für verschiedene Probleme. Ist mir nicht gleich eingefallen, da ich dass in den von mir betreuten Umgebungen in den WSUS importiere und für Win7/2008R2-Computer freigebe und automatisch installieren lasse.
Aber wie alle Tipps wie immer auf eigene Gefahr Bei mir hats bisher aber nur geholfen und nicht geschadet. Das Update wird übrigens NICHT per Windows Update angeboten, kann aber per Update-Katalog in den WSUS importiert werden.
Für mich war dieses "Netzwerk-Alles-Update" mal DIE Lösung, als in einem kleinen Unternehmen zwei Windows-Laptops mit Office 2010 in Verbindung mit Offlinesynchronisierung (beide waren im internen GBit-LAN online!) an einem Fileserver permanent Konflikte und temporäre Dateien erzeugt haben. Genau dieses Verhalten war auch in meinem eigenen Netzwerk mit zwei VMs mit 10Gbit-Verbindung am selben Hyper-V nachvollziehbar - dabei musste die zweite VM nicht mal die Datei öffnen, geschweige denn auf den Ordner zugreifen - die aktive Offline-Sync reichte aus. "Eigentlich" war dieses Problem bloß für Office-Anwendungen in besonders langsamen VPN-Umgebungen beschrieben...