The Future is SharePoint Hybrid (and the future of SharePoint Hybrid)

The Future is SharePoint Hybrid (and the future of SharePoint Hybrid)

The year 2016 is coming to an end. And for everyone who predicted SharePoint hybrid as future in past 3 years, the future is here (almost). And enterprises have also learned that the barriers to the hybrid cloud are more numerous than originally anticipated. However, it’s important to do some reflection and introspection on where the hybrid SharePoint implementation is today.

Adoption: Interest and consumption are beginning to ramp up quickly. Enterprises who, earlier had goals to move all in a cloud are now considering a hybrid approach towards using SharePoint.  Several migrations to Office 365 initiatives have failed drastically and made their way as the staple diet for discussions at various competition conferences and whitepapers.  As a result, IT leaders are making a rapid shift in the direction of public cloud by adopting hybrid cloud for their SharePoint implementation. The combination of private and public cloud gives IT the tools required to help the business innovate and iterate faster at a lower cost.

Governance: The most common policy discussion that required consensus from governance board was data protection vs extending SharePoint over the internet. Just like vim vs emacs, there were always two sides to this discussion whether SharePoint should be served over VPN or should the infrastructure be made available on DMZ for easy access or publish SharePoint over web application proxy. Each side has a stronger business case; right from a sales director citing the pathetic performance of applications over VPN vs a finance controller worried about his excel sheets leaving the very secure boundaries of their internal data center. With SharePoint 2016 hybrid, a third option as emerged as a solution and it is now easy for organizations to determine which content can be made available over cloud vs what remains on premise. The boundaries for content and their availability over search are clearly articulated.

Optimized use of Infrastructure – With 1 TB available with each OneDrive for Business and SharePoint Online Site Collections storing TB of content and Videos for storing rich media content, IT managers are now able to establish an optimized storage and compute utilization plan to store low function high storage content on cloud while retaining content that has legal, compliance or business critical applications with security and performance demands can be hosted on an on-premise environment. In addition to this, with the zero downtime patching for SharePoint 2016 and managed releases for Office 365 SharePoint Online, it is easier than before the meet the Service Level Agreements for SharePoint based solutions.

Search – Content findability has always been a challenge for most of the SharePoint Implementations. Even though in SharePoint 2013, enterprises could configure hybrid search, the results weren’t encouraging with multiple search result sets that were not commingled. The relevance was different and so was user experience. With SharePoint 2016, the search has been re-architected and these issues have been addressed.

The hybrid infrastructure does provide best of both the worlds. Combining these two cloud models leverages cost efficiencies and also builds resilience into a solution.

To achieve the Hybrid model and gain some of the benefits listed above, the core architecture for Office 365 and SharePoint On-Premises needs to be understood.

SharePoint 2016 Hybrid Cloud

SharePoint 2016 Hybrid Cloud Infrastructure

 

The core logical design is about connecting your On-Premises Active Directory with the Azure Active Directory that is available. This ensures that accounts are synchronized and licenses from the cloud services can be assigned. Once done then the On-Premises environment needs to be connected through standard network connectivity. Once SharePoint 2016 on-premise is configured with SharePoint Online, the users would be able to manage the following hybrid workloads.

Hybrid Workloads

Hybrid Workloads

 

So based on where we are, the future (Hybrid) has already arrived. But where do we go from here? What is the future of Hybrid ? With enterprises moving to Azure to host their SharePoint 2016 farm, will they continue to be true hybrid ? Or the hybrid would no longer differentiate between on-premise data center, public cloud & private cloud, but it would just be a combination of IAAS, PAAS & SAAS based solutions hosted across infrastructures.

And if you are interested in defining your SharePoint Hybrid Strategy, please reach out to me using the contact me page.

Configure SharePoint 2016 (Part 6)

Configure SharePoint 2016 (Part 6)

In the last post, we created service accounts and configured claims to windows token service. In this post, we will run products and configuration wizard and complete SharePoint 2016 configuration.

Before we start running SharePoint 2016 Product & Configuration wizard, we need to make sure that your SharePoint Application Server can talk to SQL Server. The default firewall settings may not allow SharePoint Server to Connect to SQL Server over port 1433. You can run the following script to open up the required ports for accessing SQL Server.

@echo ========= SQL Server Ports ===================

@echo Enabling SQLServer default instance port 1433

netsh firewall set portopening TCP 1433 “SQLServer”

