olc

Hi, ergänzend zu dem Link noch der Hinweis, daß es ab Windows 7 / 2008 R2 auch über GPEDIT.MSC möglich ist, das zu konfigurieren. Wenn also in der Umgebung nur diese Systeme laufen, kannst Du es per GUI erledigen. Somit also die Frage: Wie sieht Deine Umgebung aus? ;) Viele Grüße olc

Hi checkout, nur um das noch einmal herauszustellen - Du sprichst von einem DC im Forest, korrekt? Nicht etwa einem DC in einer Domain, die Teil eines Forests mit mehreren Domänen ist. In ersterem Fall hast Du die Antwort bekommen ;) - letzteres wäre problematisch. Zusätzlich wäre aber anzumerken, daß nur ein DC in einer Domäne nicht optimal ist - es sollten aus Redundanzgründen immer zwei DCs pro Domäne vorhanden sein. Und ab dem Punkt greift dann wieder die USN Thematik. Viele Grüße olc

Hi, das kann an diversen Dingen liegen: So z.B. einem noch nicht abgeschlossenen Indexierungsvorgang der internen Suchfunktion, Dein Virenscanner kann die Zugriffe auslösen usw. Testweise kannst Du einmal versuchen alle "nicht Microsoft Dienste" zu deaktivieren (mittels MSCONFIG) oder aber Perfmon.msc bzw. XPerf benutzen, um den Prozess oder die Prozesse zu identifizieren, die die Lese- / Schreibvorgänge durchführen. Ich denke nicht, daß es "an Windows 7" liegt, wie Du schreibst - es wird eher an einer konkreten Komponente liegen. Ich tippe auf die Suche - wobei das nach einigen Starts dann auch erledigt sein sollte. [EDIT] Ok, Lukas war schneller. Auch ein Frühaufsteher. :D [/EDIT] Viele Grüße olc

N'Abend, das stimmt, allerdings ging für mich hieraus hervor, daß das ab und an der Fall ist ;) : Ich hoffe nicht, daß ich mich da mit der Interpretation der Zeilen geirrt habe. :D ;) :p Viele Grüße olc

Hi, Du kannst auf einem Rechner die gewünschten Einstellungen vornehmen und den gesamten Ordner "%SYSTEMROOT%\System32\GroupPolicy" kopieren, den Du dann per GPP oder ROBOCOPY auf die Zielsysteme verteilst. So etwa mittels Domänen-Startup-Script für die Clients. Viele Grüße olc

Hallo, hast Du meine Angaben im letzten Thread korrekt gelesen? Du kannst "indirekt" die lokalen Richtlinien / Scripts verteilen, wenn auch nicht sonderlich "schön". Viele Grüße olc

Hi Canni, Korrekt. Zumindest einige, nicht alle. Aber die Scripte heißen nicht umsonst "Logon-" oder "Startup-Script" - sie werden eben nur bei diesen Aktionen ausgeführt, nicht im Background Processing. Ja, Du kannst die lokale Richtlinie für den Computer im Benutzerteil mit dem Script versehen, das funktioniert. Entweder mittels Group Policy Preferences oder mit einem Domänen-Startupscript für den Computer mit einem simplen ROBOCOPY oder XCOPY Befehl. :) Der Zielpfad sollte im Normalfall der hier sein: %SYSTEMROOT%\System32\GroupPolicy\User\Scripts\Logon Nein, zumindest nicht mit den Domänen GPOs. Es gibt aber neben den lokalen Polices sicherlich noch andere Möglichkeiten (Autostart, Dienste, geplante Tasks mit Eventtriggern etc.). Was ist denn eigentlich in den Scripts definiert - vielleicht kann man Dein Ziel ja auch anders erreichen? Viele Grüße olc

Jain, per Domänen-Logonscript oder GPP könnte man das gewünschte Logonscript an die korrekte Lokation lokal kopieren. :D Ist sicher nicht die eleganteste Lösung, aber immerhin besser als Autostart. ;) Viele Grüße olc

Hi, ergänzend zu Norberts Hinweisen sei noch die Möglichkeit genannt, die Scripte in die lokale GPO aufzunehmen. Dann laufen sie auch ohne Domänenkontakt. Viele Grüße olc

Hi Emu und wollkommen an Board, :) hast Du Grundkenntnisse in Bezug auf SCOM? Falls nicht, wird es natürlich schwer, hier die notwendigen ersten Schritte zu vermitteln. Schau Dir doch erst einmal die online Dokumentationen etc. dazu an, dann kann man konkrete Fragen beantworten. Viele Grüße olc

Hi Soapp, Computereinstellungen gelten immer nur für Computer, Benutzereinstellungen nur für Benutzer. Welche Einstellung hast Du denn genau gesetzt? Laufen die Computer vielleicht im Loopback Processing Mode? Falls ja, würde der Benutzer "virtuell" in die Cmputer OU versetzt werden und somit würden die Einstellungen auch greifen, obwohl der Benutzer in einer anderen OU liegt. Viele Grüße olc

Hi Daniel, ich würde immer noch davon ausgehen, daß die ADMX Dateien nicht zu den ADML Dateien passen. Wenn es möglich ist, benenne einmal testweise den PolicyDefinitions Ordner auf dem SYSVOL beliebig um, ab diesem Zeitpunkt werden dann nach einem GPEDIT.MSC Neustart wieder die lokalen Windows 7 PolicyDefinitions genommen. Kommt es dann immer noch zu dem Fehler? Falls nicht, mußt Du für eine korrekte Zuordnung der ADMX zu ADML Dateien auf dem central store sorgen - da es derzeit die Kombination für W7 / 2008 R2 noch nicht zum Download gibt, müßtest Du also die gewünschten Sprachversionen manuell von W7 / 2008 R2 Systemen in den central store kopieren. Viele Grüße olc

