Roaming Profile im Netzwerk bereiten nur Kopfzerbrechen und Probleme

XamBonX

Commander
Registriert
Nov. 2002
Beiträge
2.840
Wir haben eine VM, W12-AD-Profile. Jeder Benutzer der sich in der Domäne anmeldet, holt sich sein Profil von \\W12-AD-Profile\Profil\TestUser .

Hat bisher wunderbar funktioniert. Chef hat WServer 12 auf 19 geupdatet. Hat alles wunderbar funktioniert. Chef wollte die Maschine nun auch richtig und neutral bennen. Vorher hieß die Maschine W12-AD-Profile.domäne.lan, nun heißt die Maschine AD-Profile.domäne.lan .

Auf dem DC1 haben wir DNS Einträge für W12-AD-Profile, W19-AD-Profile und AD-Profile, welche alle 3 auf die IP von der Profile-VM verweisen.

Ping an alle 3 Maschinen löst die richtige IP auf.

Jetzt haben wir testweise eine Gruppe an Benutzer auf dem DC in den Eigenschaften die Profil von W12-AD-Profile\Profile\TestUser auf AD-Profile\Profile\TestUser geändert (TestUser halt immer durch den relevanten User ersetzt natürlich).

Nun luppt gar nix. Profile können nicht abgerufen werden, und es wird immer ein TEMP Ordner angelegt.

Immer kommt: https://i.imgur.com/oQ8TffG.png . Man kann ja bei den Benutzern auch das Laufwerk zum Profil verbinden, welches wir so machen: https://i.imgur.com/srK4E9T.png .

BEI jedem der Testbenutzer erscheint das Laufwerk P: mit seinem Profil im Explorer. Man kann darauf zugreifen und darin Browsen. Und dennoch wird immer https://i.imgur.com/oQ8TffG.png angezeigt.

Was ist los?
 
Das hat wahrscheinlich mit der Authentifizierung am Netzwerkshare zu tun. Damit Kerberos funktioniert muss der Share über seinen richtigen FQDN angesprochen werden. Es gibt zwar eine Möglichkeit das auch mit einem Alias laufen zu lassen, aber von der Variante rät selbst Microsoft ab.

Also entweder alles rückgängig machen oder ein DFS aufbauen und die Produkte darauf legen - alles andere macht nur Probleme.
 
  • Gefällt mir
Reaktionen: PHuV
Ein DFS aufbauen... einen voll neuen VM mit Profile-Verzeichniss und diese dann \\neuerVM\Profile\xyz? Oder verstehe ich gerade was falsch?

Kann man den Dreckskerberos nich hinweisen, dass nun neues gilt??

Würde es was bringen, wenn wir den nun umbenannten W19-AD-Profile aus der Domäne nehmen und wieder reinpacken?

sklaes schrieb:
muss der Share über seinen richtigen FQDN angesprochen werden
Es war vorher W12-AD-Profile\Profile\TestUser, als noch alles lief. Nach der Umbenennung ist es nun W19-AD-Profile\Profile\TestUser. Also ist der "richtige" FQDN nun W12-AD-Profile obwohl dieser nicht mehr existiert?

Der Rechner selbst, wo die Profile sind ist halt W19-AD-Profile.domäne.lan . Ob wir nun AD-Profile\Profile\TestUser oder W19-AD-Profile\Profile\TestUser eingeben, macht 0 Unterschied. Gleiche Fehler.
 
Zuletzt bearbeitet:
Was ich bisher nicht ganz verstehe: gibt es eine VM die die Produkte halt oder mehrere?

Wenn es mehrere sind, die sich abgleichen sollen, sollten diese in ein DFS eingebunden werden.

Wenn eine Migration angestrebt ist. Muss sichergestellt sein, dass die User auf den Share zugreifen können:
  • Share permissions setzen
  • Daten mit NTFS Berechtigungen kopieren
  • Zugriff exemplarisch mit 2/3 Usern testen (FQDN verwenden)
  • Profilpfade ändern (FQDN verwenden)

Der FQDN muss der Name sein mit dem sich das System im DNS registriert hat. Bitte keine alias verwenden. DNS Einträge die auf die gleiche IP verweisen sollten vorher entfernt werden. Falsche Reverse lookup Einträge müssen entfernt werden.
 
ich glaube auch dass der Name \\ad-profile Probleme macht. Ich würde da auch den FQDN benutzen und wenn das nicht hilft definitiv auch mal die NTFS Berechtigungen der User Profile checken, dass die richtig sitzen.
 
Moin,

wie sind denn die zusätzlichen DNS-Einträge angelegt?

Die Namensänderung hat auch korrekt im AD funktioniert?
Ist der Domain Controller ebenfalls auf dem einen Server installiert? Ihr hättet damit ja den Domain Controller umbenannt, dabei muss man aber noch ein paar Sachen beachten.

Grüße
 
Zurück
Oben