Sunday, August 20, 2017

SharePoint 2013: Review of the SharePoint Setup User Account and its use with Psconfig


Introduction

In this posting, I review the account used to install, setup and administer SharePoint, the SharePoint Setup User Administrator account and the importance of its role with respect to performing the SharePoint configuration operation using Psconfig.  In particular, I review these aspects of Psconfig in the context of performing software updates.   This review is intended to provide the professional SharePoint administrator with the references and information necessary for factually and objectively engaging discussions regarding the use of this account in performing configuration operations after software update installations.  This review is not meant to be authoritative, but a synthesis and convenient compilation of associated information that can be improved.  Therefore, critical comments and suggestions are welcome in order to improve this review to the benefit of the SharePoint technical community.

Background on the Software Update Process

From Software updates overview (SharePoint Server 2010), with regard to the Software update process:
...It is important to understand that deploying updates in a SharePoint Server 2010 environment is a two-phase process: patching and upgrading. The term patch is used in this article to differentiate between updating the software and upgrading the software.
 
Each phase has specific steps and results. It is possible to postpone the upgrade phase.
 
[However] Inconsistent farm behavior may result from postponing the upgrade for more than several days. The longer the postponement, the larger the risk is that farm behavior issues will occur. [emphasis mine]

Update phase

The patch phase has two steps, the patching step and the deployment step. During the patching step, new binary files are copied to the Central Administration server. Any services that are using files that have to be replaced are temporarily stopped. Stopping services reduces the requirement to restart the server to replace files that are being used. However, there are some instances when you must restart the server.
 
The second step in the patch phase is the deployment step. In this step, the installer copies support files to the appropriate directories on the server that is running SharePoint Server. This step ensures that all the Web applications are running the correct binary files and will function correctly after the update is installed. The update phase is complete after the deployment step.
 
The next and final phase to deploy software updates is the upgrade phase.

Upgrade phase

After you finish the patch phase, you must complete the update installation by starting the upgrade phase. The upgrade phase is task intensive and, therefore, takes the most time to finish. The first action is to upgrade all the SharePoint Server processes that are running. After the processes are upgraded, the databases are crawled and upgraded. Because the upgrade process can run on a single server, the other servers in the farm can continue to serve requests
The two-phased approach to patching SharePoint systems is in marked contrast to the patching of, say, Windows Servers, to which a patch is downloaded and installed, and the patching process is then complete. The complexities associated with the two-phased nature of the patching process for SharePoint systems may not be fully appreciated by systems administrators and IT managers who are single-system oriented and used to patching as a uni-phase process on a single system.  In contrast, SharePoint presents a distributed system-of-systems architecture, in which changes to any member of the system of systems needs to be communicated to the integrated system as a whole.

What is the role of this account in initial setup and configuration?

Since at least SharePoint 2007, the SharePoint Setup User Administrator account, along with the SQL Server service and server farm accounts, has been consistently presented by Microsoft as one of the three core accounts needed for the initial setup and then configuration of SharePoint.   For example, SharePoint 2007 TechNet documentation presents the setup account as the...
...user account that is used to run:
   - Setup on each server computer
   - The SharePoint Products and Technologies Configuration Wizard
   - The Psconfig command-line tool
   - The Stsadm command-line tool
(see Plan for administrative and service accounts (Office SharePoint Server))
and as the account...
... used to set up each server in your farm by running the SharePoint Products and Technologies Configuration Wizard, the Psconfig command-line tool, and the Stsadm command-line tool. For the examples in this article, the setup user administrator account is used for farm administration... (see Account permissions and security settings (Office SharePoint Server))
Three years later, for SharePoint 2010, the SharePoint Setup User Administrator account continued to play the same role. In Plan for administrative and service accounts (SharePoint Server 2010),  it presents this account as the...
...user account that is used to run:
- Setup on each server computer
- SharePoint Products Configuration Wizard
- The Psconfig command-line tool
- The Stsadm command-line tool
(see Plan for administrative and service accounts (SharePoint Server 2010))
This same article also noted that...
...If you run Windows PowerShell cmdlets that affect a database, this account must be a member of the db_owner fixed database role for the database. (See Plan for administrative and service accounts (SharePoint Server 2010))
...which was a new addition from the 2007 discussion, which still identified this as a requirement for appropriately provisioning the account but stating it later on in the article and not so prominently.
 
The release of SharePoint 2013 again presented these same three accounts as foundational to SharePoint farm setup and configuration:
The user account that is used to run:
- Setup on each server computer
- SharePoint Products Configuration Wizard
- The Psconfig command-line tool
- The Stsadm command-line tool
(See Plan for administrative and service accounts in SharePoint 2013)
It also stated that:
If you run Windows PowerShell cmdlets that affect a database, this account must be a member of the db_owner fixed database role for the database.
In summary, the SharePoint Setup User Administrator account is one of the three initial, core accounts needed when planning for and performing an installation of SharePoint; and it is the only account (at the outset) used to run both the Psconfig command-line and SharePoint Products Configuration Wizard tool (also known as Psconfigui).

How must the SharePoint Setup User Administrator account be initially provisioned?

The SharePoint Setup user administrator account is used to perform the installation of the SharePoint software application onto a Windows Server machine and then run the configuration of that installed software application using PSCONFIG.EXE.  The requirements for this account are:
  • Domain account (for single-server installs, it can be a local account);
  • Member of the local Administrator's group on each server on which Setup is run;
  • SQL Server login on the computer running SQL Server;
  • Member of the following SQL Server security roles: securityadmin fixed server role and dbcreator fixed server role; and
  • It must be provisioned as a member of the db_owner role for each farm database.
These standard requirements have not changed over multiple version releases of SharePoint.  See
In summary, the SharePoint Setup User Administrator account can be any domain account you choose.  It can be your own standard or administrator account if you want.  It's just that, whatever domain account you choose to use, once you use it for installation and configuration, it is only this account at the outset that has all of the appropriate permissions necessary for performing configuration operations on the farm using the post setup configuration tool, also known as Psconfig (or Psconfigui).

What is Psconfig?

This is the tool used to perform farm configuration operations.  It is also known as the Post Setup Configuration tool ("P" "S" "Config").  Configuration of the farm is performed immediately after farm setup, and it is also performed after the installation of software updates.  There are two versions of this tool: Psconfig.exe and Psconfigui.exe. The differences between them are that...
PSCONFIGUI.EXE is the UI based configuration wizard which performs several tasks one after the other after installing fixes.   PSCONFIG.EXE is the command line tool which gives users granular control over all tasks that are executed and which is therefor often quicker than PSCONFIGUI.EXE.
(See Stefan Gossner, Why I prefer PSCONFIGUI.EXE over PSCONFIG.EXE, 08/20/15)

