8
Domainübergreifendes netlogon script ausführen
Hallo zusammen,
hoffentlich kann mir hier jemand Helfen.
Ich suche eine Möglichkeit wie ich Domainübergreifend ein Login Script ausführen kann.
Zur Eklärung wir haben die Domain "alt" und die Domain "neu". Die Server sind in der Domain neu und die User in der Domain alt. Und wenn sich die User an der Domain neu anmelden zieht das Login Script was im AD von alt dem User zugeordnet ist (Profile -> Logon script).
Die User sind in die Domain neu mit Hilfe von Quest Migration "hoch syncronisiert" dabei wird die SID geändert (der Anmeldenamen der User ändert sich) und der User bleibt deaktiviert in der Domain neu.
Ich hab schon probiert die Scripts (einfache Batchdatei) in das sysvol der Domain neu zu kopieren. Hat leider nix gebracht.
Jemand von euch ne Idee wie ich das lösen könnte?
Danke!
Gruß
Lukas
hoffentlich kann mir hier jemand Helfen.
Ich suche eine Möglichkeit wie ich Domainübergreifend ein Login Script ausführen kann.
Zur Eklärung wir haben die Domain "alt" und die Domain "neu". Die Server sind in der Domain neu und die User in der Domain alt. Und wenn sich die User an der Domain neu anmelden zieht das Login Script was im AD von alt dem User zugeordnet ist (Profile -> Logon script).
Die User sind in die Domain neu mit Hilfe von Quest Migration "hoch syncronisiert" dabei wird die SID geändert (der Anmeldenamen der User ändert sich) und der User bleibt deaktiviert in der Domain neu.
Ich hab schon probiert die Scripts (einfache Batchdatei) in das sysvol der Domain neu zu kopieren. Hat leider nix gebracht.
Jemand von euch ne Idee wie ich das lösen könnte?
Danke!
Gruß
Lukas
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: 333385
Url: https://administrator.de/contentid/333385
Ausgedruckt am: 25.11.2024 um 09:11 Uhr
8 Kommentare
Neuester Kommentar
Hallo Lukas,
Gruß,
Dani
Ich hab schon probiert die Scripts (einfache Batchdatei) in das sysvol der Domain neu zu kopieren. Hat leider nix gebracht.
das ist kein technisches Problem, sondern organisatorisch - meine Meinung. Das Verhalten ist völlig normal... was möchtest du eigentlich erreichen?Gruß,
Dani
Hi,
das Loginscript, welches direkt am Benutzerobjekt eingetragen ist, muss immer im Netlogon der Domäne des Benutzers liegen, wenn es ohne Pfad angegeben wird. Wenn es mit vollständigen Pfad angegen ist, dann kann es meines Wissens auch woanders liegen.
Also am Benutzerobjekt in der alten Domäne den Scriptpfad vollständig eingeben.
Oder im Netlogon der neuen Domäne einen Symbolic Link für dieses Script erstellen (z.B. mit Bordmittel MKLINK), welcher auch das alte Script verweist. Sowas habe ich aber nich nie probiert.
Oder das Script beim User raus und statt dessen per GPO-Loginscript ausführen.
E.
das Loginscript, welches direkt am Benutzerobjekt eingetragen ist, muss immer im Netlogon der Domäne des Benutzers liegen, wenn es ohne Pfad angegeben wird. Wenn es mit vollständigen Pfad angegen ist, dann kann es meines Wissens auch woanders liegen.
Also am Benutzerobjekt in der alten Domäne den Scriptpfad vollständig eingeben.
Oder im Netlogon der neuen Domäne einen Symbolic Link für dieses Script erstellen (z.B. mit Bordmittel MKLINK), welcher auch das alte Script verweist. Sowas habe ich aber nich nie probiert.
Oder das Script beim User raus und statt dessen per GPO-Loginscript ausführen.
E.
Zitat von @Dani:
Hallo Lukas,
Gruß,
Dani
Hallo Lukas,
Ich hab schon probiert die Scripts (einfache Batchdatei) in das sysvol der Domain neu zu kopieren. Hat leider nix gebracht.
das ist kein technisches Problem, sondern organisatorisch - meine Meinung. Das Verhalten ist völlig normal... was möchtest du eigentlich erreichen?Gruß,
Dani
Es geht drum das die User in der alten Domain noch Netzwerkfreigaben per Login Batch bekommen net use X: \\nas1.altedomain.local\freigabe
aber da sie sich an einem Server server1.neuedomain.local anmelden müsste meines Verständnis nach die Policy aus neuedomain/sysvol... und nicht altedomain/sysvol... ziehen.
Zitat von @emeriks:
Hi,
das Loginscript, welches direkt am Benutzerobjekt eingetragen ist, muss immer im Netlogon der Domäne des Benutzers liegen, wenn es ohne Pfad angegeben wird. Wenn es mit vollständigen Pfad angegen ist, dann kann es meines Wissens auch woanders liegen.
Also am Benutzerobjekt in der alten Domäne den Scriptpfad vollständig eingeben.
Oder im Netlogon der neuen Domäne einen Symbolic Link für dieses Script erstellen (z.B. mit Bordmittel MKLINK), welcher auch das alte Script verweist. Sowas habe ich aber nich nie probiert.
Oder das Script beim User raus und statt dessen per GPO-Loginscript ausführen.
E.
Hi,
das Loginscript, welches direkt am Benutzerobjekt eingetragen ist, muss immer im Netlogon der Domäne des Benutzers liegen, wenn es ohne Pfad angegeben wird. Wenn es mit vollständigen Pfad angegen ist, dann kann es meines Wissens auch woanders liegen.
Also am Benutzerobjekt in der alten Domäne den Scriptpfad vollständig eingeben.
Oder im Netlogon der neuen Domäne einen Symbolic Link für dieses Script erstellen (z.B. mit Bordmittel MKLINK), welcher auch das alte Script verweist. Sowas habe ich aber nich nie probiert.
Oder das Script beim User raus und statt dessen per GPO-Loginscript ausführen.
E.
Per GPO wärs einfacher die könnte ich fix ändern oder neu anlegen. Das mit dem Symbolic Link hört sich interesant an oder kann ich das irgendwie scripten das eben nicht neuedomain/sysvol... abgefragt wird sondern altedomain/sysvol... also ohne jeden User händisch zu ändern.
Es hapert schon mal an der Sprache/den Begriffen ...
Es geht drum das die User in der alten Domain noch Netzwerkfreigaben per Login Batch bekommen net use X: \\nas1.altedomain.local\freigabe
In der neuen Domäne dann wie?aber da sie sich an einem Server server1.neuedomain.local anmelden müsste meines Verständnis nach die Policy aus neuedomain/sysvol... und nicht altedomain/sysvol... ziehen.
Am Server anmelden? Ich denke Domäne?Die User sind in die Domain neu mit Hilfe von Quest Migration "hoch syncronisiert"
Was heißt das eigentlich? Warum, und wie, und wie lange noch? Wer hat das eigerichtet? Was sagt diese Person/Firma dazu? Diese muss doch einen Plan gehabt haben?!
Sorry, ist bisschen kompliziert und auch die umgangssprachlichen Begrifflichkeiten in richtige Fachsprache zu übersetzen ist manchmal schwer, ich hab auch lange gebraucht da halbwegs mit klar zu kommen.
Wir haben 3 Domains aus denen mal eine werden soll. Also quasi 2 alte die zu einer neuen wird. Trust besteht.
Alle neu erstellten Server kommen auch in die neue Domain somit auch die neue XenDesktop Umgebung.
Eine der alten Domains hat ihren CIFS Daten Umzug schon hinter sich bei einer steht er noch aus und ausgerechnet diese Domain mit den alten Struktur soll als erstes mit XenDesktop arbeiten. Aber um die User nicht zu arg zu verwirren sollen sie sich noch mit ihrer bissherigen Anmeldung arbeiten. (Wollte die GL so)
In der neuen Struktur werden die Laufwerke dann per GPO verbunden und es sind auch wesentlich weniger und vor allem einheitlich. Aber der Umzug der Daten aus Domain alt1 dauert noch weil alles so wild durcheinander ist (selbst die Home Folder haben eine eigene Freigabe auf der Netapp).
Die Migration durch Quest war im wesentlichen wegen der Exchange Postfächer da diese auch schon in der neuen Domain sind.
Soweit funktioniert auch eigentlich alles bis eben das Login Script und dafür muss ich die nächsten Tage eine Lösung finden da ich bis ende Q1 fertig sein soll.
Wir haben 3 Domains aus denen mal eine werden soll. Also quasi 2 alte die zu einer neuen wird. Trust besteht.
Alle neu erstellten Server kommen auch in die neue Domain somit auch die neue XenDesktop Umgebung.
Eine der alten Domains hat ihren CIFS Daten Umzug schon hinter sich bei einer steht er noch aus und ausgerechnet diese Domain mit den alten Struktur soll als erstes mit XenDesktop arbeiten. Aber um die User nicht zu arg zu verwirren sollen sie sich noch mit ihrer bissherigen Anmeldung arbeiten. (Wollte die GL so)
In der neuen Struktur werden die Laufwerke dann per GPO verbunden und es sind auch wesentlich weniger und vor allem einheitlich. Aber der Umzug der Daten aus Domain alt1 dauert noch weil alles so wild durcheinander ist (selbst die Home Folder haben eine eigene Freigabe auf der Netapp).
Die Migration durch Quest war im wesentlichen wegen der Exchange Postfächer da diese auch schon in der neuen Domain sind.
Soweit funktioniert auch eigentlich alles bis eben das Login Script und dafür muss ich die nächsten Tage eine Lösung finden da ich bis ende Q1 fertig sein soll.
OK. Die Anwender melden sich also am TS, welcher zur neuen Domäne (neue Gesamtstruktur/Forest) gehört, mit ihren Konten aus einer der alten Domänen (alte Gesamtstruktur/Forest) an. Habe ich das so richtig verstanden?
Falls ja, dann liegt es wohlmöglich daran:
Standardmäßig ist die Ausführung von gesamtstrukturübergreifenden Benutzer-Loginscripten nicht erlaubt.
Bsp:
Forest: Forest_F1
Domain: Domain_F1_D1
User: Domain_F1_D1\User1
Forest: Forest_F2
Domain: Domain_F2_D1
Computer: Domain_F2_D1\Computer1
Wenn sich Domain_F1_D1\User1 an Domain_F2_D1\Computer1 anmeldet, dann ist die Ausführung des am Benutzerobjekt Domain_F1_D1\User1 eingetragenen Loginscripts nicht erlaubt. Standardmäßig. Weil verschiedene Forest.
Lösung:
GPO für das Computerobjekt des TS wirken lassen.
Computereinstellungen - Richtlinien - System - Gruppenrichtlinien - Gesamtstrukturübergreifende Benutzerrichtlinien und servergespeicherte Benutzerprofile zulassen
(Hier steht zwar nur was von Richtlinien und Profilen, aber dahinter verbirgt sich auch das mit dem Benutzer-Loginscripten.)
GPO's auf dem TS aktualisieren (gpupdate)
Kontrollieren, ob GPO angewendet wurde (gpresult /r)
Benutzer neu anmelden --> jetzt sollte das Script ausgeführt werden.
E.
Falls ja, dann liegt es wohlmöglich daran:
Standardmäßig ist die Ausführung von gesamtstrukturübergreifenden Benutzer-Loginscripten nicht erlaubt.
Bsp:
Forest: Forest_F1
Domain: Domain_F1_D1
User: Domain_F1_D1\User1
Forest: Forest_F2
Domain: Domain_F2_D1
Computer: Domain_F2_D1\Computer1
Wenn sich Domain_F1_D1\User1 an Domain_F2_D1\Computer1 anmeldet, dann ist die Ausführung des am Benutzerobjekt Domain_F1_D1\User1 eingetragenen Loginscripts nicht erlaubt. Standardmäßig. Weil verschiedene Forest.
Lösung:
GPO für das Computerobjekt des TS wirken lassen.
Computereinstellungen - Richtlinien - System - Gruppenrichtlinien - Gesamtstrukturübergreifende Benutzerrichtlinien und servergespeicherte Benutzerprofile zulassen
(Hier steht zwar nur was von Richtlinien und Profilen, aber dahinter verbirgt sich auch das mit dem Benutzer-Loginscripten.)
GPO's auf dem TS aktualisieren (gpupdate)
Kontrollieren, ob GPO angewendet wurde (gpresult /r)
Benutzer neu anmelden --> jetzt sollte das Script ausgeführt werden.
E.
Dankeschön!
Diese Policy hab ich auch schon probiert hat aber leider nicht geholfen und ist auch eher kontraproduktiv da wir in der alten Domain User Policys für Drucker haben die nicht ziehen sollen.
Nach langer Diskusion und Beratung durch den Konsultant sind wir jetzt aber zu dem Entschluss gekommen die User sich mit den Konten der neuen Domain anmelden zu lassen. Neue Umgebung, neuer Login lies sich dann doch halbwegs überzeugend Verkaufen und früher oder später kommt es eh auf die User zu. Somit haben wir das Problem nicht mehr. Einfach die Batch Files von DomAlt\Netlogon nach DomNeu\Netlogon kopiert und siehe da es werden die gewünschten Lauwerke gemappt. Und auch gelegentliche Outlook <-> Exchange Probleme z.B. mit Kalender Berechtigung sind dadurch erschlagen da diese Multidomainumgebungskombination auch hier Probleme gemacht hat.
Trotzdem Vielen Dank!
Diese Policy hab ich auch schon probiert hat aber leider nicht geholfen und ist auch eher kontraproduktiv da wir in der alten Domain User Policys für Drucker haben die nicht ziehen sollen.
Nach langer Diskusion und Beratung durch den Konsultant sind wir jetzt aber zu dem Entschluss gekommen die User sich mit den Konten der neuen Domain anmelden zu lassen. Neue Umgebung, neuer Login lies sich dann doch halbwegs überzeugend Verkaufen und früher oder später kommt es eh auf die User zu. Somit haben wir das Problem nicht mehr. Einfach die Batch Files von DomAlt\Netlogon nach DomNeu\Netlogon kopiert und siehe da es werden die gewünschten Lauwerke gemappt. Und auch gelegentliche Outlook <-> Exchange Probleme z.B. mit Kalender Berechtigung sind dadurch erschlagen da diese Multidomainumgebungskombination auch hier Probleme gemacht hat.
Trotzdem Vielen Dank!
