Jump to content

Christoph35

Members
  • Gesamte Inhalte

    3.624
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von Christoph35

  1. Hi!

     

    aber wie ich das verstanden hab, muss doch der rechner auf dem exchange läuft auch dc sein. dc, dns, iis, oder bin ich da ganz falsch.

     

    Nö, da liegst Du schief. Data1701 hat recht: Exchange und DC sind zwei Dinge, die man besser auf getrennten Servern laufen lässt, wenn es sich nicht gerade um eine Umgebung handelt, für die man auch SBS nutzen könnte.

     

    DCs zu clustern ist auch keine gute Idee, die Datenredundanz zweier DCs wird durch die Replikation erreicht, sprich die AD-Datenbank ist auf 2 Servern vorhanden. Beim Cluster wär s nur eine DB.

     

    Wie groß ist die Umgebung denn, sprich: Datenvolumen, Anzahl User?

     

    Und außerdem: DC und Exchange Cluster Knoten in einem, das wird nicht unterstützt:

    http://support.microsoft.com/kb/898634/en-us

     

    Und noch ein Artikel von MS zu DCs als Cluster Nodes:

    http://support.microsoft.com/kb/281662/en-us

    Christoph

  2. Erstmal vom 2. DC aus versuchen, die FSMO Rollen auf diesen zu übertragen, wenn sie noch auf dem defekten DC liegen, notfalls mit NTDSUtil und dem "seize"-Kommando.

     

    Dann das Computerkonto des DCs aus dem AD löschen: in AD Users & Computers, und in AD Sites & Services.

     

    Jetzt am besten mit NTDSUtil nochmal prüfen, ob der defekte DC noch irgendwo aufgelistet wird.

     

    Danach den defekten DC komplett neu installieren, als zusätzlichen DC wieder ins AD bringen und ggf. die FSMO Rollen zurücktransferieren (jetzt aber mit den Active Dir. Konsolen) und ggf. den GC wieder aktivieren.

     

    Das halte ich für die sauberste Lösung.

     

    Ach ja: Und DNS und WINS auch wieder installieren und konfigurieren.

     

    Christoph

  3. Hi,

     

    die IP 169.254.x.y hat er, wenn Du die IP automatisch beziehen willst, aber kein DHCP Server zur Verfügung steht, der passende IPs vergeben könnte.

     

    169.254.x.y liegt nicht im selben Netz, wie deine anderen Geräte, deshalb kommst Du nicht an den Gateway dran und kannst damit auch nicht surfen.

     

    Kann sein, dass der Router als DHCP Server fungieren kann, aber dann muss der Client den Router per Broadcast erreichen können, oder es muß irgendwo einen DHCP Relay Agent geben.

     

    /und mal wieder zu langsam :D

     

    Christoph

  4. Hi,

     

    mir ist noch nicht ganz klar, ob wir hier von E 2000 oder 2003 reden?!

     

    Falls 2003, kannst Du Dir mit der Recovery Storage Group behelfen.

    Wie du damit arbeitest, findest Du in einem Whitepaper von MS.

     

    Falls es sich um Exch. 2000 handelt, musst Du dir einen neuen Exchange mit dem gleichen Org.-Namen etc. bauen, dann das Backup zurückspielen und mit Exmerge arbeiten.

    Für mehr Info könntest Du hier mal reinschauen.

     

    In jedem Fall ist es eine gute Idee, das ganze vorher mal zu testen. :)

    Christoph

  5. Hi!

     

    seltsamerweise wurde das Postfach erst erstellt als ich an dieses Pofstfach eine eMail (intern) geschickt habe

     

    Das ist überhaupt nicht seltsam, sondern by Design ;).

     

    Wenn Du einem User ein Postfach gibst, werden erstmal nur die Exchange Attribute für das User Konto im AD gesetzt. Das Postfach im Mailbox Store wird erst erstellt, wenn eine Mail eingeht, oder der User sich das erstemal an Exchange anmeldet.

     

    Christoph

  6. JET ist auch keine falsche Bezeichnung.

     

    Hast Du mehrere DCs, und wenn ja, treten die Fehler auf anderen DCs auch auf?

     

    Ich habe grad mal bei EventID.net nachgesehen (Ereignis ID 705). Deren Vorschlag ist auch, ein Backup wiederherzustellen. Ansonsten wird zur Vorgehensweise für eine Reparatur auf Exchange verwiesen.

     

    Ob jetzt das Herunterstufen zum Memberserver und Neuinstallieren des AD etwas bringt, hängt wohl auch davon ab, ob du mehrere DCs hast und falls (wie ich hoffe) ja, ob die anderen DCs noch eine saubere Datenbank haben.

     

    Christoph

  7. Hi, Hr_Rossi,

     

    das ist das gleiche, wie wenn eine Exchange Datenbank diesen Fehler hat. Irgendwo ist diese Datenbank wohl korrupt.

     

    Am besten den DC im Directory Services Restore Mode starten und die AD Datenbank aus einer Sicherung wiederherstellen.

     

    Ansonsten ziehen hier die gleichen Massnahmen, wie wenn du den -1018 für Exchange hast, weil die zugrundeliegende Datenbanktechnologie die gleiche ist (ESE). Die Datenbank heisst nur anders (ntds.dit statt priv.edb bzw. pub.edb) und die Transaction-Log-Files haben 10 MB statt wie bei Exchange 5 MB.

     

    /edit: es gibt auch ein Pendant zum ESEUTIL.EXE von Exchange: ESENTUTL.EXE.

     

    Christoph

×
×
  • Neu erstellen...