Jump to content

Microwork

Members
  • Gesamte Inhalte

    34
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Microwork

  1. P.S. Meint ihr es bringt etwas einen neue OU zu erstellen?
  2. Leider keine Lösung. Ich hab jetzt für die OU die GR in eine Benutzer- und in eine Computerrichtlinie aufgeteilt (man weiß ja nie) und diese der OU zugewiesen. Die alte GR hab ich gelöscht. Nun das Resultat: Der Client übernimmt nun die Sicherheitseinstellungen von der neuen Richtlinie, die Administrativen Einstellungen jedoch immer noch von der alten!??? Dabei sagt gpresult, dass die neuen GP angewendet werden. Ich bin am verzweifeln...
  3. Sodele, jetzt hab ich den Salat ;): Es wird anscheinend nicht nur auf ein paar Rechnern die GR nicht angewendet, sondern neuerdings auf keinen Rechnern mehr, bzw. die alten Einstellungen bleiben, neue werden nicht übernommen! Ich bin mächtig am Rudern!!! Die Standardüberprüfungen hab ich schon vorgenommen; geresult und gptool melden keine Fehler. Wenn ich einen Ergebnissatz erstelle, zeigt mir der Bericht für einen PC die Einstellungen an, die er übernommen hat - wenn ich diese dann mit den Einstellungen der GR vergleiche, fällt sofort auf, dass nicht alle Einstellungen übernommen werden. Speziell die neuen werden überhaupt nicht mehr angewendet! Woran kann das liegen? Die Microsoft Ressourcen geben mir absolut keinen Lösungsansatz mehr her! Ich sitz jetzt schon ansatzweise 48 Stunden an diesem Problem. Gibt es ein geeignetes Tool (nicht gptool oder gpresult), das die Anwendung der GR genau überwacht und Fehler feststellen kann? Wie ist Fazam? Es muss doch was anständiges geben, dass den Unterschied zwischen Source und Destination feststellt J. Krieg
  4. Wenn zuerst der Name des PCs im Anmeldedialog erscheint, deutet das darauf hin, dass der PC nicht als Standard in diese Domäne integriert ist, sondern der Domänenname lediglich im Domänen-Cache des PCs liegt und dieser deshalb in der Liste auftaucht. Schau Dir die Einstellungen des PCs an, überprüfe, dass dieser ordnungsgemäß in die Domäne integriert ist (Systemeigenschaften -> Computername -> Netzwerkkennung)
  5. Jepp. Strukturell alles in Ordnung. Wie gesagt, es werden nur teilweise die GR nicht angewendet. Im Falle der Firewall GR, wird die Freigabe für Datei und Drucker (oder so) angewandt, die Freigabe für Remotedesktop jedoch nicht :( In diesem Zusammenhang: Soll ich eigentlich nicht generell die Windows Firewall im Netzwerk deaktivieren? Das einzige Problem sind ja die "toten" Steckdosen, in die ein Eindringling sich einklinken könnte, oder? J. Krieg
  6. Hallo! Ich hab ein Problem bei einem Kunden: Es ist eine OU angelegt und Gruppenrichtlinien vergeben worden. Alle Clients sind Windows XP SP2. Server ist Windows 2003 SP1. Bei fast allen PCs werden die GRs angewendet, bis auf 3 Rechner. Der einzige Unterschied, den ich finden konnte, war, dass bei diesen 3 Rechner gpresult ergibt, dass "Richtlinien der lokalen Gruppe" für den PC angewendet werden. Normalerweise werden doch in der Domain die lokalen Richtlinien gefiltert (ist auf jeden Fall bei den restlichen PCs so). Speziell werden die Richtlinien für die Windows Firewall nur teilweise angewendet. Woran kann das liegen? Ansonsten finde ich keine Unterschiede zwischen den Rechnern!? :( Danke schonmal im Vorraus - J. Krieg
  7. Per Gruppenrichtlinie geht das nicht. Hier werden nur Einstellungen vorgenommen. Erstellt werden kann hier nichts. Ein Umweg wäre über ein Anmeldescript, in welchem Du eine Verknüpfung an einem beliebigen Ort erstellt (da gibts einen Befehl 'für, den ich jetzt aber aus dem Stand heraus nicht sagen kann); Noch einfacher geht es jedoch damit, dass man der speziellen OU ein bestimmtes Persönliches Startmenü angibt, in welchem dann die Verknüpfung liegt. Gruß - Johannes Krieg
  8. Ein Neustart bringt auch nichts. Niemand eine Idee?
  9. Hallo! Erstmal kompliment für dieses Forum! Sehr professionell!! :) Mein erster Beitrag. Mal schauen, obs hilft ;) [ich geh aber stark davon aus] Also, ich hab hier in eine Firma "eingeheiratet" und muss nun das Netzwerk auf Vordermann bringen. Alles bisher kein Problem. Ich musste neue Benutzer anlegen und Gruppenrichtlinien bzw. OUs anlegen. Kurz zur Struktur: 2 Windows 2003er DCs + 1 WinNT Server. DC2 ist der Exchangeserver. Der WinNT Server ist nicht als DC eingerichtet. Eine Domäne. Ein Standort. Die Benutzer und OUs wurden zwischen DC1 und DC2 wunderbar wie erwartet repliziert. Dann wollte ich die Konfiguration testen und stieß auf das Problem, dass anscheinend die Gruppenrichtlinien nicht übernommen wurden. Kurz auf die SYSVOL Freigabe unter "\\domain.local\SYSVOL\sysvol\policies" zugegriffen und erkannt, dass dort die neuen Gruppenrichtlinien nicht eingetragen wurden. Kurz und knapp, so kam ich auf das Problem, dass anscheinend die Replikation zwischen DC1 und DC2 nicht reibungslos funktioniert, was auch Evenvwr bestätigt: Auf DC1 (der "PDC") kommt die Ereignis-ID 13508 NICHT gefolgt von 13509. Also funktioniert die Replikation schon mal nicht. Auf DC2 (der "Exchange") kommt die Eregnis-ID 13568. Also wird der NTFRS durch diesen Fehler ("JRNL_WRAP_ERROR") blockiert, was wohl den Fehler auf DC1 auslöst. Mit Sonar hab ich das auch schon kontrolliert und dieses zeigt ebenfalls an, dass nur auf DC1 der Status OK ist und DC2 einen Fehler aufweist. Jetzt kam ich nach ewigem Stöbern und Suchen auf die scheinbare Lösung, dass man mit zwei Dingen DC2 wieder zum Laufen bekommt: 1. Den "Enable Journal Wrap Automatic Restore" Eintrag und 2. Den "BurFlags" Eintrag in die Registry. Meine Fragen nun: Muss man für diese Vorgänge den Server neu starten (wäre extrem schlecht, da er immer in-Use ist)? Könnten Komplikationen auftreten oder ist es möglich das ruhigen Gewissens per Remote-Wartung durchzuführen? Wird dadurch lediglich die Replizierung von SYSVOL "wiederholt" oder sind davon noch mehr Prozesse betroffen (die wieder Probleme machen könnten [z.B. Exchange])? Wie kann ich überprüfen, warum dieser Zustand zustande kam? Es wird immer beschrieben, man soll den letzten "OK"-Zustand suchen und dann zurückdenken, was verändert wurde. Leider ist mein Gedächtnis nicht mit dem der Vorgänger vereinbar und die haben nichts dokumentiert :( Ist es möglich ein CHKDSK (immerhin könnte ja auch das Journal defekt sein) im Laufenden Betrieb für SYSVOL durchzuführen? Vielen Dank schon mal im Vorraus Microwork
×
×
  • Neu erstellen...