Learn when you want, where you want with convenient online training courses. Sign up now!
Experts Exchange Solution brought to you by
"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.
Run dcdiag /test:checksecurityerror on the source DC
SPNs may be missing, invalid or duplicated due to simple replication latency, especially following promotion, or replication failures.
Duplicate SPNs may cause bad SPN to name mappings.
DCDIAG /TEST:CheckSecurityErrorr can check for missing or duplicate SPNs and other errors.
Run this command on the console of all source DCs that fail "outbound" replication with the SEC_E_WRONG_PRINCIPAL error.
You can check SPN registration against a specific location using the syntax:
dcdiag /test:checksecurityerror replsource:<remote dc>
Verify that Kerberos encrypted network traffic reached the intended Kerberos target (name-to-IP mapping).
When inbound replicating Active Directory, destination DCs search their local copy of Active Directory for the objectGUID of the source DCs NTDS Settings objects, then query the active DNS Server for a matching DC GUIDed CNAME record which is then mapped to a host "A" / "AAAA" record containing the source DCs IP address. Active Directory performs name resolution fallback that includes queries for fully qualified computer names in DNS or single-label hostnames in WINS (note: DNS servers can also perform WINS lookups in fallback scenarios).
Stale NTDS Settings objects, bad name-to-IP mappings in DNS and WINS host records, stale entries in HOST files can all cause a destination DC to submit Kerberos-encrypted traffic to the wrong Kerberos target.
There are two methods to check for this condition:
Take a network trace.
Manually verify that name DNS / NetBIOS name queries resolve to the intended target computer.
Administration of Active Directory does not have to be hard. Too often what should be a simple task is made more difficult than it needs to be.The solution? Hyena from SystemTools Software. With ease-of-use as well as powerful importing and bulk updating capabilities.
To force the removal of a domain controller by using the Windows interface
At a command prompt, type the following command, and then press ENTER:
If the domain controller hosts any operations master (also known as flexible single master operations or FSMO) roles, or if it is a Domain Name System (DNS) server or a global catalog server, warnings appear that explain how the forced removal will affect the rest of the environment. After you read each warning, click Yes. If you want to suppress the warnings in advance of the removal operation, you must force the removal of Active Directory Domain Services (AD DS) by using an answer file. In the answer file, specify the parameter demotefsmo=yes.
On the Welcome to the Active Directory Domain Services Installation Wizard page, click Next.
On the Force the Removal of Active Directory Domain Services page, review the information about forcing the removal of AD DS and metadata cleanup requirements, and then click Next.
On the Administrator Password page, type and confirm a secure password for the local Administrator account, and then click Next.
On the Summary page, review your selections. Click Back to change any selections, if necessary.
To save the settings that you selected to an answer file that you can use to automate subsequent AD DS operations, click Export settings. Type a name for your answer file, and then click Save.
When you are sure that your selections are accurate, click Next to remove AD DS.
You can either select the Reboot on completion check box to have the server restart automatically or you can restart the server to complete the removal of AD DS when you are prompted to do so.
Open Server Manager. Click Start, point to Administrative Tools, and then click Server Manager.
In Roles Summary, click Remove Roles.
If necessary, review the information on the Before You Begin page, and then click Next.
On the Remove Server Roles page, clear the Active Directory Domain Services check box, and then click Next.
On the Confirm Removal Selections page, click Remove.
On the Removal Results page, click Close, and then click Yes to restart the server.
Yes - you should be able to promote a computer with the same name as the original DC...
Before you to though, make sure to go through each step of http://support.microsoft.com/kb/555846
If you are re-promoting the DC you previously demoted, I'd suggest reinstalling the OS - although ultimately this depends on the reason for demoting it...
Yeah that is fine, when you did the /forceremoval and metadata it got rid of the old references for that old DC (DC-GUID). There shouldn't be any lingering info.
DS team also outlined the /forceremoval, metadata cleanup, repromote process in that article (towards the end)
Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.
From novice to tech pro — start learning today.
Premium members can enroll in this course at no extra cost.