Elvereth

Hallo, ich glaub ich habs gelöst. Bin über folgendes gestolpert: How to Create a Base Profile for All Users Ich habe das Profil nochmal lokal eingerichtet mit Verknüpfungen, Hintergrund, Icons, Office usw. und dann auch in eine neue Freigabe auf dem Server kopiert unter \\Server\Profile$\Standard, also einen weiteren Unterordner. (Neue Freigabe deshalb, um auf die Einstellungen der vorigen mandantory-Profile zugreifen zu können) Wichtig beim Kopieren einen lokalen Benutzerprofils in eine Freigabe war wohl, dass man die Benutzergruppe Jeder einstellt, weil das Profil sonst nur für den Nutzer des lokalen Profils lesbar ist. Dass eine nachträgliche Änderung der Sicherheitseinstellungen der Dateien im Profil (z.B. der ntuser.man bzw .dat) nicht ausreicht, habe ich bereits bemerkt als ich letztere in regedit importiert hatte: die Berechtigungen der Schlüssel waren auf nur einen Benutzer beschränkt. Jetzt steht da "Jeder" drin. Ich hab das jetzt bei mir lokal getestet, also einen Nutzer eingestellt, der das servergespeicherte Mandantory-Profil verwendet und mich neu an einem Rechner angemeldet. Siehe da: Einstellungen wie im Profil und deutsche Tastatur. Wie schöööön das nach zwei Wochen Kopfzerbrechen sein kann :-) Nun warte ich die Resonanz aus den Abteilungen ab, ob das nicht nur bei mir auf meiner Test-Schüssel funktioniert. :-D Gruß Elvereth

Es sind mehere DCs,. ja, die Replizierung funktioniert, kene Fehlermeldungen. Habe mich als Testbenutzer am Client angemeldet (mit den Berechtigungen der problematischen Benutzer) in regedit unter HKCU\Keyboard Layout\Preload gibts: - "1" = 0x0407, - "2" = 0x0409, unter HKCU\Keyboard Layout\Substitutes ist leer, unter HKCU\Keyboard Layout\Toggle gibts: - "Hotkey" = 1 - "Language Hotkey" = 1 - "Layout Hotkey" = 2 am Server in den Ordner des servergespeicherten Profils gegangen, user.man kopiert, regedit aufgerufen, user.man unter den Zweig "HKEY_USERS" als "user-man" reingehangen. Darunter gibts diesen Zweig: unter HKCU\Keyboard Layout\Preload gibts: - "1" = 0x0407, unter HKCU\Keyboard Layout\Substitutes ist leer, unter HKCU\Keyboard Layout\Toggle gibts: - "Hotkey" = 1 - "Language Hotkey" = 1 - "Layout Hotkey" = 1 Stellt sich die Frage, warum die Clients unter "Layout Hotkey" eine 2 haben obwohl in der user.man eine "1" steht. Kann das mit Berechtigungen des Nutzers auf die user.man zusammenhängen oder dass er die Registrierung nicht bearbeiten darf? Gruß Sven

