SharePoint on a Domain Controller
Posted by Brian Gough on July 16, 2009
Many of you that have been in the SharePoint world know that it is not recommended to install SharePoint on your Domain Controller. I recently had to compile a list of the reasons WHY this is a bad thing to educate and inform a client. Well, maybe my choice of search terms was poor, but it was not an easy thing to find a list of the issues/concerns around loading SharePoint on a DC. Many folks have mentioned it in their blogs, but most just say ‘Microsoft does not recommend it’, so they also say don’t do it. I would really like to know WHY. Exactly what is the problem with doing this? What I have done is compiled a list from a myriad of sources to try and have a more complete reference for reasons why you should not do this. Now, many of us do this in our test/dev, VM’s or sandbox set ups that we use for demos, presentations etc. and I that is fine. This is more geared towards production environments.
Here is what I put together. If you have any additional facts that support this, please let me know. Also, just as important, if you have concrete facts that dispute anything here, I would love to have that as well. I broke out the list in two sections, A) SQL Server related, B) SharePoint related
Issues with Installing SQL Server on a Domain Controller
- Running SQL Server on a domain controller is a security risk. With both running on the
same physical server, should one of them be compromised, then it is possible that it might be easier to compromise the other one also.
- Reporting Services on a domain controller requires manual configuration after setup, and it seems that some folks have had problems and the manual set up does not work 100% of the time.
- You cannot run SQL Server services on a domain controller under a local service account or a network service account.
- After SQL Server is installed on a computer, you cannot change the computer from a domain controller to a domain member. You must uninstall SQL Server before you change the host computer to a domain member.
- SQL Server failover cluster instances are not supported where cluster nodes are domain controllers. This could seriously impede any future growth for scaling out.
- SQL Server is not supported on a read-only domain controller.
- You’ll never be able to move that SQL Server into another domain
- You are mixing an “application sever” with a “file server” so scripts and such become a concern. You might end up getting severe performance and stability issues on both SQL Server and ADS. Applying a service pack might want a reboot – and then nobody can log on at all, not even those who don’t use SQL Server, unless you have a BDC ( Backup Domain Controller ).
Issues with installing SharePoint on a Domain Controller
- When installed onto a member server (i.e not a Domain Controller), SharePoint creates a several local security groups. This is not unusual at all, as SQL Server does the same thing. But on a domain controller, there are no local security groups – just domain groups. Thus, the SharePoint installer figures out that it is running on a Domain Controller and changes the behavior of the creation of those groups. Normally on a member server, a SharePoint Installation would create three local groups, however, in a domain controller environment, these local groups are not created because there is no concept of local security accounts. Accounts get created in Active Directory instead.
- Service Packs, Infrastructure updates, hot fixes and the like all require the SharePoint Technologies wizard to be re-run on every server in the farm. The wizard *assumes* that the local WSS_* groups already exist and that certain permissions are already in place. Being on a Domain Controller can have unexpected results.
- Reporting Services and other wizards run expecting local services which do not exist on a DC.
- You will not be able to use Document Conversion at all. There is no work around or a resolution to this.
Hope this helps some of you.