SharePoint Experts, Information Architects, Expert Witness

SICG provides a broad array of business and technology consulting from architecture to design to deployment of global systems with a focus on surfacing data in the enterprise. We focus on the "How", not just the possible. Contact me direct: or call 704-873-8846 x704.

Search This Blog

Tuesday, January 14, 2014

Slipstreaming SharePoint 2013 and SharePoint Cumulative Updates

As was true with SharePoint 2010, Microsoft is releasing Cumulative Updates (CU's) for 2013. A new CU is generally released about every 3 months. As has been confirmed, ONLY the latest CU needs to be applied EXCEPT for 2013. For 2013, there is a mandatory update for March 2013 (which includes February 13's updates). The latest CU cannot be installed without the March 2013 applied first.

As for the CU's themselves, be sure to check for any issues folks have encountered and follow a normal process of testing on a non-production farm first. As an example, the latest CU (December 2013) has a known side effect in that it breaks the Performance Point dashboard designer - so if you are using Performance Point, don't install that CU (install October instead).

The entire list can be found here:

At any rate, it's not a lot of fun to have to incorporate the CU's on multiple systems - particularly when there are more than one. As well, Microsoft is not very clear about what to apply when - as in do you do Foundation, then Server or just Server and do you run SharePoint Configuration update after or not?

To clear the air on at least 2013, it now appears that CU's should only be applied based on the product you are running. That is, if you are running Server, ONLY apply the Server update - if running Foundation, ONLY Foundation. This can save you some time as like many of  you, I have in the past implemented both just to be sure (and Microsoft is very vague on this).

As for running PSCONFIG or SharePoint Configuration after each, the answer is YES - do it every time.

If you choose to run each of the updates separately, be aware that the updates DO NOT ALWAYS upgrade everything. Case in point: When applying the March 2013 update, it does not update the Business Connectivity Server (BCS) - after the update is done, a message will appear in the Health Analyzer that the BCS/BDC Database is running in compatibility mode. To correct this, use the SharePoint 2013 Management Shell (i.e. PowerShell) and provision the database as follows:

(Get-SPDatabase | ?{$_.type -eq "Microsoft.SharePoint.BusinessData.SharedService.BdcServiceDatabase"}).Provision()

As for "Slipstreaming", the process works the same way as it did in 2010.

NOTE: At the time of this writing, I have confirmed that the March 2013 CU is the only update that can be used in the slipstream process - the December 2013 CU must be applied manually after.

There are a few steps involved to do this.

1) Download all of the cumulative updates from the site for your product but be SURE to keep them in separate folders. When 'extracted', Microsoft uses cute names (ubersts for example) that are either because the update is coming from Germany or someone bought a VW and likes the term and includes the KB numbers so it's impossible to know which comes from which date.

2) For each the CU's, extract them to a folder - so for example, create a folder called March13CU. Copy the update (an .EXE file) to that folder - if the update (like August) comes in the form of a self-extracting zip, use that to extract the EXE (and in some cases, .CAB files) into that folder.

3) Use PowerShell or the command prompt, set default to the folder (i.e. March13CU) then breakout the CU EXE into individual files using the extract method - to extract them to the same folder, the command would be:

<CU EXE Name> /extract:<folder to extract to>

So if the downloaded CU was called March13ServerCU.exe (or you wisely renamed it as so) and wanted to extract it to the folder March13CU (the same folder where the EXE is), the command would be:

March13ServerCU.exe /extract:.\

Alternately, to create a sub-folder, the command would be:

March13ServerCU.exe /extract:.\Mar13SrvCU

If you wanted to use a different drive/folder, it would be:

March13ServerCU.exe /extract:D:\Mar13SrvCU

4) Copy the SharePoint installation into a folder on the server.

5) Run the Prerequisite installer either using the Splash screen running Setup.cmd or using the prerequisiteinsaller.exe - either way be SURE TO right click and choose Run as administrator (do this for EVERYTHING relating to SP13).

