Hallo zusammen,

wir haben gerade ein akutes Problem.

Wir stecken mitten in der Umstellung unserer Infrastruktur.
Hierzu bauen wir ein Parallelsystem auf VMware auf und haben hier nun 3 Terminalserver installiert welche als Memberserver in der Domäne sind. Seit gestern jedoch scheinen sie sich nciht mehr mit der Domäne zu verstehen.

Versuche ich z.B. einem Dömanen-Benutzer zu erlauben eine RDP Verbindung aufzubauen, so kommt der Dialog hoch wo ich den Usernamen eingebe und der Pfad zeigt automatisch auf den FQDN. Sage ich ihm nun er möchte bitte den Benutzernamen überprüfen so fragt er mich nach einer Authentifizierung für die Domäne in der er Member ist. Habe ich mich authentifiziert so fügt er den Benutzer hinzu, hat allerdings ein Fragezeichen davor. Schließe ich nun den Dialog ist der gerade hinzugefügte Benutzer aus der Liste verschwunden.

Ein Neueinbinden in die Domäne bringt hier leider keine Besserung. Das einzige was dieser Tage auf den Systemen geändert wurde ist die Installation von Datev auf allen TS Servern durch einen Datev Zertifizierten Externen Dienstleister. Den konnte ich bisher noch nicht erreichen.

Ein nslookup auf dem Meber zeigt mir erfolgreich den DC an.

Wo und wie kann ich noch nach Fehlern suchen?!

Moin,

hier gab es kürzlich ein sehr ähnliches Problem, am Schluss stellte sich heraus, dass der bzw. Die terminalserver ohne anschliesendes sysprep geklont waren. Wie hast du die virtuellen Kisten bereitgestellt?

Hi,

die Server wurden durch ein VMware Template verteilt aber alle mit sysprep behandelt. Wir haben gestern bereits das sysprep noch einmal auf einer der Maschinen durchgeführt leider ohne Erfolg.

Nun haben wir parallel noch ein Ticket bei MS aufgemacht und lassen gerade Diagnosetools laufen um diese an MS zu reporten, da die den Fehler offensichtlich auch noch nicht zu kennen scheinen.

Wenn die Maschinen durch ein VMware Template samt Customization Specification bereitgestellt wurden, dann wurde ein Sysprep durchgeführt. Ein erneutes Sysprep ist daher nicht notwendig und würde auch den Fehler nicht beheben. Ich tippe auf ein Problem mit dem Active Directory. Mal sehen was Microsoft so findet...

Jepp da bin ich auch mal gespannt. Laut DC Diag scheint mir die AD aber sauber (sie ist ja auch noch frisch). DNS läuft auch rund. Ich habe irgendwie die Datev Installation im Verdacht da hier auch GPOs gesetzt wurden. Ein deaktivieren bringt aber auch keine Besserung.

Habt ihr Datev mit auf dem DC laufen?

Was sollen die GPOs damit zu tun haben, dass die Kisten nicht sauber im AD hängen?

Hast du mal per setspn geschaut, ob du saubere Tickets bekommst?

Nein, Datev läuft nur auf den TS nicht auf dem DC.

Keine Ahnung was in den GPOs definiert ist. Zumal der Fehler ja von heute auf Morgen auftrat und vor der Datev Installation kein einziges Mal der Fall war bis dahin liefen die Kisten wochenlang sauber.

Was SPN angeht muss ich gestehen habe ich die Funktion vorher nicht gekannt. Laut dem Artikel von MS scheint aber alles sauber zu sein.
Kannst ja selber gern mal schauen:

Code:

C:\Users\Administrator>setspn -l hendusdc01
Registrierte Dienstprinzipalnamen (SPN) für CN=HENDUSDC01,OU=Domain Controllers,
DC=xxx,DC=grp:
        exchangeAB/HENDUSDC01.xxx.grp
        exchangeAB/HENDUSDC01
        ldap/HENDUSDC01.xxx.grp/ForestDnsZones.xxx.grp
        ldap/HENDUSDC01.xxx.grp/DomainDnsZones.xxx.grp
        TERMSRV/HENDUSDC01
        TERMSRV/HENDUSDC01.xxx.grp
        Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/HENDUSDC01.xxx.grp
        DNS/HENDUSDC01.xxx.grp
        GC/HENDUSDC01.xxx.grp/xxx.grp
        RestrictedKrbHost/HENDUSDC01.xxx.grp
        RestrictedKrbHost/HENDUSDC01
        HOST/HENDUSDC01/xxx
        HOST/HENDUSDC01.xxx/xxx
        HOST/HENDUSDC01
        HOST/HENDUSDC01.xxx.grp
        HOST/HENDUSDC01.xxx.grp/xxx.grp
        E3514235-4B06-11D1-AB04-00C04FC2DCD2/ec52d281-61ac-430b-91b3-fe07d0d37c6
6/xxx.grp
        ldap/HENDUSDC01/xxx
        ldap/ec52d281-61ac-430b-91b3-fe07d0d37c66._msdcs.xxx.grp
        ldap/HENDUSDC01.xxxs.grp/xxx
        ldap/HENDUSDC01
        ldap/HENDUSDC01.xxx.grp
        ldap/HENDUSDC01.xxx.grp/xxx.grp

Oben steht was von TERMSRV das war einem Kollegen schon aufgefallen. Es gab aber nie eine Maschine mit diesem Namen.

Das ist auch ein Hostname, sondern ein Service Principal.

So,

also laut MS sind es in der Tat die gleichen SIDs trotz Sysprep.

Wir haben nun eine Anleitung erhalten, wie wir Sysprep über die Konsole ausführen können. Zack: alles gut


Danke Euch für Eure Hilfestellungen!