25
DNS Active Directory 4015
Win2K3 Domäne mit 2 DCs
AD & DHCP & DNS
Hallo Administratoren
Folgende Fehlermeldung in den Eventlogs beider DCs:
Ich habe unseren allseits beliebten Freund und Helfer Google bereits genutzt.
Gefunden habe ich folgendes:
http://support.microsoft.com/?scid=kb%3Bde%3B267855&x=19&y=10
http://www.servernewsgroups.net/group/microsoft.public.windows.server.a ...
http://www.eventid.net/display.asp?eventid=4015&eventno=333&sou ...
Leider konnte ich anhand dieses Materials das Problem nicht lösen.
Oder ich steh einfach nur komplett auf dem Schlauch.
Ich habe auch einige andere Beiträge und URLs zu diesem Problem gefunden welche mir allerdings noch weniger gebracht haben.
Hinzu kommt dass ich einen 3ten DC habe der nicht funktioniert.
Wenn ich diesen mit dcpromo entfernen möchte kommt der folgende Fehler:
Ich brauch den 3ten DC nicht, also kann der getrost entfernt werden.
In der Site-config habe ich den ProblemDC bereits rausgenommen.
Was natürlich nicht das Problem gelöst hat.
Die ganze Geschichte führt dazu dass ich in den DNS Lookupzonen gleiche IPs zu unterschiedlichen Hostnamen finde.
Vor allem in der Reverse Lookup Zone.
Trotz alledem funktioniert nslookup, und alle Namen werden korrekt aufgelöst.
Einzig und allein beim Problem DC funktioniert die Auflösung nicht, ich kann ihn quasi nur über die IP erreichen.
Habe auch schon die Replizierung auf nen kleineren Intervall runtergeschraubt...leider ohne Erfolg.
Über den Lösungsvorschlag von Microsoft dnscmd habe ausserdem folgendes rausgefunden:
PROBLEM-DC 3
Von DC 1 und DC 2 werden alle Infos korrekt angezeigt, beispiel:
Ich weiss einfach nicht mehr weiter.
Sollte jemand noch eine Information brauchen, einfach fragen.
Danke an jeden der sich damit beschäftigt.
Gruß divi
Folgende Fehlermeldung in den Eventlogs beider DCs:
Event Type: Error
Event Source: DNS
Event Category: None
Event ID: 4015
Date: 05.10.2008
Time: 12:25:12
User: N/A
Computer: SRV02
Description:
The DNS server has encountered a critical error from the Active Directory. Check that the Active Directory is functioning properly. The extended error debug information (which may be empty) is "000020E3: SvcErr: DSID-031B063D, problem 5002 (UNAVAILABLE), data 0". The event data contains the error.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 34 00 00 00 4... Ich habe unseren allseits beliebten Freund und Helfer Google bereits genutzt.
Gefunden habe ich folgendes:
http://support.microsoft.com/?scid=kb%3Bde%3B267855&x=19&y=10
http://www.servernewsgroups.net/group/microsoft.public.windows.server.a ...
http://www.eventid.net/display.asp?eventid=4015&eventno=333&sou ...
Leider konnte ich anhand dieses Materials das Problem nicht lösen.
Oder ich steh einfach nur komplett auf dem Schlauch.
Ich habe auch einige andere Beiträge und URLs zu diesem Problem gefunden welche mir allerdings noch weniger gebracht haben.
Hinzu kommt dass ich einen 3ten DC habe der nicht funktioniert.
Wenn ich diesen mit dcpromo entfernen möchte kommt der folgende Fehler:
Der Vorgang ist Fehlgeschlagen. Fehler:
Active Directory konnte die verbleibenden Daten in der Verzeichnispartition
CN=Schema,CN=Configuration,DC=domain.de,DC=de nicht zum Domänencontroller srv02.domain.de übertragen.
"Ein DSA-Vorgang kann aufgrund eines DNS-Aufruffehlers nicht fortgesetzt werden." In der Site-config habe ich den ProblemDC bereits rausgenommen.
Was natürlich nicht das Problem gelöst hat.
Die ganze Geschichte führt dazu dass ich in den DNS Lookupzonen gleiche IPs zu unterschiedlichen Hostnamen finde.
Vor allem in der Reverse Lookup Zone.
Trotz alledem funktioniert nslookup, und alle Namen werden korrekt aufgelöst.
Einzig und allein beim Problem DC funktioniert die Auflösung nicht, ich kann ihn quasi nur über die IP erreichen.
Habe auch schon die Replizierung auf nen kleineren Intervall runtergeschraubt...leider ohne Erfolg.
Über den Lösungsvorschlag von Microsoft dnscmd habe ausserdem folgendes rausgefunden:
PROBLEM-DC 3
C:\Programme\Support Tools>dnscmd /info
Info query failed
status = 1722 (0x000006ba)
Command failed: RPC_S_SERVER_UNAVAILABLE 1722 (000006ba)Von DC 1 und DC 2 werden alle Infos korrekt angezeigt, beispiel:
Query result:
Server info
server name = srv01.domain.de
version = 0ECE0205 (5.2 build 3790)
DS container = cn=MicrosoftDNS,cn=System,DC=domain,DC=de
forest name = domain.de
domain name = domain.de
builtin domain partition = ForestDnsZones.domain.de
builtin forest partition = DomainDnsZones.domain.de
last scavenge cycle = not since restart (0)
Configuration:
dwLogLevel = 00000000
dwDebugLevel = 00000000
dwRpcProtocol = FFFFFFFF
dwNameCheckFlag = 00000002
cAddressAnswerLimit = 0
dwRecursionRetry = 3
dwRecursionTimeout = 15
dwDsPollingInterval = 180
Configuration Flags:
fBootMethod = 3
fAdminConfigured = 1
fAllowUpdate = 1
fDsAvailable = 1
fAutoReverseZones = 1
fAutoCacheUpdate = 0
fSlave = 0
fNoRecursion = 0
fRoundRobin = 1
fStrictFileParsing = 0
fLooseWildcarding = 0
fBindSecondaries = 1
fWriteAuthorityNs = 0
fLocalNetPriority = 1
Aging Configuration:
ScavengingInterval = 168
DefaultAgingState = 0
DefaultRefreshInterval = 168
DefaultNoRefreshInterval = 168
ServerAddresses:
Addr Count = 3
Addr => 10.145.16.200
Addr[1] => 192.1.1.250
Addr[2] => 192.168.1.250
ListenAddresses:
NULL IP Array.
Forwarders:
NULL IP Array.
forward timeout = 5
slave = 0
Command completed successfully.Ich weiss einfach nicht mehr weiter.
Sollte jemand noch eine Information brauchen, einfach fragen.
Danke an jeden der sich damit beschäftigt.
Gruß divi
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 98520
Url: https://administrator.de/contentid/98520
Printed on: April 25, 2024 at 23:04 o'clock
25 Comments
Latest comment
Von der Fehlermeldung und dem beschriebenen Verhalten vermute ich Probleme im Active Directory. Ich rate dazu erst die Probleme im ActiveDirectory zu beheben, damit das Replizieren aller Informationen funktioniert. Erst dann den nicht mehr benötigten 3.DC entfernen, damit die geänderte Konfiguration bei den beiden andren DC richtig ankommt.
Welche Fehler zeigt dir dcdiag an und was meldet replmon?
Prüfe mal welche Server welche Rollen (FSMO) haben. Vom PDC ausgehend mit nslookup -soa domain.de müssen die Einträge stimmen. Wenn das nicht der Fall ist würde ich die DNS Zone löschen, dann neu anlegen und mit ipconfig /registerdns die Basiseinträge wieder herstellen. Prüfe das auch der _msdcs, dc, _tcp Ordner wieder angelegt wird und die richtigen Einträge erstellt werden. Das dauert bis zu 3 Minuten.
Wenn das gelingt auch auf dem zweiten und drittem DC ipconfig /registerdns ausführen.
Wenn im Eventlog Fehler auftreten würde ich wieder bei eventlog.net suchen, bzw. hier Posten.
Gruß Rafiki
Update
Ich bevorzuge es wenn der DC sich selber als DNS zuerst fragt und dafür die IP 127.0.0.1 verwendet, also local host.
/update
Welche Fehler zeigt dir dcdiag an und was meldet replmon?
Prüfe mal welche Server welche Rollen (FSMO) haben. Vom PDC ausgehend mit nslookup -soa domain.de müssen die Einträge stimmen. Wenn das nicht der Fall ist würde ich die DNS Zone löschen, dann neu anlegen und mit ipconfig /registerdns die Basiseinträge wieder herstellen. Prüfe das auch der _msdcs, dc, _tcp Ordner wieder angelegt wird und die richtigen Einträge erstellt werden. Das dauert bis zu 3 Minuten.
Wenn das gelingt auch auf dem zweiten und drittem DC ipconfig /registerdns ausführen.
Wenn im Eventlog Fehler auftreten würde ich wieder bei eventlog.net suchen, bzw. hier Posten.
Gruß Rafiki
Update
Ich bevorzuge es wenn der DC sich selber als DNS zuerst fragt und dafür die IP 127.0.0.1 verwendet, also local host.
/update
Hallo,
sei bitte ab sofort sehr Vorsichtig. Das Problem solltest du wie folgt in den Griff bekommen:
Nun kannst du eigentlich ziemlich sicher sein, das DNS funktioniert. Versuche nun den 3. DC erneut herunterzustufen. Sollte dies immernoch scheitern, duche mit dem Tool DCDIAG auf allen Servern nach Konfigurationsfehlern.
sei bitte ab sofort sehr Vorsichtig. Das Problem solltest du wie folgt in den Griff bekommen:
- Suche den Server der die Rolle des SchemaMaster und DomainNamingMaster für deine Domäne hält
- Installiere auf diesem Server die Windows Support Tools (ordner: support\Tools auf der Windows-CD)
- Öffne die DNS-Konsole und ändere die Sicherheit der DNS-Zone deiner Domäne auf "Sichere und nicht Sichere Updaten zulassen"
- Ändere den primären DNS-Server in der IP-Konfiguration so, das er sich selbst als DNS-Server verwendet.
- Führe in der Konsole den Befehl
ipconfig /registerdnsundnetdiag /fixaus - Ändere auf dem zweitem DC den DNS-Server ebenfalls auf die IP des ersten Servers
- Installiere wieder die Supporttools und führe die beiden Befehle aus.
- Auf dem drittem DC gehst du nun genauso vor.
- Öffne nun auf dem 1. DC das Tool "replmon" und füge die Server DC1, DC2 und DC3 der konsole hinzu
- Klicke auf die einzelnen Server und wähle "Synchronize each directory partition with all servers". Wähle zur Sicherheit noch die Option "Cross Site Boundarys ....)".
- Sollte dies scheitern, fahre bitte alle Server herunter und starte Sie in der Folge DC1 (WARTEN BIS OS VOLLSTÄNDIG GESTARTET!!!), DC2, DC3 und versuche es nach ca. 15minuten erneut. Sollte es wieder nicht klappen, lege die DNS-Zone deiner Domäne auf dem erstem DC neu an, setze die Sicherheit wieder wie oben beschrieben und gehe wie eben beschrieben vor. Scheitert es immernoch, prüfe deine Replikationsverbindungen.
- Starte den DNS-Dienst auf allen Servern neu.
Nun kannst du eigentlich ziemlich sicher sein, das DNS funktioniert. Versuche nun den 3. DC erneut herunterzustufen. Sollte dies immernoch scheitern, duche mit dem Tool DCDIAG auf allen Servern nach Konfigurationsfehlern.
Hallo Rafiki,
du könntest recht haben dass es Probleme im AD gibt.
Manche Rechte werden nicht richtig übernommen. Es kann durchaus an der Replizierung liegen.
Allerdings habe ich über dcdiag was interessantes herausgefunden:
Wenn ich das richtig interpretiere ist die Rolle des FSMO Role Owner gelöscht.
Den gleichen Fehler erhalte ich bei SRV02.
Allerings erhalte ich zusätzlich diesen Fehler:
Ok replmon meint, das alles in Ordnung ist.
Zumindest was die Replizierung zwischen SRV01 und SRV02 angeht.
SRV03 ist nicht erreichbar.
Unter nslookup (-soa??) domain.de scheinen die Einträge zu stimmen.
Darum lass ich den Part DNS Zone löschen & neu erstellen erstmal weg.
du könntest recht haben dass es Probleme im AD gibt.
Manche Rechte werden nicht richtig übernommen. Es kann durchaus an der Replizierung liegen.
Allerdings habe ich über dcdiag was interessantes herausgefunden:
Testing server: DOM\SRV01
Starting test: KnowsOfRoleHolders
Warning: CN=NTDS Settings\0ADEL:fb2864bf-63bb-4307-a0a6-50ce4c732d4a,CN
=SRV01,CN=Servers,CN=GD-DOM,CN=Sites,CN=Configuration,DC=domain,DC=de is t
he Schema Owner, but is deleted.
Warning: CN=NTDS Settings\0ADEL:fb2864bf-63bb-4307-a0a6-50ce4c732d4a,CN
=SRV01,CN=Servers,CN=GD-DOM,CN=Sites,CN=Configuration,DC=domain,DC=de is t
he Domain Owner, but is deleted.
......................... SRV01 failed test KnowsOfRoleHoldersWenn ich das richtig interpretiere ist die Rolle des FSMO Role Owner gelöscht.
Den gleichen Fehler erhalte ich bei SRV02.
Allerings erhalte ich zusätzlich diesen Fehler:
Starting test: frsevent
There are warning or error events within the last 24 hours after the
SYSVOL has been shared. Failing SYSVOL replication problems may cause
Group Policy problems.
......................... SRV02 failed test frseventOk replmon meint, das alles in Ordnung ist.
Zumindest was die Replizierung zwischen SRV01 und SRV02 angeht.
SRV03 ist nicht erreichbar.
Unter nslookup (-soa??) domain.de scheinen die Einträge zu stimmen.
Darum lass ich den Part DNS Zone löschen & neu erstellen erstmal weg.
Hallo datasearch,
ich werde deinen vorschlag probieren...aber ich warte auf das Wochenende und mach vorher nochmal ne gründliche Sicherung. Irgendwie hab ich so ein dumpfes Gefühl das mir das mächtig in die Hose gehen wird.
Zu diesem Thema werde ich dich auf jedenfall nochmal fragen. Aber schau dir doch bitte noch die Antwort von mir an rafiki an.
Riesen Dank euch beiden (rafiki & datasearch) für die schnellen und ausführlichen Antworten.
Gruß divi
ich werde deinen vorschlag probieren...aber ich warte auf das Wochenende und mach vorher nochmal ne gründliche Sicherung. Irgendwie hab ich so ein dumpfes Gefühl das mir das mächtig in die Hose gehen wird.
Zu diesem Thema werde ich dich auf jedenfall nochmal fragen. Aber schau dir doch bitte noch die Antwort von mir an rafiki an.
Riesen Dank euch beiden (rafiki & datasearch) für die schnellen und ausführlichen Antworten.
Gruß divi
Hallo,
ich möchte nicht ins schwitzen kommen.
Darum will ich verhindern dass schlussendlich AD gar nicht mehr läuft
Ich bin kein Server Profi und alles was ich über Domänen, AD und DCs weiß habe ich mir selbst angeeignet durch lesen und probieren.
Nur weiß ich dass ich bei diesem Problem nicht probieren kann da ein Ausfall für mich nicht in Frage kommt oder kommen darf.
Ich habe jetzt mal in mmc geschaut ob der srv02 den srv01 als PDC anerkennt - das tut er.
In den NTDS Einstellungen ist die Replizierung korrekt eingestellt.
Und in rplmon scheint mit der Replizierung auch alles i.O. zu sein.
Was ich aber nicht verstehe, wieso sagt dcdiag dass srv01 PDC ist - aber gelöscht?
ich möchte nicht ins schwitzen kommen.
Darum will ich verhindern dass schlussendlich AD gar nicht mehr läuft
Ich bin kein Server Profi und alles was ich über Domänen, AD und DCs weiß habe ich mir selbst angeeignet durch lesen und probieren.
Nur weiß ich dass ich bei diesem Problem nicht probieren kann da ein Ausfall für mich nicht in Frage kommt oder kommen darf.
Ich habe jetzt mal in mmc geschaut ob der srv02 den srv01 als PDC anerkennt - das tut er.
In den NTDS Einstellungen ist die Replizierung korrekt eingestellt.
Und in rplmon scheint mit der Replizierung auch alles i.O. zu sein.
Was ich aber nicht verstehe, wieso sagt dcdiag dass srv01 PDC ist - aber gelöscht?
Ihc hab leider ned viel Zeit, aber ich kann dir sagen, das dein problem an den FSMO´s liegt. Bitte übertrage die Rolle des Schema und Domain naming Matsers auf einen der funktionierenden DC´s. Der DC3 wurde anscheind bereits aus dem AD gelöscht.
Am besten, um auf nummer sicher zu gehen, auf dem DC3 eine erzwungene herunterstufung durchführen, per NTDSUTIL ein metadata cleanup durchführen (auf dem DC1 oder 2) und die FSMO-Rollen auf einen funktionierenden Server übertragen (Bitte kein GC für den Schemamaster wählen).
Mein vorheriges Posting sollte nur sicherstellen das dein DNS und die Replikation funktioniert.
Am besten, um auf nummer sicher zu gehen, auf dem DC3 eine erzwungene herunterstufung durchführen, per NTDSUTIL ein metadata cleanup durchführen (auf dem DC1 oder 2) und die FSMO-Rollen auf einen funktionierenden Server übertragen (Bitte kein GC für den Schemamaster wählen).
Mein vorheriges Posting sollte nur sicherstellen das dein DNS und die Replikation funktioniert.
Ok, ich habs probiert. Aber der srv01 hat wohl keine lust wieder chef zu werden
Zum einen:
Soweit ist alles klar, aber was mich jetzt total aus der Bahn wirft:
Connected to srv01 > The current FSMO holder could not be contacted ????
Was für mich so viel heisst wie dass der aktuelle "schema master" nicht übernommen werden kann da der aktuelle halter nicht erreichbar ist.
Ich würde es jetzt mit "seize schema master" probieren, nur weiß ich nicht was da schief laufen kann und ob das jetzt überhaupt der richtige weg ist?
Zum einen:
C:\Program Files\Support Tools>netdom query fsmo
Schema owner srv01.domain.de
Domain role owner srv01.domain.de
PDC role srv02.domain.de
RID pool manager srv02.domain.de
Infrastructure owner srv02.domain.de
The command completed successfully.Soweit ist alles klar, aber was mich jetzt total aus der Bahn wirft:
server connections: connect to server srv01
Binding to srv01 ...
Connected to srv01 using credentials of locally logged on user.
server connections: q
fsmo maintenance: transfer schema master
ldap_modify_sW error 0x34(52 (Unavailable).
Ldap extended error message is 000020AF: SvcErr: DSID-0321034A, problem 5002 (UN
AVAILABLE), data 8
Win32 error returned is 0x20af(The requested FSMO operation failed. The current
FSMO holder could not be contacted.)
)
Depending on the error code this may indicate a connection,
ldap, or role transfer error.
Server "srv01" knows about 5 roles
Schema - CN=NTDS Settings\0ADEL:fb2864bf-63bb-4307-a0a6-50ce4c732d4a,CN=SRV01,CN
=Servers,CN=GD-DOM,CN=Sites,CN=Configuration,DC=domain,DC=de
Domain - CN=NTDS Settings\0ADEL:fb2864bf-63bb-4307-a0a6-50ce4c732d4a,CN=SRV01,CN
=Servers,CN=GD-DOM,CN=Sites,CN=Configuration,DC=domain,DC=de
PDC - CN=NTDS Settings,CN=SRV02,CN=Servers,CN=GD-DOM,CN=Sites,CN=Configura
tion,DC=domain,DC=de
RID - CN=NTDS Settings,CN=SRV02,CN=Servers,CN=GD-DOM,CN=Sites,CN=Configura
tion,DC=domain,DC=de
Infrastructure - CN=NTDS Settings,CN=SRV02,CN=Servers,CN=GD-DOM,CN=Sites,C
N=Configuration,DC=domain,DC=de
fsmo maintenance:Connected to srv01 > The current FSMO holder could not be contacted ????
Was für mich so viel heisst wie dass der aktuelle "schema master" nicht übernommen werden kann da der aktuelle halter nicht erreichbar ist.
Ich würde es jetzt mit "seize schema master" probieren, nur weiß ich nicht was da schief laufen kann und ob das jetzt überhaupt der richtige weg ist?
Bist du dir absolut sicher, das der alte DC der da als Schemamaster steht, kein DC mehr ist oder nie wieder online kommt? Sicherheitshalber (wenn möglich) instaloliere das Betriebssystem auf diesem Server neu. Wenn du mit seize schema master die Funktion übernimmst und der alte Server wie auch immer wieder online kommt, kracht es gewaltig.
Auch solltest du VORHER den alten Server aus den Metadaten des AD entfernen (metadata cleanup).
Auch solltest du VORHER den alten Server aus den Metadaten des AD entfernen (metadata cleanup).
Der DC der dort als Schema master steht also der hier:ist kein alter DC. (SRV01)
Er ist definitiv Shema Owner und Domain Role Owner.
Und das soll auch so bleiben.
Es steht im prinzip ja da:
Der SRV02 is PDC, RID und DIM (Infrastructure Owner) < SRV02 bringt ja auch keine Fehler.
Der 3te Server den ich eigentlich löschen möchte ist quasi der SRV03.
Nur war der nie wirklich DC und konnte sich nie wirklich mit AD Synchronisieren.
Ich hab da im DCPROMO ein bisschen ### gebaut und darum kam das ganze gewurstel hier zustande.
Da ist gewaltig was schiefgelaufen so dass ich nicht mal mehr den SRV03 runterstufen konnte.
Darum hab ich ihn gewaltsam mit DCPROMO /FORCEREMOVAL entfernt.
Jetzt sitzt er noch in der AD Users and Computers - Domain Controllers.
1. Frage: Was passiert wenn ich den SRV03 gewaltsam aus der AD entferne?
2. Frage: Was passiert wenn ich den Hostnamen von SRV03 in SRVXY umbenenne und ihn als File Server erneut in die Domäne einbinde?
3. Frage: wie läuft das mit dem "metadata cleanup" ?
P.S.
Ich glaub ich habe mich in den Beiträgen vorher etwas missverständlich ausgedrückt.
Nochmal zur erklärung:
SRV01 - war von anfang Master DC mit den FSMO: Shema Owner und Domain Role Owner
SRV02 - war von anfang an Slave DC mit den FSMO: PDC, RID und Infrastructure Owner
SRV03 - ist vor 4 Wochen dazugekommen und sollte ebenfalls DC Slave werden. Was allerdings aufrund konfigurationsfehler nicht geklappt hat. und ab dem zeitpunkt war es quasi schon nicht mehr möglich den srv03 zu demoten/entfernen. und das war auch der zeitpunkt ab dem die ip adressen sich im dns verdoppelt haben (also gleiche ips zu unterschiedlichen hosts)
Mein Ziel ist es den SRV03 komplett zu entfernen.
Und die Server SRV01 und SRV02 wieder in den ursprünglichen Zustand zurückbringen, also die FSMO rollen sollen wieder wie früher verteilt sein.
Laut netdom query fsmo sind die Rollen immer noch so verteilt.
Laut DCDIAG hat nur SRV01 ein Problem mit den rollen. Er ist zwar nach wie vor Shema Owner und Domain role Owner aber nach dcdiag sind diese einträge gelöscht.
Warning: CN=NTDS Settings\0ADEL:fb2864bf-63bb-4307-a0a6-50ce4c732d4a,CN
=SRV01,CN=Servers,CN=GD-DOM,CN=Sites,CN=Configuration,DC=domain,DC=de is t
he Schema Owner, but is deleted.Er ist definitiv Shema Owner und Domain Role Owner.
Und das soll auch so bleiben.
Es steht im prinzip ja da:
=SRV01.......is the Schema Owner, but is deleted.Der SRV02 is PDC, RID und DIM (Infrastructure Owner) < SRV02 bringt ja auch keine Fehler.
Der 3te Server den ich eigentlich löschen möchte ist quasi der SRV03.
Nur war der nie wirklich DC und konnte sich nie wirklich mit AD Synchronisieren.
Ich hab da im DCPROMO ein bisschen ### gebaut und darum kam das ganze gewurstel hier zustande.
Da ist gewaltig was schiefgelaufen so dass ich nicht mal mehr den SRV03 runterstufen konnte.
Darum hab ich ihn gewaltsam mit DCPROMO /FORCEREMOVAL entfernt.
Jetzt sitzt er noch in der AD Users and Computers - Domain Controllers.
1. Frage: Was passiert wenn ich den SRV03 gewaltsam aus der AD entferne?
2. Frage: Was passiert wenn ich den Hostnamen von SRV03 in SRVXY umbenenne und ihn als File Server erneut in die Domäne einbinde?
3. Frage: wie läuft das mit dem "metadata cleanup" ?
P.S.
Ich glaub ich habe mich in den Beiträgen vorher etwas missverständlich ausgedrückt.
Nochmal zur erklärung:
SRV01 - war von anfang Master DC mit den FSMO: Shema Owner und Domain Role Owner
SRV02 - war von anfang an Slave DC mit den FSMO: PDC, RID und Infrastructure Owner
SRV03 - ist vor 4 Wochen dazugekommen und sollte ebenfalls DC Slave werden. Was allerdings aufrund konfigurationsfehler nicht geklappt hat. und ab dem zeitpunkt war es quasi schon nicht mehr möglich den srv03 zu demoten/entfernen. und das war auch der zeitpunkt ab dem die ip adressen sich im dns verdoppelt haben (also gleiche ips zu unterschiedlichen hosts)
Mein Ziel ist es den SRV03 komplett zu entfernen.
Und die Server SRV01 und SRV02 wieder in den ursprünglichen Zustand zurückbringen, also die FSMO rollen sollen wieder wie früher verteilt sein.
Laut netdom query fsmo sind die Rollen immer noch so verteilt.
Laut DCDIAG hat nur SRV01 ein Problem mit den rollen. Er ist zwar nach wie vor Shema Owner und Domain role Owner aber nach dcdiag sind diese einträge gelöscht.
Okey, verstanden 
Zuerst musst du diesen dritten DC aus der Domäne entfernen. ich denke mal, da es ein zusätzlicher Server werden sollte, ist das kein Problem. Installiere das Betriebssystem neu oder formatiere die Festplatte um sicherzugehen das der Server niemals mehr bootet.
Anschließend öffnest du auf einem funktionierendem DC das ntdsutil und wechselst in den kontex "metadata cleanup"
Wähle die Target Domain, Site und den Server (DER GELÖSCHT WERDEN SOLL) unter connections, gehe zurück und entferne den Server gewaltsam mit "remove selected server".
Nun kannst du ADSIEdit öffnen und das Serverobjekt aus der "Domain Controllers" OU entfernen. Abschließend noch unter "AD Standorte und Dienste" evt. vorhandene Verweise auf den Server entfernen.
Zum Abschluss solltest du im DNS die Zone _msdcs.domain.xy von CNAME und Locator-einträgen auf den Server befreien. Nun kannst du gefahrlos die DNS A und CNAME Einträge in der "normalen" dns-zone entfernen.
Soweit sogut. Der Server sollte nun verschwunden sein. Nun musst du prüfen, was das Problem mit den FSMO's verursacht. Bitte konfiguriere dazu beide DC's auf den selben DNS-Server (Bevorzugt der, auf dem du vorher die Bereinigung durchgeführt hast), um Probleme bei der Replikation der DNS-Partition als Fehlerquelle für dcdiag auszuschließen.
mehr zum metadata-cleanup findest du auch hier:
http://support.microsoft.com/kb/216498/de
Falls du den Server "srv-03" nicht neu aufsetzen kannst, musst du ihn zwangsweise herunterstufen bevor er jemals wieder an das Netzwerk darf. Das geht mit dem parameter /forceremoval des dcpromo.
http://support.microsoft.com/kb/332199/de
Zuerst musst du diesen dritten DC aus der Domäne entfernen. ich denke mal, da es ein zusätzlicher Server werden sollte, ist das kein Problem. Installiere das Betriebssystem neu oder formatiere die Festplatte um sicherzugehen das der Server niemals mehr bootet.
Anschließend öffnest du auf einem funktionierendem DC das ntdsutil und wechselst in den kontex "metadata cleanup"
Wähle die Target Domain, Site und den Server (DER GELÖSCHT WERDEN SOLL) unter connections, gehe zurück und entferne den Server gewaltsam mit "remove selected server".
Nun kannst du ADSIEdit öffnen und das Serverobjekt aus der "Domain Controllers" OU entfernen. Abschließend noch unter "AD Standorte und Dienste" evt. vorhandene Verweise auf den Server entfernen.
Zum Abschluss solltest du im DNS die Zone _msdcs.domain.xy von CNAME und Locator-einträgen auf den Server befreien. Nun kannst du gefahrlos die DNS A und CNAME Einträge in der "normalen" dns-zone entfernen.
Soweit sogut. Der Server sollte nun verschwunden sein. Nun musst du prüfen, was das Problem mit den FSMO's verursacht. Bitte konfiguriere dazu beide DC's auf den selben DNS-Server (Bevorzugt der, auf dem du vorher die Bereinigung durchgeführt hast), um Probleme bei der Replikation der DNS-Partition als Fehlerquelle für dcdiag auszuschließen.
mehr zum metadata-cleanup findest du auch hier:
http://support.microsoft.com/kb/216498/de
Falls du den Server "srv-03" nicht neu aufsetzen kannst, musst du ihn zwangsweise herunterstufen bevor er jemals wieder an das Netzwerk darf. Das geht mit dem parameter /forceremoval des dcpromo.
http://support.microsoft.com/kb/332199/de
1. srv03 per "dcpromo /forceremoval" entfernt
2. metadata cleanup: der srv03 steht nicht in der "list servers in site" - also kann ich auch nix mehr da raus löschen
3. DNS: keine CNAME oder Locator einträge von diesem Server vorhanden
4. Habe ich einen Fehler entdeckt, der wahrscheinlich mit dem ganzen zusammenhängt:
---> MMC SRV01 > DNS > SRV02 > Forward Lookup Zones > domain.de > _msdcs > pdc > tcp
(tcp hat ein rotes X und zeigt keinen eintrag)
---> MMC SRV02 > gleicher Pfad wie gerade angegeben hat "pdc > tcp" einen Eintrag:
"_ldap | Service Location (SRV) | srv02.domain.de"
5. Unter ADSIEdit > Domain Controllers > kann ich den Server nur über "This domain controller is permanently offline and can no longer be demoted using dcpromo" entfernen. Habe den server03 über srv01 entfernt, srv02 hat es direkt repliziert und übernommen.
6. SRV01 > MMC > Active Directory Shema > Fehlermeldung: Snap-in failed to initialize. Name <unknown> CLSID: {632CCCF4-asdfgasdgasdf}
Aber in SRV02 > MMC > AD Shema > keine Fehlermeldung, funktioniert wunderbar.
7. Heute zusätzlich ein neuer Fehler über dcdiag rausgefunden (unter srv01 und srv02):
2. metadata cleanup: der srv03 steht nicht in der "list servers in site" - also kann ich auch nix mehr da raus löschen
3. DNS: keine CNAME oder Locator einträge von diesem Server vorhanden
4. Habe ich einen Fehler entdeckt, der wahrscheinlich mit dem ganzen zusammenhängt:
---> MMC SRV01 > DNS > SRV02 > Forward Lookup Zones > domain.de > _msdcs > pdc > tcp
(tcp hat ein rotes X und zeigt keinen eintrag)
---> MMC SRV02 > gleicher Pfad wie gerade angegeben hat "pdc > tcp" einen Eintrag:
"_ldap | Service Location (SRV) | srv02.domain.de"
5. Unter ADSIEdit > Domain Controllers > kann ich den Server nur über "This domain controller is permanently offline and can no longer be demoted using dcpromo" entfernen. Habe den server03 über srv01 entfernt, srv02 hat es direkt repliziert und übernommen.
6. SRV01 > MMC > Active Directory Shema > Fehlermeldung: Snap-in failed to initialize. Name <unknown> CLSID: {632CCCF4-asdfgasdgasdf}
Aber in SRV02 > MMC > AD Shema > keine Fehlermeldung, funktioniert wunderbar.
7. Heute zusätzlich ein neuer Fehler über dcdiag rausgefunden (unter srv01 und srv02):
Starting test: frsevent
There are warning or error events within the last 24 hours after the
SYSVOL has been shared. Failing SYSVOL replication problems may cause
Group Policy problems.
......................... SRV01 failed test frsevent
Starting test: kccevent
An Error Event occured. EventID: 0xC0000748
Time Generated: 10/08/2008 13:02:53
(Event String could not be retrieved)
An Warning Event occured. EventID: 0x8025082B
Time Generated: 10/08/2008 13:02:53
(Event String could not be retrieved)
An Error Event occured. EventID: 0xC0000748
Time Generated: 10/08/2008 13:02:53
(Event String could not be retrieved)
An Warning Event occured. EventID: 0x8025082B
Time Generated: 10/08/2008 13:02:53
(Event String could not be retrieved)
An Error Event occured. EventID: 0xC0000748
Time Generated: 10/08/2008 13:02:53
(Event String could not be retrieved)
An Warning Event occured. EventID: 0x80000785
Time Generated: 10/08/2008 13:11:03
Event String: The attempt to establish a replication link for
......................... SRV01 failed test kccevent
So langsam wirds brenzlig.
Irgendwas passiert. nur weiss ich nicht was.
Die ersten clients haben jetzt schon probleme auf bestimmte ressourcen zuzugreifen
Komischerweise wenn ich mich als admin anmelde und danach als user, gehts wieder.
*schwitz*
Nachtrag:
Punkt 6 und 7 fallen weg, die fehler kommen nicht mehr.
Irgendwas passiert. nur weiss ich nicht was.
Die ersten clients haben jetzt schon probleme auf bestimmte ressourcen zuzugreifen
Komischerweise wenn ich mich als admin anmelde und danach als user, gehts wieder.
*schwitz*
Nachtrag:
Punkt 6 und 7 fallen weg, die fehler kommen nicht mehr.
Okey, ruhe bewaren. Du hast ein Problem auf dem DC1. Woran das jetzt genau liegt, kann ich dir auf diesem Weg leider auch nicht sagen. Müsste mir das Ganze selbst einmal anschauen. Ich vermute ein Replikationsproblem oder ähnliches. Bitte konfiguriere auf beiden DC's den selben DNS-Server (dc2) und versuche mit netdiag /fix auf beiden DC's eventuelle DNS-Probleme zu eliminieren. Du musst auf jeden Fall herausfinden, was mit dc1 los ist. Wenn du dir sicher bist, das DC2 funktioniert, übertrage alle FSMO's vorrübergehend zu diesem.
Hi datasearch,
wenn ich jetzt shema owner und domain owner mit fsmo maintenance > transfer schema owner & transfer domain owner
auf DC2 übertrage, was passiert dann genau ?
Kann ich die beiden fsmos wieder ohne probleme zurückübertragen?
Kann dadurch alles noch schlimmer werden?
Infrastructure Owner und Shema Owner dem gleichen DC zu geben ist doch schlecht oder?
wenn ich jetzt shema owner und domain owner mit fsmo maintenance > transfer schema owner & transfer domain owner
auf DC2 übertrage, was passiert dann genau ?
Kann ich die beiden fsmos wieder ohne probleme zurückübertragen?
Kann dadurch alles noch schlimmer werden?
Infrastructure Owner und Shema Owner dem gleichen DC zu geben ist doch schlecht oder?
Du überträgst die FSMO-Rollen auf den funktionierenden Server. Bitte übertrage alle Rollen, bis auf den "Infrastructure master" auf DC2 und aktiviere auf DC2 den globalen Katalog. Dieser enthält einen Index bestimmter Atribute des LDAP-Verzeichnises (AD). Zum Abschluss deaktiviere auf DC1 den globalen Katalog.
Anschließend hast du wieder mehr Optionen. Die Clients verwenden nun DC2 als bevorzugten Anmeldeserver und es ist weniger Schlimm, wenn DC1 einmal kurz ausfällt.
Bitte konfiguriere auch noch in den DHCP-Optionen DC2 als primären DNS-Server für Clients. Ändere bitte auch die Zonensicherheit für die DNS-Zone "domäne.de" auf "Sichere und nicht Sichere Updates zulassen". Kann später, wenn ales funktioniert, wieder geändert werden.
Ziel ist, das alle Clients und Server DC2 als DNS-Server verwenden (inklusive DC1).
PS: Infra und Schema sind auf einem DC OK aber nicht empfohlen. Allerdings sollte niemals der Infra auf deinem DC, welcher gleichzeitig Globaler Katalog ist, ausgeführt werden. Andernfalls müsste JEDER DC in dieser Domäne ein GC sein. Hast du nur einen DC, hat dieser alle Rollen und da dieser ja "jeder DC in der Domäne ist", ist es wieder okey. Selbst wenn übergeordnete Domänen mit mehreren DC´s existieren.
Anschließend hast du wieder mehr Optionen. Die Clients verwenden nun DC2 als bevorzugten Anmeldeserver und es ist weniger Schlimm, wenn DC1 einmal kurz ausfällt.
Bitte konfiguriere auch noch in den DHCP-Optionen DC2 als primären DNS-Server für Clients. Ändere bitte auch die Zonensicherheit für die DNS-Zone "domäne.de" auf "Sichere und nicht Sichere Updates zulassen". Kann später, wenn ales funktioniert, wieder geändert werden.
Ziel ist, das alle Clients und Server DC2 als DNS-Server verwenden (inklusive DC1).
PS: Infra und Schema sind auf einem DC OK aber nicht empfohlen. Allerdings sollte niemals der Infra auf deinem DC, welcher gleichzeitig Globaler Katalog ist, ausgeführt werden. Andernfalls müsste JEDER DC in dieser Domäne ein GC sein. Hast du nur einen DC, hat dieser alle Rollen und da dieser ja "jeder DC in der Domäne ist", ist es wieder okey. Selbst wenn übergeordnete Domänen mit mehreren DC´s existieren.
Der funktionierende Server (SRV02) ist Infrastrukturmaster und GC
SRV01 ist kein GC.
Könnten daher die Probleme kommen?
dsquery server -domain domain.de -isgc
"CN=SRV02,CN=Servers,CN=GD-DOM,CN=Sites,CN=Configuration,DC=domain,DC=de" SRV01 ist kein GC.
Könnten daher die Probleme kommen?
C:\Program Files\Support Tools>netdom query fsmo
Schema owner srv01.domain.de
Domain role owner srv01.domain.de
PDC role srv02.domain.de
RID pool manager srv02.domain.de
Infrastructure owner srv02.domain.de
Okey, ändere das bitte mal. Das könnte das Problem mit verursacht haben (als du den 3. DC in die Domäne hinzufügen wolltest). Am besten den InfraMaster auf DC1 übertragen, den KCC und Netlogon Dienst neustarten und sehen was passiert.
Also ich mach jetzt quasi das hier:
ntdsutil
roles
connections
connect to server srv01
transfer infrastructure master
Danach Kerberos Key Distribution Center und Net Logon neustarten?
Und wenn ich mich dann nicht mehr Anmelden kann? :P
ntdsutil
roles
connections
connect to server srv01
transfer infrastructure master
Danach Kerberos Key Distribution Center und Net Logon neustarten?
Und wenn ich mich dann nicht mehr Anmelden kann? :P
Der InfraMaster ist eigentlich keine für die Anmeldung kritische Funktion. Er Überwacht "nur" die Topologie und kümmert sich um Replikationsverbindungen, zuweisen des Bridgehead usw. Den GC auf einen anderen Server übertragen würde da wesentlich größere Kopfschmerzen verursachen.
Hier wird die Vorgehensweise auch nochmal erwähnt. Du liegst also richtig.
http://technet.microsoft.com/en-us/library/cc782485.aspx
EDIT
Sorry, oben wollte ich eigentlich KCC und nicht KCC schreiben.
/EDIT
Hier wird die Vorgehensweise auch nochmal erwähnt. Du liegst also richtig.
http://technet.microsoft.com/en-us/library/cc782485.aspx
EDIT
Sorry, oben wollte ich eigentlich KCC und nicht KCC schreiben.
/EDIT
<EDIT>
Sorry, oben wollte ich eigentlich KCC und nicht KCC schreiben.
</EDIT>
KCC oder KCC ?
Sorry, oben wollte ich eigentlich KCC und nicht KCC schreiben.
</EDIT>
KCC oder KCC ?
Naja, ist heute irgendwie nicht mein Tag. KDC=Key Distribution Center, KCC= Knowledge Consistency Checker.
Also, dritter Versuch. Ich meinte KCC und nich KDC.
Also, dritter Versuch. Ich meinte KCC und nich KDC.
Nach einer genaueren Analyse und einigen Tests habe ich folgendes Herausgefunden.
ich habe folgende Schritte in Tests durchgeführt:
Anschließend hatte ich fast die selben Fehlermeldungen im Eventlog. Ich vermute, irgendwann wurde dein srv01 einmal neu installiert oder ausgetausch (oder eine Sicherung eingespielt) und vergessen die beiden FSMO´s für "Schema Master" und "Domain Naming Master" zu übertragen.
Der DNS-Server meldet den kritischen Fehler im Active Directory, weil der Wert des Attributes "fSMORoleOwner" auf ein nicht existentes Objekt "CN=NTDS Settings\0ADEL:fb2864bf-63bb-4307-a0a6-50ce4c732d4a,CN=SRV01...." verwiesen hat.
Warum allerdings du den 3. DC nicht promoten konntest, konnte ich nicht herausfinden. In meiner Testumgebung konnte ich ohne "Schema" und "Naming Master" dennoch weitere Server hinzufügen. Werde ich mir aber bei Gelegenheit noch einmal genauer anschauen.
Mit der Übernahme der Funktionen des "Schema Master" und "Domain Naming Master" auf den richtigen "srv01" haben wir quasi die Attribute im AD auf das richtige Objekt gesetzt. "ntdsutil seize ... master" macht quasi nichts anderes. Der neue Rolleninhaber weiß durch abfrage dieses Attributes, das er diese Funktion ausführen soll. Zusätzlich wird von NTDSUTIL eine "Mitteilung" an den neuen FSMO gesendet, das dieser sofort die entsprechende Rolle übernimmt. Bei einem "transfer" würde eine Benachrichtigung an den alten Inhaber gesendet, das dieser diese Funktion beenden soll und sobald dies geschehen ist, der neue Inhaber benachrichtigt.
Dummerweise habe ich keine Dokumentation von MS zur genauen Funktionsweise der FSMO-Übertragung gefunden. Wie es oberflächlich funktioniert ist klar, aber was da genau passiert, ausser das das Attribut im LDAP geändert und der Quellserver kontaktiert wird, ist unklar. Wieder eine schöne Beschäftigung das herauszufinden Naja, der alte Server, falls vorhanden, darf desshalb nicht mehr gebootet werden, da er noch über eine alte Version des AD verfügt, in der steht, das er diese Funktion ausübt und diese dann natürlich auch startet.
Ich denke, du kannst das Problem nun schließen und dich auf andere Dinge konzentrieren.
ich habe folgende Schritte in Tests durchgeführt:
- promoten eines neuen DC "srv01" für eine neue Domäne "testdrive.lan"
- promoten eines weiteren DC "srv02" als zusätzlicher DC für "testdrive.lan"
- srv01 neu installieren, selben namen vergeben
- auf srv02 ein metadata cleanup druchführen und alle computerobjekte des alten DC entfernen
- promoten den neu installierten srv01 als zusätzlichen DC für "testdrive.lan"
- übername der Funktionen RID, PDC und Infra-Master auf "srv01"
Anschließend hatte ich fast die selben Fehlermeldungen im Eventlog. Ich vermute, irgendwann wurde dein srv01 einmal neu installiert oder ausgetausch (oder eine Sicherung eingespielt) und vergessen die beiden FSMO´s für "Schema Master" und "Domain Naming Master" zu übertragen.
Der DNS-Server meldet den kritischen Fehler im Active Directory, weil der Wert des Attributes "fSMORoleOwner" auf ein nicht existentes Objekt "CN=NTDS Settings\0ADEL:fb2864bf-63bb-4307-a0a6-50ce4c732d4a,CN=SRV01...." verwiesen hat.
Warum allerdings du den 3. DC nicht promoten konntest, konnte ich nicht herausfinden. In meiner Testumgebung konnte ich ohne "Schema" und "Naming Master" dennoch weitere Server hinzufügen. Werde ich mir aber bei Gelegenheit noch einmal genauer anschauen.
Mit der Übernahme der Funktionen des "Schema Master" und "Domain Naming Master" auf den richtigen "srv01" haben wir quasi die Attribute im AD auf das richtige Objekt gesetzt. "ntdsutil seize ... master" macht quasi nichts anderes. Der neue Rolleninhaber weiß durch abfrage dieses Attributes, das er diese Funktion ausführen soll. Zusätzlich wird von NTDSUTIL eine "Mitteilung" an den neuen FSMO gesendet, das dieser sofort die entsprechende Rolle übernimmt. Bei einem "transfer" würde eine Benachrichtigung an den alten Inhaber gesendet, das dieser diese Funktion beenden soll und sobald dies geschehen ist, der neue Inhaber benachrichtigt.
Dummerweise habe ich keine Dokumentation von MS zur genauen Funktionsweise der FSMO-Übertragung gefunden. Wie es oberflächlich funktioniert ist klar, aber was da genau passiert, ausser das das Attribut im LDAP geändert und der Quellserver kontaktiert wird, ist unklar. Wieder eine schöne Beschäftigung das herauszufinden
Naja, der alte Server, falls vorhanden, darf desshalb nicht mehr gebootet werden, da er noch über eine alte Version des AD verfügt, in der steht, das er diese Funktion ausübt und diese dann natürlich auch startet.Ich denke, du kannst das Problem nun schließen und dich auf andere Dinge konzentrieren.
Hallo datasearch,
interessant was du da herausgefunden hast.
Aber was ich noch viel interessanter finde dass du wegen diesem Problem eine Testumgebung aufgesetzt hast
Warum ich den 3ten DC nicht promoten konnte hat sicher noch eine andere Ursache gehabt. Welche kann ich aber auch nicht mehr nachvollziehen.
Vielen Dank für deine Bemühungen.
Wir lesen hoffentlich noch voneinander.
Gruß divi
interessant was du da herausgefunden hast.
Aber was ich noch viel interessanter finde dass du wegen diesem Problem eine Testumgebung aufgesetzt hast
Warum ich den 3ten DC nicht promoten konnte hat sicher noch eine andere Ursache gehabt. Welche kann ich aber auch nicht mehr nachvollziehen.
Vielen Dank für deine Bemühungen.
Wir lesen hoffentlich noch voneinander.
Gruß divi
Es ließ mir einfach keine Ruhe. Herauszufinden wie so etwas verursacht werden kann, ich doch schon die Mühe wert. Testumgebung ist schnell aufgesetzt, "Deploy from Template" ... 10min Später habe ich 3 neue Server . Also nicht wirklich Aufwand.
Hauptsache es läuft bei dir wieder alles und ich habe wieder ein neues Szenario. Deshalb hilft man ja anderen, um selbst zu lernen und dieses Wissen wieder an andere weiterzugeben.
. Also nicht wirklich Aufwand.Hauptsache es läuft bei dir wieder alles und ich habe wieder ein neues Szenario. Deshalb hilft man ja anderen, um selbst zu lernen und dieses Wissen wieder an andere weiterzugeben
.
Machst du dann alles über VMWare?
