Scripted Installation of SharePoint 2013 and Office Web Apps Server – From the Field (Part 3)

This is third post in the Scripted Installation of SharePoint 2013 and Office Web Apps Server blog series, covering the following service applications deployment:

  • User Profile
  • Search
  • Distributed Cache

For SharePoint farm topology, installation and provisioning of the basic service applications please see blog one and two of this series.

  1. Farm Topology and Prerequisites
  2. SharePoint Installation, Configuration and Basic Service Applications Deployment
  3. User Profile, Search and Distributed Cache Service Applications Deployment
  4. Office Web Apps Server farm Implementation and Configuration

Prerequisites and Assumptions

  • Please download and extract the attached files onto a local directory on each SharePoint Server. For the purposes of this blog the directory is suggested to be: E:\Scripts\Install.
  • From the downloaded files, update the SPUserProfile.xml file with environment specific information such as, SQL server alias name, service account details, database name, service application name, etc. This will be self-explanatory once you open the file.
  • Also update the SPSearchService.xml file with environment specific information such as, SQL server alias name, service account name and password, database name, service application name, Index Location, etc.

Configure Distributed Cache

The Distributed Cache service can be deployed in two modes: dedicated mode or collocated mode. In dedicated mode, all services other than the Distributed Cache service are stopped on the application server that runs the Distributed Cache service. In collocated mode, the Distributed Cache service runs together with other services on the application server. Dedicated mode is the recommended mode in which to deploy the Distributed Cache service if the total number of users exceed 10,000.

When more than one server is used for Distributed Cache, all the servers must have the same cache size configured.

Please see Planning for Distributed Cache service in SharePoint Server 2013 for more information.

Provision Distributed Cache Service in dedicated mode:

Launch SharePoint Management Shell as administrator and execute the following PowerShell script on all Application, Search and Web Application Servers (all servers apart from Distributed Cache servers SPDCache01 and SPDCache02) to remove them from the Distributed Cache cluster and stop the services:

 $instanceName ="SPDistributedCacheService Name=AppFabricCachingService" 
$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($ -eq $env:computername}
Stop-SPDistributedCacheServiceInstance -Graceful

Change the Memory Allocation of the Distributed Cache Service

When SharePoint Server 2013 is installed, it assigns the Distributed Cache service 10 percent of the total memory on the server. It is recommended to allocate sufficient amount of memory on each Distributed Cache server. Please see Change the memory allocation of the Distributed Cache service to calculate how much memory can be assigned to the Distributed Cache service. It is important to note that the allocated memory on each server should not exceed 16 GB.

Use the following procedure to update the memory allocation accordingly:

Launch SharePoint Management Shell as Administrator on SPDCache01 and SPDCache02 and run the following scripts:

Stop the Distributed Cache service:

 $instanceName ="SPDistributedCacheService Name=AppFabricCachingService" 
$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($ -eq $env:computername}

Reconfigure the cache size of the Distributed Cache service:

 Update-SPDistributedCacheSize -CacheSizeInMB 7168 

Restart the Distributed Cache service:

 $instanceName ="SPDistributedCacheService Name=AppFabricCachingService" 
$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($ -eq $env:computername}

Change Service Account

When the server farm is first configured, the server farm account is set as the service account of the AppFabric Caching service. The Distributed Cache service depends on the AppFabric Caching service. For security purposes it is advised to change the service account from the farm account. To change the service account of the AppFabric Caching service to a managed account, set the Managed account as the service account on the AppFabric Caching service.

At the Windows PowerShell command prompt, run the following command:

 $farm = Get-SPFarm 
$cacheService = $farm.Services | where {$_.Name -eq "AppFabricCachingService"}
$accnt = Get-SPManagedAccount -Identity DomainName\SVC_SPFabric
$cacheService.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$cacheService.ProcessIdentity.ManagedAccount = $accnt

Where the ‘DomainName’ is the NetBIOS domain name.

Configure User Profile Services

Login to SPAPP01 (Application Server hosting the Central Administration site) and launch SharePoint Management Shell as administrator. Execute the following command to start and configure User Profile Service:

 E:\Scripts\Install\SPUserProfile.ps1 -configLocation E:\Scripts\Install\SPUserProfile.xml 

When prompted provide the My Site Application Pool account variable “$MySiteAppPool”