Hi, welche Server Versionen werden eingesetzt? Außerdem müßten wir wissen, was Du für Daten sichern möchtest: Nur Dateien / Ordner oder auch Datenbanken, Exchange etc.? Ohne diese Angabe kann man kaum ein Backup Programm oder anderes Sicherungssystem empfehlen. ;) Viele Grüße olc

Moin, im Eröffnungsthread von Dir stand nichts vom R2. ;) Du kannst den W7 PolicyDefinitions Sprachordner auch auf den Server kopieren, das sollte klappen, auch wenn die MUI des Servers englisch ist. Ansonsten hat der Server selbst doch ebenfalls einen PolicyDefinitions Ordner - warum nimmst Du nicht den? Beschreibe doch noch einmal die Konstellation genauer, also OS, Sprachen, Dein Ziel etc. Viele Grüße olc

Hi, setze die SPNs einmal mit "Domänen Admin" Rechten: SETSPN -A WSMAN/server1.****.**** server1 und SETSPN -A WSMAN/server1 server1 . Dann sollte die Meldung verschwinden. :) Viele Grüße olc

Hi, sind die ADMX und ADML Dateien in der gleichen Version vorhanden? Ggf. einmal ersetzen: http://www.microsoft.com/downloads/details.aspx?FamilyID=927fc7e3-853c-410a-acb5-9062c76142fa&displaylang=en Viele Grüße olc

Moin, ok, gut daß Du nachfragst, ich habe mich undeutlich ausgedrückt: Meine Empfehlung wäre die, die DCs erst gar nicht aus der Domänencontroller OU heraus zu nehmen. Wenn es, wie beim TO passiert, nun doch schon der Fall ist, sollte man ganz genau prüfen, welche Abhängigkeiten in der aktuellen Konstellation existieren (etwa die genannten Zertifikate etc.) - und ggf. einzeln DCs nach Tests zurück zu verschieben, um bei Problemen sofort eingreifen zu können. Es kann alles problemlos laufen, aber die Erfahrung zeigt, daß es in der Praxis diverse Abhängigkeiten vom OU-Standort gibt. Viele Grüße olc

Hi, wie in dem Artikel auch zu lesen, ist das im Kern nicht wirklich supported. Selbst Sub-OUs in der Domain Controllers OU fallen schon darunter. Man sollte auch nicht vergessen, daß unter Umständen DC Zertifikate auf die alte OU Struktur verweisen (DN etc.) oder ähnliche Themen. Da gibt es noch weit mehr Dinge, die zu Problemen führen können. Solange Ihr es anders lösen könnt würde *ich persönlich* empfehlen, die DCs nicht zu verschieben. Viele Grüße olc

Hi, das ist doch mal ein guter Ansatz. :) Guter Startpunkt ist beispielsweise Public Key Infrastructure for Windows Server 2003 , jedoch finden sich auf Technet diverse größere und kleinere Artikel und Whitepaper dazu. EInfach mal die Technet Suche zu PKI und CA bemühen. :) Ansonsten kann ich das folgende Buch empfehlen: Windows Server® 2008 PKI and Certificate Security Einen kurzen Überblick findest Du auch hier: Public-Key-Infrastruktur ? Wikipedia Aber wie gesagt, das Thema ist kein Bereich, den man "mal eben" nebenbei anschaut. PKI ist ein breites Themengebiet und es benötigt meiner Erfahrung nach "mehr als ein Whitepaper", bis man die notwendigen Aspekte verstanden hat. Viele Grüße olc

Hi, BlankManBlog: Powershell 2.0 session MGT320 scripts and feedback Viele Grüße olc

Hi, von welchem Betriebssystem sprechen wir? Du könntest ab Vista / 2008 Trigger auf Änderungen im Verzeichnis setzen und dann mit simplen Scripts (etwa PowerShell) die neuen Dateien inhaltlich checken. Viele Grüße olc

Hi, deinstalliere einmal den Virenscanner auf dem System und versuche die Installation erneut. Deinstallieren, nicht nur deaktivieren. ;) Viele Grüße olc

Hi, warum ist "Security" ausgegraut und kein Eventlog ausgewählt? Wenn Du eine Event ID suchen läßt, die Du im Eventlog definitiv siehst, bekommst Du dann im EventComBT eine Rückmeldung. Für mich sieht es so aus, als ob der Durchlauf schlichtweg nicht erfolgreich ist, da kein Eventlog ausgewählt wurde. Alternativ schau Dir einmal PsLogList an, ehe Du Dich jetzt mit dem Tool beschäftigst anstatt mit dem Problem. Viele Grüße olc

Hi, a) Nein, es ist nur das Schema-Upgrade auf Windows Server 2003 R2 (v31) oder später (2008 oder 2008 R2) notwendig. b) In welche Richtung zielt die Frage? Ohne Deine Umgebung genauer zu kennen wird eine Antwort schwierig. c) Nein, hier ist DFSR standardmäßig auch dabei. Viele Grüße olc

Hi, eine CA auf einem DC zu installieren ist nicht optimal und sollte vermieden werden. Die Fehlermeldung zeigt an, daß Du scheinbar bei der Einrichtung der CA die notwendigen Aufgaben zur Konfiguration nicht durchgeführt hast - die URLs für die CRL sind also nicht korrekt bzw. sind dort keine CRLs verfügbar. Du mußt Dich zuallererst einmal mit den Grundlagen einer PKI beschäftigen, sonst wird das nichts. Schneller bist Du mit jemandem, der sich damit auskennt. Das notwendige Wissen können wir hier im Forum nicht "nebenbei" vermitteln. Viele Grüße olc