y-z-Vertauschung mit kopierten Benutzerprofilen

[lefg 276]

Hallo gemeinde,

 

nun habe ich mir etwas eingefangen durch eigens Verschulden.

 

Ich habe Benutzerprofile von einer Domäne zur anderen kopiert, die strenge Eigentümerprüfung per Gruppenrichtlinie abgeschaltet und habe trotzdem das Problem mit der angelsächsischen Tastaur.

 

Jetzt stehe ich unter extremen Druck.

 

Kann mir bitte jamand Rat geben, wie dieses Problem lösbar ist?

 

Die Anwendung von ADMT war leider nicht möglich, es meldete Fehler verweigerte die Arbeit.

[zahni 554]

Probiere mal

 

CLASS USER

CATEGORY "System"
     CATEGORY "Custom"
CATEGORY "Keyboard Layout"
 		POLICY Preload
 		KEYNAME "Keyboard Layout\Preload"
   		PART 1 EDITTEXT
   		VALUENAME "1"
   		DEFAULT "00000407"
   		END PART
   		PART 2 EDITTEXT
   		VALUENAME "2"
   		DEFAULT "00000409"
   		END PART
 		END POLICY
 		POLICY Toggle
 		KEYNAME "Keyboard Layout\Toggle"
   		PART Hotkey EDITTEXT
   		VALUENAME "Hotkey"
   		DEFAULT "3"
   		END PART
   		PART "Language Hotkey" EDITTEXT
   		VALUENAME "Language Hotkey"
   		DEFAULT "3"
   		END PART
   		PART "Layout Hotkey" EDITTEXT
   		VALUENAME "Layout Hotkey"
   		DEFAULT "3"
   		END PART
 		END POLICY
END CATEGORY
    END CATEGORY

 

-Zahni

[lefg 276]

Danke, mache ich.

[zahni 554]

PS: Die Richlinie wirkt u.U. erst bei der 2. Anmeldung nach der Aktivierung.

 

-Zahni

[lefg 276]

Ich habe da noch ein END CATEGORY angehängt. Ich denke, das ist richtig so.

 

Dann habe ich es in eine lokale Richtlinie eingefügt, ich hoffe, es ist richtig so.

 

Ich habe bisher allerdings keine Erfolg.

 

Was hat das mit dem Hotkey auf sich? Muss da ein Schalter betätigt werden?

 

Ich habe das übrigens an einer 2kWS getestet.

[zahni 554]

Ah ja, sorry. Hatte das hier aus einer grösseren ADM rauskopiert.

 

Das Teil soll eigentlich das deutsche Tastaturlayout fest einstellen und die Hotkeys zum Umschalten deaktivieren. Hier geht es. Ach ja, Die Richtlinie muss natürlich aktiviert werden. Bei den Filtern den Haken bei "nur vollständig verwaltbare..." raus.

 

-Zahni

[zahni 554]

PS: Ob das unter W2K geht, K.A. . Hier benutze ich XP.

 

-Zahni

[lefg 276]

Das mit dem Filter habe ich gemacht.

 

Ich Moment bin ich blockiert, muss ich gestehen. Ich werde deshalb mal in den Entspannungsmodus schalten.

 

Den Usern hab ich signalsiert, sie sollen wieder die alte Domäne benutzen, den Schalter habe ich vorbelegt.

 

Diese Massnahme nimmt erstmal den Druck von mir.

 

Das Problem kommt anscheinend aus der User.dat. Diese stammt aus der alten Domäne wie das Profil. Ich habe mich da total verhauen. Die alten Profile sollten nicht übernommen werden, die User sollten beim Anmelden neue auf der WS bilden. Dann wurde eine nicht abweisbare Bitte an mich herangetragen, ich war total hin.

[Hirgelzwift 10]

Ich verstehe das Problem leider nicht ganz. An welcher Domäne sich die Benutzer anmelden dort einerlei. Beim Anmeldefenster kommt immer der Wert der in HKEY_USERS/.DEFAULT/Keyboard Layout/Preload der unter 1 eingestellt ist.

 

407 = deutsch

409 = englisch

 

Wenn es nun schon ein neues Profil gibt dann musst du wohl oder übel das englische Keyboard oder das Profil löschen und sicher stellen das vor der ersten Anmeldung 407 auf dem Wert 1 steht.

 

Oder lieg ich total neben dem Thema? :D

[zahni 554]

Wenn die Profile auf die neue Domäne kopiert werden, ändert sich dann nicht die SID des Users ? Dann muss dem User Schreibrecht in seiner user.dat erteilt werden.

 

Ich hatte das mal so gemacht:

 

shell "cmd /c dir /B /AD /O-D > dirlist.txt"

open(1,"changeprofiles.log",5)

$dummy = WriteLine( 1 , "Aenderung der Profiles gestartet am " + @DATE + " " + @TIME + Chr(13) + Chr(10) )

close(1)

open(1,"dirlist.txt",2)

$x = ReadLine(1)

WHILE @ERROR = 0

? $X

