DC restored - Clients können nicht in Domäne

[onestone 10]

Liebe Leute!

 

Wäre toll wenn ihr was wisst, verbringe meinem Sonntag beim Kunden.

 

Was ist passiert? Raid-5 degraded. Neu aufgesetzt (virtuelle Maschine auf anderem Rechner). Server 2003 SP2 installiert, Systemstate (etwa 8 wochen alt) eingespielt.

 

Nun können sich die Clients nicht anmelden. Wenn ich manuell aus Domäne und wieder hinein funktioniert es bereits. Habe bei BDC gelesen dass alle 7 Tage ein PWD zwischen PDC und BDC generiert wird, evtl. auch auf den Maschinen? Habe bereits im AD probiert das Computerkonto "zurückzusetzen". Auch nach neustart des Clients keine Änderung.

 

Habe ich eine Möglichkeit eine Funktion zu deaktivieren damit das nicht mehr geprüft wird (Security-Risk vs. Zeitrahmen bis morgen früh wäre OK) bzw. wie kann ich das ohne auf alle Maschinen (>50) wieder aktivieren???

 

danke danke dan:wink2: ke,

onestone@notfall@sonntag

[gysinma1 13]

Hallo

 

Wieso gibt es denn keinen juengeren Systemstate ??

 

Der Maschinenaccount laeuft mit der Standard Sicherheitsrichtlinie nach 28 Tage ab. Es sei denn, dass die Sicherheitsrichtlinie entsprechend veraendert wird (was aber rueckwirkend icht mehr geht). (Leider bin ich im Ausland und habe meine Linksammlung nicht) Der Systemstate ist dafuer deutlich zu alt und das Passwort wird nicht mehr synchron sein.

 

Das Passwort wird zwischen der Resource und der Domain generiert und nicht zwischen PDC und BDC.

 

Du wirst keinen Weg finden ausser alle Geraete neu zu joinen oder einen neueren Systemstate zu finden (Der gehoert taeglich gesichert !). Schau mal ob es eventuell ein Tool von sysinternals gibt um das Resourcenkonto neu zu setzen.

 

Gruss & Viel Erfolg

[Daim 12]

Bonjour,

 

Der Maschinenaccount laeuft mit der Standard Sicherheitsrichtlinie nach 28 Tage ab.

 

das Computerkonto-Kennwort unter NT wird standardmäßig alle 7 Tage geändert.

Ab Windows 2000 sowie XP wird standardmäßig das Kennwort für das Computerkonto alle 30 Tage geändert.

 

 

 

@onestone

 

Neben dem was gysinma1 bereits angesprochen hat, ist das Alter des System States aus weiterer Hinsicht ebenfalls kritisch. Du sprichst von "etwa 8 Wochen alt". Nehmen wir an, die Gesamtstruktur wurde unter Windows Server 2003 (ohne SP1 sowie SP2) erstellt, so beträgt die Tombstone Lifetime standardmäßig 60 Tage. Das bedeutet, wenn dieses "etwa" doch mehr sein sollte, bekommst du ohnehin noch weitere Probleme.

[onestone 10]

Danke für die Ratschläge. Habe es manuell gemacht (Kollegen gebeten).

 

Weiterführung (neue Probleme) des themas unter

 

http://www.mcseboard.de/windows-forum-ms-backoffice-31/dc-systemstate-ad-exchange-setup-schlaegt-fehl-126839.html

[onestone 10]

@Dr.Melzer: Also ich fands andersrum übersichtlicher, aber bitte,...

 

@gysinma1:

 

der exchange server war keine vm - nein.

 

ich habe mangels stabiler eigener hardware einen virtuellen server angelegt, 2003 installiert + systemstate + clients manuell in neue domäne (weil bkp zu alt). user melden sich an, passt. exchange installieren scheitert bzw. iis konnte nur langsam entfernt und nun nicht installiert werden.

[gysinma1 13]

Hallo

 

Also ich denk' das sind zwei verschiedene Sachen ...

 

Exchange

Attache bitte das exchange-setup-log. War die Exchange Organisation in dem alten Systemstate Schema schon vorhanden ?

 

IIS

Welche Servicepack Version verwendest Du ? Deinstalliere den IIS und lasse das SP2 nochmals durchlaufen. Gibt es zu dem Fehler irgendwelche Zusatzinformationen ? Wird der Fehler durch den Exchange Application Pool verursacht ? Oft hilft auch .net2.0 reregistrieren dazu im .netframework verzeichnis die Binary aspnet_regiis -i ausfuehren.

 

Gruss

Matthias

[gysinma1 13]

Hallo

 