Start User Profile Synchronisation

  1. Ensure that the Farm Admin account (SVC_SPFarm) is a member of local administrators group on SPAPP01. 
    Please note this is only required while configuring User Profile synchronisation Settings. However, when a backup of the User Profile application is initiated, the synchronization service provisions the User Profile application again. During the course of provisioning the User Profile application, the farm account must stop and start the synchronization service. To do this, the farm account must be a member of the Administrators group on the computer that is running the synchronization service. Due to this you may decide that the farm account will remain a member of the Administrators group on SPAPP01.
  2. Ensure that the Farm account is able to logon locally on both SPAPP01 and SPAPP02 (Please see
  3. Reboot SPAPP01 after granting above permissions
  4. Starting the user profile synchronisation service introduce the same challenge as we had in SharePoint 2010. This needs to be done under the farm account. There are a number of options:
    1. Login to SPAPP01 using the Farm Admin account (SVC_SPFarm). Navigate to Central Administration Site and click on Services on Server and start User Profile Synchronization Service.
    2. Launch the SharePoint Management Shell as the SVC_SPFarm account and use New-SPProfileServiceApplication Cmdlet.
    3. Use the third option described in: Avoiding the Default Schema issue when creating the User Profile Service Application using Windows PowerShell by Spencer Harbar.
    4. Perform an IIS reset on SPAPP01 server

The following activities are recommended however are out of scope of this blog post:

  1. Add a new synchronisation connection
  2. Define exclusion filters for a synchronisation connection
  3. Map user profile properties
  4. Start profile synchronization and configure Import Schedules


Configure Search Service

Login to SPAPP01 (Application Server hosting the Central Administration site) and launch SharePoint Management Shell as administrator. Execute the following command to start and Search Services and configure the search topology:

 E:\Scripts\Install\SPSearchService.ps1 -configLocation E:\Scripts\Install\SPSearchService.xml 

Please note the following Search post configuration steps are required to be carried out; however, are out of scope of this blog post:

  1. Provide the location of the global Search Centre
  2. Setup People Search
  3. Configure result sources
  4. Configure Search Result Exclusions
  5. Configure Search Alert Settings
  6. Configure Search Crawling Schedule

Lookout for the next blog post, where we implement Office Web Application Components and its integration with SharePoint.

Comments (8)
  1. Nik Patel says:

    Thanks for posting Ashkan.. This is indeed one of my favorite blog series regarding SharePoint 2013.. This is definitely great series to learn how to automate multi-server farm along with tools like AutoSPInstaller.. Great stuff here…Looking forward to last series on your blog.. Any time frame you have on Office web apps post?

  2. Dennis Gaida says:

    Great work! Though I don't understand why you don't reference AutoSPInstaller anywhere. Do your Powershell scripts do something better? Why not contribute to AutoSPInstaller then? Or is it more of a though experiment in the terms of "we wanna do it on our own?"

  3. @moontear Thank you for your question and just to clarify the purpose of my blog series was to illustrate an example of an end to end implementation of SharePoint and OWA farm based on the field experience. It is important to note that the intention has never been to create a managed set of scripts and IP such as AutoSPInstaller. hope this helps.

  4. @Nick, Many thanks for your comment. I am glad you find this blog series useful. I am working on the last blog and hoping to have it published in the next few weeks.

  5. raoul gonzagao says:

    Many thanks Ashkan .. great work and good tutorial ..

    its a good way to understand "inside sharepoint" … just few point

    you must run the wizard time to time  (to register the 1 billion of secret element) … and health and data collection never work even with last build ..

    Thks to share you're knowledge

  6. Venkat says:

    Good article and many thanks for the series…

  7. Guru says:

    Very nice Article. I have a question on configuring apps in 3 tier farms. In which server we should run app management service and subscription settings service applications? I mean whether in app server or WFE server?

  8. shaun says:

    Great article thank you very much.

    I have a question about the step 'start user profile sync'. After running the script ' E:ScriptsInstallSPUserProfile.ps1 -configLocation E:ScriptsInstallSPUserProfile.xml ' it creates the service application. But then step 4b of 'start user profile sync' you say to run  New-SPProfileServiceApplication Cmdlet. Why is this when the service application is already created? Are all the steps (from 1-4 supposed to be performed)? or are they just an alternative way to get UPS started if you cannot get it to start the first time after running the script.

    It just doesn't make sense to run  New-SPProfileServiceApplication unless recreating it. I may have missed something. Could you please provide some light for me.

    kind regards

Comments are closed.

Skip to main content