So the other day I was reading into project documentation for a new SharePoint 2013 installation for one of our customers. In said documentation I found some disturbing images that made me think that SharePoint and SQL both were to be installed on a domain controller. We all generally know that this is considered to be a bad idea. But Why exactly is that? What specifically are the reasons that you want to avoid this situation?
Issues with SharePoint on a Domain Controller
•When installed onto a member server (i.e not a Domain Controller), SharePoint creates 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. Unexpected as in ugly, scary system-crashing 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. At all. Got it?
•User Profile issues, Search issues when you install SharePoint 2013 in “Stand Alone” mode.
Issues with 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 ).
resources;
Gaston's SharePoint Blog 