2 gescheiden sites weer bij elkaar brengen-DC terugplaatsen

[anoniem]

dag, ik heb thuis een domein welke voorheen gescheiden was tussen 2 adressen. middels VPN werden de sites gerepliceerd wat allemaal prima werkte. met een domainbased share werden ook nog eens de shares tussen de sites gerepliceerd waardoor afhankelijk van de subset (ipadres) de juiste target werd gekozen. enige tijd geleden vloog de VPN eruit en kreeg ik die niet meer aan de praat. repliceren ging dus niet meer. helaas ben ik vergeten hoe lang dat ongeveer geleden is. omdat ik wist dat de sites binnenkort toch weer bij elkaar gebracht werden heb ik niet de moeite genomen om de VPN weer proberen te maken. dit weekend is de tijd gekomen dat de sites bij elkaar gebracht werden. het is denk ik wel maaaaanden geleden dat voor het laatst ingebeld is via VPN. hoe heb ik het aangepakt? de site heb ik down gebracht op de te verhuizen locatie. de DC en clients zijn meegenomen naar de andere site. hier heb ik die weer aangesloten en de ipadressen aangepast aan die van de site waarnaar verhuisd werd. ik heb de DNS gerepareerd en alle oude verwijzingen naar de oude situatie verwijderd. ik heb de DHCP van de verhuisde DC uitgeschakeld en de andere neemt het over. tot op heden wordt er niet gerepliceerd in de AD. met DFS zijn beide locaties wel beschikbaar en ook al schakelen de clients over op de ene server naar de andere kwa shares, er wordt niet tussen gerepliceerd. de oude site heb ik uit de AD verwijderd, maar ook dit wordt niet gerepliceerd naar de andere DC. de rollen zijn op de server die niet is verhuisd gevuld met ERROR. dat is dus niet goed... :( ik weet ff niet meer wat ik meot doen. de verhuisde server is de PDC maar op die staat alles nog goed. denk dat ik 1 van de twee moet demoten. ligt eraan welke of ik dan ook nog rollen moet gaan seizen? op de PDC draait overigens ook nog exchange. weet nie of dat nog voor problemen zorgt. ik ontvang iig geen mail en voor de clients is de exchange server ook niet te benaderen.

[anoniem]

Zie je in AD Sites and Services nog wel beide domain controllers staan? Met andere woorden: heb je niet die andere site verwijderd, inclusief de verwijzing naar de DC van die site? Een Domain Controller demoten, waar ook Exchange op draait, gaat niet. Je zal dan eerst Exchange moeten verwijderen, wat uiteraard geen optie is. Je zal er in ieder geval voor moeten zorgen dat beide domain controllers elkaar op FQDN kunnen benaderen, dus je DNS moet 100% in orde zijn. Verder is het handig om de eventlogs te bekijken. Welke meldingen heb je daar zoal staan?

[anoniem]

beide DC's zijn nog te zien ja. de site is verwijderd maar voor de rest bestaat alles nog. mocht ik 1 van de twee moeten demoten, dan zal dat degene zijn die al op de bestaande locatie stond. Dit is ook niet de PDC dus ik verwacht daar niet al te veel problemen mee. Voorwaarde is inderdaad zorgen dat ze elkaar kunnen benaderen op de FQDN. Dit zal ik nog voor elkaar moeten krijgen. Ze synchroniseren op dit moment totaal niet, dus moet ik de DNS handmatig in beide DC's hetzelfde krijgen?? Op dit moment kom ik alleen op de niet-PDC (op afstand). de PDC die verhuisd is staat momenteel uit. De eventlogs op de machine die ik wel kan benaderen spreekt over het algemeen dat AD: replication niet mogelijk is (tombstone voorbij), the remote server which is master of FSMO is not responding DHCP: failed to see a directory server for authorization DNS: the DNS server is waiting for AD DS to signal that the initial synchronization of the directory has been completed. (dit is de enige waarschuwing) file: the DFS replication service failed to communicate with partner megatron for replication group x. Host unreachable. system: name resolution for the name <myhood.com> timed out after none of the configured DNS servers responded, This computer was not able to set up a secure session with a DC in domain MYHOOD due to the following: there are currently no logon servers available to service logon request. hoop meldingen dus, al valt het mee :| misschien dat op de PDC meer meldingen zijn als ik die weer aanzet.

[anoniem]

Welke FSMO rollen heeft de domain controller die nu aan staat en waarom staat de andere domain controller uit? Om dit probleem op te lossen zul je in ieder geval beide domain controllers moeten hebben draaien...

[anoniem]

ik heb de verhuisde DC uitgezet omdat ik er niet aan kon werken afgelopen dagen. Ik heb ze vorige weekend en wat dagen rondom beide laten draaien om ze iig te laten syncen voor zover ze dat konden. toen ik daar geen beweging in zag heb ik ze alletwee uitgezet. dacht ik...de andere draaide nog :) ik zal zo de PDC aanzetten welke naar mijn weten alle FSMO rollen heeft. De niet-verhuisde DC geeft ook de <ERROR>'s bij de FSMO-rollen. Die kreeg ie dus niet door van de PDC.

