Setting up a SharePoint 2016 Preview Farm in Azure 4


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

1. Server 1 – Active Directory Domain Service (ADDS) Domain Controller

2. Server 2 – Database Server (SQL Server 2014)

3. Server 3 – SharePoint 2016 Preview Server1 (Min Role of Application)

4. Server 4 – SharePoint 2016 Preview Server2 (Min Role of Search)

5. Server 5 – SharePoint 2016 Preview Server3 (Min Role of Custom)

6. Server 6 – SharePoint 2016 Preview Server4 (Min Role of Web Front End)

7. Client 1 – Windows 10 Enterprise

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


These boxes are all A3 Azure boxes, with specs as you see below. 4 cores and 7 gigabytes of memory on Windows Server 2012 R2 Datacenter. Now if you desire to do this, and I would encourage this behavior most definitely in a Production Environment but quite possibly also in Dev/POC is… create your own VHD from your Windows Server “Standard” image and upload them to Storage and then use that to build out your VM. That way you are billed at a lesser rate than these 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 us discuss why we are building out our farm, and specifically why in this way. First, I could have built out this farm as a “Single Server Farm” and I could have achieved this with at least a 2 server outlay for Domain Controller/SQL box and a SharePoint box, I could have also done a Multi Server Farm with one Custom Min role with all features. I could have even taken it further out than I did 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, Proof of Concept (POC) endeavor, I would have done just that. So, here is my journey and I hope it provides some assistance to you in your efforts as well. This will be a two part blog, I don’t want to make it a TL;DR post so in this installment, I will be covering the Who, What, Where, Why, and How from a base level of installing the SharePoint Bits, basic configurations, some gotchas along the way. In the second installment, I will go over the configuration of Service Applications under the Min Role model more closely and the creation and inspection of Web Applications, Site Collections and all the new do-dahs of SharePoint 2016 Preview.

What you will [may] need before this endeavor

Clearly, as the blog post suggests, we are doing this in Azure, so the first thing you will need and an Azure subscription which you can get here and you can even get a free Trial here which gives you two hundred dollars $200 in Azure Credits to use. I will cover later on my experience (burn rate) of having my servers and workstation running for a time period that you may extrapolate what your cost ‘could’ be like. I also encourage you to have a read of this 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 where they can effectively communicate amongst each other. After you have looked at that, you may also want to review this one here as well “Test Lab Guide: Configure SharePoint Server 2013 in a Three-Tier Farm” as it will cover how I set up my farm. While the model expressed here is for a 3 tier farm, you can extend it for any number you need.


Updated 09/21/2015 – To be clear, when it comes to installing the bits for both SQL and SharePoint, I absolutely would advocate using PowerShell as it provides more granular configuration parameters, better naming of objects, and a repeatable process.  There are tons of examples out there, but the one I use most comes from these fine folks.

Download and Install SharePoint 2013 Prerequisites on Windows Server 2012 by Craig Lussier

AutoSPInstaller by Brian Lalancette

Manually Download and Install the Prerequisites for SharePoint 2016 by Patrick Curran

End Update

Installing SharePoint is a two-step process because of the dependency of the Database backend, in this case SQL Server. Now you can do 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 assumes that your SQL is up and running, all ports that need to be open for communications is 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, the things that you may notice or should pay attention to is the new Pre-Reqs that are being installed as part of SharePoint 2016 Preview. Most notably 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 the screen shot here


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 do 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 from below


and the rest of the list here


Of course when you are finished with the pre requisites, a restart is required, so do that and then 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, in my world here I have the following

· SPInstall

· SQLInstall

· SPFarm

· SQLsvc

· SPSvc

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


And when you are complete you will be prompted to run the Products Configuration Wizard (PSConfig.exe).


This (I term) pre-configuration 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. Also, at this point I will also do a RESTART and when I eventually LOGON to the servers again, I do so using the “SPFarm” account


After your fire up PSConfig and as in this case select “New Farm” the next step is where you configure your database settings. In this case, I am connecting to my SQL Box previously installed and configured and I am identifying the SPFarm account as the Database Access Account. In a prior step you gave SPFarm and SPAdmin if you elected to create an Admin account as well (following Best/Better Practices) the requisite permissions they need in the Security Section of SQL Server. 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.


So, 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 onwards 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, we have 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 part 2 of this series, its very easy to visually see if one of your defined server roles is out of compliance and it also gives you the ability with the “Check Mark”[1] in image below (that will turn red) and give you the ability to “Fix” as it says… any offending items that is “not in compliance”.


At time we are going to pause on this server and configure the other servers in the farm in their respective roles. Lets begin

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


And configuration of the roles, we cast to Custom, I am leaving custom just to see what types of services in “lit up” by default. I was just curious.


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, we don’t know yet what we will be putting on there, so that is reflective/analogous of what you had in SharePoint 2013 where you would have all the bits and pieces on all your servers and then you decided what services you want 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 user’s access. We will go over those finer points in Part 2.

Lessons Learned (Gotcha’s too)

Normally I would have done this all in PowerShell, but it would have been perhaps less visual, and I wanted to give that visual feel to this blog. As far as lessons learned for this part of the exercise, besides the upgraded Pre-Requisites, new Min Roles, and Enhanced Central Administration, its pretty much the same run of the mill installation of SharePoint from an Installer experience. There is obviously a lot more under the hood that we will explore in Part 2 by way of

· What’s Changed and How do you decide/administer/roll out the varied services (roles if you will) that you designated during configuration

· How different is User Profile Services now and what does Microsoft Identity Manager (MIM) give you now that FIM has gone by the way side.

· As this is Preview Bits, expect a few Gotchas. I tweeted one out around Search a while back which is noted as an issue by Microsoft, but that’s for part 2

What’s Next?

Part 2 – hyperlink pending.

Hope you learned something new here… Cheers.

Leave a comment

Your email address will not be published. Required fields are marked *

4 thoughts on “Setting up a SharePoint 2016 Preview Farm in Azure