LoadHive("HKEY_USERS\"+$x, $x+"\ntuser.dat")

if @error=0

shell "setacl Users\"+$x+" /registry /grant "+$x+" /full /r:cont_obj"

ENDIF

unloadhive("HKEY_USERS\"+$x)

$x = ReadLine(1)

LOOP

close(1)

 

Du brauchst http://setacl.sourceforge.net/

und Kix .

 

Prüfe bitte, ob die Parameter von setacl noch stimmen. Hatte das damals mit einer älteren Version gemacht.

 

Das Script wird in der Root des Profilordners auf dem Server ausgeführt. Verzeichnis- und Kontoname müssen gleich sein.

 

-Zahni

[lefg 276]

Ich danke für eure Hilfe.

 

An der Lösung des eigentlichen Problems konnte ich noch garnicht arbeiten.

 

Das Loginscript der alten Domäne musste erstmal wieder laufen.

 

Ich glaubte, wenn sich der User an der alten Domäne anmeldet, müsste auch dessen Login.bat (definiert im Benutzerkonto) abgearbeitet werden. Pustekuchen macht sie nicht.

 

Dann habe ich den Aufruf der Batch (alte Dom) in die Login.bat der neuen Dom eingebaut, nichts tut sich.

 

Dann habe ich in der Root des AD der neuen Dom eine Richtlinie gebaut, den Loopbackverarbeitungsmodus aktiviert und in der Benutzerkonfiguration die Login der ADomän aufgerufen.

 

Nun klappt es.

 

Die leute können sich morgen in der Früh an der alten dom anmelden, erhalten ihre Laufwerke und gut ist es.

 

Das nimmt den Druck jetzt weg, ich fahr einkaufen und eine Runde Karteln.

 

Bis morgen.

 

Edgar

[lefg 276]

Ich verstehe das Problem leider nicht ganz.

Ich schildere mal die History.

 

Eine fehlerhafte 2k3-Domäne (Lubeca) solle durch eine neue (2Lubeca) ersetzt werden. Der Fehler ist ein Problem mit dem GC. Der Fehler stammt schon von 2k-OS.

 

Der DC von 2Lubeca wurde installiert, die gegenseitige Vertrauensstellung hergestellt. Ein Migrieren mit ADMT 3.0 schlug fehl.

 

Also war Handarbeit angesagt.

 

Die Computer wechselten per Skript (netdom) die Domänezugehörigkeit , das ging auch eigentlich sehr schön.

 

Die Benutzer- und Gruppenkonten, Profil-, Home-und Gruppenverzeichnisse wurden per Batch angelegt.

 

Es war mir bekannt, mit von einer zur anderen Domäne kopierten Benutzerprofilen gibt es Probleme. Ein auffälliges ist dabei die Voreinstellung der angelsächsischen Tastatur. Weiter geschieht der Anmeldevorgang und das Laden eines servergespeicherten Profils sehr langsam. Das mag bei einem P4 nicht auffallen, bei einem P3 mit 128MB ist es bemerkbar.

 

Deshalb sollten die die Profile der alten Domäne auch nicht in die neue übernommen werden, es solten neue entstehen. Die Inhalte der Homeverzeichnisse wurden per Batch kopiert.

 

Ich wurde von einer aussergewöhnlich schönen und charmanten Frau gebeten, die Verwendung der alten Profile möglich zu machen. Mir war in der Gruppenrichtlinie die Möglichkeit bekannt, die auf strenge Prüfung des Besitzverhältnisses von Profilen zu verzichten.

 

Nun, dachte ich (habe ich gedacht?, nein, gefühlt, mein Hormonpegel stand unter der Schädeldecke), das machste.

 

Und es schien auch so, bei einem Test(?), dann kam die erste Fehlermeldung gestern Nachmittag, ich war mit im Hörsaal. Also Kommando zurück, Anmeldung erfolgt wieder an der alten Domäne (Lubeca).

 

Dort trat bei der Anmeldung von Testusern ein für mich neues Phänomenen auf. Die Loginbatch von Lubeca wurde nicht mehr verarbeitet. RSOP zeigte aber, es werden die Richtlinen von 2Lubeca behandelt. Also wurde in 2Lubeca eine Richtlinie angelegt, zum Aufruf der Login.bat von Lubeca. In der Root wurde eine Richtline angelegt, der Loopbackverarbeitungsmodus aktiviert und die Batch in der Benutzerkonfiguration als Startskript eingebunden. Das funktionierte auch gestern abend.

 

Die User und Dozenten wurden per Bildschirmnachricht vor der Anmeldung gebeten, sich an Lubeca anzumelden, der Auswahlschalter wurde dafür vorbelegt. Bisher habe ich keine Negativmeldungen.

 

Festgestellt habe ich wieder, die Leute lesen die Nachricht auf dem Prelogin-Screen nicht.

[lefg 276]

Wenn die Profile auf die neue Domäne kopiert werden, ändert sich dann nicht die SID des Users ? .

Genau, das ist ist mir ja auch bekannt.

Dann muss dem User Schreibrecht in seiner user.dat erteilt werden

Ich werde mir das gleich mal mit einem klareren Blick nochmals anschauen.

[lefg 276]

Ich habe nur mit dem Explorer mal die Eigenschaften der Ordner und Dateien im Profil angeschaut. Demnach hat der Benutzer Vollzugriff auf alles, ist aber nicht Besitzer.

 

Ich werde mal prüfen, ob eine Änderung des Besitzes eine Änderung des Verhaltens ergibt.

[zahni 554]

Es geht mir um die ACL in der Registry, nicht um die NTFS-Rechte.

 

-Zahni