[anoniem]

In principe hoef je de rollen ook niet over te zetten als je een DC gaat verhuizen naar een ander subnet. Het is een kwestie van IP-adressen aanpassen en binnen AD Sites and Services de domain controller verplaatsen naar de andere site. Daarnaast moet de DNS aangepast worden, zodat daar het nieuwe IP-adres in staat en na een 'ipconfig /flushdns' op de andere DC, moet alles het weer gewoon doen... Zet inderdaad de verhuisde domain controller maar eens aan en controleer of DNS goed werkt (maw: de andere DC moet de verhuisde DC kunnen pingen op FQDN). Herstart hierna eerst maar eens de niet-verhuisde DC en controleer of deze weer de FSMO rollen kan vinden op de verhuisde DC.

[anoniem]

Ip adressen op niet verhuisde nog aangepast. Sec dna verwees nog naar oude subnet. Nu beide dc ingericht primary dns zelf, secondary de ander. Ze kunnen elkaar pingen op fqdn. Echter niet verhuisde heeft nog steeds error bij fsmo rollen. Op verhuisde zijn fsmo aan zelf toegewezen. Heb servers verschillende malen in proces herstart. Heb ipadressen in dns nog niet nagekeken maar Lingen gaat goed. Wanneer ik op niet verhuisde handmatig willen repliceren zegt ie dat tombstone is bereikt. Dit is al andere melding dan voorheen dus communicatie tussen de servers is iig goed. Op de verhuisde server handmatig repliceren geeft een foutmelding over de naming context of text niet juist is en daarom niet repliceert. Dit kan overigens misschien ook te maken hebben met feit dat op deze server nog een oude gecrashte server zweeft die ik op de andere met adsiedit heb moeten verwijderen .... Ik laatze vannacht maar ff aan. Hopelijk syncen ze nog iets alhoewel ik met die tombstone niet veel hoop heb...

[anoniem]

Als je nog een gecrashte domain controller in je Active Directory hebt zweven, kun je deze opruimen met een 'metadata cleanup' in ntdsutil. Google hier maar eens op voor de procedure. Kunnen PC's wel inloggen op het domein als ze de verhuisde domain controller als (enige) DNS server hebben ingesteld? Wat draait er allemaal voor bijzonders op de niet-verhuisde domain controller? Misschien is het een mogelijkheid om deze te demoten en opnieuw DC te maken, maar dan moeten er geen dingen als Exchange, IIS of iets dergelijks op draaien en dan moet je zeker weten dat de andere domain controller goed functioneert.

[anoniem]

Metadata cleanup ja. Die bedoel ik. Dat had ik al uitgevoerd op de niet verhuisde. Maar dat is dus niet gesynct naar de andere. Daar dus nogmaals handmatig uitvoeren .... Ik zal zo kijken of de dc goed werkt als clients inloggen met alleen die dns server. Op de niet verhuisde draait niet veel bijzonders. Wel een evaluatieversie van exchange 2007 of 2010 maar daar hangt geen enkele mailbox onder. Hij was meer bedoeld ooit als fallback.

[anoniem]

Hmmm, als er Exchange op draait zul je die eerst moeten de-installeren, maar dat gaat natuurlijk niet, als Active Directory niet goed werkt... Je zal toch moeten proberen om Active Directory goed aan de praat te krijgen... Het is voor mij zo vrij lastig om te beoordelen waar het probleem nu precies zit. Ik neem aan dat beide domain controllers een Global Catalog hebben? Je kan dit controleren in 'Active Directory Sites and Services', als je de properties neemt van 'NTDS Settings' onder beide servers...

[anoniem]

ik heb net voor een client het wachtwoord veranderd. deze lijkt goed gesynchroniseerd te zijn naar beide DC's. Ik kan via remote desktop op beide DC's met het nieuwe wachtwoord inloggen. als ik ingelogd ben op een client en ik verander mn ip adres naar alleen DNS van de verhuisde DC dan kan ik wel pingen naar de FQDN van de verhuisde DC, maar verkenner openen om de shares te zien doet ie niet op de FQDN. inloggen zal dan ook wel niet gaan. dat ga ik nu proberen. beide servers kunnen wel pingen naar elkaar, dat gaat allemaal goed. zowel op computernaam als op FQDN. alleen ook op de server kan ik de verhuisde niet met verkenner openen om de shares te zien. wel op IP-adres. ik zal op de verhuisde eerst nu met metadata clean up de oude server verwijderen. beide servers zijn GC.

