Jump to content

SEMA

Members
  • Gesamte Inhalte

    31
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von SEMA

  1. SEMA

    Windows 7 Samba

    Tausend Dank! Genau das wars ... :)
  2. SEMA

    Windows 7 Samba

    Ich habe hier gerade das gleiche Problem. Eingesetzt werden zwei Rechner mit SuSE 8.3 und SuSE 9.2 mit jeweils Samba 3.0.20. Die Shares werden über DFS-Verknüpfungen eines Win2k Domänencontrollers im Netz verteilt. Unter Windows Vista habe ich die Registry im LmCompatibilityLevel entsprechend geändert und alles hat funktioniert. Windows 7 interssiert das jedoch überhaupt nicht. Gibt es hierzu schon eine Lösung? Die beiden SuSE-Rechner sollen auf absehbare Zeit "sterben", jeodch bräuchte ich für die Übergangszeit eine Lösung. Danke und viele Grüße
  3. Beim nächsten Mal ist es sicher nicht mehr schwer ... Und was soll ich sagen? Es funktioniert!!!! Keine Fehlermeldungen mehr!!! "Die Sicherheitsrichtlinien in den Gruppenrichtlinien wurden erfolgreich angewendet" Du hast mir den Tag gerettet Nobex! *jubel* Tausend Dank nochmal! :jau:
  4. Manchmal müssen einem die Augen geöffnet werden ... Unter "Alle" stehen sie drin. Alle beide ... :rolleyes: Ist ja peinlich Tausend Dank Nobex! Eine kleine bescheidene Frage noch: Unter "Verwaltung" -> "Active Directory-Benutzer und -Computer", Rechtsklick auf die Domäne -> "Eigenschaften" -> "Gruppenrichtlinien" ... kommen da beide Defaults rein oder nur die Default Domain Policy? Falls da nur diese rein kommt ... Wohin verlinke ich dann die Default Domain Controller Policy?
  5. Die beiden Ordner sehe ich über den Explorer unter ...\sysvol\domainname\policies. Dort werden die mit recreatedefpol sauber erstellt und auf die anderen DCs repliziert. Wenn ich jetzt über "Verwaltung" -> "Active Directory-Benutzer und -Computer" einen Rechtsklick auf die Domäne mache und dort auf "Eigenschaften" -> "Gruppenrichtlinien" klicke, dann sehe ich dort in der Auswahlliste nur die von mir selbst erstellte Richtlinie. Dort sollte doch normalerweise auch die Default Policy stehen ... Ich kann da zwar auf "Hinzufügen" klicken aber ich finde die Defaults nicht. Vielleicht liegt es auch an meinen mittlerweile eckigen Augen ... ;)
  6. Hallo Nobex, das Tool habe ich tatsächlich recht frühzeitig eingesetzt. Da wusste ich aber noch nichts von den beiden Ordnern die Du selbst gerade erwähnst. Ich dachte wenn man das Tool ausführt dann ist alles wieder gut. ;) Also ... die beiden Ordner sind da. So weit so gut. Aber normalerweise sollten die beiden Policies doch in der Auswahl der Richtlinien erscheinen (falls ich jetzt nicht komplett alles missverstanden habe). Das tun sie aber nicht. In der Auswahl ist nach wie vor nur meine eigene, selbst erstellte Gruppenrichtlinie zu sehen. Wie bekomme ich die da wieder rein?
  7. Wieder ein Wochenende grübelnd und testend mit diesem Problem verbraten ... Ich denke ich bin der Ursache jetzt auf die Spur gekommen. Es fehlen schlicht und einfach die Default Policies. Und zwar alle beide. - Default Domain Policy und - Default Domain Controller Policy Warum und vor allem wohin die verschwunden sind bleibt wohl für immer ein Rätsel. Auf alle Fälle habe ich das Tool "recreatedefpol" ausgeführt welches die beiden Policies wieder herstellen sollte. Ich habe mich aus- und wieder eingelogged so wie es beschrieben wird aber die beiden Policies tauchen trotzdem nicht auf. Habe ich was vergessen? Wie bekommt man die beiden Policies wieder in die Auswahlliste? Ich finde leider keine ausführliche Anleitung zu dem Tool. :(
  8. Ich habe auf den drei übrigen DCs alles was ich über den demoteten DC gefunden habe gelöscht. Ich gehe davon aus, dass da nichts mehr übrig war ... Eine Garantie habe ich natürlich keine.
  9. Hallo zusammen! Vielleicht kann mir hier jemand einen Tip geben. Ich habe hier eine Win2k-Maschine mit einer intel Quad-Core CPU stehen. Darauf läuft ein Task der per Systemdienst gestartet wird welchem ich gerne einen einzigen, bestimmten Core zuweisen würde. Wenn ich das über den Taskmanager per Rechtsklick -> "Zugehörigkeit festlegen" versuche, erhalte ich die Fehlermeldung "Kein Zugriff auf Prozessaffinität. Der Vorgang konnte nicht beendet werden. Zugriff verweigert" Wie kann man das in den Griff bekommen? Hier zu noch etwas anderes ... sind diese Einstellungen dauerhaft? Bleiben diese nach einem Neustart des Rechners erhalten oder muss ich diese Einstellungen jedes Mal neu eingeben?
  10. Nachtrag: Ich habe es jetzt doch gewagt und den DC per Ghost Offline-Image auf die neue Hardware übertragen. Dazu habe ich die anderen beiden DCs ebenfalls ausgeschaltet. und vorab eigentlich nur den Treiber für die Netzwerkkarte installiert. Nach dem ersten Neustart die restlichen Treiber installiert, alte Treiber entfernt, ein weiterer Neustart, starten der beiden anderen DCs und fertig. Das ganze funktioniert astrein. Keinerlei Fehler in den logs oder sonstige Probleme.
  11. So ... leider hat das alles nicht geholfen. Ich habe den entsprechenden Domänencontroller per dcpromo erst de- und dann wieder promotet. Das Problem besteht nach wie vor ... :( Hat jemand noch eine andere Idee?
  12. Ooops. Sorry ... Wer lesen kann ist klar im Vorteil.
  13. ?¿? Öhm ... Alles was ich vor hatte war die FSMO Schema master von dem DC der herumkaspert auf einen anderen zu übertragen, diesen zu demoten und danach wieder zum DC zu promoten. Warum sollte ich die HDU formatieren wollen?
  14. Der Server hält zwar die FSMO Schema Master aber die sollte sich ja problemlos auf einen der anderen DCs schieben lassen. Der GC läuft auf allen vier DCs, daher sollte das auch kein Problem darstellen. Dann werde ich das wohl oder übel am Wochenende versuchen. Vorher wird das leider nichts ... Danke nochmals für die guten Tipps so weit. :)
  15. Hat hierzu noch jemand einen Einfall? Oder gibt es noch was was ich versuchen könnte? Danke für die Bemühungen :)
  16. Hallo grizzly999! Danke für die Info mit den Anmeldeservern, das wusste ich noch nicht. Ich habe mit dem "set"-Befehl verschiedene Clients überprüft. Es ist tatsächlich so, dass die Gruppenrichtlinien nur dann nicht funktionieren wenn die Clients den abgestürzten Server als Anmeldeserver verwenden. Wird einer der anderen drei benutzt dann funktionieren diese. Es sind dann keine Fehler im Log des Clients. Es werden aber nach wie vor auf allen vier Domänencontrollern im 5-Minuten-Takt die weiter oben bereits beschriebenen Fehlermeldungen ausgegeben. Ob DNS sauber läuft möchte ich jetzt nicht schwören müssen aber es sind alle DCs so weit ich das beurteilen kann eingetragen wo sie meiner Meinung nach auch hingehören. Um das ganze noch einmal aufzurollen ... Ursache war ein Absturz mit BSOD dieses Servers. Danach lief der darauf installierte DHCP-Server nicht mehr. Ich habe diesen dann neu aufgesetzt. Kann hier irgendwas schief gelaufen sein? Würde es Sinn machen diesen nochmals zu deinstallieren und neu einzurichten? Noch was anderes: Würde es was bringen den abgestürzten Server im Wiederherstellungsmodus zu starten und zu restoren? Oder hole ich mir damit eventuell noch andere Probleme ins Haus? Wie alt darf eine Sicherung maximal sein?
  17. @nobex: Willkommen auf dem Schlauch ... :) Vielen Dank für Deine Hilfe. @lefg: Es sind in der Domäne alle FSMO-Funktionen sowie der globale Katalog da. Wobei der GC auf allen vier Domänencontrollern läuft. Nein, der DC der abgeschmiert ist war nicht der erste in der Domäne. Er hält die FSMO-Funktion Schema Master und ebenfalls wie die anderen den GC. Ich checks echt nicht mehr ... P.S.: Das Problem mit Event-ID 13559 NtFrs ist Dank dem Link von macdaniels erledigt. Vielen Dank nochmal.
  18. @mcdaniels: Danke für Deine Hilfe und für den Link. @nobex: Wenn ich auf den Domänencontrollern unter Start -> Ausführen -> \\domainname eingebe dann bekomme ich eine Fehlermeldung: "Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch". Wenn ich das auf den Clients eingebe dann werden mir die Freigaben der DCs sowie die DFS-Struktur angezeigt. nslookup ergibt auf dem Domänencontroller der abgestürzt war folgendes: Server: server-2.zentrale.firma.de Adress: 192.168.1.3 Name: zentrale.firma.de Adresses: 192.168.1.3 192.168.1.2 192.168.1.4 192.168.1.5
  19. Hallo macdaniels, sorry mein Fehler. Da habe ich in der Eile nicht aufgepasst bei der Antwort. Ja, in der DNS MMC unter _msdcs sind alle vier Domänencontroller drin. Auch in den anderen Einträgen sind alle Domänencontroller eingetragen. DNS ist AD integriert und die Einstellung für die dynamische Aktualisierung ist in den Forward Lookupzonen auf "Ja". In den Reverse Lookupzonen steht die Einstellung auf "Nur gesicherte Aktualisierungen" Was die Event-ID 13559 NtFrs angeht ... Sollte ich da besser einen neuen Thread erstellen? Das Ding macht mir bald mehr Sorgen wie die Gruppenrichtlinien.
  20. Hallo mcdaniels, Ja, die Freigabe ist da. Ja, ist er. An erster Stelle er selbst und als zweites ein weiterer Domänencontroller. Nein. Das zwar nicht aber ich habe z.B. gestern Abend den Server mehrfach neu gestartet. Im Anwendungsprotokoll (welches jeden zweiten Tag überläuft) steht nach wie vor alle 5 Minuten die Event-ID 1000 Userenv. "Die Abfrage der Gruppenrichtlinien ist fehlgeschlagen. Bisher wurde eine Fehlermeldung dieser Art im Richtlinienmodul protokolliert." und Event-ID 1000 Userenv "Auf die Datei gpt.ini des Gruppenrichtlinienobjekts kann nicht zugegriffen werden. Die Datei muss im Pfad <> vorhanden sein (). Die Verarbeitung der Gruppenrichtlinie wird abgebrochen." Im Sicherheits-, System-, Directory-Service- und DNS Server-Protokoll sind keinerlei Fehlermeldungen. Aber im Protokoll des Dateireplikationsdienstes steht ca. alle 24 Stunden etwas das mich beunruhigt: Event-ID 13559 NtFrs "Der Dateireplikationsdienst hat ermittelt, dass ein Replikatstammpfad von "d:\sysvol\domain" in "d:\sysvol\domain" geändert wurde. Falls diese Änderungen absichtlich vorgenommen wurde, muss die Datei NTFRS_CMD_FILE_MOVE_ROOT im neuen Stammpfad neu erstellt werden. Folgendes wurde für diesen Replikatssatz ermittelt: "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" Die Replikatstammpfadänderung erfolgt in zwei Schritten, die durch das Erstellen der Datei NTFRS_CMD_FILE_MOVE_ROOT ausgelöst wird. [1] Bei der ersten Abfrage, die in 5 Minuten durchgeführt wird, wird dieser Computer vom Replikatssatz entfernt. [2] Bei der darauffolgenden Abfrage wird der Computer dem Replikatssatz erneut hinzugefügt. Durch das Hinzufügen wird eine vollständige Struktursynchronisierung ausgelöst. Nach der Synchronisierung befinden sich alle erforderlichen Dateien am neuen Ort." Was ist das denn bitte?¿? Gerne mache ich das: Windows 2000-IP-Konfiguration Hostname. . . . . . . . . . . . . : server-2 Primäres DNS-Suffix . . . . . : zentrale.firma.de Knotentyp . . . . . . . . . . . . : Hybridadapter IP-Routing aktiviert. . . . . . . : Nein WINS-Proxy aktiviert. . . . . . : Nein DNS-Suffixsuchliste . . . . . . .: zentrale.firma.de firma.de Ethernetadapter "LAN-Verbindung": Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : 3Com Gigabit LOM (3C940) Physikalische Adresse . . . . . . : 00-0C-6E-93-7F-44 DHCP-aktiviert. . . . . . . . . . : Nein IP-Adresse. . . . . . . . . . . . : 192.168.1.3 Subnetzmaske. . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . .: 192.168.1.190 DNS-Server. . . . . . . . . . . . : 192.168.1.3 192.168.1.2 Primärer WINS-Server. . . . : 192.168.1.3 Sekundärer WINS-Server. . .: 192.168.1.2 Ich kriege hier echt keinen Kopf mehr zusammen ...
  21. So, ich konnte das jetzt endlich mal halbwegs in Ruhe ansehen und Eure Tips ausprobieren. Der Befehl dfsutil /PurgeMupCache funktioniert nicht. Falscher Parameter. Laut replmon treten bei der Replizierung keine Fehler auf. Zumindest werden bei keinem der Domänencontrollern Fehler bei "Search Domain Controllers for Replication Errors" angezeigt. Bei dcdiag sieht es da schon wieder anders aus. Auf dem Domänencontroller der mit BSOD (das ist der Schema Master) abgestürzt ist heisst es: Doing initial required tests: . . . GUID DNS name could not be resolved to an IP adress. Check the DNS server, DHCP, server name, etc. Although the GUID DNS name ... couldn`t be resolved, the server name ... resolved to the IP adress (192.168.1.3) and was pingable. Check that the IP adress is registered correctly with the DNS server. . . . Doing primary tests: . . Skipping all tests because server ... is not responding to directory service requests Enterprise tests und FSMO check sind in Ordnung. Allerdings sind ein paar andere Sachen "seltsam". Auf den anderen Domänencontrollern bekomme ich über dcdiag ebenfalls eine Fehlermeldung in Bezug auf das Active Directory. Auf dem Server der die FSMO Funktionen PDC, RID, Infrastructure und Domain Tree hat erscheint folgendes: Starting test frssysvol There are errors after the SYSVOL has been shared. The SYSVOL can prevent the AD from starting. Alle anderen Tests auf diesem Server sind in Ordnung. Auf den anderen beiden Servern die keinerlei FSMO Funktionen tragen ist folgende Fehlermeldung zu sehen: Starting test frssysvol Error: No record of File Replication System, SYSVOL started. The Active Directory may be prevented from starting. There are errors after the SYSVOL has been shared. The SYSVOL can prevent the AD from starting. Ich glaube hier liegt insgesamt nicht nur ein Problem vor. Allerdings wäre es jetzt erst einmal am wichtigsten das Problem mit der DNS auf dem Schema Master irgendwie in den Griff zu kriegen. Wie kann/soll/muss ich vorgehen? Danke und viele Grüße
  22. Hallo zusammen, ich habe hier seit gestern ein Problem dem ich nicht beikomme. Hier stehen insgesamt 4 Win2k-Domänencontroller (alle mit aktuellem SP und aktuellen Patches). Einer von denen ist gestern mit BSOD abgeschmiert, Nach dem Neustart funktionierte der darauf installierte DHCP-Server nicht mehr und musste neu eingerichtet werden. Dieser verteilt jetzt auch brav wieder die IP-Adressen. Ob das jetzt was mit dem Gruppenrichtlinien zu tun haben kann weiss ich nicht. Aber seit dem Absturz werden die Gruppenrichtlinien nicht mehr verteilt. Jeder Client hat im Ereignisanzeige nach dem Login unter Anwendungen folgendes stehen: Ereignis-ID 1054 Userenv Der Domänencontrollername für das Computernetzwerk konnte nicht ermittelt werden. (Die angegebene Domäne ist nicht vorhanden oder es konnte keine Verbindung hergestellt werden. ). Die Verarbeitung der Gruppenrichtlinie wurde abgebrochen. Der Zugriff auf die gesamte Domäne funktioniert jedoch absolut fehlerfrei. Alle Freigaben und Anwendungen funktionieren auf den Clients. Auf ALLEN Domänencontrollern erscheinen im 5-Minuten-Takt in der Ereignisanzeige folgende Fehlermeldungen: Ereignis-ID 1000 Userenv Die Abfrage der Liste der Gruppenrichtlinienobjekte ist fehlgeschlagen. Bisher wurde eine Fehlermeldung dieser Art im Richtlinienmodul protokolliert. Ereingis-ID 1000 Userenv Auf die Datei gpt.ini des Gruppenrichtlinienobjekts kann nicht zugegriffen werden. Die Datei muss im Pfad <> vorhanden sein. (). Die Verarbeitung der Gruppenrichtlinie wird abgebrochen. Aufgrund dessen habe ich mit dem Tool recreatedefpool.exe die Standardgruppenrichtlinien wiederhergestellt. Da die PDC FSMO aber auf einem anderen Domänencontroller läuft musste das Tool dort ausgeführt werden. Das wurde auf allen Domänencontrollern übernommen ... bis auf den einen der den Absturz hatte. Dort steht unter Sysvol\domänenname\Policies immer noch die ID der alten Policy aber das Script ist dort auch weg. Das bedeutet, dass eigentlich nirgendwo eine Richtlinie hinterlegt ist aber die Fehlermeldungen erscheinen trotzdem alle 5 Minuten. Egal welche Änderungen ich an den Gruppenrichtlinien mache, auf diesen einen DC werden diese nicht übertragen. Und das ist dummerweise genau der, der diese verteilen sollte. Wenn man an den Clients gpresult laufen lässt heisst es unter Benutzereinstellungen: . . . Neues Gruppenrichtlinienobjekt Filterung: Nicht angewendet (unbekannte Ursache) . . Weiss jemand Rat? Was ist mit diesem DC faul? Wie bringe ich diesen einen DC dazu die Gruppenrichtlinien wieder mit den anderen DCs abzugleichen? Was sich völlig meiner Kenntnis entzieht: Wie bringt man einen anderen DC dazu die Gruppenrichtlinien an die Clients zu übergeben?
  23. Hallo zusammen, ich habe hier seit gestern ein Problem dem ich nicht beikomme. Hier stehen insgesamt 4 Win2k-Domänencontroller (alle mit aktuellem SP und aktuellen Patches). Einer von denen ist gestern mit BSOD abgeschmiert, Nach dem Neustart funktionierte der darauf installierte DHCP-Server nicht mehr und musste neu eingerichtet werden. Dieser verteilt jetzt auch brav wieder die IP-Adressen. Ob das jetzt was mit dem Gruppenrichtlinien zu tun haben kann weiss ich nicht. Aber seit dem Absturz werden die Gruppenrichtlinien nicht mehr verteilt. Jeder Client hat im Ereignisanzeige nach dem Login unter Anwendungen folgendes stehen: Ereignis-ID 1054 Userenv Der Domänencontrollername für das Computernetzwerk konnte nicht ermittelt werden. (Die angegebene Domäne ist nicht vorhanden oder es konnte keine Verbindung hergestellt werden. ). Die Verarbeitung der Gruppenrichtlinie wurde abgebrochen. Der Zugriff auf die gesamte Domäne funktioniert jedoch absolut fehlerfrei. Alle Freigaben und Anwendungen funktionieren auf den Clients. Auf ALLEN Domänencontrollern erscheinen im 5-Minuten-Takt in der Ereignisanzeige folgende Fehlermeldungen: Ereignis-ID 1000 Userenv Die Abfrage der Liste der Gruppenrichtlinienobjekte ist fehlgeschlagen. Bisher wurde eine Fehlermeldung dieser Art im Richtlinienmodul protokolliert. Ereingis-ID 1000 Userenv Auf die Datei gpt.ini des Gruppenrichtlinienobjekts kann nicht zugegriffen werden. Die Datei muss im Pfad <> vorhanden sein. (). Die Verarbeitung der Gruppenrichtlinie wird abgebrochen. Aufgrund dessen habe ich mit dem Tool recreatedefpool.exe die Standardgruppenrichtlinien wiederhergestellt. Da die PDC FSMO aber auf einem anderen Domänencontroller läuft musste das Tool dort ausgeführt werden. Das wurde auf allen Domänencontrollern übernommen ... bis auf den einen der den Absturz hatte. Dort steht unter Sysvol\domänenname\Policies immer noch die ID der alten Policy aber das Script ist dort auch weg. Das bedeutet, dass eigentlich nirgendwo eine Richtlinie hinterlegt ist aber die Fehlermeldungen erscheinen trotzdem alle 5 Minuten. Egal welche Änderungen ich an den Gruppenrichtlinien mache, auf diesen einen DC werden diese nicht übertragen. Und das ist dummerweise genau der, der diese verteilen sollte. Wenn man an den Clients gpresult laufen lässt heisst es unter Benutzereinstellungen: . . . Neues Gruppenrichtlinienobjekt Filterung: Nicht angewendet (unbekannte Ursache) . . Weiss jemand Rat? Was ist mit diesem DC faul? Wie bringe ich diesen einen DC dazu die Gruppenrichtlinien wieder mit den anderen DCs abzugleichen? Was sich völlig meiner Kenntnis entzieht: Wie bringt man einen anderen DC dazu die Gruppenrichtlinien an die Clients zu übergeben?
  24. Öhmm ... aber dann ginge es ja doch so wie ich es zuerst vorhatte. Nur dass das Image eben nicht in der alten Hardware, sondern in der neuen zum Einsatz kommt. Dass ich den alten DC nach dem Imagen nicht mehr einschalte war eigentlich klar. Oder stehe ich jetzt völlig neben mir?
  25. O.K. ... Die Profis hier müssen es wissen. Dann lasse ich lieber die Finger davon. Da für den Hardwaretausch nicht wirklich eine Deadline gesetzt ist kann ich mir das mit Acronis näher ansehen. Was ich bisher darüber gelesen habe klingt so weit ganz gut. Hat hierzu jemand gute Info- oder Bezugsquellen?
×
×
  • Neu erstellen...