Where is it located?

In SharePoint 2007, Psconfig.exe was a DOS command located in the BIN directory of the 12 hive, "%COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\BIN\Psconfig.exe."; and the SharePoint Products and Technologies Configuration Wizard was the GUI version.  You could launch the GUI version from the Windows Startup menu, but this was just a shortcut; and if you examined the properties of that shortcut, you would find "...\12\BIN\PsconfigUI.exe, which you could just as easily have executed from the command prompt of an elevated DOS shell. At the initial launch of SharePoint 2007, Psconfig and Psconfigui were only available as DOS commands; PowerShell versions were not available.
 
SharePoint 2010 was the first version of SharePoint to natively support PowerShell - in this case, PowerShell V2.0.  In SharePoint 2010, Psconfig could be executed both at the DOS and PowerShell command prompts.  The DOS versions of these commands were located in the "...\14\BIN" folder in the 14 hive and executed just as for SharePoint 2007. To use the PowerShell versions of these commands, one first opened an elevated instance of the new PowerShell shell and then loaded the Microsoft.SharePoint.PowerShell module, a dynamic link-library (DLL) based upon the .NET platform that could output SharePoint objects (see SharePoint 2010 Products administration by using Windows PowerShell).  The module, SharePoint.ps1, was located in the "...\14\Config\PowerShell\Registration" folder in the 14 hive.  I have found from experience that Psconfig command parameters are exactly the same, whether executed in DOS or PowerShell.
 
SharePoint 2013 continued the support for PowerShell.  In SharePoint 2013, as previously for SharePoint 2010, Psconfig could be executed within elevated instances of the DOS or PowerShell shells.  Psconfig parameters also remained the same (in 2013) from experience (I was unable to find any definitive reference asserting this however) .  It's just that now the commands are located in the 15 hive, "...\15\BIN" for the DOS commands, and "...\15\Config\PowerShell\Registration" for the PowerShell SharePoint module (see Use Windows PowerShell to administer SharePoint 2013).

SharePoint 2016 continues this approach. The Psconfig command executes in the same manner, and the respective DOS and PowerShell versions are found in the folders in the 16 hive, "...\16\BIN and ...\16\Config\PowerShell\Registration" (see Use Windows PowerShell to administer SharePoint Server 2016).

How are Psconfig and Psconfigui different?

As noted above, both Psconfig and Psconfigui perform post-setup configuration of the SharePoint farm.  This means that if you perform a routine upgrade using Psconfig and its standard operations (e.g., PSCONFIG -cmd upgrade -inplace b2b -wait), you may have a different experience performing a routine upgrade using Psconfigui. The difference here is not due to these two commands being fundamentally different.  Psconfig enables more granular control over what specific operations the Post Setup Configuration Tool is to perform, while Psconfigui automatically performs a specific subset of all of these operations that Psconfig can perform.
The Psconfig command-line reference (SharePoint Foundation 2010) lists 14 different operations that can be performed.  A routine upgrade performed using Psconfig.exe -cmd upgrade -inplace b2b -wait, which is the standard upgrade command syntax for Psconfig,  only performs one of the available operations.   On the other hand, Psconfigui automatically performs six of these operations.
Available OperationsAutomatically performed
by PsconfigUI
?
help
adminvs
applicationcontent✓
configdb
evalprovision
helpcollections✓
installfeatures✓
quiet
secureresources✓
services✓
setup
standaloneconfig
upgrade✓
(References: Psconfig command-line reference (SharePoint Foundation 2010), Why I prefer PSCONFIGUI.EXE over PSCONFIG.EXE)

The equivalent Psconfig syntax would be:
PSconfig.exe -cmd helpcollections -installall -cmd secureresources -cmd services -install -cmd installfeatures -cmd applicationcontent -install -cmd upgrade -inplace b2b -wait
In summary, Psconfig and PsconfigUI are not fundamentally different in how they engage the SharePoint farm.   It's just that Psconfig enables granular control over what operations are to be performed, leaving it up to the administrator to decide what configuration operation is to be performed, while PsconfigUI automatically performs a specific subset of these operations for you. (See Why I prefer PSCONFIGUI.EXE over PSCONFIG.EXE and Sharepoint 2010 PSCONFIG Basic guidelines).

Incidentally, Stefan Gossner, Microsoft senior escalation engineer for SharePoint productions and technologies, recommends using Psconfigui over Psconfig, because it performs a wider range of configuration operations by default than would otherwise be performed executing the standard upgrade command syntax.

When should Psconfig (or Psconfigui) be run?

Brief reminder.  Implementing software updates to a SharePoint farm is a two-phase process.  The first phase consists of installing the actual software update binaries on each server.  The second phase consists of performing what is effectively a configuration operation on each server.   The order in which the binaries are installed and configuration is performed is important.  The general flow for both phases is: Central Admin server > App servers > web servers.

SharePoint 2007 

In SharePoint 2007, the UI version of Psconfig (also known as the SharePoint Products and Technologies Configuration Wizard) performed the configuration operation and was launched automatically after installation of the software update binaries was finished:
4. At the end of the software update installation, the SharePoint Products and Technologies Configuration Wizard starts...
(see Deploy software updates for Office SharePoint Server 2007: Installing a software update, Installation steps, To install a software update, step 4)
 If the wizard didn't start automatically, you would:
...click Start, point to All Programs, point to Administrative Tools, and then click SharePoint Products and Technologies Configuration Wizard.
(see Deploy software updates for Office SharePoint Server 2007: Installing a software update, Installation steps, To install a software update, step 4)
Because the SharePoint Products and Technologies Configuration Wizard was launched automatically on a server after finishing installation of the binaries to that server, you had to engage in a little trick to ensure that farm SharePoint servers were upgraded in the right order.  First, you would launch the binary installation on all SharePoint servers.  Then, as the binary installation on a server completed the wizard automatically launched.  You clicked through the various dialogs of the wizard until the last prompt, which would actually begin the configuration operation, leaving this open.  Once all SharePoint servers had the final prompt displayed, you then closed the last prompt first on the server hosting Central Administration; then on each App server, and then on each web server in turn, allowing the configuration to complete on one server before allowing it to begin on the next.  In this way, implementing the proper upgrade order was maintained.

