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

Hallo, wir verfügen über eine JBF-Domäne, die gestützt wird von 2 Servern: - JBFDBS (Win2000 SP4, DC) und - JBFS01 (Win2003 SP2, (P)DC), die sich replizieren. Wenn ich auf dem Server JBFS01 in Active Directory die GPMC starte, auf eine GPO gehe, oben den Reiter Einstellungen, erscheint diese so, als wäre sie neu angelegt (keine Einstellungen bei Computer und Benutzer). Das ist bei allen GPOs der Domäne so. Da sind aber definitiv Einstellungen vorhanden, die ich z.B. sehe, wenn ich eine GPO öffne bzw. über Gruppenrichtlinienmodellierung werden die für einen PC und bestimmten Benutzer simulierten Einstellungen auch korrekt angezeigt. Von den Clients werden die GPOs ebenso korrekt übernommen (Laufwerkszuweisung, Druckerzuweisung etc.). Habe auf meinem Arbeitsrechner, Win XP SP3 mit Adminpak, mit Ausführen Als das Active Directory und darüber die GPMC ebenfalls gestartet. Wenn ich hier in der Baumansicht auf eine GPO gehe, rechts Reiter Einstellungen, wird nach einer Weile die Fehlermeldung "RPC-Server nicht verfügbar" angezeigt. Dann kam ein Dialogfeld, wo ich die Server auswählen kann, welche die GPMC abfragen soll. Habe es auf JBFDBS umgestellt. Nun funktioniert es, die Einstellungen werden angezeigt. Vermutung: irgendetwas blockiert auf dem JBFS01 den Zugriff auf die Gruppenrichtlinien. Da JBFS01 der PDC ist, fragen die Clients erstmal diesen, dann beim zweiten Versuch den JBFDBS, der die GPOS auch hat, aber nicht die Blockade. Das zweimal fragen denke ich kostet auch Anmeldezeit. Hat jemand eine Idee, wie man es schafft, dass der JBFS01 die GPOs der Domäne korrekt anzeigt? Danke schonmal. Gruß Sven

Hallo Leute ! ich bin gerade mitten im Prüfungsstress zum MCSA: Messaging. Die XP-Prüfung und die erste Win2K3Srv-Prüfung (70-290) hab ich schon geschafft. Gibt es jemanden in Raum Erfurt, der/die sich auch auf die Prüfung vorbereitet ? Wäre nicht schlecht, wenns da wen gäbe... Die 70-291... da bin ich 2x durchgerasselt. Unerklärlicherweise. Wenn ich das so lese Simus mit 100 Punkten und so kann ich mir das durchaus erklären, da ich auch verklickt habe. Das erstemal hatte ich 519 und das zweitemal 498 Punkte, und die Balken waren völlig anders. Muss wohl an den Simulationen gelegen haben. Dachte die werden erst gezählt wenn man "Fertig" drückt"... CU Elvereth

Hallo Leute ! Ich bin der Techniker hier in einer beruflichen Bildungseinrichtung und wir betreiben hier eine Win2000 Domäne mit Active Directory. Angeschlossen sind ca. 50 Clients, die meisten mit WinXP, andere mit Win2000. Zwei PCs von den XP-Rechnern haben u.a. o.g. Ereignis gemeldet, nachdem sie mit dem SP 2 in unsere Domäne beigetreten sind. PC 1 Ich habe nun einen PC mit WinXP SP1a gegen einen schnelleren mit WinXP SP2 getauscht. Letzterer ist also in der Domäne. Das Problem ist, dass ich diesen seit 2 Tagen als lokaler Admin immer wieder in die Domäne hinzufügen muss. Im Systemprotokoll befindet sich u.a. o.g. Event 36872 mit Quelle Schannel. Ein Tag scheints jedesmal zu funktionieren, dann ist scheinbar das "Computerkennwort" abgelaufen und er kann den Rechner im AD nicht finden. :eek: PC 2 Bei einem anderen Rechner hatte ich das Problem auch. Da hatte ich einen PC neu aufgesetzt und das XP-SP2 auch gleich mal drauf gemacht. Daraufhin kam er auch nur für einen Tag in die Domäne. Vielleicht gibts da sowas wie ein timeout, denn die Kollegen haben ausgeschaltet gegen 16 Uhr und frühs am nächsten Tag war der PC nicht mehr Domänencomputer. Im Zusammenhang mit Anmeldung am AD und dem XP-SP2 gibt es folgende Ereignisse: Ereignistyp: Fehler Ereignisquelle: NETLOGON Ereigniskategorie: Keine Ereigniskennung: 5723 Datum: 07.12.2004 Zeit: 09:36:02 Benutzer: Nicht zutreffend Computer: JBF-SRV Beschreibung: Die Sitzung konnte von Computer "PC-FBWV-1" nicht eingerichtet werden, da kein Vertrauenskonto in der Sicherheitsdatenbank für diesen Computer vorhanden ist. Der Kontoname in der Sicherheitsdatenbank ist PC-FBWV-1$. und Ereignistyp: Fehler Ereignisquelle: NETLOGON Ereigniskategorie: Keine Ereigniskennung: 5790 Datum: 07.12.2004 Zeit: 09:49:37 Benutzer: Nicht zutreffend Computer: JBF-SRV Beschreibung: Die Beschreibung der Ereigniskennung (5790) in (NETLOGON) wurde nicht gefunden. Der lokale Computer verfügt nicht über die zum Anzeigen der Meldungen von einem Remotecomputer erforderlichen Registrierungsinformationen oder DLL-Meldungsdateien. Ereignisinformationen: PC-FBWV-1; Zugriff verweigert . Die Ereignisse 5723 und 5790 kommen immer zusammen vor. Es gibt von Microsoft ein Workaround unter http://support.microsoft.com/kb/318266/DE/ hier wird beschrieben, wie man beim SP2 in den lokalen Sicherheitsrichtlinien die Verschlüsselung beim Verbinden mit der Domäne ausschaltet. Das allein hat bei mir aber das Problem nicht gelöst. Den PC-Namen habe ich sogar manuell ins Active Directory eingetragen. Scheint aber nichts zu bringen. Weiterhin habe ich die WINS und DNS-Einstellungen eingetragen. Das hat beim PC 2 das Problem gelöst, beim anderen PC 1 hatte es auch keine Auswirkungen. Kennt jemand eine Software, wo man die Einstellungen zweier XP-Rechner miteinander vergleichen kann... oder es reicht auch schon wenn man die auslesen kann in eine Textdatei oder so... ich habe mir gedacht dass ich die beiden PCs miteinander vergleiche denn auf einem läufts ja. Wenn ich mir vor Augen halte, dass hier ca. 40 PCs das XP haben und früher oder später mit dem Service Pack 2 laufen sollen krieg ich ne Gänsehaut... Das was ich rausgefunden hab ist, dass es sich um PCs handelt mit XP und Service Pack 2. die mit 1a gehen. CU Elvereth