β11-04-2012 12:14 PM
Hi,
I had to recover my server from an unexpected rollback yesterday using Backup Exec System Recovery 8.0 to restore an image from earlier in the week (10/29). I didn't realize I needed to check off the Preserve domain trust token on destination option that perserves the Active Directory information when doing the restore and now I have a PDC that cannot communicate with any other computers on my network. (The network is only 1 PDC which is WIndows 2003 SBS and 5 Windows XP clients.)
When running dcdiag, I am getting the following:
C:\Documents and Settings\Administrator>dcdiagDomain Controller DiagnosisPerforming initial setup:Done gathering initial info.Doing initial required testsTesting server: Default-First-Site-Name\SERVERStarting test: ConnectivityThe host bd51ce3c-796b-4435-8cdf-df9b31afeb05._msdcs.coltsnecknursery.local could not be resolved to anIP address. Check the DNS server, DHCP, server name, etcAlthough the Guid DNS name(bd51ce3c-796b-4435-8cdf-df9b31afeb05._msdcs.coltsnecknursery.local)couldn't be resolved, the server name (SERVER.coltsnecknursery.local)resolved to the IP address (192.168.2.5) and was pingable. Check thatthe IP address is registered correctly with the DNS server.......................... SERVER failed test ConnectivityDoing primary testsTesting server: Default-First-Site-Name\SERVERSkipping all tests, because server SERVER isnot responding to directory service requestsRunning partition tests on : ForestDnsZonesStarting test: CrossRefValidation......................... ForestDnsZones passed test CrossRefValidationStarting test: CheckSDRefDom......................... ForestDnsZones passed test CheckSDRefDomRunning partition tests on : DomainDnsZonesStarting test: CrossRefValidation......................... DomainDnsZones passed test CrossRefValidationStarting test: CheckSDRefDom......................... DomainDnsZones passed test CheckSDRefDomRunning partition tests on : SchemaStarting test: CrossRefValidation......................... Schema passed test CrossRefValidationStarting test: CheckSDRefDom......................... Schema passed test CheckSDRefDomRunning partition tests on : ConfigurationStarting test: CrossRefValidation......................... Configuration passed test CrossRefValidationStarting test: CheckSDRefDom......................... Configuration passed test CheckSDRefDomRunning partition tests on : coltsnecknurseryStarting test: CrossRefValidation......................... coltsnecknursery passed test CrossRefValidationStarting test: CheckSDRefDom......................... coltsnecknursery passed test CheckSDRefDomRunning enterprise tests on : coltsnecknursery.localStarting test: Intersite......................... coltsnecknursery.local passed test IntersiteStarting test: FsmoCheck......................... coltsnecknursery.local passed test FsmoCheck
Event Type: ErrorEvent Source: DNSEvent Category: NoneEvent ID: 4000Date: 11/3/2012Time: 11:18:28 PMUser: N/AComputer: SERVERDescription:The DNS server was unable to open Active Directory. This DNS server is configured to obtain and use information from the directory for this zone and is unable to load the zone without it. Check that the Active Directory is functioning properly and reload the zone. The event data is the error code.For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.Data:0000: 2d 23 00 00 -#..
Is there a way to fix this problem after the fact without resinstalling the OS, rebuilding the network, and then restoring the system checking off the option to preserve the new network information?
Thanks.
Keith
Solved! Go to Solution.
β11-04-2012 11:59 PM
I'd rather post this question to microsoft - but why don't you restore the system again now with the option unchecked ?
β11-04-2012 11:59 PM
I'd rather post this question to microsoft - but why don't you restore the system again now with the option unchecked ?
β11-05-2012 07:14 AM
That won't work. That's how I got into this mess. You're supposed to check off the option so that it perserves the AD information on the disk and doesn't overwrite it from the backup. I didn't check the option and, therefore, overwrite the original AD information which is what landed me in this mess. Now the AD information on disk is bad (out of date) and I need a configurative way to reinstate the PDC to the network as the PDC.
I thought of rolling back all clients on the network (since there are only 5 and they are all imaged) but that wouldn't work either as it's not just the clients who can't communicate w/ the server, there are services on the server itself that are failing b/c the AD information can't be used.
My only idea at this point is to reinstall the OS, rebuild the network (reconnect clients to server), and then reimage the device with the option checked so as to preserve AD info. Would like to see if:
1.) someone can confirm this will work.
2.) There is anyway to avoid all of that.
Keith
β11-05-2012 06:02 PM
Markus,
Rereading your response... I am wondering, did you mean to say "rerun with the option checked"? i.e. as in how it should be?
I think I presumed that would not work since I had already overwritten the existing information. However, now I am wondering if there is a potential that might work. Reading up on active directory, it seems the way to reinstate a PDC is to do a non-authoriative restore so that the PDC uses the replicated information as the source of truth.
The option is says:
"Preserve domain trust token on destination" - Perserves the token that is used to authenticate a user or a computer on a domain. This option helps ensure that the recovered computer is recognized by a network domain after it is recovered.
I interpreted this as preserving the exsting information on disk but maybe it means non-authoriative restore so that the information is updated from replication? Can you speak to how this option actually works?
Keith
β11-05-2012 10:09 PM
What I meant is that in the backup there is the "good" domain token contained, right ? If you do a full restore of the machine, including an authoritative AD restore, you'll overwrite the "bad token" on the disk with the "good token" from the backup.
β11-06-2012 03:03 AM
I don't know... I hope so. That is really the question. I have already tried to restore twice with the option unchecked and it produced the result I have now both times.
I am thinking I should try to do it with the option checked as it advised. If I understand correctly, this would be the recommended procedure for a bare metal restore so I am hoping it should work. (Otherwise how would I do a bare metal resore???)
Thanks.
Keith
β11-06-2012 03:32 AM
Yep, give it a try and keep us posted !
β11-06-2012 09:26 PM
Markus,
Thank you! You just became a personal hero!
You're advice UNCHECKING the box did the trick. Unfortunately, I had the whole concept of what was going on backwards. I thought I had failed to check the box, and thus deleted information that I needed to sync w/ the clients. Now I see that infact it was leaving the box checked that was causing the updated information to persist and thus not match the restored information. UNCHECKING the box to completely restore from backup was just what I needed!
Thank you.
Keith
PS. My compliments to the Symantec team. I have always been a big fan of Symantec products but System Restore just wins me over more every time I use it. Well done!
β11-06-2012 10:36 PM
It was a pleasure to work with you !