Probleme mit DNS-Alias \printserver trotz sichtbarer Drucker – Verbindung schlägt fehl

[einfachpeer]

Hallo zusammen,
ich habe folgendes Problem mit einem DNS-Alias im Zusammenhang mit Windows-Druckdiensten und Kerberos:

• Zwei Druckserver: printserver1 (aktiv), printserver2 (Reserve)
• DNS-CNAME printserver → printserver1 (um bei Wartung einfach auf printserver2 umzuschalten)
• Aufruf von \printserver zeigt korrekt alle Drucker, die auf printserver1 freigegeben sind
• Aber: Wenn ein Benutzer versucht, sich mit einem Drucker zu verbinden (z. B. \printserver\DruckerXYZ), kommt sofort folgende Fehlermeldung:
  „Es konnte keine Verbindung mit dem Drucker hergestellt werden. Überprüfen Sie den Druckernamen...“
• Aufruf direkt über \printserver1 funktioniert einwandfrei.

Das habe ich bisher rausgefunden

• Kerberos scheint hier eine Rolle zu spielen: Der Client sucht einen SPN für HOST/printserver, dieser ist aber nicht immer korrekt gesetzt.
• In den Logs oder im Event Viewer erscheint kein Eintrag, wenn der Fehler auftritt.
• Auch ServerNameAlias (Registry unter HKLM\SYSTEM\CurrentControlSet\Control\Print) bringt keine Abhilfe.
• Sicherheitsrichtlinien (PointAndPrint, TrustedServers etc.) wurden korrekt gesetzt.
• Virenscanner komplett deaktiviert → keine Besserung
• DNS-Auflösung korrekt (nslookup printserver zeigt auf printserver1)

Frage:
Wie kann man \printserver als funktionierenden Alias für Kerberos-basierten Druckzugriff konfigurieren, ohne auf jedem Client Registry- oder Gruppenrichtlinienänderungen vorzunehmen?


Ideal wäre eine zentrale Lösung, bei der:

• Clients den Alias \printserver nutzen können
• Druckserver im Hintergrund (via DNS) ausgetauscht werden können
• Kerberos funktioniert, ohne manuelle SPN-Pflege auf den Zielservern

Bin für jeden Hinweis dankbar – gerne auch Erfahrungsberichte, wer sowas mit Failover erfolgreich umsetzt.


Viele Grüße

Peer

---

Checkliste / Was bereits gemacht wurde:

• DNS-CNAME printserver → printserver1 eingerichtet
• DNS-Namensauflösung via nslookup funktioniert korrekt
• Aufruf von \printserver zeigt Drucker
• Verbindung mit Drucker über \printserver\xyz schlägt direkt fehl
• Direkter Zugriff über \printserver1 funktioniert
• ServerNameAlias in Registry unter HKLM\SYSTEM\CurrentControlSet\Control\Print gesetzt
• Druckerspooler-Dienst neu gestartet
• Gruppenrichtlinie für PointAndPrint konfiguriert (InForest, TrustedServers, etc.)
• SPNs überprüft (setspn -L printserver1)
• Versuch: Dummy-Computerobjekt printserver im AD angelegt (inkl. Delegierung & SPNs)
• Rückgängig gemacht – Verbindung ging danach gar nicht mehr
• Kerberos-Cache am Client gelöscht (klist purge)
• Manuelle Druckeranmeldung über rundll32 printui.dll,PrintUIEntry /in ... getestet
• Druckerfreigaben in GUI sichtbar, aber Verbindung schlägt fehl
• Event-Log geprüft → keine Einträge
• Virenschutz temporär deaktiviert
• Fokus liegt auf Serverseite, Client wurde nicht verändert

 

[pumuck|]

• Zwei Druckserver: printserver1 (aktiv), printserver2 (Reserve)
• DNS-CNAME printserver → printserver1 (um bei Wartung einfach auf printserver2 umzuschalten)

Kerberos tickt da etwas anders. Am Besten schaust du dir das hier mal an
https://www.msxfaq.de/netzwerk/grundlagen/cname_vs_arecord.htm#kerberos

 

[luckysh0t]

Also Perplexity schlägt folgende Punkte vor

Bekannte Lösungsansätze

1. Registry-Eintrag auf dem Druckserver anpassen (Hope This Helps - IT Tipps die das Leben einfacher machen)
   Auf dem Druckserver muss der Schlüssel
   HKLM\SYSTEM\CurrentControlSet\Control\Print\DnsOnWire vom Typ DWORD auf den Wert 1 gesetzt werden.
   Dies sorgt dafür, dass der Druckspooler den DNS-Alias korrekt im Kerberos-Ticket verwendet und die Aliasnamen akzeptiert werden. Nach dem Setzen muss der Druckspooler-Dienst neu gestartet werden.
2. SPN (Service Principal Name) korrekt setzen
   Da Kerberos den SPN für den Alias benötigt, kann man versuchen, den SPN für den Alias-Computername im Active Directory zu registrieren. Dies ist aber oft aufwendig und fehleranfällig, vor allem wenn man dynamisch zwischen Druckservern wechseln möchte.
3. ServerNameAlias Registry-Eintrag
   Der Eintrag ServerNameAlias unter HKLM\SYSTEM\CurrentControlSet\Control\Print wird oft empfohlen, bringt aber in vielen Fällen keine Verbesserung.
4. Vermeidung von Client-Seitigen Änderungen
   Das Ziel ist eine zentrale Lösung ohne Client-Registry- oder Gruppenrichtlinienänderungen. Die oben genannte DnsOnWire-Lösung am Druckserver ist hier der praktikabelste Weg, da sie auf Serverseite wirkt und Clients den Alias direkt nutzen können.
5. Keine Dummy-Computerobjekte im AD anlegen
   Versuche, für den Alias einen eigenen Computeraccount im AD mit SPNs anzulegen, führen oft zu weiteren Problemen und sollten vermieden werden.

Manches hast du schon getestet, allerdings steht da auch dabei das es wohl Fehler anfällig ist.
Daher würde ich Punkt 1 testen - davon habe ich bei deinen Versuchen nichts gelesen.

 

[pumuck|]

sorry aber gerade eine LLM setzt bei Detailwissen echte Grundlagen voraus. Zumindest ist das meine Erfahrung.

 

[einfachpeer]

Vielen vielen Dank !!! Die 6h Arbeitszeit hätte ich sparen können haha. Punkt 1 war die Lösung ! Danke

 

[luckysh0t]

Gerne, ich nutze perplexity.ai an sich gerne - hat zwar wie jedes LLM so seine Schwächen, aber wenn man auch noch weiterhin selbst denkt und recherchiert gehts - oder seine Frage anders formuliert ^^