VMware: Redo files (Snapshots) and Active Directory


Om even een punt aan te wakkeren met betrekking tot de discussie over het virtualizeren van een Domain Controller (vanaf nu DC red.) de volgende post. Redo files / Snapshots en DC’s. Toevallig had ik gisteren de nare ervaring van een redo file die afgelopen vrijdag gecommit werd met oude data. Je raad het al de desbetreffende DC was corrupt.

Even de voorgeschiedenis over hoe dit ontstaan is.

VMBK zoals het hoort

VMBK.pl word gestart. Deze maakt een redo file aan zodat er een hot backup plaats kan vinden.

vmbkredo.gif

Nadat de backup klaar is, wordt de redo file gecommit en worden alle wijzigingen die op het moment dat de redo file actief is, samengevoegd met de data op de vmdk. De data uit de redo file krijgt voorang op de data die al op de vmdk staat.

vmbkredo1.gif

Redo file als het mis gaat

In mijn geval was de vmbk.pl job blijven hangen. Door gebrek aan tijd kon ik de log files niet nakijken en kwam ik er pas afgelopen vrijdag achter. Nadat ik de ESX server (2.5.4 patch 4) opnieuw opgestart had ging de back-up job gewoon weer aan de slag die nacht. Maar wat er volgens mij gebeurd is nadat de backup klaar was, heeft vmbk de redo file gecommit die al meer dan week oud was. Balen want het was mijn eerste DC welke alle FSMO roles had etc.

Zoals je in het volgende plaatje ziet wordt de oude redo file gecommit.

vmbkredo2.gif

En het gevolg is dat de DC corrupt raakt.

vmbkredo3.gif

EventID’s op de DC

Hier vindt je een overzicht van alle evenID’s die optraden nadat de DC corrupt raakte.

dcaftercommit.gif

dcaftercommit1.gif

dcaftercommit2.gif

dcaftercommit3.gif

dcaftercommit4.gif

Hoe deze ellende weer herstellen

Volgens KB875495 is de enige oplossing na zo’n voorval als deze het “demoten” van de DC en het daarna weer opnieuw aanmaken van de AD.

FSMO roles verplaatsen

Voordat je dit gaat doen dien je de FSMO roles te verplaatsen (informatie over FSMO roles vindt je hier: http://www.petri.co.il/ en hier: KB197132). In KB324801 lees je hoe je na kunt gaan welke FSMO roles er actief zijn op de DC die verwijderd moet worden. Nadat je bent nagegaan welke FSMO roles er actief zijn dien je deze te verplaatsen. Hier http://www.windowsdevcenter.com/ vindt je meer informatie over het plaatsen van FSMO roles.

Het kan zijn dat de DC dermate beschadigd is, dat het verplaatsen niet meer mogelijk is. In dit geval moet je de FSMO roles “seizen”. Meer informatie over hoe dit in zijn werk gaat lees je hier: http://www.petri.co.il en KB255504.

DC demoten

Nadat je de FSMO roles hebt overgezet kun je de DC demoten. Dit kun je doen via start | Run | dcpromo {enter}.

In mijn geval lukt dit niet en moest ik het volgende commando gebruiken: start | Run | dcpromo /forceremoval {enter}. meer informatie over deze actie lees je in KB332199.

Mocht je gebruik moeten maken van de /forceremoval dan dien je nadat de DC gedemote is ook de oude data van de DC uit de werkende AD te halen. Hoe dit in zijn werk gaat kun je hier lezen: http://www.petri.co.il/

AD weer installeren

Nadat de AD geschoond is en de DC welke kapot was weer een stand alone server is, moet deze weer geconfigureerd worden als DC. Dit heb ik als volgt gedaan. De DC heb ik lid gemaakt van het domain. Daarna heb ik dcpromo (start | Run | dcpromo {enter}.) uitgevoerd en geconfigureerd als additionele domain controller.

Na dit alles kwam de replicatie weer op gang en werkte alles weer naar behoren.

Server responds very slow when shadow copies are running


Event Id’s

eventID : 7001

VSS

VssAdmin: Unable to create a shadow copy: The shadow copy provider had an error. Please see the system and application event logs for more information.
Command-line: ‘C:\WINDOWS\system32\vssadmin.exe Create Shadow /AutoRetry=5 /For=\\?\Volume{c5b975b9-d6bc-11da-90ad-0050569c1bf5}\’.

eventid 12317,

File Server Resource Manager failed to enumerate share paths or DFS paths. Mappings from local file paths to share and DFS paths may be incomplete or temporarily unavailable. FSRM will retry the operation at a later time.

Event ID 12289, VSS

Volume Shadow Copy Service error: Unexpected error DeviceIoControl(\\?\Volume{c5b975b9-d6bc-11da-90ad-0050569c1bf5} – 0000012C,0x0053c008,000374C0,0,000384C8,4096,[0]). hr = 0x80070005.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp

Oplossing

Microsoft heeft een patch vrijgegeven welke een aantal shadow copies problemen oplost. Je kunt patch hier downloaden KB891957

Mocht deze patch het probleem niet verhelpen dan kun het als volgt oplossen: Restore de shadow copies configuratie naar default, dus disabled. Let op! alle shadow copies gaan verloren als je dit doet!

Configureer nu shadow copies zoals het was voordat je het naar default had gezet.

Mogelijke Oorzaak

Mijn collega ICT-Freak Jimmy kreeg deze event id’s nadat hij de partities van zijn fileserver had vergroot.

EventID: 1054


De volgende foutmelding stond er in het evenlog:

Event ID: 1054
Source: Userenv
Type: Error

Description: Windows cannot obtain the domain controller name for your computer network. (The specified domain either does not exist or exist or could not be contacted). Group Policy processing aborted.

In KB326152 vindt je meer informatie over het probleem.

Er is nog geen officiele patch beschikbaar voor dit probleem maar, Micorosft heeft het volgende KB artikel beschikbaar gesteld KB239924/ met daarin een workaround.

In de workaround wordt beschreven hoe je een registry key aan moet passen. Dit kun je doen door de volgende registry key te kopieeren naar kladblok en op te slaan als kb239924.reg.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
“DisableDHCPMediaSense”=dword:00000001

Vervolgens kun je dubbel klikken op het bestand om de registry key te importeren. Na het importeren wordt DHCP Media Sensing uitgeschakeld


bron: KB326152 KB239924/