Freigeben über

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

  • Artikel

This is the first in a series of posts where I will talk about my involvement in the TAP (Technology Adoption Program) and more specifically a project I was involved in to implement the SharePoint 2013 platform and Office Web Apps Server farm. I will be sharing my findings and experience that will hopefully help you to:

  • Create a reusable SharePoint 2013 build and configuration guide
  • Implement SharePoint and Office Web Apps Server in a consistent manner using the scripts I will provide throughout this blog post series.

The series is broken down into the following articles that I will write:

  1. Farm Topology and Prerequisites (This article)
  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

Introduction

This post will focus on providing an overview of the overall farm topology, the end to end build sequence from preparation to testing, recommended service accounts and the prerequisites.

Build Sequence

The following diagram illustrates the high level overview of the steps required to implement and configure the SharePoint and Office Web Apps Server farms. The Office Web Apps server farm requires dedicated hardware and is no longer implemented as a SharePoint service application.

 

Farm Topology

The server farm topology will have multiple tiers and each tier will have redundant server instances, this is the most common topology that provides an efficient physical and logical layout to support scaling out or scaling up, and provides better distribution of services across the
member servers.

It is important to adopt an iterative design approach to analyse the architecture model, to verify that the model identifies all the elements that are required for the farm solution. 

The Plan for monitoring in SharePoint 2013 TechNet article provides great introduction on tools and scenarios on how to best use them. 

Redundant member servers are hosted on different Hyper-V hosts and Anti-Affinity helps to eliminate single points of failure. It is worth noting that the Deployment guide for SharePoint 2013 eBook, provides great detailed information regarding recommended practices when implementing SharePoint 2013 on a virtualised platform such as:         

  • Leave adequate memory for the Hyper-V partitions - For SharePoint products virtual machines, we recommend 4 GB of RAM or more for host computer operations.
  • Use a minimum of two physical network adapters - For better network management and performance, dedicate one adapter to virtual machine network traffic and use the other adapter for virtualization host network traffic.
  • Do not oversubscribe the CPU on the virtualization host computer - Review the supported ratio of virtual processors per logical processor and avoid oversubscribing the host computer CPU. The optimum virtual processor:logical processor ratio is 1:1. For more information, see Configure the processors for the virtual machines in Deployment guide for SharePoint 2013 eBook.
  • Do not cross Non-uniform memory access (NUMA) boundaries - Hyper-V spans NUMA nodes to assign physical memory to a virtual machine; however, this does reduce performance on the virtual machine. For more information, see Configure the memory for the virtual machines in Deployment guide for SharePoint 2013 eBook.
  • Do not use snapshots in a production environment - Do not use snapshots for the virtual machines in a SharePoint products production environment.  When you create a snapshot, Hyper-V creates a new secondary drive for the virtual machine. Write operations occur on the new drive and read operations occur on both drives, which has the same net affect as a differencing disk. Every snapshot that you add reduces disk performance further.
  • Do not use dynamic memory - The reason is that this implementation of dynamic memory does not work with every SharePoint feature. For example, Distributed Cache and Search do not resize their caches when the allocated memory for a virtual machine is dynamically changed. This can cause performance degradation, especially when assigned memory is reduced.

Service Accounts

The following service accounts are what I have used to create the farm. This list may vary for your implementation depending on Server resources management versus least privilege security recommendation, required service applications and in general what works for your implementation based on the organisations security guidelines and policies.

Account

Purpose

Requirements

SVC_SPInst

Setup user account

(Install Account)

The Setup user account is used to run the following:

  • Setup
  • SharePoint Products Configuration Wizard
  • Domain user account.
  • Member of the Administrators group on each server on which Setup is run.
  • SQL Server login on the computer that runs SQL Server.
  • dbcreator and securityadmin
  • This account must be a member of the db_owner fixed database role for the content databases database.

SVC_SPFarm

The server farm account is used to perform the following tasks:

  • Configure and manage the server farm.
  • Act as the application pool identity for the SharePoint Central Administration Web site.
  • Run the Microsoft SharePoint Foundation Workflow Timer Service.
  • Domain user account.
  • Additional permissions are automatically granted for the server farm account on Web servers and application servers that are joined to a server farm.
  • The server farm account is automatically added as a SQL Server login on the computer that runs SQL Server. The account is added to the following SQL Server security roles:
  • dbcreator fixed server role
  • securityadmin fixed server role
  • db_owner fixed database role for all SharePoint databases in the server farm

SVC_SPSvc

A generic services account for grouped Service Applications
  • Domain user account

SVC_SPSvcPool

