Jump to content

y-z-Vertauschung mit kopierten Benutzerprofilen


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar
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.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...