[anoniem]

geprobeerd in te loggen op de verhuisde server :( lukt niet. bij het inloggen krijg ik rood kruis en de melding dat er geen vertrouwensrelatie opgebouwd kan worden tussen deze client en het primaire domein. grrrrrrr....wat nu te doen. :evil:

[anoniem]

ik probeer nu met RDP in te loggen met bijvoorbeeld mijn telefoon en laptop. ik kom elke keer terecht op de niet-verhuisde DC als ik dit met de FQDN of met de computernaam probeer.. als ik met ipadres doe dan kom ik er wel op... :( dan verder nog: als ik een password wijzig en ik kan op beide DC's met RDP inloggen met nieuwe wachtwoord, betekent dit dan dat het wachtwoord is gesynchroniseerd? m.a.w.; is de DC waarop je inlogt met RDP, automatisch ook de LOGONSERVER? als ik nl nu een nieuwe gebruiker aanmaak in 1 van de DC's wordt die niet gesynchroniseerd... met metadata cleanup nu wel de oude gecrashte DC verwijderd. scheelt weer iig...

[anoniem]

Zoals ik al eerder schreef is het voor mij op deze manier erg lastig om te bepalen waar het mis gaat... Had je al gecontroleerd of beide domain controllers een global catalog bevatten? Om te bepalen wat de huidige logonserver is, kun je in een command prompt 'echo %logonserver%' doen...

[anoniem]

met set heb ik op de client vastgesteld dat het elke keer de niet verhuisde server is. die had ik op een gegeven moment uitgezet om zeker te weten dat de client de verhuisde server zou pakken. toen kreeg ik de melding over het niet vertrouwen van de client en het primaire domein. beide servers zijn inderdaad GC. kan ik nog controleren of ze deze echt hebben/bevatten oid? in de properties zijn ze iig als GC ignesteld. ik las op internet iets over het vergroten van de tombstone lifetime en DNSLint gebruiken om te controleren of het repliceren goed gaat (van microsoft zelf). http://support.microsoft.com/kb/321046/nl weet alleen niet of dat precies is wat ik zoek.

[anoniem]

increasen van de tombstone lifetime helpt ook niet. als ik dan handmatig replicate NOW doe, zegt ie op de niet-verhuisde server nog steeds dat de tombstone lifetime exceeded... nog eens wat anders proberen.

[anoniem]

dit is toch ook gek...: https://picasaweb.google.com/lh/photo/-UHu7FvuRJmLk_g6LzeTd2Lf6LvdSAR4RBYeetaUOgU?feat=directlink als je queriet op de FSMO rollen staan ze correct, kijk je in de properties van domein staat er ERROR... :o

[anoniem]

Welke naam heeft de domain controller die verhuisd is en wat is degene die niet verhuisd is? In het screenshot heb je namelijk van AD Users and Computers een connectie naar 'neo'. Deze DC kan de andere niet meer vinden. Wat geeft ie weer als je in AD Users and Computers een connectie naar de andere DC maakt?

[anoniem]

Verhuisde: megatron niet-verhuisde: neo Er lijkt overigens iets moois gebeurd vannacht. Op Neo zijn de errors verdwenen en hij geeft nu bij de fsmo rollen aan dat megatron die heeft. Als ik in ADU&C verbindt met megatron krijg ik ook geen fout. Ook lijkt de testuser die ik enkele dagen geleden heb aangemaakt gerepliceerd naar de andere. DFS lijkt ook weer beetje te werken. De shares zijn aan het repliceren gegaan. Handmatig replicate now lukt op Neo voor Neo van Megatron niet (fout: directory object not found). Op Neo voor Megatron van Neo lukt wel :) Ga nu proberen op Megatron beide kanten op.

[anoniem]

Handmatig repliceren op Megatron geeft beide kanten op geen problemen :) Als ik nu met mn telefoon ook rdp opstart kom ik ook netjes in de dc die ik wil en niet telkens in Neo zoals voorheen. Gisteren kon ik ook al met een client verbinding maken met Megatron als exchange server. Wel raar....de verbinding leek wel via Neo te lopen want ik kreeg een certificaat melding die ik moest accepteren van Neo (win2008). Terwijl daar geen mail boxen op draaien....