@echo Enabling Dedicated Admin Connection port 1434

netsh firewall set portopening TCP 1434 “SQL Admin Connection”

@echo Enabling conventional SQL Server Service Broker port 4022

netsh firewall set portopening TCP 4022 “SQL Service Broker”

@echo Enabling Transact-SQL Debugger/RPC port 135

netsh firewall set portopening TCP 135 “SQL Debugger/RPC”

@echo ========= Analysis Services Ports ==============

@echo Enabling SSAS Default Instance port 2383

netsh firewall set portopening TCP 2383 “Analysis Services”

@echo Enabling SQL Server Browser Service port 2382

netsh firewall set portopening TCP 2382 “SQL Browser”

@echo ========= Misc Applications ==============

@echo Enabling HTTP port 80

netsh firewall set portopening TCP 80 “HTTP”

@echo Enabling SSL port 443

netsh firewall set portopening TCP 443 “SSL”

@echo Enabling port for SQL Server Browser Service’s ‘Browse’ Button

netsh firewall set portopening UDP 1434 “SQL Browser”

@echo Allowing multicast broadcast response on UDP (Browser Service Enumerations OK)

netsh firewall set multicastbroadcastresponse ENABLE

Once the connection to SQL Server is configured, you can start SharePoint 2016 Products and Configuration from the Start Menu. You will see the following screen. Click next.

Figure 1

You will see a message about IIS services, click Yes and Next.

Figure 2

You will have an option to connect to an existing server farm or create a new server farm. Since this is the first SharePoint server in the farm, we will click on option Create a new server farm. Click Next.

Figure 3

Specify database settings on this screen. Click Next.

Figure 4

Specify a Passphrase. And make sure the Passphrase is stored in a safe and retrievable place as we would need this for various activities like adding more servers to the farm, etc.

Figure 5

This is new in SharePoint 2016. You can specify a predefined role for the server you are configuring. For this lab, we will configure single server farm. For an elaborated description of each role, refer to my previous post “What’s new in SharePoint 2016 (and what’s deprecated)“. Click Next.

Figure 6

Review the parameters selected and entered and click Next.

Figure 7

You should see the configuration in progress. Creating the configuration database may take most of the time, everything else should complete relatively fast.

Figure 8

Once the configuration is successful, you will see the following completion message. Click Finish. This should start Central Administration screen and a wizard to configure all Service Applications. Click cancel, we will configure these service applications manually.

Figure 9

Navigate to Central Administration à Security à Configured Managed Service Accounts and add the service accounts configured. You should be able to see the following once the Managed Accounts are configured.

Figure 10

Navigate to Central Administration à Manage Service Applications. You should be able to see the two default service applications.

Figure 11

Once this step is completed, it’s good to review the following.

  1. Central Administration à Security à Manage the farm administrators group and review that you have all the required accounts (E.g. Admins, etc) added in there.
  2. You are able to access SharePoint 2016 PowerShell.

In my next blog post, I will show you how to create and configure service applications manually along with their PowerShell scripts. Till then, keep watching this space.

Configure SharePoint 2016 Service Accounts (Part 5)

In part 4, I showed you how to install SharePoint 2016 and we stopped at running Products & Configuration wizard. And before we complete our configuration, we need to ensure the following service accounts are created for using against various service applications. Some of the best practices of creating SharePoint Service Accounts are

  1. Use Password Never Expires – All service accounts should be set to “Password never expires” in Active Directory because if they expire in future after installation of SP2016 it would be an issue for the continued operations of SharePoint.
  2. Place all Service Accounts in single OU – This placement allows system administrators to easily locate and view service accounts, group them in one Active Directory OU.
  3. Strictly Avoid Special Characters – Do not use service account names that contain anything other than _.
#

Account

Description

Access Level

1 svcSPSetup The Setup user account is used to

a. Install SharePoint

b. Run the following: Setup SharePoint Products Configuration Wizard

  1. Member of the Administrators group on each server on which SharePoint Setup is run.
  2. SQL Server login on the computer that runs SQL Server.
  3. Member of the following SQL Server roles:
    1. securityadmin fixed server role
    2. dbcreator fixed server role
  4. 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.
2 svcSPFarm The Server farm account or database access account. The server farm account is used to configure and manage the server farm. And acts as the application pool identity for the SharePoint Central Administration Web site.
  1. Additional permissions are automatically granted for the server farm account on Web servers and application servers that are joined to a server farm.
  2. 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:
    1. dbcreator fixed server role
    2. securityadmin fixed server role
    3. db_owner fixed database role

