Jump to content

olc

Expert Member
  • Gesamte Inhalte

    3.978
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von olc

  1. Hallo,

     

    man kann in keiner Umgebung die Aussage treffen: "Das glaube ich nicht, denn das funktioniert auf anderen Clients auch." Es gibt derart viele Wechselwirkungen, daß sich das niemals einfach so sagen läßt. Also würde ich der Deinstallation des Virenscanners auf Server und Client eine Chance geben.

     

    Zusätzlich hatte ich in meinem letzten Beitrag zwei Links angeführt, auf die Du hier nicht weiter in Deiner Antwort eingegangen bist. Vielleicht solltest Du das also auch erst einmal prüfen. :)

     

    Viele Grüße

    olc

  2. Hallo,

     

    man sollte davon ausgehen, daß bei der recht eindeutigen Fehlermeldung die CDPs / AIA nicht per HTTP erreichbar sind oder? ;)

     

    Soll heißen, wahrscheinlich stimmen die Pfade dahin nicht bzw. der IIS / WebServer hat Probleme. Ggf. könntest Du also einmal prüfen, ob die Pfade denn manuell erreichbar sind (das wird nicht der Fall sein) und dementsprechend auf dem IIS überprüfen, ob die Dateien dort vorhanden sind bzw. das entsprechende Verzeichnis veröffentlicht.

     

    Ansonsten kann es auch sein, daß die falschen Pfade bei der CA Einrichtung angegeben wurden, das sollte dann schnell auf der CA geändert werden. Für bestehende Zertifikate läßt sich das jedoch nicht mehr anpassen.

     

    Viele Grüße

    olc

  3. Hi,

     

    werden die Daten unter Umständen repliziert, etwa mittels DFSR oder FRS?

    Falls ja kann es zu Konflikten gekommen sein und damit die alte Datei überschrieben werden. Oder die Replikation ist noch nicht durch, wenn Dein Client sich auf das zweite Target verbindet.

     

    Vielleicht gibst Du noch ein paar mehr Informationen zur Umgebung und dem Problem, dann kann man das vielleicht besser eingrenzen.

     

    Viele Grüße

    olc

  4. ...wobei dazu noch zu sagen wäre, daß die Deaktivierung der Option "bridge all site links" auch "Nebenwirkungen" mit sich bringt - so setzt beispielsweise DFSN darauf auf. Ohne die Option sind sitespezifische Referrals nicht mehr möglich - auch nicht für das SYSVOL.

     

    Das läßt sich jedoch mit ein wenig Arbeit bzw. einem etwas anderen Vorgehen in den Griff bekommen: The Storage Team at Microsoft - File Cabinet Blog : New for Windows Server 2003 SP1: the ability to turn off Bridge All Site Links without breaking DFS site costing

     

    Viele Grüße

    olc

  5. Hi naison und herzlich willkommen an Board,

     

    zu 1) Soweit ich weiß, mußt Du bei "externen" Veröffentlichungspunkten die Veröffentlichung manuell vornehmen, d.h. etwa scripten oder ähnliches. Eine von der SubCA initiierte Verteilung wäre mir persönlich nicht bekannt.

    Denk in diesem Zusammenahng auch daran, daß die AIA / CDP der offline Root CA verfügbar sein sollten, sonst kann die key chain vom Client nicht verifiziert werden, siehe dazu auch: Event ID 100 ? AD CS Certification Authority Certificate and Chain Validation .

     

    zu 2) Nein, in den ausgerollten Zertifikaten sind die Sperrlistenverteilungspunkte fest eingetragen. Hier kannst Du in bestehende Zertifikate keine zusätzlichen Einträge hinzufügen, vielmehr müßten die Zertifikate neu ausgestellt werden.

    Aus dem Grund müssen die CDP (CRL distribution points) immer frühzeitig gut geplant werden - sonst läuft Du schnell in Probleme, wenn sich die Verteilungspunkte ändern.

     

    zu 3) Die SubCAs können keine Sperrlisten für die jeweils andere CA ausstellen - jede Datenbank arbeitet für sich. D.h. für richtige Ausfallsicherheit müßtet Ihr die SubCAs clustern: Installing and Configuring the CA Cluster .

     

    Viele Grüße

    olc

  6. Hi Canni,

     

    und was möchtest Du damit sagen? ;)

     

    Hoffentlich nicht, daß das richtig so ist. Denn solche Firmen sind dann meist auch diejenigen Firmen, die am lautesten schreien, wenn Sie einen eklatanten Sicherheitsvorfall hatten oder Ihre Domäne geschrottet ist.

     

    Von daher ist das "Argument" eher fragwürdig.

     

    Ich denke, es ist doch alles zu dem Thema gesagt oder? Und genügend Hinweise, wie man es besser macht, kamen auch noch von den verschiedenen Kollegen. Den Rest muß der TO wohl oder übel selbst entscheiden und man kann nur hoffen, daß auch sicherheitstechnischer Sicht die richtigen Entscheidungen getroffen werden.

     

    Viele Grüße

    olc

  7. Hi,

     

    neben den wichtigen Hinweisen / Fragen von XP-Fan und der Produktempfehlung von Thomas vielleicht noch der Hinweis auf "normale" Replikationstechniken (wie z.B. WAFS oder DFSR), wenn es nur um Fileservices geht.

     

    Damit kannst Du die Fileserver Daten bandbreitenschonend in Dein Datacenter replizieren und dort dann sichern.

     

    Wie oben schon von XP-Fan gesagt kommt es auf die Anforderungen an, daher wäre es optimal, wenn Du es diese wenig genauer beschreiben würdest.

     

    Viele Grüße

    olc

  8. Hi,

     

    ich kenne mich mit dem KMS nicht aus - aber ich dachte immer, daß man einen KMS laufen lassen muß, wenn man Terminal Server Dienste nutzt (hatte da etwas von 180 Tagen im Kopf)? Aber vielleicht irre ich mich da auch.

     

    Falls wirklich nicht notwendig, stoppe den Dienst doch einfach auf dem TS. Dann sollte der Fehler nicht mehr auftreten.

     

    Viele Grüße

    olc

  9. Hi,

     

    wahrscheinlich hat das Metadata Cleanup gefehlt oder - wie auch als Fehlertext angegeben - es war schlichtweg ein Rechner mit dem gleichen Namen im Netz.

     

    Trotzdem komme ich nicht umhin zu fragen, ob tatsächlich ganze 3 1/2 Stunden für eine Antwort auf einen unleserlichen Thread zu viel sind, der ohne Begrüßung, ohne äußere Form und nur in Stichpunkten verfaßt wurde?

     

    Da der TO hier neu ist, vielleicht der kurze Hinweis, daß das Board hier kostenfrei ist und auch gewisse Umgangsformen gepflegt werden. Die Alternative dazu ist dann ein entsprechend kostenpflichtiger Supportvertrag mit Service Level Agreement bei einem Dienstleister Deiner Wahl.

     

    Viele Grüße

    olc

  10. Hi Edgar,

     

    ok - man hätte zumindest die Standard-GPOs wiederherstellen können, aber die nicht gesicherten Policies wären "verloren"gewesen, wenn kein Backup vorhanden ist.

    Neuaufbau ist natürlich auch eine "Lösung". :D

     

    Drücke Dir die Daumen, daß dann am Montag alles klappt. Am besten Du setzt gleich ein korrektes Backup auf, also Systemstate und GPMC GPO Backup per Taskplaner o.ä. :)

     

    Viele Grüße

    olc

  11. Hi Edgar,

     

    verschiebe einmal den Inhalt des "DO_NOT_REMOVE_NtFrs_PreInstall_Directory" Verzeichnisses direkt in das "C:\WINDOWS\SYSVOL\sysvol\1Lubeca.loc" Verzeichnis. Dort sollten bestenfalls der "Policies" und der "Scripts" Ordner samt Inhalt zu finden sein.

     

    Wenn das nicht der Fall ist, schau einmal in das Systemstate Backup - sind die Ordner dort vorhanden?

     

    Falls ja, dann sichere diese an einen alternativen Ort zurück und kopiere sie dann in den Ordner "C:\WINDOWS\SYSVOL\sysvol\1Lubeca.loc". Falls nicht vorhanden, ist das Problem ein etwas größeres, denn dann sind die Policies irgendwann einmal "abhanden gekommen" und müßten von Dir ggf. allesamt wieder neu angelegt werden (ggf. mit Hilfe von einigen Tools, aber da müßte man dann später noch einmal drüberschauen, wenn der derzeitige Status klarer ist).

     

    Viele Grüße

    olc

  12. N'Abend,

     

    das Problem bei Edgar ist, daß der DC1 derzeit der einzige DC der Domäne ist (siehe oben). Der DC2 kann dementsprechend nicht vollständig promotet werden, da er das SYSVOL vom "defekten" DC1 nicht bekommt / nicht bekommen kann.

     

    Daher bleibt nur (wie oben angesprochen) den DC1 selbst auf D4 zu setzen und den neuen DC2 auf D2 zu stellen. Damit sollte es klappen.

    Aber so, wie ich das DCDIAG oben lese, scheint es damit schon geklappt zu haben. Nun warten "nur noch" die anderen Fehler darauf, behoben zu werden. :D

     

    Viele Grüße

    olc

  13. Hi,

     

    also das SYSVOL scheint wieder da zu sein. Was sagt das Eventlog?

     

    Nun fehlen wahrscheinlich noch die DC DNS SRV Einträge. Ggf. noch einmal den NETLOGON Dienst auf DC1 starten - in diesem Zusammenhang könntest Du auch noch einmal die DNS Server Einträge in den TCP/IP Einstellungen des DC1 prüfen.

     

    Was ist in der Umgebung passiert? Kein Monitoring?

     

    Der nicht mehr existierende DC in den Standorten und Diensten hat noch ein untergeordnetes NTDS Objekt? Falls ja, müßtest Du für diesen DC ein "metadata cleanup" durchführen. Wenn es kein NTDS Objekt mehr unter dem Objekt gibt, ist es kein Problem. Das Serverobjekt kannst Du (falls gewünscht) dann einfach löschen.

     

    Viele Grüße

    olc

  14. Hi Edgar,

     

    Du könntest versuchen, den betroffenen DC einmal auf D2 zu setzen: Troubleshooting journal_wrap errors on Sysvol and DFS replica sets .

     

    Wenn das allein nicht hilft, müßte ein "guter" DC auf D4 gesetzt werden - aber Achtung, das zieht die komplette Replikation des SYSVOL für alle anderen DCs bedeuten, diese müssen vorher auf D2 gesetzt werden. Ich würde es also erst einmal mit einem "alleinstehenden" D2 versuchen.

     

    EDIT:

    Ah, stopp: Ich habe übersehen, daß die Meldung ja auf dem ersten DC geloggt wird. Wie viele DCs sind in der Domäne vorhanden?

    Wenn es sich nur um die beiden DCs handelt (der alte und der neue), dann kannst Du den 1. DC auf D4 setzen und den neuen auf D2. Das sollte das Problem beheben.

     

    Viele Grüße

    olc

  15. Hallo,

     

    genau wie RanCyyD sagte, der String bringt eine Menge Ergebnisse. :)

    Stichwort ist D4 / D2, siehe dazu auch: How to rebuild the SYSVOL tree and its content in a domain

     

    P.S.: Bitte schreibe 100x an die Tafel: "Nein, ich werde nicht meine Acronis Image Sicherung von nur einem DC zurücksichern, denn das würde die Umgebung noch mehr beschädigen und einen USN Rollback hervorrufen." ;)

     

    Viele Grüße

    olc

  16. Hallo,

     

    damit Du hier nicht noch mehr "SPAM" verbreitest möchte ich Dir den Hinweis geben, daß Dein Vorhaben keinen Sinn macht. Denn wenn Du diesen Dialog unterdrücken würdest, würde auch beim zweiten Boot nach dem Kopiervorgang der Daten (mit eingelegter DVD) der gleiche Vorgang wieder gestartet werden.

     

    Die Windows NT Benutzer unter uns kennen das Problem sicher noch...

     

    Wenn Du es trotzdem (ohne Sinn) erzwingen möchtest, hätte eine 2 minütige Web-Recherche ausgereicht, um eine Möglichkeit zu finden: Installing Windows to an EFI-Based Computer

     

    Und in den Foren, die ich so kenne, verbietet es die Netiquette, Cross-Postings auf verschiedenen Foren zu machen und damit sinnfrei Ressourcen zu binden... Das MCSEboard.de wäre also ausreichend gewesen.

     

    Gruß olc

  17. :D :D :D

     

    Gar keine schlechte Idee - zumal damit vielleicht auch die Cross-Postings aufhören würden. Das Problem scheint beim TO so wichtig zu sein, daß er es jetzt auch noch auf verschiedenen Foren postet.

     

    Da fragt man sich, warum dann kein Dienstleister bezahlt wird - das wäre bei einem scheinbar derart wichtigen Unterfangen doch eher die Lösung oder?

     

    So etwas macht mich immer wieder "traurig"... :rolleyes:

     

    Viele Grüße

    olc

×
×
  • Neu erstellen...