Setting up a SharePoint 2016 Preview Farm in Azure update from September 2015

Whether you are a developer or IT pro, if your shop uses SharePoint, you need to gain some experience with the 2016 edition as it will behave in a production setting. The new roles afforded by SharePoint Server 2016 IT Preview mandate a variety of servers with specific hardware requirements. This post examines how you can set all this up in Azure.

This blog post depicts the process of setting up a SharePoint 2016 Preview Farm using Virtual Machines in Azure. This farm will include servers with the following roles

Here is a visual representation of those boxes from the Azure Management Portal:

These boxes are all A3 Azure boxes, with specs as you see below: four  cores and 7 GB of memory on Windows Server 2012 R2 Datacenter. In a production environment, but quite possibly also in dev/proof of concept (POC), you should create your own VHDX from your Windows Server “Standard” image, upload it to Storage, and then use it to build out your VM. That way you are billed at a lesser rate than with Datacenter, which is all you get for Server in Azure OOB.

Now that you have a visual sense of how we will be building out our farm, let's discuss why we are building out our farm--and, specifically, why in this way.

I could have built out this farm as a “Single Server Farm,” and I could have achieved this with at least a two-server outlay for Domain Controller/SQL box and a SharePoint box. I could also have done a Multi Server Farm with one Custom Min role with all features. I could have taken it further by incorporating multiple Web front ends, which would then encourage me to add a Distributed Cache server into the mix.

But my intention is to explore the new features of Min Roles without going out into the weeds, and this configuration provides that; indeed, if this was not a dev rig, POC endeavor, I would have done just that.

How to Get Started

The first thing you will need is an Azure subscription, which you can get here or, as a free trial, here (along with $200 in Azure Credits). I also encourage you to read  the MSDN article “Test Lab Guide: Base Configuration in Azure,” which covers how to sets up several servers in a LAN environment in Azure. This base model shows you how to assign a DNS server and subnet in Azure, along with a Storage Location, which ensures that all your boxes live in an area in which they can effectively communicate with each other. You should also read “Test Lab Guide: Configure SharePoint Server 2013 in a Three-Tier Farm,” which explains how I set up my farm. While the model examined here is for a three-tier farm, you can extend it for any number you need.

Installation

Installing SharePoint is a two-step process because of the dependency of the database backend--in this case, SQL Server. You can install SQL via the GUI or via Powershell, for more manageability of the entire installation and configuration process. I highly encourage POSH, as it is ensures repeatability and more refinement of your build. This post will not go over the installation process of SQL; I assume that your SQL is up and running, all ports that need to be open for communications are already open, and all systems are green.

Laying down the SharePoint bits is pretty much similar or the same to what you may have done in previous installs of SharePoint Server, and this post will stop right when you finish PSConfig. You should pay attention to are the new Pre-Reqs that are being installed as part of SharePoint 2016 Preview. Most notable is a new .NET version and a few other assemblies that are needed. Take a look below. I purposely ran setup without the Pre-Reqs so you can see what that would look like:

Notice there is also a link to find out all the pre-reqs you will need; this is helpful if you want to run a POSH to pull them down ahead of time, or if you are faced with this situation like we were in the Fed Space, where you are not  permitted to connect your servers to the Internet. You will need to have these somewhere accessible locally or on the LAN. So, after you run the Pre-Req installer you will get a better picture of what is needed, as you can see below:

The rest of the list is here:

Of course, when you are finished with the prerequisites, a restart is required. After you do that, you will be ready to lay down the actual SharePoint 2016 preview bits.

Your next task is to run Setup and follow the instructions as provided. Now, mind you, if you are following better/best practices, you should have already created some accounts for installation and configuration. During my testing, I had the following:

They are pretty much self-explanatory, but if you have questions, put them in the comments section. Install the bits on all the servers using the “SPInstall” account.

When you are done, you will be prompted to run the Products Configuration Wizard (PSConfig.exe).

Preconfiguration

I call this "preconfiguration," because it is still a part of the base configuration of attaching the product to the underlying database and defining the roles of all the SharePoint Servers that will participate in the farm. At this point I will also do a restart. When I eventually logon to the servers again, I do so using the “SPFarm” account

After your fire up PSConfig, select “New Farm.” This is where you configure your database settings. In this case, I am connecting to a previously installed and configured SQL box, and I am identifying the SPFarm account as the Database Access Account. (Prior to doing this, you would have assigned SPFarm and SPAdmin if you elected to create an Admin account, following best/better practices.) You may also at this time give the SPSvc, or whatever account you designate as the User Profile Sync Account, the requisite permissions in Active Directory as well for Replicate Permissions.

Here are some particulars on how I installed SharePoint on each Server with respect to Roles. SharePoint Server 1 farm was by the books, with the exception of the introduction to the Specify Server Role screen

In this instance, I selected Application and continued onward with the defaults. In the end, when the process was completed, I had a farm up and running. However, at this point, do not run/configure any Service Applications, as there is more work to do.

Here is what you will have by way of Central Administration. Pay special attention to the “Role” column and the “In Compliance” column. I REALLY, REALLY love this inclusion, as I will get to in the “gotcha” section and more in detail in a future post. It's very easy to see if one of your defined server roles is out of compliance (see below).

Here, we are going to pause and configure the other servers in the farm in their respective roles.

In the Second SharePoint Server, when I am in the configuration phase, I am connecting this guy to the farm:

And when it comes to the configuration phase, we are assigning it to the Search Role.

When we are done, we should expect to see the outcome we have below in Central Admin:

We take the same approach for the third server:

We chose "Custom" when sepcifying server roles.

And next we do the Web Front End:

And finally we should have a Central Admin that looks like this:

Notice that under In Compliance for the Custom Role we have nothing. That is by design, as we don’t know yet what we will be putting on there. This is reflective of/analogous to what you had in SharePoint 2013, where you would have all the bits and pieces on all your servers and then decide what services you wanted to run on each respective server. This is simplified for you when you select hardened roles like Web, Search, Distributed Cache and Application, and this will also enable SharePoint to monitor the health and feature enablement via a compliancy model.

At this point you have a real farm that you can do real business with; all that is left to do is create and configure some Service Applications, create a web app and site collections, and give users access.

With the exception of the upgraded Pre-Requisites, new Min Roles and Enhanced Central Administration, all of this is pretty much the same run-of-the-mill installation of SharePoint, from an Installer experience. However, there is a lot more under the hood, which we will explore in a future post.