badger
Goto Top

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

Content-Key: 222520

Url: https://administrator.de/contentid/222520

Ausgedruckt am: 29.03.2024 um 08:03 Uhr

Mitglied: loonydeluxe
loonydeluxe 20.11.2013 um 22:04:22 Uhr
Goto Top
- 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?
Mitglied: Badger
Badger 20.11.2013 um 22:24:54 Uhr
Goto Top
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:

- 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.

- 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.

- 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.

- 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.

- 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.
Mitglied: loonydeluxe
loonydeluxe 20.11.2013 um 22:48:15 Uhr
Goto Top
> - 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.

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.

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.
Mitglied: Badger
Badger 21.11.2013 aktualisiert um 08:47:50 Uhr
Goto Top
Gestern um 22 Uhr ist es noch gegangen - heute um 6:30 Uhr nicht mehr.
Daher konnte ich wieder ein paar Sachen testen face-smile

- 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.
Das löschen alleine hat aber nichts gebracht.

- Was sagt GPResult zur Richtlinienübernahme?
21d6afec5d0ce0ebfd822183dd1e4374

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:
8ad2a7dfd9627e6ab0e73ca3c57784bb

ed7248f52b9ae9eef202f2fc7da98cb7

0f9a71a31df6dc13e32cb2ca7990bc29

- 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.
Mitglied: Badger
Badger 21.11.2013 um 08:42:22 Uhr
Goto Top
> > - 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..

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?
Mitglied: Badger
Badger 21.11.2013 um 08:47:28 Uhr
Goto Top
- 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?

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
Mitglied: loonydeluxe
loonydeluxe 21.11.2013 um 19:08:33 Uhr
Goto Top
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.
Mitglied: loonydeluxe
loonydeluxe 21.11.2013 aktualisiert um 19:40:52 Uhr
Goto Top
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.
Mitglied: loonydeluxe
loonydeluxe 21.11.2013 um 19:39:16 Uhr
Goto Top
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?
Mitglied: Badger
Badger 22.11.2013 um 11:27:04 Uhr
Goto Top
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.

Sind alle genau so vorhanden.
Mitglied: Badger
Badger 22.11.2013 um 11:43:53 Uhr
Goto Top
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}:
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.

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 verteilt

- 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 -> Drucker

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.
Mitglied: Badger
Badger 22.11.2013 um 11:47:31 Uhr
Goto Top
Und die Schlinge wird schön langsam enger face-smile :
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!
Mitglied: Badger
Badger 22.11.2013 um 12:14:59 Uhr
Goto Top
{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

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?
Mitglied: loonydeluxe
loonydeluxe 22.11.2013 um 18:57:41 Uhr
Goto Top
{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

Achso, nur so'n Zeug face-smile 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).
Mitglied: loonydeluxe
loonydeluxe 22.11.2013 um 19:04:03 Uhr
Goto Top
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.


DANKE dir recht, recht herzlich loonydeluxe für deine ganzen Mühen!

Gern geschehen!
Mitglied: loonydeluxe
loonydeluxe 22.11.2013 um 19:06:11 Uhr
Goto Top
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?

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.
Mitglied: loonydeluxe
loonydeluxe 22.11.2013 um 19:12:23 Uhr
Goto Top
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."

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.
Mitglied: loonydeluxe
loonydeluxe 22.11.2013, aktualisiert am 12.06.2014 um 11:16:11 Uhr
Goto Top
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 face-wink 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...
Mitglied: Badger
Badger 22.11.2013 aktualisiert um 23:52:24 Uhr
Goto Top
Zitat 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.

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.
Mitglied: Badger
Badger 09.12.2013 um 19:28:51 Uhr
Goto Top
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!
Mitglied: Badger
Badger 07.05.2014, aktualisiert am 11.05.2014 um 18:42:30 Uhr
Goto Top
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.
Mitglied: Badger
Badger 12.01.2015 um 12:34:24 Uhr
Goto Top
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!