I demoted one of my domain controllers, that has Sharepoint Services on it. After demoting it, I was unable to access my Sharepoint site. Now, I've tried to repair the Sharepoint site, but it just seems to be getting farther from fixed. I ran the SharePoint Products and Technologies Configuration Wizard in an effort to recover the site, but that only seemed to make things worse, since it caused my website to vanish from IIS. So now I don't even know if my data is there anymore. So, if I were to restore the server, from a backup when it was still a DC, can reintroduce it into the network? Or should I restore it, then do a DCPromo and demote it while it is disconnected from the network first? Either way, I still need to get my Sharepoint Services working. What needs to be modified so that my demoted DC works with Share point Services? Thanks

Hi ksaaeta, While it's great that you have a backup here, I would always recommend attempting something like this in a virtual environment prior to running on a live server. What error did you get upon trying to access the SharePoint site? If your DC was running a DNS service as well it may simply be that the site name is not resolving. With regard to loss of data, SharePoint content is stored within a SQL database so losing your IIS configuration does not necessarily mean your content is lost. Also, if you are using NTBackup to back up your system state it is likely you have an IIS metabase backup which can be used to restore your IIS configuration if necessary. You could restore from the backup and reintroduce the DC to the network so long as the backup is not longer than the tombstone lifetime for your forest. Restoring a domain controller from backup: http://technet.microsoft.com/en-us/library/cc782127(WS.10).aspxBenjamin Athawes - Twitter: @benjaminathawes - Blog: http://mossblogger.blogspot.com - Email: mail at bathawes.com

Just working from (my) logic... If you install a v3 SharePoint product you can't later make it a DC. The order needs to be 1. make a server a DC 2. Add SharePoint. My logic says that therefore in order to remove the DC function correctly you must first remove SharePoint (LIFO principle) and then remove the DC function. So that was the error imo. I suspect the solution is along the lines Benjamin states but my first try would be to start from scratch and do a new server OS installation on the server (without a DC) and then install MOSS using the installation version that uses the existing content database. Take all kinds of other backups first. Only if that doesn't work should you imo get rid of MOSS; reinstall the DC on the server and then reinstall MOSS (because of course then you'd be back in the situation with DC you started with but didn't want) perhaps using Benjamin's restore approach.2010 Books: SPF 2010; SPS 2010; SPD 2010; InfoPath 2010; Workflow etc. 2007 Books: WSS 3.0; MOSS 2007; SPD 2007; InfoPath 2007; PerformancePoint; SSRS; Workflow Both lists also include books in French; German; Spanish with even more languages in the 2007 list.

Please take a look at the caution and notes section in http://technet.microsoft.com/en-us/library/cc740017(WS.10).aspx.

> Please take a look at the caution and notes section in All true but that post is from 2005 and also doesn't have anything about DCs and SharePoint - it is only general information for things to watch out for when demoting a DC. Here I think we are more concerned with the effect on SharePoint when demoting a DC where SharePoint was also installed.2010 Books: SPF 2010; SPS 2010; SPD 2010; InfoPath 2010; Workflow etc. 2007 Books: WSS 3.0; MOSS 2007; SPD 2007; InfoPath 2007; PerformancePoint; SSRS; Workflow Both lists also include books in French; German; Spanish with even more languages in the 2007 list.

I was able to restore my server with a week of smacking my head against the server, and much investigation of the WWW. Thanks for your insights as well. Luckily, first of all, we were using Backup Exec System Recovery, and I was able to pull the C: drive of the Sharepoint Server back from the grave. It resurrected fine. I left it off, and then proceeded with an administrative restore of the NTDS settings from a previous backup, onto a different server. Needless to say, I recovered the WRONG System State onto the wrong server... nothing was affected thankfully since nothing had changed on that server. I then proceeded to recover the System state to the correct server. I then restarted that server BEFORE telling it which items I wanted to Authoritatively restore. So essentially, I just recovered some data and then it was replicated over by the other domain controllers. Finally, I ran it again, recovered it properly, and ran NTDSUTIL to authoritatively restore the NTDS settings for the Sharepoint domain controller. Everything came up, as well as a slew of replication errors, Exchange errors, DNS errors, KCC errors and my DNS zones vanished from the computer that I had used to restore the Active Directory. This problem was mostly caused because the Kerberos password on the server I used to restore the data was not matching the rest of the domain (possibly because it got restored, I'm not sure). I then used the NETDOM.EXE program, shut off the KCC service on all my domain controllers except one, and reset the password. This fixed all the problems I could see. And my Sharepoint works, my Active Directory works, my Exchange works... So the Lessons are: 1. Do NOT Demote a Domain Controller running Sharepoint services. 2. When you Do an Authoritative Restore, don't forget that little step at the end where you actually run NTDSUTIL and tell it what data to keep. Very important. 3. Make sure your backups work properly. If you have nothing to backup from your SOL. 4. There might be a lot of errors everywhere, but it may all be caused by a base item; In this case the Kerberos key was missing, so it's worth hunting through your logs to find the most basic problem, then solving that. Everything else will likely start working afterword.