Hmm… Where to start? It’s been so long since i wrote my last blog post so I forgot what I used to use for intro paragraphs.. Maybe i should say “Long time, no blogging..”
Anyway, back to our topic.. Recently i was working on a SharePoint 2013 environment setup, where you do the classics, such as provisioning DEV, QA, and PROD environments. It was a very sophisticated piece of hardware where I was using vSphere 5 to manage the hosts, VMs, LUNs, etc. It was an amazing learning curve for me and made me realize once again while working with SharePoint at the application layer, actually how much we are missing or taking things granted happening on the infrastructure level.
Ok, enough powder puff.. This time really back to our topic.. In this post, I’ll try to walk you guys through a scenario where we’ll try to deploy/configure a 3-Tier SharePoint 2013 farm in an unattended-automated-parallel fashion. So what does that really mean? Sounds like a sales quote, but actually it’s really possible. I could even exaggerate it a little by saying “almost one-click“, but i won’t go that far for now. My intention is to showcase a scenario as follows:
- 2 DB server, 2 APP servers, 2 WFEs
- OS: Windows Server 2012
- DB: SQL Server 2012 SP1 Enterprise
- DB servers are clustered (if not we can get there in the following posts)
- SQL Server 2012 AlwaysOn will also be used for HA and DR
- AutoSPInstaller will be used for parallel automated installation
- Getting this to work error-free with your environment is most of the work, believe me. By now, I think i know thousand ways of not building a SharePoint farm properly.
Preparing Topology for Automated Deployment
It’s important to mention that AutoSPInstaller won’t do all the magic for you, although it’ll handle most of it quite smoothly. One of the first things to do is to prepare your topology accordingly so that AutoSPInstaller can run error-free. At this point, assuming that your servers will be hosted by VMs, we need to get all servers – DBs, Apps, WFEs – to a point that all prerequisites are installed and configured properly, before running the automated parallel deployment scripts. This is also the time you get a snapshot of all servers and maybe call it “Starting Image”. This will allow you to go back and launch the installer again and again w/o worrying about preparing the servers from scratch.
Preparing OS Template
For production environment, chances are your DBs will be clustered. For my setup, I also took advantage of SQL Server 2012 AlwaysOn Availability Groups. Will also try to give details on that in another post. But for now, here is how DBs look like:
|Disable Enhanced Security Configuration. (scripted)|
|Disable the Windows Firewall. (scripted)|
|Enable Remote Desktop for your VM. (scripted)|
|Configure the local Administrator account so the password never expires. (scripted)|
|NOTE: Detailed instructions are here: Preparing.Servers|
|(Optional) Configure the Windows Update settings.|
|(Optional) If you have a Windows Server 2012 product key, activate the Windows operating system.|
Here is the “Preparing OS-Template” PowerShell script: Preparing.OS.Template
Also make sure that .NET Framework 3.5.1 is installed. To do this run the following command using PowerShell:
dism.exe /online /enable-feature /all /featurename:NetFX3 /Source:D:\sources\sxs
Above first four PowerShell scripted steps should be good to go to prepare our OS-Template VM. Optionally you can configure Windows Update settings and activate the Windows OS. Once done, take a snapshot of this VM and call it “OS-Template“. Going forward this will be our first base and any other VM templates will be cloned from this one, such as DB-Template or SP-Template.
Preparing DB Template
Now that you have your OS-Template snapshot, you can easily convert it into a template VM. Here is a quick definition of what a VM Template is.
Go ahead and spin another VM using OS-Template. This will be your DB-Template VM.
Now you can install SQL Server 2012 SP1. Feel free to install with default settings either using UI or unattended installation. SQL Server 2012 AlwaysOn does not require SQL instances to be clustered, so when we configure AlwaysOn in the following posts, default instances will work just fine.
Note that still this VM is not joined to the domain, no service account are created, …etc since currently we are just configuring individual VM templates. Once we clone from these templates to create our 3-tier farm topology, then all VMs will be joined to the domain, we are not there yet..
|Configure the Named Pipes protocol using the SQL Server Configuration Manager.|
|Max. Degree of Parallelism set to 1.|
Above is just a couple of items to set before we save this VM as our DB-Template. Once they are done, shut down your VM and take a snapshot called “DB-Template“.
Now, we are done with our DB-Template. Go ahead and convert this snapshot to VM Template and spin 2 DB VMs from it. Those identical DB VMs will be our DB1 and DB2 servers of our topology.
Preparing SharePoint 2013 Template
Using the first OS-Template we created, spin another VM which will be configured as SharePoint template. Both App servers and WFEs will be cloned using this template. Here the idea is to install in advance:
- SharePoint prerequisites
- SharePoint binaries
- SharePoint Cumulative Updates and hotfixes
We’ll use AutoSPInstaller to take care of it, simply with one-click. Now it’s time to jump to AutoSPInstaller topic and see how to structure it. Here i’m not gonna go into details of Input.xml and its options. Simply i’m trying to get above installed to create a template. Remember, we are not deploying and configuring the farm now. We are just trying to get SP binaries installed.
We could have easily left this part to AutoSPInstaller while performing parallel installation but believe me, the amount of time you’ll save by doing this in advance is simply priceless.
You can get AutoSPInstaller from CodePlex: http://autospinstaller.codeplex.com/
1. Copy SharePoint binaries under SharePoint folder.
2. Copy all the prerequisites installer files under PrerequisiteInstallerFiles folder under SharePoint folder.
In order to download the following prerequisite installer files, you can use the script provided below. Once you download these files, simply copy them to your AutoSPInstaller directory shown below.
3. Copy .Net Framework 3.5 installer under sxs folder.
At this point we are almost ready to run AutoSPInstaller to install the binaries. But we need to add this VM to domain now to run AutoSPInstaller. I’ll explain the details of it later. But for now we just want to get binaries installed.
AutoSPInstaller will install all prerequisites, SharePoint 2013 binaries and updates as shown above. Then, it’ll ask you if you want to proceed with farm deployment. Since we are building SP-Template VM right now, we’ll stop here, shut down our VM and take a snapshot, call it “SP-Template“.
Milestone – Topology Template VMs are ready!
Let’s step back for a moment and see what we’ve done so far. Until this point we simply:
Created 3 Template Virtual Machines:
- OS-Template (Base Template)
- Windows Server 2012 Standard
- SQL Server 2012 SP1 Enterprise installed
- SharePoint 2013 Enterprise installed, not configured
You can see the above activity performed as your investment for your SharePoint infrastructure. Regardless of how many farms you provision, such as DEV, QA, PROD; now you can use these templates to clone your VMs from.
Provisioning the Production Environment Topology
Now, we are ready to provision our PROD environment. All you have to do now, is to spin:
- 2 VMS from DB-Template
- 4 VMs from SP-Template (2 App Server and 2 WFEs)
Once you create your VM instances, make sure you add them to your domain, setup local admin passowords, and now you are good to go for the next part, which is indeed where the real action happens – parallel remote SharePoint 2013 farm deployment and configuration.
Before we go back and start talking on how to prepare AutoSPInstaller setup for our topology, let’s figure out our logical architecture and naming conventions.
xxxxPRDB001 and xxxxPRDB002
xxxxPRAP001 and xxxxPRAP002
xxxxPRSP001 and xxxxPRSP002
Your naming convention might be different based on your organizational needs. For the rest of the article i’ll refer to above computer names.
Also we need a set of Service Accounts to be created in advance. Those are 2 SQL Server service accounts (sp13prodsqlagent and sp13prodsqlengine) and SharePoint Service accounts as follows.
Adapt AutoSPInstallerInput.XML to your topology
AutoSPInstallerInput.xml file is the heart of farm provisioning and configuration. Once you launch AutoSPInstallerLaunch, it will use this input file to figure out the servers in the topology, which servers have which roles (app or wfe), which server will host central admin, search components, web sites, …etc.
When I was going through this exercise, it took me quite sometime to really understand which attributes to use and how to use them, for an effective 3-tier farm deployment. So, I’ll try to document here as much as i can with the details.
First let’s take a look at root attributes:
Things you need to update
- Install SPVersion
- PIDKey – provide your own SharePoint 2013 license key
- AutoAdminLogon Password – provide your SharePoint Setup Account password here. This is the account which will be used to login when server is restarted. Local Admin on all servers, possibly a domain administrator account.
- Passphrase – provide your own SharePoint farm passphrase
- Domain Name – In username attributes, provide your own domain name. Ex: <Username>MyDOMAIN\SP_Farm</Username>
- CentralAdmin Provision – provide computernames of your SharePoint WFEs. Ex: xxxxPRSP001 and xxxxPRSP002. Note that there is only space between computernames. No comas, no semi-columns.
- Database DBServer – provide the alias for your SharePoint instance. Regardless if they are clustered or not, use db alias here. In my case, I enabled SQL Server 2012 AlwaysOn Availability Groups, so I have SP13-AGAP, which my availability group’s access point, which is on port 2001. More to come on that..
- Domain Name – In attributes, provide your own domain name.
- This is where we identify Service Apps Topology. i.e. this is the critical part where we defined which service apps will be provisioned on which servers, such as AppServer1, AppServer2. By default, i’m provisioning all service apps on both AppServers named as PRAP001 and PRAP002.
- Provision – replace server names with your own app server computer names.
- StartProfileSync – Note that we are also starting User Profile Synchronization Service. I know, it’s like magic, ain’t it? But best part is – it works!
- CreateDefaultSyncConnection – this is set to true. We are also creating the a sync connection. For that don’t forget to give appropriate AD permissions to SP_UPS account and provide its password.
Before moving to next attribute, it might be good to pause a little here and pay some attention to Enterprise Search Topology settings. You can define which app servers, wfes will run which Search components such as:
Search Query and Site Settings
Content Processing component
Analytics Processing component
- Excel Services Provision – replace server names with your own app server computer names.
- Other Enterprise Service Apps are not provisioned as for this example. If you decide to provision them as well, just make sure that you create their dedicated service account in advance.
Of course, you don’t need to worry about every single option of this input xml. I just wanted to give some insights to it. I prepared a template input xml which can be tailored to your topology easily. You can get AutoSPInstallerInput-TEMPLATE.xml here: AutoSPInstallerInput-TEMPLATE.XML
I also prepared a little cmd to be used with FNR tool (find and replace tool, which you can find on CodePlex here). This will help to replace the correct parameters.
AutoSPInstallerInput.FNR.cmd here: AutoSPInstallerInput.FNR
Now it’s time to recap.. Let’s see where we are at now with automation, deployment, and identify what the gaps are to get this environment PROD ready.
So far, we have 3 VM Templates and 6 Servers (2 DB, 2 App, 2 WFE) as shown below, where all 4 SharePoint 2013 Servers were deployed and configured remotely.
In the next post, I’ll try to show how to configure SQL Server 2012 AlwaysOn Availability Groups from SharePoint 2013 content and admin databases.