22
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 222520
Url: https://administrator.de/contentid/222520
Ausgedruckt am: 23.11.2024 um 04:11 Uhr
22 Kommentare
Neuester Kommentar
- 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?
Danke für deine Hilfe loonydeluxe.
Nachdem ich den Server mittlerweile wieder neu gestartet habe funktioniert gerade wieder alles. Daher kann ich ein paar Sachen nun gerade nicht testen. Werde diese aber beim nächsten eintreten gleich testen.
Aber ein paar Sachen kann ich ja schon beantworten:
Nachdem ich den Server mittlerweile wieder neu gestartet habe funktioniert gerade wieder alles. Daher kann ich ein paar Sachen nun gerade nicht testen. Werde diese aber beim nächsten eintreten gleich testen.
Aber ein paar Sachen kann ich ja schon beantworten:
- Tritt das Problem mit allen Benutzerkonten auf oder nur mit "ausgewählten" Konten?
mit allen.- Tritt das Problem mit einem neuen Benutzerprofil auf?
noch nicht probiert- 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.
- Kann ein Domänenadmin (Sicherheitsberechtigung vorausgesetzt) die Drucker problemlos manuell hinzufügen?
Nein. Geht bei dem auch nicht.- Wurden die Berechtigungen für die freigegebenen Drucker eingeschränkt, z. B. dass der Netzwerkdienst nicht mehr
zugreifen darf?
Nein.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.
Werde ich mir anschauen.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?
Prinzipiell ja. Aber wie oben beschrieben gibt es tlw. Programme die am DC installiert sind und über eine Freigabe geöffnet wurde, die Probleme machen (Wenn auch das Drucken nicht geht). Aber prinzipiell kann man sagen, dass die Dateifreigabe soweit funktioniert.- 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?
Probier ich noch.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.
Könnte man probieren. Aber warum funktioniert es dann tlw. Tage ohne Probleme?- Was sagt GPResult zur Richtlinienübernahme?
Liefere ich nach.- Was sagt nslookup bei der Abfrage nach dem Domänennamen?
Nur die Domäne selbst habe ich noch nicht abgefragt. Aber Hostname/FQDN/IP löst er perfekt auf- Stimmt Datum/Uhrzeit/Zeitzone bei DC/Druckserver/Terminalserver überein?
Ja. Heute kontrolliert. Wird auch alles über Timeserver syncronisiert.> - 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.
Gestern um 22 Uhr ist es noch gegangen - heute um 6:30 Uhr nicht mehr.
Daher konnte ich wieder ein paar Sachen testen
Das löschen alleine hat aber nichts gebracht.
Was bedeutet eigentlich die Meldung "eine schnelle Verbindung wurde entdeckt"? Google liefert dazu gar nichts. Und der Link "Weitere Informationen..." geht nicht.
Die einzelnen GPOs mit Warnungen sehen so aus:
Habe gestern auch noch soweit möglich die neuen Druckertreiber installiert. Das hat aber scheinbar auch nichts gebracht.
Ich habe zwar schon einige, wenige Drucker, für denen es offiziell keine Treiber für Server 2012 gibt. Aber da sind die für Server 2008 installiert und die gingen ja bisher auch ohne Probleme.
Daher konnte ich wieder ein paar Sachen testen
- Tritt das Problem mit einem neuen Benutzerprofil auf?
Ja- 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.
Hab nur die Registry Keys gelöscht. Auf den Neustart vom Spooler habe ich vergessen.NT\CurrentVersion\Printerports zu löschen, Spooler neustarten, nochmal versuchen.
Das löschen alleine hat aber nichts gebracht.
- Was sagt GPResult zur Richtlinienübernahme?
Was bedeutet eigentlich die Meldung "eine schnelle Verbindung wurde entdeckt"? Google liefert dazu gar nichts. Und der Link "Weitere Informationen..." geht nicht.
Die einzelnen GPOs mit Warnungen sehen so aus:
- Was sagt nslookup bei der Abfrage nach dem Domänennamen?
geht ohne Probleme.Was auch helfen kann ist z. B. DCDiag, das Dienstprogramm spuckt noch ein paar Daten zur AD-Gesundheit aus.
Alles bestanden bis auf NSecDesc - und das ist zumindest lt. MS egal.Habe gestern auch noch soweit möglich die neuen Druckertreiber installiert. Das hat aber scheinbar auch nichts gebracht.
Ich habe zwar schon einige, wenige Drucker, für denen es offiziell keine Treiber für Server 2012 gibt. Aber da sind die für Server 2008 installiert und die gingen ja bisher auch ohne Probleme.
> > - 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.
Am besten vergleichen mit einem funktionierenden Printserver, z. B. bei einer anderen Umgebung..
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.
Am besten vergleichen mit einem funktionierenden Printserver, z. B. bei einer anderen Umgebung..
Leider habe ich nur eine Umgebung bei uns im Unternehmen.
Habe mir jetzt am SRV1 mittels "setspn -L SRV1" eine Liste aller SPNs ausgegeben. Auf was soll ich da jetzt genau achten?
- 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?
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?
Wie genau darf ich das genau verstehen:
Ich richte einen Ordner auf SRV1 ein, auf den der TerminalServer Zugriff hat. Und anschließend probiere ich es dann mittels psexec?
Danke
Patrick
Richtig, das Computerkonto des Terminalservers braucht Leseberechtigungen auf die Freigabe. Und mit psexcec versuchst du, ob du per Kommandozeile problemlos auf den Share (nun mit den Berechtigungen des Computerkontos) zugreifen kannst.
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?
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."
Nur mit Alias gehts.
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.
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.
Sind alle genau so vorhanden.
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?
{D4C2CD04-D924-486A-A9D8-90B5CB163B01}: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?
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 CSE Policy:
automatisch erstellt vom SBS.
führt einige exe (z.b. sbslogon.exe, clientagentx86.msi) aus sowie ClientAgent.vbs
- 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.
\\domänenname\sysvol\domänenname\Policies mit der lokalen Kopie c:\Windows\SYSVOL\domain\Policies vergleichst.
Sind ident!
- Verteilst du die Drucker per Computerkonfiguration oder Benutzerkonfiguration? Bei freigegebenen Druckern macht die Verteilung
per Benutzerkonfiguration Sinn, bei lokalen Druckern die Verteilung per Computerkonfiguration.
Sind alle Netzwerkdrucker und werden über die Benutzerkonfiguration verteiltper 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"?
Einstellungen -> Systemsteuerungseinstellungen -> DruckerWindows-Einstellungen -> Bereitgestellte Drucker?
- Falls über die Systemsteuerungseinstellungen, steht dort als Aktion "Erstellen" oder "Ersetzen"?
Ich habe die Einstellungen Löschen bzw. aktualisieren gesetzt.
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?
Werde ich noch probieren.- 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?
Und die Schlinge wird schön langsam enger :
Heute um 04:30 Uhr geplanter Neustart des Terminalservers. Um 06:30 Uhr ging dann wieder mal nichts.
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??
DANKE dir recht, recht herzlich loonydeluxe für deine ganzen Mühen!
:Heute um 04:30 Uhr geplanter Neustart des Terminalservers. Um 06:30 Uhr ging dann wieder mal nichts.
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??
DANKE dir recht, recht herzlich loonydeluxe für deine ganzen Mühen!
{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"
{13180A53-DB09-4719-9D2A-A8B40E5FC3B3}:
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
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 CSE Policy:
automatisch erstellt vom SBS.
führt einige exe (z.b. sbslogon.exe, clientagentx86.msi) aus sowie ClientAgent.vbs
Passt jetzt zwar nicht ganz zum Thema aber trotzdem:
Nachdem ich nun endlich diese GPOs aufräume:
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?
{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...
1Zitat von @loonydeluxe:
> 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??
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.
> 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??
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.
Ich glaube fast nicht, dass es an den RegKeys liegt.
Ich befürchte, dass sich der Spool aufhängt und durch den Neustart dann alles wieder geht.
Aber das werde ich noch genau sehen, wenn es das nächste mal nicht mehr geht. Ich befürchte, dass wird bald wieder sein.
Werde dann nur den Spooler neu starten und dann sehen, ob dann alles wieder geht.
Aber was genau macht der Spooler alles?
Ich befürchte wirklich einen defekten Treiber....
Danke auch für die restlichen Tipps bez. KB/GPOs usw. Werde ich installieren/anschauen.
Nach einiger Zeit muss ich mich hier jetzt auch wieder Stellung dazu nehmen:
Seit dem installieren vom KB2775511 ist dieses Problem nicht wieder aufgetreten. Mag jetzt auch Zufall sein, dass es bis jetzt ging.
Aber sieht auf jeden Fall schon mal alles sehr gut aus.
Habe daher auch nun diesen Thread als gelöst markiert!
Danke dir loonydeluxe für deine Mühen!
Seit dem installieren vom KB2775511 ist dieses Problem nicht wieder aufgetreten. Mag jetzt auch Zufall sein, dass es bis jetzt ging.
Aber sieht auf jeden Fall schon mal alles sehr gut aus.
Habe daher auch nun diesen Thread als gelöst markiert!
Danke dir loonydeluxe für deine Mühen!
Wie weiter oben beschrieben löste das KB2775511 das Problem für einige Zeit.
Leider eben nur für einige Monate. Wie aus dem Nichts tauchte dieses Problem immer wieder auf.
Nach sehr viel Spielerei ist nun das Problem wieder behoben.
Ich änderte die RegKeys vom KB2492632 sowie entfernte ich die HP Dienste "Net Driver HPZ12" und "Pml Driver HPZ12" sowohl auf dem TS als auch auf den DC.
Was genau von diesen beiden Einstellungen das Problem behoben hat, kann ich nicht sagen. Aber ich vermute sehr stark, dass die HP Dienste schuld hatten.
EDIT:
Auch das war leider nur eine "Lösung" für 2 Wochen.
Werde posten, was weiter rauskommt.
Leider eben nur für einige Monate. Wie aus dem Nichts tauchte dieses Problem immer wieder auf.
Ich änderte die RegKeys vom KB2492632 sowie entfernte ich die HP Dienste "Net Driver HPZ12" und "Pml Driver HPZ12" sowohl auf dem TS als auch auf den DC.
Was genau von diesen beiden Einstellungen das Problem behoben hat, kann ich nicht sagen. Aber ich vermute sehr stark, dass die HP Dienste schuld hatten.
EDIT:
Auch das war leider nur eine "Lösung" für 2 Wochen.
Werde posten, was weiter rauskommt.
Nach über einem Jahr konnte ich das Problem nun lösen:
Beide installierten Server liefen auf einem Hyper-V Server.
Hyper-V selbst war auf einem Server 2012 installiert.
Ich habe nun einen neuen Server 2012R2 installiert und dabei auch gleich die Firmware von der Netzwerkkarte aktualisiert.
Seither läuft alles ohne Probleme!
Beide installierten Server liefen auf einem Hyper-V Server.
Hyper-V selbst war auf einem Server 2012 installiert.
Ich habe nun einen neuen Server 2012R2 installiert und dabei auch gleich die Firmware von der Netzwerkkarte aktualisiert.
Seither läuft alles ohne Probleme!