for all SharePoint databases in the server farm

3 svcSPApp This account is used for Content Web Application. None unless using Office Web Apps. Then must give access to content databases manually.
4 svcSPService This account is used for Service Application Pool. Must be a member of the Farm Administrators group.
5 svcSPMySite This account is used for My Site Application Pool. This account must not be a member of the Administrators group on any computer in the server farm.
6 svcSPSearch
7 svcSPCrawl This account is used for default content access account for Search Crawling
  1. The default content access account must be a domain user account that has read access to external or secure content sources that you want to crawl by using this account.
  2. For SharePoint Server sites that are not part of the server farm, you have to explicitly grant this account full read permissions to the web applications that host the sites.
  3. This account must not be a member of the Farm Administrators group.
8 svcSPWorkFlow This account is used for SharePoint Workflow Manager Service
9 svcSPC2WTS This account is used for Claims to Windows Token Service Must be a member of the Farm Administrators group.
10 svcSPUPSync User Profile Synchronization Connection Service Account Member of the Administrators group on each server on which SharePoint Setup is run.
11 svcSPCacheSuperUsr Cache Super User
  • The object cache accounts are user accounts that are given FullControl and FullRead privileges on WebApplications so items can be cached by ASP.Net to improve performance.
  • These accounts should not have any special Active Directory privileges other than Domain User membership
12 svcSPCacheSuperRdr Cache Super Reader
  1. The object cache accounts are user accounts that are given FullControl and FullRead privileges on WebApplications so items can be cached by ASP.Net to improve performance.
  2. These accounts should not have any special Active Directory privileges other than Domain User membership
13 svcSPSSRS SQL Server Reporting Services Service Application Account
14 svcSPPPS Performance Point Services Service Application Account

In addition to the above configuration, there are some special configuration changes required for claims to windows token service account to be done on each SharePoint server. The Claims to Windows Token Service (C2WTS) is a component of the Windows Identity Foundation (WIF) which is responsible for converting user claim tokens to windows tokens. Excel services uses the C2WTS to convert the user’s claims token into a windows token when the services needs to delegate credentials to a back-end system which uses Integrated Windows authentication.

Each SharePoint service application must run the C2WTS locally. The C2WTS does not open any ports and cannot be accessed by a remote caller. Further, the C2WTS service configuration file must be configured to specifically trust the local calling client identity

As a best practice you should run the C2WTS using a dedicated service account and not as Local System (the default configuration). But Local System will work if you configure the Kerberos constrained delegation to use the machine name account. The C2WTS service account requires special local permissions on each server the service runs on so be sure to configure these permissions each time the service is started on a server. Optimally you should configure the service account’s permissions on the local server before starting the C2WTS, but if done after the fact you can restart the C2WTS from the Windows services management console (services.msc).

To start the C2WTS using Domain Account

  1. Add an arbitrary Service Principal Name (SPN) to the service account to expose the delegation options for this account in Active Directory Users and Computers. The SPN can be any format because we do not authenticate to the C2WTS using Kerberos authentication. It is recommended to not use an HTTP SPN to avoid potentially creating duplicate SPNs in your environment. In our example, we will have registered ‘SP/C2WTS’ to the ‘infrafusion\svcspC2WTS’ using the following command:

    SetSPN -S SP/C2WTS infrafusion\svcspC2WTS

  2. Configure Kerberos constrained delegation on the C2WTS services account. In his scenario we will delegate credentials to the SQL service running with the ‘MSSQLSVC/NACDB02.infrafusion.xyz:1433’ service principal name.

    Key configuration options on the delegation tab are the following:

    a) Select “Trust this user for delegation to specified services only”

    b) Select “Use any authentication protocol”

  3. Next, configure the required local server permissions that the C2WTS requires. You will need to configure these permissions on each server the C2WTS runs on. In our example this is VMSP10APP01. Log onto the server and give the C2WTS the following permissions:
    1. Add the service account to the local Administrators Groups.
    2. In local security policy (secpol.msc) under user rights assignment give the service account the following permissions:
      1. Act as part of the operating system
      2. Impersonate a client after authentication
      3. Log on as a service

This will prepare Claims to Windows Service Account to be used with SharePoint 2016 after the configuration is completed.

