ntconfig.pol im NETLOGON-Verzeichnis von SLSS-Samba
Hallo, bis vor zwei Tagen hatte ich einen Windows NT 4.0-Server mit servergespeicherten verbindlichen (mandatory) Profilen im Einsatz. Ein Teil der PCs an unserer Schule sollen mit Linux bestückt werden, der andere Teil verbleibt unter Windows NT 4.0 (ServicePack 6a). Es geht jetzt um die verbleibenden Windows NT 4.0-Kisten. Diesen hätte ich gerne wieder auf dem SLSS im NETLOGON-Verzeichnis von Samba die Datei ntconfig.pol verpasst, damit diese Policies weiterhin ihre Gültigkeit und Wirksamkeit haben. Nun habe ich die ntconfig.pol einfach vom alten Server gesichert und auf den dann installierten neuen SLSS in das besagte Verzeichnis hineinkopiert. Das Seltsame ist nun, dass ein Teil der in dieser ntconfig.pol festgelegten Richtlinien abgearbeitet wird, ein anderer Teil nicht. Zum Beispiel habe ich ein vorgegebenes Hintergrundbild (funktioniert) und die Icons auf dem Desktop sollen komplett ausgeblendet werden (funktioniert). Leider nicht funktioniert z. B. das Ausblenden im Start-Menü von "Einstellungen", "Ausführen" usw. Gibt es da einen Trick bei der Geschichte mit ntconfig.pol? Was mache ich falsch? Hat jemand dazu eine Idee? Herzliche Grüße Michael Kolb Systembetreuer Rückertschule Coburg http://www.rueckertschule.de
Hallo Am Dienstag, 13. Juli 2004 19:39 schrieb Michael Kolb:
Nun habe ich die ntconfig.pol einfach vom alten Server gesichert und auf den dann installierten neuen SLSS in das besagte Verzeichnis hineinkopiert. Das Seltsame ist nun, dass ein Teil der in dieser ntconfig.pol festgelegten Richtlinien abgearbeitet wird, ein anderer Teil nicht. Zum Beispiel habe ich ein vorgegebenes Hintergrundbild (funktioniert) und die Icons auf dem Desktop sollen komplett ausgeblendet werden (funktioniert).
Evtl. finden die Clients den Ort der neuen ntconfig.pol nicht bzw. suchen Sie noch auf dem alten Server? Was ist in der Registry unter: HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\Update\ bei "NetworkPath"= und "UpdateMode"= eingetragen? Am einfachsten wäre hier wohl zunächst, wenn die Pfade festgelegt würden: "NetworkPath"="\\<pdc-name>\netlogon\ntconfig.pol" "UpdateMode"="0x00000002 (2)" "Verbose"="0x00000001 (1)"
Gibt es da einen Trick bei der Geschichte mit ntconfig.pol? Was mache ich falsch? Hat jemand dazu eine Idee?
Oft hilft 2-3maliges Neubooten, bis die Konfiguration wirklich erneuert wird. Warum das so ist: M$ fragen... Viele Grüße, Lars -- Lars Rupp, SUSE LINUX AG Maxfeldstr. 5, Lars.Rupp@suse.de D-90409 Nürnberg +49 (0) 911 74053193 -------------------------------------------
Hallo Lars,
vielen Dank für die Mailantwort.
Wir, das heißt ein EDV-Mitarbeiter unseres Sachaufwandsträgers und ich sind
mittlerweile ziemlich frustriert. Leider funktionieren die weiter unten
geposteten Vorschläge (Registry-Eintrag und mehrmaliges Neubooten) nicht.
Der Registry-Eintrag ist auf den Windows NT 4.0 (ServicePack 6a)-Clients
nicht eingetragen gewesen. Also händisch per RegEdit eingetragen. Kiste
runterfahren, Kiste neu starten. Ergebnis: nichts. Die im
Samba-NETLOGON-Verzeichnis gespeicherte ntconfig.pol (alles
kleingeschrieben) wird nicht abgearbeitet.
Auch fünmaliges Runter- und Rauffahren des NT-Clients brachte absolut
nichts.
Das am SLSS überprüfte Protokoll für die Zugriffe auf das
NETLOGON-Verzeichnis (kann's leider nicht fachmännischer ausdrücken, das hat
der EDV-Mitarbeiter gemacht) weist aus, dass auf die Datei ntconfig.pol
zugegriffen bzw. dass diese Datei abgearbeitet wird. Das heißt dann ja, dass
der Client die Datei ausliest, nur irgendwie nicht bei sich anwenden kann
oder will oder darf.
Die nächste Idee war, dass es vielleicht daran liegen könnte, dass die
NT-Clients bisher ja schon immer mit ntconfig.pol zugebügelt worden sind,
dass irgendwelche Policies irgendetwas nach der Domänen-Umstellung von NT
4.0 auf SLSS verhindern.
Also: Einen "jungfräulichen", noch nie mit irgendwelchen Policies versehenen
NT-Rechner hergenommen (ein alter Privat-Rechner), diesen in die SLSS-Domäne
eingebunden und dann die ntconfig.pol angewendet. Erfolg: derselbe, leider
nichts.
Muss man auf der NT-Workstation noch irgendwelche Rechte nach der Aufnahme
in die SLSS-Domäne setzen, damit da Policies abgearbeitet werden dürfen (nur
so eine Idee)? Oder ist die auf dem alten NT-Server zum Einsatz gekommene
ntconfig.pol mit irgendwelchen Rechten, die in der Datei drinstehen
versehen, dass man die Datei nicht einfach auf den SLSS-Samba-NETLOGON
kopieren darf?
Die nächste Überlegung war, einfach eine neue ntconfig.pol mit dem PolEdit
zu erstellen. Also die common.adm und winnt.adm als Richtlinienvorlagen in
den PolEdit importiert. Eine klitzekleine ntconfig.pol mit einem in
SLSS-Samba-NETLOGON abgelegten Bild namens schule.bmp verknüpft, das als
Hintergrundbild per Policy zugewiesen werden soll. Weiter nichts. Dies als
einzige und alleinige Richtlinie. Auch das hat nicht funktioniert.
Dann kam die Frage auf, ob NT 4.0 an dem Dilemma Schuld haben könnte! Nichts
leichter als einen Windows 2000-Rechner herzunehmen und auf diesem eine
2000er-Policy anzuwenden. Erfolg: ebenfalls nichts.
Tja, nach 2000 kam XP. Also noch einen XP-Client schnell installiert und die
von dir, Lars, bereitgestellten Vorlagen verwendet. Auf einmal: BINGO. Mit
XP funzt es. Absoluter Unglaube, aber es ging. Die Richtlinie mit dem
besagten Hintergrundbild wurde anstandslos abgearbeitet, nicht nur bei einem
Account namens schueler1, sondern auch bei schueler2, lehrer1 usw.
Warum funktioniert es bei Windows NT 4.0 nicht? Wo ist der kleine oder
riesige Denkfehler?
Tschuldigung, wenn die Mail jetzt schon so lange geworden ist, aber die
Gedanken mussten raus! Ich hoffe, es hat noch jemand bis hierher gelesen.
Einen schönen Abend wünscht
Michael Kolb
Systembetreuer
Rückertschule Coburg
http://www.rueckertschule.de
----- Original Message -----
From: "Lars Rupp"
Nun habe ich die ntconfig.pol einfach vom alten Server gesichert und auf den dann installierten neuen SLSS in das besagte Verzeichnis hineinkopiert. Das Seltsame ist nun, dass ein Teil der in dieser ntconfig.pol festgelegten Richtlinien abgearbeitet wird, ein anderer Teil nicht. Zum Beispiel habe ich ein vorgegebenes Hintergrundbild (funktioniert) und die Icons auf dem Desktop sollen komplett ausgeblendet werden (funktioniert).
Evtl. finden die Clients den Ort der neuen ntconfig.pol nicht bzw. suchen Sie noch auf dem alten Server? Was ist in der Registry unter: HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\Update\ bei "NetworkPath"= und "UpdateMode"= eingetragen? Am einfachsten wäre hier wohl zunächst, wenn die Pfade festgelegt würden: "NetworkPath"="\\<pdc-name>\netlogon\ntconfig.pol" "UpdateMode"="0x00000002 (2)" "Verbose"="0x00000001 (1)"
Gibt es da einen Trick bei der Geschichte mit ntconfig.pol? Was mache ich falsch? Hat jemand dazu eine Idee?
Oft hilft 2-3maliges Neubooten, bis die Konfiguration wirklich erneuert wird. Warum das so ist: M$ fragen... Viele Grüße, Lars
Hallo zurück Ganz kurz mal mein vermutetes Vorgehen bei der Umstellung - evtl. finden wir dadurch ja einen Hinweis: 1) Die Rechner von der Pflicht zur Nutzung der Profilvorlage befreien. Dazu mal als lokaler Administrator (ohne Rechteeinschränkungen durch das Profil) in der Registry nach den Einträgen "UpdateMode" und "NetworkPath" suchen und UpdateMode auf 0 stellen (0x000000000). Dann die Rechner neu starten und überprüfen, ob das Profil wirklich nicht mehr gilt. (Als Admin und auch für normale Nutzer.) 2) Die Rechner aus der bisherigen Domäne nehmen (in einer Arbeitsgruppe anmelden). 3) Eine neue Profilvorlage erstellen und diese dann unter anderem Namen (etwa slssprof.pol) im Netlogon-Verzeichnis des SLSS speichern. Als root unter Linux überprüfen, ob die Rechte für alle stimmen (Lese- und Ausführrechte für Verzeichnis und Datei). 4) Die Rechner in der neuen Domäne des SLSS anmelden und registrieren. 5) Die Registry umstellen (Pfad und Einträge s.o.). Hier halt bei UpdateMode den Wert 2 (manuell) und bei NetworkPath den Pfad zur Datei auf dem SLSS eintragen. 6) Neu booten und das bewährte Plug and Pray praktizieren. Habt ihr das so gemacht? Viele Grüße und gute Nacht in Dt. Lars
Hallo an alle, zweites Problem: Das im NETLOGON-Verzeichnis abgelegte Windows NT 4.0-Profil wird nicht korrekt abgearbeitet. Ich gehe davon aus, dass das Verzeichnis "Default User" im NETLOGON-Verzeichnis von SLSS-Samba das Verzeichnis ist, im dem laut Handbuch eine Art "Default-Profil" für alle User hineinkopiert werden kann, das der sich einloggende User dann ausgelesen bekommt und somit z. B. Verknüpfungen auf dem Desktop, im Programme-Ordner im START-Menü usw. von mir vorgegeben zugewiesen bekommt. Das Verzeichnis "Default User" hat die Berechtigung Lesen, also nicht schreiben oder ändern. Die Datei ntuser.dat habe ich in ntuser.man umbenannt, um ein mandatory (verbindliches) Profil zu erhalten. Jetzt habe ich da mein altes Profil vom Windows NT 4.0-Server einfach per Explorer zunächst auf eine Festplatte gesichert und dann nach Installation des SLSS in das besagte Verzeichnis hineinkopiert. Mir war klar, dass das später gut gehen kann aber nicht muss, da man das eigentlich nicht händisch kopieren sollte, sondern ein gerade angelegtes Profil auf einer Workstation per START -> Einstellungen -> Systemsteuerung -> System -> Benutzerprofile -> Benutzerprofil kopieren (unter NT 4.0) kopieren sollte. Aber ich wollte halt mal sehen, ob's funktioniert. Dank einem Tipp von Roland Barwig bin ich auf eine hervorragende, äußerst ausführlich und informativ geschriebene Mail vom Mai von Markus Bölling gestoßen, wo Markus beschreibt wie er das gemacht hat. Aufgrund des Rates von Markus habe ich also einen neuen, noch nie eingeloggten Benutzer auf der Web-Admin-Oberfläche des SLSS angelegt. Diesen User habe ich auf der NT 4.0-Workstation eingeloggt (innerhalb einer SLSS-Domäne) und siehe da, der bekam beim ersten Einloggen das Profil ordentlich zugewiesen. Alle im Profil getätigten Verknüpfungen auf dem Desktop und im Startmenü unter Programme waren verfügbar. Beim zweiten Einloggen des gleichen Users war nichts mehr da. Es funktioniert also nur einmal beim ersten Einloggen. Also wieder in der Mail von Markus nachgelesen - na klar, das korrekte Kopierverfahren fehlt ja noch. Einen anderen User in der WebAdmin-Oberfläche des SLSS angelegt. Diesen User eingeloggt, er erhielt wiederum korrekt das vorgegebene Profil. Diesen User ausgeloggt und sofort als root bzw. admin bzw. administrator wieder eingeloggt. Jetzt das Profil ordentlich über Systemsteuerung -> System -> Benutzerprofile kopieren. Aber jetzt kommts: Ich hatte keine Chance dazu, denn mir wurde kein einziges lokal an dieser Workstation vorhandenes Profil angezeigt. Soweit der Stand der Dinge :-( Meine Fragen: Warum sieht der root (admin, administrator) der SLSS-Domäne das Profil auf der Workstation nicht. Es ist laut Explorer definitiv auf der Workstation abgelegt. Liegt das an fehlenden Rechten auf dieser Workstation? Und wenn ja, was muss ich tun, um diese Rechte zu erteilen? Warum wurde das Profil nach dem ersten Einloggen nicht auf dem SLSS im home-Verzeichnis abgelegt? Ich denke, der SLSS ist so voreingestellt, dass er das tun müsste. Also müsste doch nach dem zweiten Einloggen des gleichen Users das Profil des home-Verzeichnisses hergenommen werden. Aber das ist nicht der Fall! Auch das wurde leider wieder eine ziemlich lange Mail. Aber nach entsprechendem Frust-Level ist das einfach so. Je genauer ich meine Problematik beschreibe, desto mehr hoffe ich auf Hilfe. Und nach insgesamt 39 Stunden im Computerraum (alten NT-Server sichern, SLSS aufspielen, Domänenanbindung realisieren, Fehlversuche, Fehlversuche und nochmals Fehlversuche mit ntconfig.pol und Profilen ist man dann so weit :-( @ Peter Varkoly Vielen herzlichen Dank für die äußerst rasche und zuverlässige Zusendung der aktuellsten Version des SLSS per CD. Ist schon am nächsten Morgen in der Schulpost gewesen :-)) Domänenanbindung hat dann auch funktioniert :-)) Mit besten Grüßen Michael Kolb Systembetreuer Rückertschule Coburg http://www.rueckertschule.de
participants (2)
-
Lars Rupp
-
Michael Kolb