Noch ein Nachtrag wegen dem IIS. Hattest Du diesen zuefallig vor dem dcpromo installiert ? Ich hatte verschiedentlich schon Probleme damit, dass nachher Exchangesetup die ApplicationPools anlegen konnte. Die Loesung war meist den IIS reinstallieren.

(Microsoft empfiehlt kein Exchangebetrieb auf einem DC und wenn dies trotzdem gemacht werden muss, muss die IIS und Exchange Installation am Schluss sein. Auch ein demoting eines Exchange/DC sollte nicht gemacht werden. Es ist mir schon klar, dass die meisten Kleinbetriebe - auch meiner - diese Konstellation trotzdem haben).

 

 

Gruss

Matthias

[onestone 10]

ad dcpromo: nie gemacht, wann SOLLTE ich das denn machen in der reihenfolge? habe das gefühl es gibt NIRGENDWO eine vollständige, korrekte und gescheite darstellung des restore-prozesses. dcpromo ist ja herauf/herabstufen von DCs, oder? Bisland war NIE die rede hiervon,...???

[onestone 10]

Exchange

Attache bitte das exchange-setup-log.

 

finde ich wo?

 

War die Exchange Organisation in dem alten Systemstate Schema schon vorhanden ?

 

ja, natürlich.

 

IIS

Welche Servicepack Version verwendest Du ?

 

Windows SP2

Exchange SP2

 

Deinstalliere den IIS und lasse das SP2 nochmals durchlaufen.

 

Du meinst: System + SP2 + Systemstate + IIS deinstallieren + SP2 + IIS installieren?

 

Gibt es zu dem Fehler irgendwelche Zusatzinformationen ?

 

nein, das wäre zu einfach,,...

 

Wird der Fehler durch den Exchange Application Pool verursacht ? Oft hilft auch .net2.0 reregistrieren dazu im .netframework verzeichnis die Binary aspnet_regiis -i ausfuehren.

 

Der IIS scheint einfach nicht "da" zu sein. Über IIS-Manager keine Verbindung zu Server.

[gysinma1 13]

Mein lieber Freund

 

Merkst Du jetzt wieso dies in einem Post besser ist dies zusammenzuhalten. Das ist ferner ein tolles, cooles Forum wo mit Eigeninitiative gearbeitet werden muss und kein Helpdesk somit ist auch ein bisschen googlen, technet und wikipedia angesagt ;-)

 

Wie Daim und meine Wenigkeit Dir schon erklaerten ist ein derart alter Systemstate nicht unproblematisch die Daten der Exchange Organsation sind alle bereits im DC hinterlegt, weshalb Du diese Exchange-Organisation auch nicht nochmals installieren kannst.

 

Der Reihe nach. Du musst auf dem hergestellten DC zuerst den IIS zum Laufen kriegen. Systemstate machst Du gar nichts, sonst kann Du alle >50 Gerate neu joinen. IIS einfach deinstallieren, SP2 nochmals drueberlegen und dann den IIS wieder installieren (ganz wichtig, Ihr hattet vorher auch SP2 auf dem Server gehabt ?). Den Exchange Pool sofern noch vorhanden loeschen. Schaue was im Eventlog (apps und system) waehrend dem Vorgang geschrieben wird. Der W3SVc1 Service muss jedenfalls starten koennen. Es werden bei diesem Service immer logeintraege geschrieben wenn er dies nicht kann. Danah am Besten neu starten.

 

Fuer Exchange musst Du eine Reparaturinstallation durchfuehren. (Es duerfen keine Laufwerkspfade geandert worden sein und der hergstellte Server muss gleichen Namen und gleiche IP haben, gegenueber dem alten Server). Wie dies gemacht wird findet Du auf der Site MSXFAQ.DE - Franks MSExchangeFAQ (unter Notfall, Verlust Mailserver) von Frank Carius sehr gut beschrieben. Das Setuplog des exchange 200x (ohne 2007) wird in das Root des Systemlaufwerk geschrieben (simpel die Datei mit einer neuen Uhrzeit). Danach muessen die Datenbanken restored und die Userkonten neu verbunden werden.

 

Noch etwas zum Schluss:

Es ist alles dokumentiert bezogen des Herstellungsprozesses auch, dass der systemstate mit den Exchange DBs nach best practice taeglich gesichert werden soll. Sonst hilft Dir auch Microsoft TechNet Home Page oder Microsoft Help and Support weiter.

 

Gruss aus Caracas & Viel ERfolg

Matthias

[onestone 10]

Hallo ihr,

 