If you didn't want to use the UI version, it was possible to force a software update from the command prompt using Psconfig:
  1. Open a Command Prompt window and at the command prompt change to the following directory:
    %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin
  2. Type the following command:
    psconfig -cmd upgrade -inplace b2b -wait -force
(see Deploy software updates for Office SharePoint Server 2007: Installing a software update, Installation steps, To install a software update, To force a software update)
Again, as noted earlier, whether configuration was performed using the UI or command line, it was important that
...the SharePoint Products and Technologies Configuration Wizard perform the configuration procedures on only one computer at a time.
(see Deploy software updates for Office SharePoint Server 2007: Installing a software update, Installation steps, To install a software update, step 13)

SharePoint 2010

In SharePoint 2010, the UI version of Psconfig is again run after the software update binaries have been installed and the same upgrade sequence.  Just like for 2007: patches were installed and then upgrade configuration was performed in the same sequence as before: Central Admin server > App servers > web servers. Unlike for SharePoint 2007, in SharePoint 2010, completion of patch installation did not automatically launch the SharePoint Products and Technologies Configuration Wizard.  Instead, after launching patch installation, the usual progress dialog appeared, and then, once installation completed, a simple OK dialog was displayed to complete the installation or a prompt was displayed to restart the server.  Nothing more.  This change more definitively separated the two phases of the software update process: updating and upgrading. Other important changes are discussed in Deploy software updates for SharePoint Server 2010.  Other than these changes, in 2010...
...After you finish the patch phase, you must complete the update installation by starting the upgrade phase. The upgrade phase is task intensive and, therefore, takes the most time to finish. The first action is to upgrade all the SharePoint Server processes that are running. After the processes are upgraded, the databases are crawled and upgraded. Because the upgrade process can run on a single server, the other servers in the farm can continue to serve requests.
(see Software updates overview (SharePoint Server 2010))
After you have verified that all farm servers were updated successfully, you
9. Run the SharePoint Products Configuration Wizard on the Central Administration server (APP-1) to upgrade the configuration database and upgrade each content database serially.
10. Run the SharePoint Products Configuration Wizard on the application server that hosts the search query component (APP-2).
11. Run the SharePoint Products Configuration Wizard on the first Web server (WEB-1).
12. Repeat the preceding step for each remaining Web server...
(see Install a software update (SharePoint Server 2010))
...which were the general steps for the in-place method without backward compatibility and the in-place method with backward compatibility.  The database attach method for high availability of existing content takes this same approach by performed the software update phases on a new farm, and then migrating the content databases from the existing farm to that new one.In all these variations, Psconfig (or, in this case, Psconfigui) is run after updates have been installed.

Note that it isn't necessary to immediately perform upgrade after installing the patch.  In fact,
...It is possible to postpone the upgrade phase...
[However] Inconsistent farm behavior may result from postponing the upgrade for more than several days. The longer the postponement, the larger the risk is that farm behavior issues will occur.
(see Software updates overview (SharePoint Server 2010))
This warning likely encompasses failed upgrades as well, since a failed upgrade means that one or more upgrade tasks could not be completed and thus were not upgraded.

One last thing: the in-place method with backward compatibility and the database attach method for high availability of existing content discussed in Install a software update (SharePoint Server 2010) are not fundamentally different methods of performing a build-to-build upgrade.  For the first one, the upgrade is stretched out by first performing content database upgrades only so as to reduce the amount of time needed for farm outage.  For the second method, an identical second farm is upgraded, and then the content databases of the first farm are migrated over to the second farm, followed by DNS updates to point everyone to the second farm.  Neither of these variations alter the basic two-phase process or the use of the post-setup configuration tool, whether its commandline or UI version, for performing the upgrade itself.

SharePoint 2013

The SharePoint 2013 software update method is generally identical to the 2010 method.  In SharePoint 2013...
...After you finish the patch phase, you must complete the update installation by starting the build-to-build upgrade phase. The build-to-build upgrade phase is task intensive and, therefore, takes the most time to finish. The first action is to upgrade all the SharePoint processes that are running. After you upgrade the processes, the databases are crawled and upgraded. After you complete a farm upgrade on one server, you have to complete the process on all other servers to maintain incompatibility.
(see Software updates overview for SharePoint 2013)
Just like in 2010, after you have verified that updates have been successfully installed to all farm servers, you then...
...10. Run the SharePoint Products Configuration Wizard on the Central Administration server (APP-1). This will upgrade the configuration database and upgrade each content database. For information about how to run the wizard, see Create and configure the farm in the article Install SharePoint 2013 across multiple servers for a three-tier farm.
11. Run the SharePoint Products Configuration Wizard on the other application servers.
12. Run the SharePoint Products Configuration Wizard on the first web server (WEB-1).
13. Repeat the preceding step for each remaining web server.
(see Install a software update (SharePoint 2013): Use the in-place method without backward compatibility)
Just as for 2010, in 2013 there again are several variations to the software update process, including the:  in-place method without backward compatibility, the in-place method with backward compatibility, and the database attach method for high availability of existing content.  Whatever the variation, the software update process continues to be a two-phase process, where the first phase involved installing the update followed by a second phase that consists of running the post-setup configuration tool Psconfig (or Psconfigui, also known as the SharePoint Products Configuration Wizard).

As was the situation for 2010, in SharePoint 2013...
 It is possible to postpone the build-to-build upgrade phase....
[However]...the longer you run in such a state, the greater the chance of finding a case where farm behavioral issues might occur.
(see Software updates overview for SharePoint 2013)
Note too that the 2013 update procedure also includes the: 1) in-place method with backward compatibility and 2)  database attach method for high availability of existing content methods for performing a software update.  As discussed previously, neither of these variations to the basic two-phase software update procedure alter the use of post-setup configuration tool or when it is used in the software update process.

SharePoint 2016

The wording for 2016 is identical that of 2013:
 ...After you finish the patch phase, you must complete the update installation by starting the build-to-build upgrade phase. The build-to-build upgrade phase is task intensive and, therefore, takes the most time to finish. The first action is to upgrade all the SharePoint processes that are running. After you upgrade the processes, the databases are crawled and upgraded. After you complete a farm upgrade on one server, you have to complete the process on all other servers to maintain incompatibility.
(See Software updates overview for SharePoint Server 2016)
To perform the actual upgrade phase, you can...
  • Run the SharePoint 2016 Products Configuration Wizard [or]
  • Run the following commands at the Windows PowerShell command prompt:
    cd \Program Files\Common Files\Microsoft Shared\web server extensions\16\bin
    .\psconfig.exe -cmd secureresources -cmd installfeatures -cmd upgrade -inplace b2b -force -wait -cmd applicationcontent -install
