phoenixcp

Du hast ihn wieder entfernt? Wie soll denn dann eine Replikationsverbindung aufgebaut werden? Beim DCPromo wird er dort eingetragen und anschliessend "kaspern" sich die DC's die Replikationsverbindungen untereinander aus. Du kannst diese allerdings auch händisch wieder anlegen und damit selber die Verbindung der DC's herstellen. Anschliessend "sollte" die Replikation funktionieren.

Im Enterprise-Manager im Normalfall. Dort kannst du den Speicherort der Datenbanken festlegen. Wäre es nicht sinnvoller gewesen, die DB's woanders hinzulegen? Unter Umständen blähen die sich mächtig auf und rammeln dir das Systemlaufwerk zu. Handlet man zumindest bei nem richtigen SQL-Server so.

Also scheint es zumindest so, das er DC geworden ist. Findet sich irgendwo ein Hinweis darauf, das seine Heraufstufung zugelassen wurde? Wenn ich mich recht entsinne müsste das die Event-ID 13509 sein, die meistens direkt auf 13508 folgt.

Und was sagt das Eventlog des werdenden DC's?

Mit wem soll der denn noch replizieren? Oder hat das DCPromo auf dem werdenden geklappt? Dann versuch mal in der Sites and Services-MMC die Repliaktion per Replicate now zu erzwingen.

Workaround mit dem deine Umgebung trotzdem etwas unsauber bleibt: Installier den zweiten Server mit einem neuen Namen, dann müsstest du den zumindest sauber in die AD bekommen. War die Eventlogmeldung vom bestehenden DC oder vom werdenden DC?

wenigstens was konstantes :)

Schonmal mit der Event-ID bei http://www.eventid.net nachgeschaut? Da finden sich immer recht gute Ansätze.

Auch keine alte Repliaktionsverbindung unter Sites and Services mehr? Was sagen denn die Eventlogs des DC's und werdenden DC's zu dem Thema?

Wie äussert sich das Problem des intern nicht Mails versenden können? Nur das die nicht ankommen oder hast du ne konkrete Fehlermeldung?

Findet sich der "alte" (abgerauchte) DC noch in der AD oder den Replikationseinstellungen?

*Gähn* Diesen Thread gibt es ja immer noch :)

Du kannst doch Policies auch pro OU vergeben. Egal welche Art von Policies. Also leg auf die OU der Scanner eine Policy, das deren Kennwort nie abläuft und fertig.

Lass mich raten: Der unsanft aus der ADS entfernte Server war vorher DC und der neu aufgesetzte DC soll wieder den selben Namen erhalten? Wenn dem so ist, dann ist NTDSUtil das Werkzeug deiner Wahl um den Server auf den verbliebenen DC's aus den NTDS-Settings und der Repliaktionshierarchie zu entfernen. Kommandozeilenkenntnisse sind dabei durchaus von Vorteil. ;)

Die SMB-Signing-Policy des DC's wäre auf jeden Fall ein Ansatzpunkt, genauso wie der DS-Client. Wenn es damit nicht geht, dann würde ich sagen das sich deine Anwender damit abfinden müssen. Das kannst du dann wiederrum nutzen, um eine Migration der Clients zu forcieren, indem du deine Anwender auf deine Vorgesetzten loslässt. Wenn es nunmal nicht anders geht, geht es nicht anders. Niemand von dir Verlangen können, einem 10 Jahre alten System, was noch nicht mal sauber 32 bit spricht, die selbe Funktionalität abzuverlangen, wie einem zeitgemässen System. So hart ist die Realität nunmal. Für die Migration der Server reicht das Geld, damit kommen die Probleme und dann ist das Geld alle und der Admin darf die Scherben aufkehren. Is doch wie immer oder? :(

Kostengründe schön und gut, aber rechtfertigen nicht alleine die Probleme die du jetzt mit den Win95ern hast die Migration auf Windows XP? Gerade bei der Menge... Andere Variante: Umsetzen der Drucker an modernere Maschinen mit Windows XP oder Windows 2000? Für mich ist es fraglich, inwieweit der produktive Einsatz von Windows 95 überhaupt noch gerechtfertigt ist. Es gibt dafür weder Support noch Patches geschweige denn aktuelle Treiber für die Hardware. Das solltest du in deine Kostengründe mit einbeziehen.