habe mich dafür entschieden den exchange auf einem anderen server (Windows 2003 Standard SP2) zu installieren. einerseits weil ich glaube, dass die problemlösung auf dem notfall-dc aussichtslos ist (und letztlich so und so neu aufgesetzt werden muss), andererseits weil ich ja schön öfter gehört habe (und auch hier gelesen) dass DC+Exchange außer bei SBS nicht gerade klug ist (abgesehen von Wiederherstellungs-problemen die ich jetzt nur allzugut kenne).

 

Habe folgendes gemacht: Win 2003 installiert, zur Domäne hinzugefügt, SP2 installiert, Komponenten (ASP.NET, etc) installiert, Exchange /disasterrecovery installiert, Exchange-SP2 /disasterrecovery installiert.

 

Er hatte Probleme (bei Setup sowie SP2) den Kalender-Connector zu installiert, habe das mit "abbrechen" übergangen. Datenbank stellt nun von Log-Files wieder her. Nun schreibt er das Event

 

MSExchangeFBPublish > 8213

Der Systemaufsichtsdienst konnte die Sitzung für den virtuellen Computer EXCHANGE nicht erstellen. Die Fehlernummer ist 0xc103073a.

 

ins Eventlog. In einen MS-Dokument finde ich nur eine Möglichkeit, das generell zu deaktivieren. Natürlich benötigen wir jedoch die Outlook-Kalender.

 

Hat jemand von Euch eine Idee, wie man das sinnvoll troubleshooten kann?

 

Frohe Feiertage & Danke!

[onestone 10]

nochmal ich,

 

habe mir folgendes zum Event-Eintrag angesehen:

 

J's Den -- Jasper Kuria's WebLog : Those 8197 Free/Busy Errors

 

wobei bei mir die anfangs erwähnten regentries am Exchsvr nicht existieren, der output vom ldif-kommando ist

 

C:\Dokumente und Einstellungen\Administrator.xxx>ldifde -f output.ldf -d "dc=xxx

,dc=at" -t 3268 -p subtree -r "(&(objectclass=*)(name=myserver))

Verbindung mit "yyy.xxx.at" [=DC] wird hergestellt.

Anmelden als aktueller Benutzer unter Verwendung von SSPI

Das Verzeichnis wird in die Datei output.ldf exportiert.

Es wird nach Einträgen gesucht...

Die Einträge werden geschrieben.

Keine Einträge gefunden

 

Der Befehl wurde einwandfrei durchgeführt.

 

Ideen?

[gysinma1 13]

Hallo

 

Das handelt sich lediglich um die Free-Busy Info und nicht um die Kalender des Outlook. Diese laufen ueber die Public Folder Replication. Das kriegen wir hin.

 

Sobald ich da wieder was klarer sehe ;-) - Weihnachtsfete - schauen wir weiter.

 

Gruss

Matthias

[onestone 10]

gut, das beruhigt mich mal ordentlich. er stellt weiterhin die db her,....bin gespannt ob er sie starten kann.

 

lg

[gysinma1 13]

Hallo

 

Noch zwei, drei Gedanken dazu.

 

Wie ich erwaehnte wird bis und mit Exchange 2003 die Free-/Busy Funktion ueber die Public Folders abgewickelt. Ab Exchange 2007 dann mit HTTP(S) von dem CAS Servers.

 

Der DSAccess Fehler ist ein genereller Fehler bei dem Zugriff auf den GlobalKatalog. (Ich gehe davon aus, dass die DNS Konfiguration nicht veraendert hat. Habe da bei einer Repairinstallation scho alles moegliche erlebt - auch, dass "ploetzlich" die Localhost IP eingetragen ist). Hast Du im DNS Server den GlobalCatalog SRV-Record im _msdcs Verzeichnis.

 

Du hast die Servicepack(s) von Exchange drauf so wie vorher ?

Wie gross ist denn diese DB. Ich meinte, das muesste er laengst haben :(

Welche Exchange Dienste sind im Momentan gestoppt und welche gestartet ?

 

Wie sieht es mit dcdiag und netdiag aus ? (Ist das immer noch okey ?)

 

Nimm mal die Microsoft Tools von Download details: Microsoft Product Support's Reporting Tools

 

und lasse folgende Tests durchlaufen:

MPSRPT_Alliance_X86.EXE

MPSRPT_Exchange.EXE

MPSRPT_NETWORK.EXE

 

Auf dem DC wuerde ich mal folgendes anschauen:

MPSRPT_Alliance_X86.EXE

MPSRPT_NETWORK.EXE

MPSRPT_DirSvc.EXE

 

Vorweg die Dinge rarttern ne Weile und exportieren alle Daten in das Verzeichnis C:\windows\mpsreports.

 

Gruss & Viel Erfolg

Matthias