(See Install a software update for SharePoint Server 2016)
The 2016 software update procedure does not present the standard in-place method without backward compatibility method; and nor does it present the database attach method for high availability of existing content  variation.  However, the process remains the same.

What about after installing security fixes?

Microsoft requires performing a configuration operation even if only a security patch has been installed:
...it is mandatory to run PSConfig (UI/Command line) after every patch/security update has been installed on the SharePoint servers. Most of the security patches may not have the mandatory to run PSConfig, but we recommend that you run the wizard or command line every time to ensure that the corresponding .dlls get updated as and when patches are released. When a patch gets installed on the server, only the file system level update takes place. When we run PSConfig, it updates the database as well as it is a necessary to have the database and the SharePoint servers in sync at all times. We will run into issues in the future if PSConfig has not been run as this will result in an unstable farm.
(See Sharepoint 2010 PSCONFIG Basic guidelines)
And per Stefan Gossner, Senior Escalation Engineer for SharePoint Products and Technologies
...You should run the SharePoint Configuration Wizard (psconfigui.exe or psconfig.exe with the correct parameters) after all SharePoint fixes! [highlighting original]
  • SharePoint Configuration Wizard updates the database schema to the latest version
  • SharePoint Configuration Wizard fixes security settings on the file system to match what SharePoint needs
  • SharePoint Configuration Wizard copies required binaries from the install location into the _app_bin directories of the web applications
  • SharePoint Configuration Wizard updates features registrations with SharePoint
