Well, it’s been well known in SharePoint Community that you shouldn’t use the Farm Configuration Wizard (aka. FCW) in the production farm, even if you can. At first FCW feels like bliss but its devil under the cloak. I am sure you have heard this phrase but it would be nice to know why you shouldn’t be using the FCW.
For the novice, in MOSS 2007 days, one of the biggest complaint was SharePoint takes too many steps to configure after initial installation. Microsoft answered that question in SharePoint 2010 by providing FCW which would configure all the service applications, initial content web application, and initial site collection to enable administrators to configure the SharePoint by walking through simple steps.
To access the Farm Configuration Wizard, please visit the central administration site and click on the “Farm Configuration Wizard” on the home page. As shown below, I have specified the “Niks\Administrator” as service accounts to configure all the services and initial farm using FCW.
To configure the SharePoint 2010 using FCW makes sense in the development or sandbox environments but it must be avoided by all means in the production environment. To understand why you shouldn’t be setting up SharePoint environment using FCW, it would be nice to know what really happens behind the screens and how it avoids the best practices required for the real production farms.
Reason 1 – FCW configures to run all the services under same service account.
Typically best practices are to have dedicated service accounts for each service applications for security isolation. Although you can change the service accounts later, it would be really cumbersome process to go through all the service applications to run under specific service accounts. Instead, create the service applications from the manage service applications page and specify dedicated service accounts as needed.
As shown below, “Niks\Administrator” service account was configured to run all the services by the FCW.
Reason 2 – FCW doesn’t have option to specify Service Application database names.
Whenever FCW configures the service applications, it creates underlying databases with GUID. You don’t have much control over GUIDs on the database names whenever service applications are configured using FCW. Having cryptic GUIDs in the database names has big issues including database backup/restore and database maintenance plans. Instead create the service applications from the manage service applications page and specify the human readable database names.
As shown below, database names are configured with GUIDs by the FCW.
Reason 3 – User Profile Service application configures the My Site Host on the default web application.
At first having My Site host configured on the default web application may not be a big issue but in the medium to large farm deployment scenarios, you would like to configure the My Site host on the dedicated web application. This would allow organizations to configure the My Sites taxonomy, topology, security, and storage allocations on the dedicated web application running in its own IIS application pool under dedicated service account.
As shown below, FCW creates the default web application “SharePoint-80” on the http://sp2010vm, port-80 and My Site Host is configured on the default web application by FCW.
Hope this will help you to avoid the FCW in the production farm.