Application Pool Identity for SharePoint Web Services Default application
  • Domain user account

SVC_SPWeb

Application Pool Identity for the main web application
  • Domain user account

SVC_SPUPA

The User Profile Service account is used to run the following:

  • User Profile Synchronisation with AD
  • Domain user account
  • AD Delegate rights for: Replication Directory Changes

SVC_SPSearch

This is the Windows Service account for the SharePoint Server Search Service. This setting affects all Search Service Applications in the farm.
  • Domain user account

SVC_SPSrchPl

Search Admin Web Service application pool

Search Query and Site Settings Web Service application pool
  • Domain user account

SVC_SPSrchCrl

Windows user credentials for the Search service application to use to access content when crawling
  • Domain user account

SVC_SPFabric

AppFabric Caching service
  • Domain user account

SVC_SPOWAPool

Office Web App Application pool account
  • Domain user account

SVC_SPOWASvc

Office web application Services Pool
  • Domain user account
SVC_SPSecStr

Secure Store application Pool account
  • Domain user account

 

Prerequisites

  1. All SharePoint servers would require an additional drive to host Data, Log and Index flies.
    1. An additional VHD is required
    2. Bring the disk online
    3. Format the drive as NTFS, label: Data
  1. Ensure that the following are implemented:
    1. Remote Registry Service started (or Automatic - Trigger Start) on all servers
    2. Inbound firewall rules enabled on all SharePoint servers: (Please see SharePoint 2013 Ports, Proxies and Protocols - An Overview of Farm Communications for more information)
      1. ICMP v4
      2. ICMP v6
      3. Central Administration port number on the servers hosting the Central Admin Site only. It is recommend to use SSL for the central administration site.
      4. Distribution Cache port 22233 on the Distribution Cache Servers only
  2. Ensure that the Install account has SQL securityadmin and dbcreator roles and is member of local administrator group on all SharePoint servers
  3. Ensure that the Farm account is a member of local administrators group on the server hosting the User Profile Service Synchronisation Service. This is only required during the User Profile Synchronisation Configuration defined in post #3 User Profile, Search and Distributed Cache Service Applications Deployment. These permissions are 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.
  1. Ensure that the Farm account is able to logon locally on the server hosting the User Profile Service Synchronisation Service (Please see Plan account permissions).

 Now we are ready to implement SharePoint and configure the basic services. Look out for part two for detailed step by step scripted deployment and configuration of the farm.

Comments

  • Anonymous
    February 18, 2013
    Great Post, Again please

  • Anonymous
    February 18, 2013
    When will the rest of the parts be published?

  • Anonymous
    February 18, 2013
    I really like this blog post. I am looking forward to the other parts. I like that you detail the VM prerequisites, no one else (not even I) does that. :)

  • Anonymous
    February 18, 2013
    I am glad you find this post useful. I am currently working on part two and will publish soon.

  • Anonymous
    February 21, 2013
    This is very promising series.. I am hoping it will get completed soon.. looking forward to it..

  • Anonymous
    March 05, 2013
    I am really looking forward to your 2nd article on this series.. especially I am interested in when how you are using SVC_SPInst  and SVC_SPFarm and when do you switch from SPInst to SPFarm account. I believe you will switch as soon as you are done laying down binaries & creating/joining farm and switch to farm account before configuring service applications & web applications using Powershell but I am looking forward to see how you do it..

  • Anonymous
    March 25, 2013
    The comment has been removed

  • Anonymous
    May 14, 2013
    Hi Chris, Unfortunately this is outside of the scope of these series. The requirements that are considered for capacity planning and sizing vary from project to project. Please see TechNet article Capacity planning for SharePoint Server 2013 (technet.microsoft.com/.../ff758645.aspx). If you have any specific questions please feel free to contact me directly and I would be happy to help.

  • Anonymous
    June 15, 2013
    Great post, I trimmed the number of servers and configured my farm, but post configuration I did not see many options in central admin like "Manage Services", "New" button to create a service application disabled and many other links were not available.

  • Anonymous
    June 26, 2013
    @Himanshu this sounds like a permission issue. ensure that the account that you are logged in with is a member of the Farm administrators group.

  • Anonymous
    July 01, 2013
    Counting for your last post Office Web Apps Server farm Implementation and Configuration Great Post!

  • Anonymous
    August 25, 2013
    What program have you used to create the drawing with the Hyper - V cluster? if visio - where can I get the stencils?

  • Anonymous
    August 27, 2013
    @JmATK - yes the drawings were created using Visio custom stencils similar to those found here www.jonathancusson.com/.../virtualization-stencil