Hi Sunny, es hat leider nicht funktiooniert. ADMTemplate habe ich importiert, Einstellungen vorgenommen, Test-Benutzer hat immernoch englisches Tastaturlayout. Wenn ich das auf Deutsch umstelle, mich abmelde, nochmal mit gleichem Nutzer anmelde, ist es wieder englisch. Wiederhole ich das mit vorherigem Löschen der lokalen Kopie des Benutzerprofils, ist es das gleiche (nach Umstellen auf deutsch und neu anmelden wieder englisch. Gruß Sven

Danke Sunny, werd ich gleich mal ausprobieren. Gruß Elvereth

Hallo Leute, ich verzweifle daran, dass einige Domänen-Benutzer nach dem Anmelden die englische Tastaturbelegung haben. Es handelt sich hierbei um Nutzer für Auszubildende, denen über die Benutzereigenschaften des AD ein Mandantory Profil in einer Serverfreigabe zugewiesen wird. Die Clients laufen auf Windows XP, Server ist Windows 2003. Es sind ca. 350 Benutzerkonten, die betroffen sind. Man kann die Tastatur manuell über die Systemsteuerung umstellen aber bei der nächsten Anmeldung ist sie wieder auf englisch. Beim Erstellen des Mandantory Profils habe ich mich an einem XP-Client als Admin angemeldet, alles soweit eingestellt (Desktop, Office, Icons) und auch das englische Tastaturlayout rausgeworfen und das Deutsche als einzigstes und aktuell eingestellt. Dann habe ich das Profil über die Benutzerprofile-Verwaltung auf die Freigabe kopiert. User.dat in User.man umbenannt. Freigabeberechtigungen der Profilfreigabe sind auf Jeder - Vollzugriff und die Berechtigungen auf den Ordner sind: - Domäne\Administratoren - Vollzugriff - SYSTEM - Vollzugriff - Benutzer - Lesen/Ausführen - Domäne\Teilnehmergruppe - Ändern (alle betroffenen Nutzer sind Mitglied dieser Gruppe). Wie gesagt, beim Anmelden bekommen diese Nutzer ein englisches Tastaturlayout bzw. wird aus irgendeinem Grund die deutsche Tastaturbelegung nicht nachgeladen. Durch eine Internetrecherche bin ich darauf gestoßen, dass es eine GPO-Einstellung gibt, wo man die Regional/Spracheeinstellung vorgeben kann. Habe diese eingerichtet (Deutsch). Tastaturlayout ist trotzdem englisch. :confused: Bei anderen Nutzern, die kein Mandantory-Profil benutzen, ist deutsch eingestellt. Ich vermute schon, dass es mit dem Profil zu tun hat, aber da es über 300 Konten sind, deren Profil gleich aussehen muss, komme ich wohl um ein servergespeichertes Mandantory-Profil nicht herum. Es ist so, dass die Einstellungen des Mandantory-Profils (Office, Desktop, Icons) geladen werden, nur haben die Nutzer eine englische Tastaturbelegung - sonst wäre es wohl zu perfekt. :mad: Für Anregungen und weitergehende Ideen wäre ich sehr dankbar. Gruß Elvereth

Anscheinen hat niemand eine Idee, warum ich mit VBS die Computerinfos aus dem AD nicht auslesen kann... :-/

Hallo Leute, ich möchte abhängig von der OU, in der sich das Computerkonto des Clients befindet, einen Drucker mounten. D.h. wir haben 2 Computerräume mit je einem Lehrerplatz und einem freigegebenen Drucker. Die Konten der Computerräume sind jeweils in einer OU zusammengefasst, eine OU heisst z.B. "Computerraum1" und die andere "Computerraum2". Hier das Script, welches in einer GPO "drucker-pc-raeume" verteilt wird (in Computer- und Benutzereinstellungen festgelegt). Dim wshNet, ADSysInfo, CurrentUser, CurrentComputer, strGroups Set WshNet = CreateObject("WScript.Network") Set ADSysInfo = CreateObject("ADSystemInfo") Set CurrentComputer = GetObject("LDAP://" & ADSysInfo.ComputerName) strComputerName = ADSysInfo.ComputerName on error resume next If InStr(strComputerName, "OU=Computerraum1") Then WshNet.AddWindowsPrinterConnection "\\lehrerpc1.meine.domäne\PRINTER1" WshNet.SetDefaultPrinter "\\lehrerpc1.meine.domäne\PRINTER1" End If If InStr(strComputerName, "OU=Computerraum2") Then WshNet.AddWindowsPrinterConnection "\\lehrerpc2.meine.domäne\PRINTER2" WshNet.SetDefaultPrinter "\\lehrerpc2.meine.domäne\PRINTER2" End If Auf meinem Test-PC, den ich in die OU eines Computerraums gesetzt habe, lief das. Ich hab mir anstelle der If-Anweisungen über Echo testweise den String strComputerName anzeigen lassen, der korrekterweise den kompletten FQDN-Pfad des PCs enthielt. Habe nun aber beim Anmelden auf den Clients im Computerraum2 bemerkt, dass beim Anmelden eine Laufzeitfehlermeldung aufploppt: \\meine.domäne\SYSVOL\......\druckerdran.vbs Zeile: 4 Zeichen: 1 Fehler: 0xC0000005 Code: C0000005 Quelle: (null) und der Drucker wird nicht verbunden. Mit einem anderen Testscript lokal auf diesem PC im Computerraum habe ich das darauf eingrenzen können: DN_Name = CreateObject("ADSystemInfo").ComputerName Wscript.Echo DN_Name Das Script liefert den gleichen Fehler 0xC000005 an Zeile 1. Scheinbar kann er aus irgendeinem Grund nicht auf die Property "ComputerName" der Objektinstanz "ADSysInfo" zugreifen. Das Objekt scheint leer zu sein (Quelle: (null)). Das Betriebssystem des Clients ist Windows XP ServicePack 2 (ja ich weiss das wird demnächst auf 3 aktualisiert), Domäne ist z.Zt Windows 2003 gemischt. Ein anderer Client hat Service Pack 3 und da gibts den Fehler auch. Ich denke da klemmts woanders. Ich meldete mich auch als Administrator der Domäne dort an um das Script zu testen. An der Berechtigung sollte es auch nicht liegen - abgesehen davon sollte die LDAP-Abfrage über Scripte doch zumindest mit Auth Benutzer funktionieren, oder? :confused: Also mal kurz: Testcomputer in OU des Computerraum1 --> Testscript zeigt FQDN des PCs. 1. physischer PC im Computerraum1 (SP2) --> Laufzeitfehler C0000005 2. physischer PC im Computerraum1 (SP3) --> Laufzeitfehler C0000005 ich habe Testscript und Drucker-Script mehrmals getestet und bin sozusagen zum Schluss gekommen, dass es PCs gibt, wo das Objekt ADSystemInfo nicht ausgelesen werden kann. Kennt sich damit jemand aus bzw. hat ähnliche Erfahrungen? :confused: Gruß Elvereth

Stimmt nicht. Die Sicherung wurde erfolgreich erstellt, liegt auf dem Zielmedium mit ca. 640 MB. 20100112-0409 di server1 backup02.log: Sicherungsstatus Vorgang: Sicherung Aktives Sicherungsziel: Datei Mediumname: "server1-systemstatus.bkf erstellt am 12.01.2010 um 04:00" Volumeschattenkopie-Erstellung: Versuch 1. Sicherung von "System State" (mit Schattenkopie) Sicherungssatz #1 auf Medium #1 Sicherungsbeschreibung: "Satz am 12.01.2010 um 04:00 erstellt" Mediumname: "server1-systemstatus.bkf erstellt am 12.01.2010 um 04:00" Sicherungsart: Kopieren Sicherung begonnen am 12.01.2010 um 04:03. Sicherung abgeschlossen am 12.01.2010 um 04:09. Verzeichnisse: 1635 Dateien: 3006 Bytes: 641.046.515 Zeit: 5 Minuten und 38 Sekunden ---------------------- Ja, da widerspricht er sich, der Gute. Gruß Sven

Hallo Norbert, ich vermute mal stark, dass das Problem mit certsvc.exe zu tun hat. Das wiederum hängt mit NTBackup zusammen. Wir sichern täglich den Systemstatus der Server auf eine externe Platte. Dabei passiert in den letzten Tagen folgendes (diese Ereignisse passieren an Tagen der Sicherung in gleicher Reihenfolge): Ereignistyp: Informationen Ereignisquelle: NTBackup Ereigniskategorie: Keine Ereigniskennung: 8018 Datum: 12.01.2010 Zeit: 04:00:42 Benutzer: Nicht zutreffend Computer: SERVER1 Beschreibung: Vorgang starten Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.'>http://go.microsoft.com/fwlink/events.asp.'>http://go.microsoft.com/fwlink/events.asp.'>http://go.microsoft.com/fwlink/events.asp.'>http://go.microsoft.com/fwlink/events.asp. Ereignistyp: Informationen Ereignisquelle: ESENT Ereigniskategorie: Protokollierung/Wiederherstellung Ereigniskennung: 210 Datum: 12.01.2010 Zeit: 04:00:42 Benutzer: Nicht zutreffend Computer: SERVER1 Beschreibung: certsrv.exe (1396) Eine vollständige Sicherung wird gestartet. Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp. Ereignistyp: Fehler Ereignisquelle: ESENT Ereigniskategorie: Protokollierung/Wiederherstellung Ereigniskennung: 215 Datum: 12.01.2010 Zeit: 04:00:42 Benutzer: Nicht zutreffend Computer: SERVER1 Beschreibung: certsrv.exe (1396) Die Sicherung wurde abgebrochen, weil sie vom Client angehalten wurde, oder weil die Verbindung mit dem Client unterbrochen wurde. Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp. Ereignistyp: Informationen Ereignisquelle: Userenv Ereigniskategorie: Keine Ereigniskennung: 1516 Datum: 12.01.2010 Zeit: 04:10:10 Benutzer: NT-AUTORITÄT\SYSTEM Computer: SERVER1 Beschreibung: Die Registrierung des Benutzers S-1-5-21-13(...)500_Classes wurde entladen, nachdem eine Benachrichtigung empfangen wurde, das keine Anwendungen bzw. Dienste dieses Profil verwenden. Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp. Ereignistyp: Informationen Ereignisquelle: Wechselmediendienst Ereigniskategorie: Keine Ereigniskennung: 98 Datum: 12.01.2010 Zeit: 04:10:12 Benutzer: Nicht zutreffend Computer: SERVER1 Beschreibung: Der Wechselmediendienst wurde angehalten. Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp. Sicherung wird gestartet, aber sofort abgebrochen, weil certsrv seinen Client verliert... (= Backup-Ziel?). Wenn der Wechselmediendienst vorher beendet würde, täte ich das ja verstehen, aber der Wechselmediendienst (der das Backupziel USB-Platte verwaltet) wird beendet, nachdem certsrv seinen Client verliert. Hier: http://www.mcseboard.de/windows-server-forum-78/event-esent-215-a-90292.html bin ich erstmal fündig geworden, offensichtlich gibts noch andere die das Problem haben, allerdings verweist dieser Thread am Ende auf einen anderen, der sich auf Ereigniseinträge stützt, die ich wiederum nicht nachvollziehen kann (Probleme mit der DHCP-Sicherung und tcpsrvc.exe). Ich denke, dass certsrv.exe - Zertifikatsdienste - mit meinem Gruppenrichtlinienproblem bei lokaler Anmeldung auf dem Server zu tun haben. Wenn ich auf meinem Arbeitsrechner als Admin in die Gruppenrichtlinien einwähle, kann ich alle GPOs einsehen und ändern. Die Gruppenrichtlinienergebnisse (Simulation) funktioniert auf dem Server. Anderen Benutzern als dem Admins ist die lokale Anmeldung am Server nicht erlaubt. Wie könnte ich das anders testen? Gruß Sven

Hallo Norbert, danke für Deine Antwort. Es wundert mich ja gerade, dass ich die GPT.INI's öffnen kann. Okay ist ne andere Berechtigung. Aber wenn "DOMÄNENCONTROLLER DIESER ORGANISATION" Lese/Ändern-Rechte und "SYSTEM" Vollzugriff hat, müsste der Rechner doch die Dateien öffnen können. Oder? Im Zusammenhang mit "Netzwerkpfad nicht gefunden" tippte ich erst auf ein DNS-Problem und prüfte die Verbindungen mit nslookup einmal auf jbf.local und andererseits auf die Replikationspartner von beiden Seiten: Ergebnis: lief. Ich habe noch festgestellt, dass sich der Wechseldatenträger und der Volumeschattenkopiedienst ausschaltet. Vermutlich 1x am Tag in der Nacht bzw. wenn die Volumenschattenkopien erzeugt werden (6 Uhr und 12 Uhr). Ich denke das hat damit zu tun - zumindest der Wechseldatenträgerdienst. Hab die Dienste in den letzten zwei Tagen frühs per Hand neu gestartet. Was mich wundert: keine Ereigniseinträge drüber (wg. Zeitpunkt bzw. Ursache). Montag kann ichs weiter verfolgen. Gruß & schönes Wochenende Sven

Hallo Norbert, Wenn Du die damit verbundende kb meinst (Ereigniskennung 8 wird im Anwendungsprotokoll protokolliert) - sie sagt aus, dass der Server versucht die Stammserverzertifikate übers Internet bei Windows Update zu aktualisieren und das nicht gebacken kriegt, weil er (der Server) nicht ins Internet kommt. Habs getestet: Bin auf betreffenden meckernden Server über Internet Explorer ins Internet gekommen. Wir benutzen keinen Proxy, es geht direkt über nen ISA ins Internet. Es muss eigentlich gehen, denn Windows Update funzt ja auch. :confused: Gruß Sven

Hallo Norbert, Ok, nun mal in (für Dich) verständlicher Reihenfolge. :-) - Im Ereignis 1058 auf dem Server steht, dass auf eine bestimmte GPT.INI nicht zugegriffen werden kann. Habe eben diese (\\<Domainname>\sysvol\sysvol\policies\{...}\GPT.INI mit dem notepad öffnen können. Von beiden DCs aus. Die Sicherheitseinstellungen hab ich überprüft. Sind bei beiden DCs gleich. - Habe das auch mit den GPT.INI's der anderen policy-Ordner probiert. Ich kannse alle öffnen. - habe im Ordner \\<Domainname>\sysvol\<Domänenname\policies\ die 2 wichtigsten Sicherheitseinträge aller Ordner (die "{...}") geprüft: Nutzer "DOMÄNENCONTROLLER DIESER ORGANISATION" hat Read/Apply-Recht, "SYSTEM" hat Vollzugriff. - UserEnv logging hab ich angeschaltet, Auswertung erfolgt später. - WaitForNetwork seh ich mir auch später genauer an. - TCP/IP Helperdienst läuft auf Client und auch auf den beiden DCs. Ja. Es werden auch alle GPOs von den Clients abgearbeitet (Laufwerke zugeordnet, Desktopeinstellungen etc.) Zur Erinnerung: Mein Problem ist, dass ich auf dem Server die Einstellungsberichte nicht kriege und die GPMC beim Anlegen einer Gruppenrichtlinie sagt "Netzwerkpfad nicht gefunden" obwohl ich überall drauf komme. Komischerweise funktionieren die Gruppenrichtlinienergebnisse. Ja. Da steht ne Hex-Nummer. und was soll die mir sagen? Googeln kann ich auch. Was meinstn, warum ich mir trotzdem die Mühe mache, mein Problem vor der zynischen Expertenschar breitzutreten? Ich dachte die dienen nur der Unterhaltung. :-/ Ich hab überlegt, vielleicht liegts ja auch an der GPMC selbst. Werde versuchen das Tool neu zu installieren. Gruß Sven

Hallo, ich habe eben versucht, im GPMC eine Gruppenrichtlinie anzulegen. Fehler "Netzwerkpfad nicht gefunden" (direkt am Server lokal). Dann hab ich die Freigabe \\<Domäne.local>\sysvol probiert und komme überall drauf, selbst in die Unterordner der GPOs. Die Einstellungen der GPOs kann ich mir nach wie vor nicht in der GPMC ansehen, editieren geht aber. Ich bin am verzweifeln. Gruß Sven

Hallo Norbert, danke für Deine Antwort. Schon vor dem Urlaub testete ich \\<Domäne.local>\sysvol. Da konnte ich eigenartigerweise drauf zugreifen. Ich hatte Deine Antwort gestern abend erst gesehen und habe es jetzt nochmal getestet. Ich kann also von dem Client, von dem ich Dir die Ereignisprotokolleinträge geschickt habe, auf \\<Domäne.local>\sysvol zugreifen. Da ist dann nochmal ein Ordner drin, der <Domäne.local> heisst. Ich vermute, dass - da die Domäne zwischen 2 Servern repliziert wird - einer davon die Freigabe immer korrekt liefert - bei Aufruf über die Domäne. Deshalb teste ich gleich nochmal gezielt die Zugriffe auf die sysvols der einzelnen Server. JBFDBS\sysvol --> klappt. Da ist der Ordner "<Domäne.local>" zu sehen. JBFS01\sysvol --> klappt auch. Gleiche Verzeichnisebene zu sehen. Gestern habe ich über Ausführen Als... die GPMC von meinem Arbeitsrechner aus gestartet. Beim Aufruf der Einstellungen einer der GPOs kam die Fehlermeldung "RPC-Server nicht verfügbar". Ein Dialog erschien und ich konnte den anderen DC wählen --> die Einstellungen waren zu sehen. Der Dienst "Remoteprozeduraufruf" läuft und ist automatisch. "RPC-Locator" ist auf manuell und nicht gestartet. Hatte letzteren gestern gestartet, hatte keinenEinfluss auf lokalen Zugriff auf die GPOs über die GPMC. Der Dienst läuft auf JBFS01 und JBFDBS und auf meinem Arbeitsrechner (Client). Gruß Sven

Hallo Norbert, ja, bei mir auf dem Arbeitsrechner (kürzester Weg *g*) habe ich bei Anwendung-Ereignissen eine ganze Menge dieser Fehlereinträge: ---- Ereignistyp: Fehler Ereignisquelle: Userenv Ereigniskategorie: Keine Ereigniskennung: 1030 Datum: 06.01.2010 Zeit: 08:39:16 Benutzer: JBF\######### Computer: PC-EDVB Beschreibung: Die Abfrage der Liste der Gruppenrichtlinienobjekte ist fehlgeschlagen. Bisher wurde eine Fehlermeldung dieser Art im Richtlinienmodul protokolliert. Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.'>http://go.microsoft.com/fwlink/events.asp. ----- Scheinbar kriegt der die GPO-Liste nicht vom Server JBFS01. Über den Arbeitstag verteilt ca. 4-6 mal. Ebenfalls gibt es Fehlereinträge mit Quelle "crypt32", die sich anscheinend auf Windows Update beziehen, deshalb hab ich die bisher nicht damit in Zusammenhang gebracht. ----- Ereignistyp: Fehler Ereignisquelle: crypt32 Ereigniskategorie: Keine Ereigniskennung: 8 Datum: 06.01.2009 Zeit: 07:02:19 Benutzer: Nicht zutreffend Computer: ###### Beschreibung: Der automatische Aktualisierungsabruf der Drittanbieterstammlisten-Sequenznummer von <http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt> ist fehlgeschlagen mit dem Fehler: Dieser Vorgang wurde wegen Zeitüberschreitung zurückgegeben. . Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp. ----- Windows Update bei Clients und Server an sich funktioniert ja. Vieleicht hat crypt32 auch ganz nebenbei was mit der AD-Kommunikation zu tun ?! Gruß Sven