Sollte es für das Replikationsproblem des SP1 nicht inzwischen schon einen Patch von MS geben?

Hallo Urmel und Blub Leider weder das eine noch das andre. Hab am Freitag die MSDN reparieren können, aber die Technet-Installation will leider ne CD haben. Also werd ich mir die wohl mal aus dem Office zum Kunden schicken lassen müssen. Ich hatte gehofft, das das Problem jemand kennt. :( Schade aber auch. Naja, muss ich halt warten bis die Post da ist.

Es ist bedauerlich, das Nichttechniker den Bedenken von Technikern selten Glauben schenken und nach dem Motto "Es läuft doch alles" reagieren. Problem: Wenn es einmal nicht läuft, wird der Chef sicher nicht sagen "Meine Schuld, hätte sollen doch Geld locker machen" sondern eher "Sie sind der Techniker und müssen sicherstellen das es läuft." Was sind also deine Möglichkeiten? 1. Du setzt dich mit deinem Chef zusammen, ihr diskutiert sachlich den Worst-Case-Fall und seht, ob sich die Anschaffung eines zweiten Systems rechnet. Wenn sich das für deinen Chef nicht rechnet, weil er der Meinung ist, das alles läuft, dann mach ihn auf das Risiko aufmerksam und lass dir die Entscheidung schriftlich geben, damit du im Fall der Fälle was in der Hand hast. 2. Lass dich und deinen Chef von einem Externen über die Risiken bei diesem System beraten, das kommt immer besser. 3. Teste wieder und wieder deine Backup- und Recoverystrategie, um Möglichkeiten für die Optimierung zu finden. Wenn ihr 30 DB's mit 250 GB laufen habt, dann wird da schon ein ordentliches Blech drunter hängen. Und dann dürfte es kein Problem sein, als Ausfalllösung eine etwas schwächere Maschine daneben zu stellen, die einfach nur für den Fall der Fälle da ist. Ich wünsche dir aus kollegialer Sicht nicht, das du den Recoveryplan je aus dem Schreibtisch holen musst.

Was dann wiederrum für die Clusterlösung sprechen würde.

Naja, ein paar Spalten solltest du schon mitgeben, oder?

Hallo Leute, so richtig weiß ich nicht, wie ich es beschreiben soll. Habe auf meinem Notebook neben VS 2003 die MSDN komplett sowie die Technet (Stand Mai 2005) installiert. Heute wollte ich die Technet aufreissen und was nachschauen. Aber was muss ich feststellen? Der Document Explorer kommt hoch, aber ich seh nix. Nur den leeren Explorer. Eben fiel mir auf, das es mit der MSDN genauso aussieht. Kennt jemand dieses Problem und weiß, wie ich das wieder hingebogen bekomme? Lasse grade ein Repair auf die MSDN laufen, aber ich weiß noch nicht, wie weit das läuft. Installationsmedien liegen natürlich im Büro, wo ich aber aus Projektgründen in den nächsten Monaten sehr schlecht hinkomme. :-(

Hm, dann hast diese Infos aber nicht über Thread bekommen oder gegeben, sonst hätt ich das ja gelesen und hätte gewusst: Ok, noch einer, der nen guten Tipp auf Lager hat. ;) Auf der andren Seite muss ich sagen: Wenn man 30 DB mit 250 GB auf einem SQL-Server fährt, dann sollte man sich schon eher Gedanken über Cluster oder Auslagerung machen, als über Replikation. Für 30 DB's dürfte der Traffic bei der Replikation recht barbarisch werden.

Wie sieht denn deine WMI-Query aus?

Wie wäre es einfach mit Risikominderung? Auch der SQL-Server beherrscht sowas wie Replikation. Heißt, du bräuchtest einen zweiten SQL-Server, der als Subscriber konfiguriert ist und sich von dem ersten Server (Publisher) sein DB-Replikat holt. Wenn dir einer der beiden Server abraucht, hast du nen zweiten, der weiterhin läuft und kannst in aller Ruhe den abgerauchten Server frisch machen und drehst dann einfach die Rollen um.