Depending on which patch level you were before installing the security fix and depending on what component got fixed each of the above listed actions can be part of the security fix to be applied. E.g. some security fixes might require a modification of some stored procedures in a SharePoint database. Or security settings on the file system need to be updated to remove an attack vector. Or the fix is inside a DLL that usually resides in the _app_bin directory of the web application.
With other words: not running the configuration wizard after installing a SharePoint fix means that the fix is not completely applied and that means that specific security fixes might not be active without running PSCONFIG.
As a result let me repeat my initial answer: You should run the SharePoint Configuration Wizard (psconfigui.exe or psconfig.exe with the correct parameters) after all SharePoint fixes [highlighting original]
(See Why we recommend / require to run the Configuration Wizard also for Security fixes)
And, more recently,
...[Stefan Gossner]: There is not a single fix for SharePoint which does NOT required psconfig.
(see SharePoint security fixes released with January 2017 PU and offered through Microsoft Update#comment-194125) 

Summary

In summary, configuration is performed after software updates have been installed, and the tool used to perform the configuration operation is Psconfigui (also known as the SharePoint Products and Technologies Configuration Wizard) or Psconfig run at the command prompt.  This has been the consistent procedure presented by Microsoft over the course of four successive SharePoint versions, from 2007 through 2016.  Furthermore, configuration must be performed after any type of software update is installed, even if it is only a security patch.

Which account should be used to run Psconfig?

Discussion in successive Account permissions and security settings articles

Successive TechNet Account permissions and security settings articles for SharePoint versions 2007, 2010 and 2013 indicate that the appropriate account to use for running Psconfig is the SharePoint Setup User Administrator account.  For example, for SharePoint 2007, in Account permissions and security settings (Office SharePoint Server), it states that:
This account is used to set up each server in your farm by running the SharePoint Products and Technologies Configuration Wizard, the Psconfig command-line tool, and the Stsadm command-line tool. For the examples in this article, the setup user administrator account is used for farm administration... The setup user administrator account requires the following permissions:
  • It must have domain user account permissions.
  • It must be a member of the local administrators group on each server in the Office SharePoint Server 2007 farm, excluding SQL Server and the Simple Mail Transfer Protocol (SMTP) server.
  • This account must be able to log in to the computer running SQL Server.
  • This account must be assigned to the securityadmin and dbcreator SQL Server security roles.
  • If you use any Stsadm operations that affect a database, the administrator account must be a member of the db_owner role.
(see Account permissions and security settings (Office SharePoint Server)).
This same SharePoint 2007 procedure also presented this warning:
If the setup user administrator account is removed from the computer running SQL Server, the PSC tool will not run correctly. If you run the PSC tool using an account other than the account under which the PSC tool was first run, the PSC tool will not run correctly [emphasis mine] (see Account permissions and security settings (Office SharePoint Server)).
This description remains generally consistent in the corresponding 2010 version of this procedure:
This account is used to set up each server in your farm by running The SharePoint Configuration Wizard, the initial Farm Creation Wizard, and Windows PowerShell. For the examples in this article, the setup user administrator account is used for farm administration... The setup user administrator account requires the following permissions:
  • It must have domain user account permissions.
  • It must be a member of the local administrators group on each server in the SharePoint Server 2010 farm, excluding SQL Server and the Simple Mail Transfer Protocol (SMTP) server.
  • This account must have access to the SharePoint Server 2010 databases.
  • If you use any Windows PowerShell operations that affect a database, the setup user administrator account must be a member of the db_owner role.
  • This account must be assigned to the securityadmin and dbcreator SQL Server security roles during setup and configuration.
(see Account permissions and security settings (SharePoint Server 2010))
...though the 2010 version of the procedure presents a different warning that doesn't include the bolded statement above:
If the setup user administrator account is removed as a login from the computer running SQL Server, the configuration wizards will not run correctly. If you run the configuration wizards using an account that does not have the appropriate special SQL role membership, or access as db_owner on the databases, the configuration wizards will not run correctly. (see Account permissions and security settings (Office SharePoint Server)).
There are no significant changes to the description or the warning in the SharePoint 2013 version of this procedure:
This account is used to set up each server in your farm by running the SharePoint Configuration Wizard, the initial Farm Creation Wizard, and Windows PowerShell. For the examples in this article, the setup user administrator account is used for farm administration... The setup user administrator account requires the following permissions:
  • It must have domain user account permissions.
  • It must be a member of the local administrators group on each server in the SharePoint farm.
  • This account must have access to the SharePoint databases.
  • If you use any Windows PowerShell operations that affect a database, the setup user administrator account must be a member of the db_owner role.
  • This account must be assigned to the securityadmin and dbcreator SQL Server security roles during setup and configuration [emphasis author]
(see Account permissions and security settings in SharePoint 2013).
...and...
If the setup user administrator account cannot a log on to the computer running SQL Server, the configuration wizards will not run correctly. If the account that you use to run the configuration wizards does not have the appropriate special SQL Server role membership or access as db_owner on the databases, the configuration wizards will not run correctly [emphasis author] (see Account permissions and security settings in SharePoint 2013).
The SharePoint 2016 version of this procedure again presents the same general direction:
This account is used to set up each server in your farm by running the SharePoint Products Configuration Wizard, the initial Farm Configuration Wizard, and Windows PowerShell. For the examples in this article, the setup user administrator account is used for farm administration...The setup user administrator account requires the following permissions:
  • It must have domain user account permissions.
  • It must be a member of the local administrators group on each server in the SharePoint farm.
  • This account must have access to the SharePoint databases.
  • If you use any Windows PowerShell operations that affect a database, the setup user administrator account must be a member of the db_owner role.
  • This account must be assigned to the securityadmin and dbcreator SQL Server security roles during setup and configuration. [emphasis author]
(see Account permissions and security settings in SharePoint Server 2016)
...and...
If the setup user administrator account cannot log on to the computer running SQL Server, the configuration wizards will not run correctly. If the account that you use to run the configuration wizards does not have the appropriate special SQL Server role membership or access as db_owner on the databases, the configuration wizards will not run correctly.
(see Account permissions and security settings in SharePoint Server 2016)
Note the wording that leads the discussion in each case:
This account is used...
not
This account shall be used... or This account is to be used...
Thus, this sentence is presenting the role of this account, not specific direction on its usage. Another sentence found each time is:
For the examples in this article, the setup user administrator account is used for farm administration...
This statement is not presenting definitive direction that you must use the SharePoint Setup User Administrator account to run Psconfig, but it does indicate that the SharePoint Setup User Administrator account can be used for performing the farm administration operations listed in this procedure.  Additionally, if Microsoft is indicating in this procedure that it is using this account for administration operations, that would seem to be a pretty good indication that it is a good or even very good account to use for such operations.  And it's easy to understand why, given its unique provisioning.

Unique provisioning of the Setup User Administrator Account

This account is properly provisioned at the outset to perform all administrative operations. Summarizing the provisioning requirements discussed above for 2007, 2010, 2013 and 2016, it's provisioning includes:
  • Domain user account permissions
  • Member of local administrators group on all farm servers
  • Added to SQL Server login
  • Assigned securityadmin and dbcreator roles in SQL Server
This is the manual provisioning that you must perform prior to using this account.  After you use this account to perform initial installation and configuration, this account is further provisioned with:
  • Membership in the WSS_ADMIN_WPG Windows security group.
  • Membership in the IIS_WPG role.
  • Membership in the WSS_SHELL_ACCESS database role.
  • db_owner on the SharePoint server farm configuration database.
  • db_owner on the SharePoint Central Administration content database
(cfi, Account permissions and security settings (SharePoint Server 2010).  And there may be additional provisioning that occurs, but this is what I have found thus far.  In any case, being able to successfully run Psconfig using a different account involves more than merely adding it to the local Administrators group on each farm server.

Discussion in in successive software update installation articles

In Deploy software updates for Office SharePoint Server 2007, Installing a software update, Before you begin, it states that...
...For the account that you use to install the software update and run the SharePoint Products and Technologies Configuration Wizard, the minimum permissions are the following:

  • Member of the Administrators group on the local computer that runs Office SharePoint Server 2007
In SQL Server, the account must be all of the following:

  • Authorized to access all SharePoint Products and Technologies databases
  • Granted the Database Creators (dbcreator) fixed server role.
  • Granted the Security Administrators (securityadmin) fixed server role.
    •
To ensure that you have the correct permissions to install the software update and run the SharePoint Products and Technologies Configuration Wizard, Microsoft recommends that you add the account for the SharePoint Central Administration v3 application pool identity to the Administrators group on each of the local Web servers and application servers and then log on by using that account [emphasis mine]. These changes are only required for installing the update and then running the SharePoint Products and Technologies Configuration Wizard to complete the upgrade. After you finish installing the update, remove the account on each of the local Web servers and the application servers.
The application pool identity for the Central Administration web application will usually be the farm service account. Thus, this 2007 procedure is recommending that the farm service account be used interactively to run Psconfig.  This recommendation is not repeated in the corresponding software update installation articles for 2010 and 2013.

For example, review of the equivalent procedure for 2010, Prepare to deploy software updates (SharePoint Server 2010), Verify account permissions and security settings, finds that you should only...
Verify that you have the required account permissions and know which security settings are in place on the farm. For more information, see Account permissions and security settings (SharePoint Server 2010).
Further, this procedure indicated that the SharePoint Setup User Administrator account should be used to run Psconfig or PsconfigUI (also known as the SharePoint Products and Technologies Configuration Wizard).

Review of the equivalent procedure for 2013, Prepare to deploy software updates for SharePoint 2013, Verify account permissions and security settings, states pretty much the same thing:
Verify that you have the required account permissions and know the security settings that are in place on the farm. For more information, see Account permissions and security settings in SharePoint 2013.
Further, this procedure indicated that the SharePoint Setup User Administrator account should be used to run Psconfig or PsconfigUI.  No other discussion on the appropriate account to use for running Psconfig is provided.  All the patching procedure does is point you back to the appropriate Account Permissions and Security Settings procedure for details on what account to use.  This approach changes somewhat for 2016.

In the SharePoint 2016 software update installation procedure, Install a software update for SharePoint Server 2016, Before you begin, it states that
Before you begin the software update process, review the following information about permissions, hardware requirements, software requirements, and update processes.
This direction is consistent with the direction presented in the corresponding software update installation procedures for SharePoint 2010 and 2013, presented previously.  Like for 2010 and 2013, it refers the reader to existing procedures on account provisioning for details on what account to use in 2016.  However, the next paragraph in the 2016 version of this procedure departs from that approach, providing specific direction on provisioning the account that will be used to run the PowerShell commandlets in that procedure:
To perform the Windows PowerShell procedures in this article, you must have the following memberships and roles:
  • securityadmin fixed server role on the SQL Server instance
  • db_owner fixed database role on all databases that are to be updated
  • Local administrator on the server on which you run the Windows PowerShell cmdlets
This direction is much like that provided in the 2007 deploy software updates procedure:
...For the account that you use to install the software update and run the SharePoint Products and Technologies Configuration Wizard, the minimum permissions are the following:
  • Member of the Administrators group on the local computer that runs Office SharePoint Server 2007
In SQL Server, the account must be all of the following:
  • Authorized to access all SharePoint Products and Technologies databases
  • Granted the Database Creators (dbcreator) fixed server role.
  • Granted the Security Administrators (securityadmin) fixed server role.
(See Deploy software updates for Office SharePoint Server 2007, Installing a software update, Before you begin)
It's also the same direction presented in the successive Account permissions and security settings procedures reviewed earlier.

If you read further in that 2016 procedure, Install a software update for SharePoint Server 2016, Before you begin, it discusses running commandlets for getting Search status, upgrading content databases, and pausing and resuming the Search service.  It does discuss running Psconfig at the Windows PowerShell command prompt, but look carefully at the path it presents for running Psconfig: this is not the path to the SharePoint module SharePoint.ps1, located at ...\16\Config\PowerShell\Registration, but the path to the DOS version, located at  ...\16\bin.  And note that this statement indicates running Psconfig in an ordinary PowerShell shell, not the SharePoint Management Shell, which loads the SharePoint module automatically.  So, since the Psconfig command discussed in this procedure is not the PowerShell version but the DOS version, it would appear that the additional provisioning guidance doesn't apply to running Psconfig and thus this 2016 procedure is not actually departing from the approach to running Psconfig discussed in 2010 and 2013 procedures.

What about using the Farm service account?

Only one procedure (that I have found to date) recommends using the farm service account to run Psconfig, and that is found in Deploy software updates for Office SharePoint Server 2007, Installing a software update, Before you begin.  This recommendation is not repeated in subsequent software update installation procedures and it conflicts with other 2007 procedures on running Psconfig. 
From a provisioning perspective, the farm service account seems to have the same provisioning as the SharePoint Setup User Administrator account. For example, Account permissions and security settings in SharePoint 2013, presents provisioning granted to the farm service account after farm deployment that is identical to the setup account.  However, it's not recommended to use the farm service account interactively. From Marj Palmer, Microsoft Premier Field Engineer:
...To perform any ongoing maintenance to the SharePoint farm, avoid routine practice where SharePoint Farm Admins need to login interactively using SharePoint Server Farm Service account (or the Setup User Account). Move toward better practice where Farm Admins login interactively using their individual user accounts to perform their day-to-day duties.  Why?
  • Security best practice is to not permit service accounts to be routinely used for interactive login by any user.  One reason is service accounts typically have very high privilege, usually more than is required by the user (doesn’t follow the least privilege security model).  
(see Recommendations for SharePoint Setup User Account and SharePoint Farm Administrators Group)

Review

In review, the discussion in the software update installation procedures on what account to use in order to run Psconfig has been reasonably consistent over the course of multiple versions, from 2007 through 2016.  In the 2007 procedures, there is a conflict, with Account permissions and security settings (Office SharePoint Server) stating emphatically that the Setup User Administrator account should be the only account one uses, while Deploy software updates for Office SharePoint Server 2007, Installing a software update, Before you begin, indicates that any account can be used so long as it meets certain requirements, and that the farm service account can be used as well. In the 2010 and 2013 procedures, these conflicts are removed, and the reader interested in knowing what account to use for running Psconfig is clearly referred to Account permissions and security settings (SharePoint Server 2010), or Account permissions and security settings in SharePoint 2013, for definitive discussion on that topic, and both indicate that the SharePoint Setup User Administrator "is used" to run configuration, but provides requirements for using a different account to run Psconfig. The 2016 version of the software installation procedures presents the same discussion presented previously for 2010 and 2013. On alternative account that is discussed in various postings for running Psconfig is the farm service account. While this account seems to identical provisioning to the SharePoint Setup User Administrator account, it is not best practice to use farm service accounts interactively.

Summary

In summary, throughout multiple SharePoint versions, Microsoft is stating that the SharePoint Setup User Administrator account "is used" - not "will be used," not "shall be used," no "must be used," just "is used" - for running Psconfig (or Psconfigui). Microsoft also discusses using other accounts to run Psconfig and presents some of the requirements that these other accounts must have in order to run Psconfig - the other provisioning requirements being inferred by the requirement needed for the SharePoint Setup User Administrator account at initial provisioning, and others inferred by its provisioning after being run for the first time.

In my opinion, as I understand what Microsoft has written, the SharePoint procedures I have read do not actually mandate using the SharePoint Setup User Administrator account for running Psconfig, and these procedures do discussing using a different account.  However the fact that these procedures routinely state this account as being used to run Psconfig seems to me to be a pretty good indication to me that it is probably the best account to use. These procedures do indicate that another account can be used to run Psconfig, but none of them provide a definitive, comprehensive discussion and set of requirements for how that other account should be provisioned, though much can be inferred by careful review of these procedures.  Thus, if one is to use a different account to run Psconfig, one should diligently ensure that that account is provisioned fully consistent with procedural requirements, including those plainly stated and those that are inferred.  

How do you monitor the status of the update process?

SharePoint 2007

In SharePoint 2007, to verify the successful completion of the update process you would:
  • View the upgrade log file...
  • Check version numbers on certain files and registry keys...
  • Examine the SQL schema...
  • View the version number on the Servers in Farm page...
(See Deploy software updates for Office SharePoint Server 2007: Installing a software update, Verify update completion and success; and see Verify upgrade (Office SharePoint Server))
For example, to use the upgrade log file as a means of verifying upgrade status, you would:
Search, or visually scan, for the following entries:
Finished upgrading SPFarm Name= <Name of Configuration Database>
 
In-place upgrade session finishes. Root object = SPFarm=<Name of Configuration Database>, recursive = True. 0 errors and 0 warnings encountered.
If you find these entries, the installation was successful.
   
(See Deploy software updates for Office SharePoint Server 2007: Installing a software update, Verify update completion and success, To view the upgrade log file)

Note that in SharePoint 2007, the Servers in Farm page did not present a Status column, which was added beginning SharePoint 2010 and continued in SharePoint 2013 and 2016.
SharePoint 2007
SharePoint 2010
SharePoint 2013
SharePoint 2016
The challenge in using these various methods for verifying patch status was that they could present conflicting information.

For example, to verify patch status by monitoring the version number on the Servers in Farm page, you would navigate to the Servers in Farm page in Central Administration.  There you would see the Version number presented on the Servers in Farm page.  Now, this number is pulled from the farm configuration database.  However, this number is only updated by those patches that update the config DB schema. Thus, monitoring the Servers in Farm Configuration database version was not (and still is not ) a reliable method for determining successful patch installation and upgrade. (see SharePoint does not have a build version. Full Stop.)

To verify patch status by monitoring file version numbers of DLLs and EXE, you would navigate to %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\ISAPI or _app_bin directories, right and view the file properties.  However, with regard to files in the _app_bin directory,
...The Windows installer can only update files it installed earlier. When you install a product, then the location of all installed files in stored in the installation database on the current machine. These are the locations the installer can update later. But the files in the _app_bin directory are not installed here by the Windows installers. SharePoint copied these files to this location when the web applicaton was created. To update these files after a fix was installed it is required to perform manual actions to update also the files in locations the Windows Installer is not aware of. And that is done by running the SharePoint configuration wizard or the Install-SPApplicationContent Powershell command.
(see SharePoint does not have a build version. Full Stop., File Versions of SharePoint dlls and exe files)
The DLL files that you would look at include the WSS OWSSVR.DLL and MOSS Microsoft.SharePoint.portal.dll files located in %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\ISAPI (see Verify upgrade (Office SharePoint Server)).  Right-clicking on one of these files would present the Properties dialog for that file, and you would select the Version tab of the Properties dialog in order to view the binary file version numbers of these files. However, there is a problem with using these binary file version numbers for verification purposes:
...Between two monthly releases of CUs developers integrate fixes for different issues into the source code of SharePoint. E.g. lets look at SharePoint 2013 June 2016 CU and July 2016 CU. June 2016 CU was released with version number 15.0.4833.1000. July 2016 CU was released with version number 15.0.4841.1000. You can see that at least 8 builds were created between these two CUs. Some fixes were checked in into build 15.0.4834.1000, some might be checked in into 15.0.4837.1000 and of course some into 15.0.4841.1000. If two of these fixes update the same files, then of course the relevant files will get the higher version number. But if files update with the check-in to build 15.0.4834.1000 did not get update again before the CU was released, then these files will be included in the CU with version 15.0.4834.1000 - so a version between the official version number (15.0.4841.1000) in the KB for July CU and the official version number (15.0.4833.1000) in the KB for June CU.
(see SharePoint does not have a build version. Full Stop., File Versions of SharePoint dlls and exe files)
To monitor patch status by monitoring SQL schema, you would view the Versions table of the specific SharePoint database.  However, these numbers are only updated by those patches that include schema changes for that specific database.  Even if the patch does implement a schema change, the version number that is shown may not be consistent with the version number presented in the associated KB article. (see SharePoint does not have a build version. Full Stop., Versions table of the different SharePoint databases).

To verify patch status by monitoring upgrade log files, you needed to go to each server and look in the %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS directory on that server for the Upgrade.log file.  In this file, you would look for these entries that verified successful upgrade:
Finished upgrading SPFarm Name= <Name of Configuration Database>
In-place upgrade session finishes. Root object = SPFarm=<Name of Configuration Database>, recursive = True. 0 errors and 0 warnings encountered.
(See Verify upgrade (Office SharePoint Server))
 While this method was reliable, it was not conveniently centralized.

SharePoint 2010

In SharePoint 2010, Microsoft significantly improved update monitoring. In addition to the Status column added to the Servers in Farm page, Microsoft also added two key tools to the Upgrade and Migration toolset:
  • Check product and patch installation status
  • Check upgrade status
These are made available as links in the Upgrade and Migration group on the Central Administration main page:
SharePoint 2007
SharePoint 2010
SharePoint 2013
Clicking the Check product and patch installation link navigates to the Manage Patch Status page, which lists each and every individual patch that was installed, grouped by server, product and component. The Check upgrade status link navigates to the Upgrade Status page, which lists each upgrade operation, including: the date and time it was performed, whether it failed or succeeded, and any errors or warnings associated with the operation.  This same information is available in the psconfig upgrade log file also created for each upgrade operation.

The Manage Patch Status page pulls its information from the ServerVersionInformation table in the farm's configuration database.  The information in this table is updated whenever a patch is installed to a server and the configuration operation is performed. Additionally, the version number shown for a patch reflects the version number in the associated KB article.

I have not been able to find definitive information on where the Upgrade Status page pulls its information.  In any case, this page:
...lists the upgrade sessions and gives details about the state of each session — whether it succeeded or failed, and how many errors or warnings occurred for each server. The Upgrade Status page also includes information about the log and error files for the upgrade process and suggests remedies for issues that might have occurred.
(see Verify upgrade and review upgraded sites (SharePoint Server 2010))
SharePoint 2010 also introduced additional log files that could be used to verify and troubleshoot upgrades (see Verify upgrade and review upgraded sites (SharePoint Server 2010)):

  • The SharePoint Products Configuration Wizard (Psconfig.exe) log file (new)
  • upgrade log file (continued from 2007)
  • upgrade error log file (new)
Their naming was also changed to facilitate tracking and organization.  All of these new monitoring tools significantly improved the SharePoint administrator's ability to monitor and verify the software update process.

2013

There was no significant change to these monitoring tools for 2013, which continued to provide the Check product and patch installation status and Check upgrade status capabilities for monitoring the update process, along with the set of log files discussed previously. For SharePoint 2013, Microsoft recommended that you
...use the Upgrade and Migration page in Central Administration as the primary tool to view product and patch installation status, data status, and update status in real time.
(See Install a software update (SharePoint 2013))

2016

Ditto for 2016, and no changes.  Again Microsoft recommended that you,
...use the Upgrade and Migration page in Central Administration as the primary tool to view product and patch installation status, data status, and update status in real time.
(See Install a software update for SharePoint 2016)

Summary

In SharePoint 2007, the primary and definitive means of verifying the success of an upgrade operation was by reviewing the upgrade log file.  This would be done on each machine that was upgrade.  Other options were also available but could present misleading results.  Beginning with SharePoint 2010, Microsoft significantly improved the update experience by providing a two pages in Central Administration that present centralized update status information across the farm, the Check product and patch installation status and Check upgrade status pages, and by new log files, the Psconfig and Update Error Log files.  The two new status pages provide the administration with centralized and reliable means of monitoring and verifying software update installation and configuration operations.  Over the course of successive version upgrades, from 2010 to 2016, there have been no significant changes to these tools.

Summary

Based upon what has been found among the Microsoft SharePoint procedures and SharePoint team member blog posts, here's what can be determined about the SharePoint Setup User Administrator account and its role with respect to performing the SharePoint configuration operation using Psconfig:

  • Patching of SharePoint systems is a two-phase process, the first phase involving installing and deploying the actual software update binaries, and the second phase involving running a configuration operation on all of the SharePoint servers in the farm.  
  • The SharePoint Setup User Administrator account is one of the three initial, core accounts needed when planning for and performing an installation of SharePoint; and it is the only account (at the outset) used to run both the Psconfig command-line and SharePoint Products Configuration Wizard tool (also known as Psconfigui).
  • The SharePoint Setup User Administrator account is used for initial setup and configuration can be any account you choose, so long as it is: a standard domain account; member of the local Administrators group on each server in the SharePoint farm; has a login to the farm's SQL Server database server and has been provisioned on that SQL Server with the securityadmin and dbcreator fixed server roles and has been provisioned with the db_owner role for each farm database on the server.
  • The SharePoint Setup User Administrator account is used for post-setup configuration operations performed after the installation of software updates.  
  • There is some ambiguity as to whether a different account other than the SharePoint Setup User Administrator account can be used to perform post-setup configuration operations performed after the installation of software updates.  At first glance, based upon the published Microsoft procedures, it would appear that any account can be used so long as it is provisioned as the SharePoint Setup User Administrator account was provisioned to perform initial setup and configuration. But note the additional provisioning that the SharePoint Setup User Administrator account undergoes during setup and configuration, including membership in the local WSS_ADMIN_WPG and IIS_WPG groups on each SharePoint server, and membership in the db_owner roles for the farm configuration and content databases.  Additionally, if you are going to use this account to perform operations against the farm databases, it needs to be a member of the WSS_SHELL_ACCESS to execute stored procedures and edit tables in the farm database server.  And then there is the SP_DATA_ACCESS role in the farm database server that replaced the db_owner role in SharePoint 2013.  To date, there is still no clear, definitive presentation by Microsoft on the provisioning requirements for the account used to run Psconfig.
  • Psconfig is the tool used to perform configuration operations.  It was originally known as the Post Setup Configuration tool.  It comes in both a command line version, Psconfig.exe, and UI version, Psconfigui.exe.  The UI version is also known as the SharePoint Products and Technologies Configuration Wizard.  There is no fundamental difference in how these two operate. Psconfig is parameterized and enables you to have granular control over which of the 14 configuration operations you want to perform.  Psconfigui presumes a set of five of those operations for you.
  • Up through SharePoint 2007, Psconfig was a DOS command located in the hive's BIN folder (e.g., 12\BIN).  Beginning with SharePoint 2010, Psconfig was available in both DOS and PowerShell varieties.  To run the PowerShell version, you had load the Microsoft.SharePoint.PowerShell module, SharePoint.ps1, located in the hive's Config\PowerShell\Registration folder.
  • Psconfig or Psconfigui is run after initial installation of the farm binaries and after a new software update is installed.  The type of software update triggering a configuration is irrelevant: you perform configuration no matter whether the update is a hotifx, security fix, public patch or cumulative update.
  • Microsoft states repeatedly through successive installation procedures that the SharePoint Setup User Administrator account "is used" (not "must be used," or "shall be used," or "will be used") to perform post setup configurations using Psconfig (or PsconfigUI).   For one SharePoint 2007 procedure, Microsoft stated that the farm service account should be used for post-setup configuration; however, this direction conflicts with that presented in other SharePoint 2007 procedures.  The farm service account does appear to have the same provisioning as the SharePoint Setup User Administrator account.  However, at least one Microsoft engineer recommends not using the farm service account interactively for performing configuration operations due to auditability concerns.
  • Through SharePoint 2007, the tools used to monitor and verify patching status used to consist of viewing registry key properties, DLL version numbers, version number displayed in Central Administration and version numbers displayed in farm database tables.  These various sources could present conflicting or ambiguous information.  Beginning with SharePoint 2010, Microsoft significantly improved the tools available to SharePoint administrators by implementing centralized patch and upgrade status monitors in Central Administration, the Manage Patch Status and Upgrade Status pages.  It also added a status column to the Servers in Farm page; and it added additional log files providing more information on configuration activities, the SharePoint Products Configuration Wizard (Psconfig.exe) log file and the upgrade error log file.  This improved suite of patch monitoring and verification tools has remained consistent since SharePoint 2010 and continues to be available in SharePoint 2016.

Common Questions

  • Can the farm still run if it's not upgraded after patching or an upgrade fails?  Yes, and you can easily verify this yourself.  After installing an update, but before performing upgrade, if you look on the Database Status page in Central Administration, you may see "Database is in compatibility range and upgrade is recommended".   If you then look on the Servers in Farm page, you may see "Upgrade Required" in the Status column for one or more farm servers listed on this page. These are all factual verifications that show that a farm can continue to operate after a software update installation without an upgrade being performed.
  • Can the farm still run if, after installing a software update, I then attempt to upgrade it and the upgrade fails? Yes, and you can easily verify this yourself.  After installing an update, and then after attempting to upgrade the farm but the upgrade fails, if you look on the Upgrade Status page in Central Administration, you will see "Failed" in the Status column of the upgrade session you performed.  Obviously, you would not be able to view this information if the farm could not operate after a failed upgrade.

References

Notes

  • Whether run in DOS or PowerShell shells, the command parameters are exactly the same.  This assertion is based entirely upon experience at this point.  I have not been able to find any definitive TechNet reference discussing Psconfig and any differences between running it in DOS or PowerShell, all though much can be inferred through careful reading of TechNet articles on using PowerShell for SharePoint administration. 
  • The complexities associated with the two-phased nature of the patching process for SharePoint systems may not be fully appreciated by systems administrators and IT managers who are single-system oriented and used to patching as a uni-phase process.  Thus it is incumbent upon SharePoint administrators to factually and objectively engage systems administrators, IT managers and others on the nature of the distributed, asynchronous system-of-systems architecture exhibited by SharePoint and the resultant complexities associated with software updating.
  • My own preference in performing post-setup configuration operations is to use the SharePoint Setup User Administrator account - the account used to perform the initial setup and configuration of the farm.  This approach has worked without fail for the last seven years.  I understand that Microsoft's SharePoint procedures do seem to indicate that I could provision a different account for post-setup configuration usage, so as not to have to use a shared account, however, up to the present time, I have had neither the time nor the inclination to diligently investigate this. I understand that some might be hesitate in using "shared accounts" and I understand their reasoning.  My own experience has been that, in practice, this comes down to a cost/benefit analysis, and the system administrators I have worked closely with knew and understood these risk and benefits and worked with them.  There is reasonable justification for using them and there is reasonable justification for not using them. The determination here will be unique for every environment.  There are straightforward ways of determining accountability even when using shared accounts that competent systems administrators will know about.
Posted by at
Labels:

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)