In this post, we configured service accounts with their appropriate access. In the next post, we will run the product & services configuration wizard and configure each Service Application to use their designated service account. Till then, keep watching this space.

Build SharePoint 2016 (Part 4)

Build SharePoint 2016 (Part 4)

In part 3, I showed you how to build a database server on SQL Server 2014 SP1. In this part, we will see how to install SharePoint 2016 on the first application server in the farm. This post would be restricted to installation of SharePoint 2016 pre requisites and server product. In the next post, we shall discuss in detail about product configuration, security and service applications.

  1. From SharePoint 2016 installation media, run spash.hta and click on Install software prerequisites.

Figure 1

  1. Click on Next.

Figure 2

  1. Accept the terms of license agreement and click next.

Figure 3

  1. Pre requisite installation will begin and as shown in Figure 5, you would be asked to restart the server by clicking on continue. The prerequisite installation will continue after the server reboot completes until all the prerequisites are installed.

Figure 4

Figure 5

  1. Open spash.hta again and click Install SharePoint Server. If you are installing trial version of SharePoint 2016, install the product key below. Or else, use the product key available with your product. Click continue.

Figure 6

  1. Accept the terms of the agreement and click continue.

Figure 7

  1. Choose file location and change as needed.

Figure 8

  1. The installation would begin and would take several minutes to complete.

Figure 9

  1. STOP. At this screen, uncheck “Run the SharePoint Products Configuration Wizard now.” And click close. I would configure Product and Configuration wizard in next post.

Figure 10

In this part, I showed installation of SharePoint 2016 Server. In the next part, we will see the service accounts and other configuration required to configure SharePoint 2016 Application server. Till then, keep watching this space.

Build SQL Server 2014 (Part 3)

Build SQL Server 2014 (Part 3)

In part 2, I showed you how to build an Active Directory Domain Controller. In this part, we shall build a SQL Server 2014 SP1 database server. The following steps are to install SQL Server 2014 SP1. These steps do not necessarily include hardening and enterprise grade configuration, but I have added two critical steps which is part of best practices, i.e. custom instance name and SPN configuration. .Net Framework 3.5 is a mandatory pre-requisite. You can verify and install it using Add Roles and Features Wizard under Features as shown in Figure 1.

Figure 1

  1. Run SQL Server setup.exe and under installation, select New SQL Server stand-alone installation or add features to an existing installation.

Figure 2

  1. Enter your Product Key (or select evaluation) and click next. Click next after accepting the License Terms.

Figure 3

  1. Select Use Microsoft Update to check for updates (recommended) and click next.

Figure 4

  1. Click next

Figure 5

  1. On the Setup Role, select SQL Server Feature Installation and click next.

Figure 6

  1. Select Database Engine Services along with other required Shared Features as showing in Figure 7 and 8

Figure 7

Figure 8

  1. Click on Named Instance and enter the name of Instance you wish to select. In this case, I have added SP2016SQL. Click Next.

Figure 9

  1. Change the default account name to SQL Server Service Account that you have created in Active Directory. If you have not yet created, use Active Directory Users and Computers to create a service account. The service account should have local admin rights on SQL Server. Click Next.

Figure 11

  1. Under Database Engine Configuration, you have an option to go total windows authentication or Mixed Mode. For lab accounts, I prefer to use Mixed Mode, but you can choose the one that is convenient to you. Click Next.

Figure 12

  1. The Ready to install screen will show the summary of features and configurations. Its always a good idea to review it. Click Install.

Figure 13

  1. Once the installation is completed successfully, you would see the following screen. Click Close.

Figure 14

  1. Reboot the server.
  2. Open SQL Server Management Studio and verify that you are able to connect to your database instance.

Figure 15

  1. SPN registration is mandatory as we are planning to use Kerberos as authentication method for web applications. Please note that you need to register SPN for
    1. SQL Server Name
    2. SQL Server Name (FQDN):
    3. SQL Server Name Instance:Port
    4. SQL Server Name (FQDN) Instance:Port

    The following figure illustrates SPN registration for MS SQL Server service account.

Figure 16

Once this step has completed, it is imperative to configure firewall for accepting requests to SQL Server based on your existing firewall configurations. The SQL Server is ready for hosting database server for SharePoint 2016.

This article showed you steps to build and configure MS SQL Server 2014 SP1. In the next article of the series, we will install SharePoint Server 2016. Till then, keep watching this space.