6) After the Prerequisites are installed, there are additional patches that must be run:

    *   KB2554876 - The SharePoint parsing process crashes in Windows Server 2008 R2.  (
    *   KB2708075 - IIS 7.5 configurations are not updated when you use the ServerManager class to commit configuration changes.  (
    *   KB2472264 - You can't customize some TCP configurations by using the netsh command in Windows Server 2008 R2.  (
    *   KB2567680 - Vulnerability in Windows Client/Server Run-time subsystem could allow elevation of privilege.  (
    *   KB2759112 - Hotfix for the .NET Framework 4.5 that resolves an ASP.NET race condition issue in Windows Server 2008 R2. ( (download:

    *   KB2765317 - Hotfix for the .NET Framework 4.5 that resolves an ASP.NET race condition issue in Windows Server 2012. ( (download:

While running these updates, if you receive an error or message saying "Update not applicable", that's fine. The key one here is KB2759112 - you CANNOT run a slipstream installation unless this has been applied.

7) If you are running a VM, snapshot it at this time (this gives you a fallback if the installation doesn't work).

8) Prepare the slipstream installation by copying the extracted CU files into the installation folder called 'updates'. Be sure to copy them in order by date released, March, August, etc.

9) Run the SharePoint setup (on ONE SERVER ONLY) - the first step of this only installs the binaries. At the end, if it says "Compete" the update took - if it shows "Some updates were not applied" you are hosed and you need to start over or install the CU's manually. When complete, you can verify the version installed by going to the hive, c:\Program files\common files\microsoft shared\web server extensions\15\isapi then right clicking on Microsoft.SharePoint.dll and selecting properties then clicking the Details tab. You can validate the number either from the Microsoft site or Steve Chen's blog post:

If the first server went OK, copy the same installation folder to other servers to install there.

10) As a first time installation, running the SharePoint 2013 Configuration Wizard will apply the updates so PSConfig (or PSConfigUI) not needed.

Friday, January 3, 2014

Creating an SQL Server Database alias (For SharePoint and other applications)

Setting Up a SQL Alias

Setting up a SQL Alias enables the ‘masking’ of a SQL Server instance name (default or named) and port in use so an alternate name can be used for the connection to SQL by another server. Using an alias is much more convenient for any application since an alias can be easier to remember than a complex instance name (for example, MyAlias vs. W3A842SQL\ProductionInstance). It is also better for security (such as hiding the port in use) and for moving between environments like QA to Production – if the alias is consistent between environments (though the underlying name will be different), it enables development and workflows to be created against the alias meaning code and workflows don’t have to be altered.

Before setting up an SQL Alias, it is important that the account in use has permissions to connect to the SQL Server. If using this alias for SharePoint, this should be the SharePoint Farm Account – this account should have already been added to SQL Server and have rights to login to the server.

In terms of SharePoint, setting up an alias is VERY important since several services in SharePoint cannot handle the use of an instance name (including the ‘famed’ User Profile Service). While SharePoint does not prevent the use of a full instance name, the problems with the services will appear later and cannot be corrected after the fact.

Setting up an alias is done on each server that will access SQL Server (in many cases, it is useful to setup the Alias on the SQL Server itself) and is done using SQL Server Client Network Utility also known as the “cliconfg” command. This can found simply by searching for it or simply opening up a Command Prompt (using ‘Run as administrator’) and entering the command: cliconfg.exe.  The SQL Server Client Network Utility enables setup of the alias and specifics such as a non-standard port.

Once the utility is opened, the first thing to do is to enable Named Pipes and TCP/IP protocols. While some applications may not require both (i.e. Named Pipes), SharePoint does. Under Disabled protocols:, click to select each in the left window and click the Enable >> button – this moves them over to the right window (Enabled protocols by order:):

In the Enabled protocols by order: window, click on TCP/IP then click the green arrow to move it to the top spot as shown (this makes TCP/IP the preferred connection):

Next click the Alias tab and click the Add… button:

Next add the connection using the steps shown below:

Note that the Alias name used can be any name however SPSQL is quick to remember. Click OK to save the changes and the entry will be shown:

Note that the connection parameters can be seen – the above indicating an instance name of SICGT1SQL using port 1433. Click Apply then OK to close.

Testing the Alias

Validate the SQL connection works by opening Start > Administrative Tools then clicking on ODBC Data Sources (64-bit). Click the System DSN tab then click the Add button:

On the Create New Data Source page, click the SQL Server default (see the version number as shown) – be aware that others may appear here:

On the Create a New Data Source to SQL Server page, enter the name (this can be anything) and specify the server as the alias name or the instance name (though alias should be used with SharePoint – per this example, shown as SPSQL):

On the next page, it will prompt for the security and client settings. By default ‘With Windows NT authentication using the network login ID.’ is selected – for most installations this will be correct.

Clicking the Client Configuration button will display the settings to be used – this should match what was entered using the cliconfg tool:

Be sure that ‘Dynamically determine port’ is NOT checked, click OK then click Next – this should bring up the next page indicating a successful connection:

If this does not show immediately, the connection will likely fail. Some troubleshooting tips here:
  1. Double check SQL Server accounts and be sure that the account in use (for SharePoint, the Farm Account) has been added with either DBO or DBCreator/Security Admin rights
  2. Verify that the account in use has a User Mapping to the Master database
  3. Verify that the firewalll has been disabled or the proper ports have been opened
  4. Ping the server to ensure that the IP Address is corect
  5. Double check spelling
  6. Double check SQL Confirmation for the IP and Port Number

If the connection works, click Next then on the next page, click Finish:

This displays the setup summary:

Click Test Data Source… and the Test Results page should appear:

This process should be repeated on each server.

Copying cliconfg Settings

As an alternate to the manual process of setting up the SQL Server alias on every server, it can be faster (and more accurate) to utilize the Registry key. Using ‘regedit’, the Registry key can be saved to a file and simply copied to then clicked on to apply it to each system.
NOTE: Do not do this unless all client connections will be the same across all servers. If there are additional aliases on the server, these will be included in the registry export.
To do this, open the registry editor (RegEdit.exe). Once opened, simply search for the SQL Alias name or navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client. Right click on the Client folder and select Export:

This pops up a window enabling the saving of the registry file:

To add this to another server, simply copy the file to a server, double click on the file and when prompted, click Yes to add it to the registry.

After adding the entry via the registry, it is necessary to verify the connection using the ODBC data connection (see Testing the Alias above).

Creating an Alias using SharePoint PowerShell

For SharePoint it is also possible to establish the SQL Alias using the Microsoft SharePoint (2010/2013) Management Shell. To use this, the account in use should have Administrator permissions to run PowerShell – right click on the SharePoint 2013 Management Shell (or 2010) and select Run as administrator.
If the standard SQL Port (1433) is used, the command format is simply:

Add-SQLAlias –AliasName <name to use> -SQLInstance <instance name>

If using a non-standard port, it is necessary to include it as so:

Add-SQLAlias –AliasName <name to use> -SQLInstance <instance name> -Port <port number>

  •  <name to use> is the name for the alias, for example SPSQL
  • <instance name> is the name of the SQL Instance, either the Server name or the instance name (Server\Name)
  •  <port number> is the port number assigned via the SQL Server Configuration Manager

As a few examples (assume the SQL Server name is “MySQLServer”):

·         Adding the default instance using Port 1433:
Add-SQLAlias –AliasName SPSQL –SQLInstance MySQLServer

·         Adding a named instance using Port 1433:
Add-SQLAlias –AliasName SPSQL –SQLInstance MySQLServer\MyInstanceName

·         Adding a named instance using Port 4900:
Add-SQLAlias –AliasName SPSQL –SQLInstance MySQLServer\MyInstanceName –Port 4900

After adding the entry via the Management Shell, it is necessary to verify the connection using the ODBC data connection (see Testing the Alias above).