viernes, 1 de noviembre de 2013

Sabías que es de conocimiento general que Microsoft no recomienda instalar SharePoint en un Controlador de Dominio?

sabias-queSabías que es de conocimiento general que Microsoft no recomienda instalar SharePoint en un Controlador de Dominio?

Eh aquí una lista de tips que me ayudó a comprender él porque de dicha afirmación; la misma se divide en dos secciones:

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.

Gracias Marcos Costarella por el aporte.