On November 14th I had the pleasure of presenting as part of the SharePoint Saturday event in Edmonton. My presentation was on migrating from path-based site collections to host-named site collections and I was surprised at how many people were interested in the topic.
It was the first time I presented at a public event outside of Regina and I enjoyed the discussions that came up during the presentation and shortly after, as well as hearing about the scenarios people were encountering and how they were thinking of tacking the topic on their own.
A colleague of mine, Richard Egleston, presented in the same room after my presentation and he was talking about creating a SharePoint development environment in Azure. Richard mentioned that he had taken the scripts I had created for my own purposes and modified them a bit in creating his own environment. People that attended that session expressed interest in the scripts and related files, so I am linking to them here.
The scripts were built quickly after I had finished reading Automating Microsoft Azure Infrastructure Services, an excellent book by Michael Washam, and I used some of the PowerShell snippets from the book plus some additional logic to fit my purposes.
There are some enhancements that can be made to the scripts, such as extracting some of the variables and defining them as parameters to the script with default values. I plan on creating a new SharePoint development environment in Azure over the winter holidays and I will likely update the scripts at that time.
The environment that both Richard and I built consists of one AD controller (also DNS server), a SQL server and a SharePoint 2013 server.
The first file is NewVirtualNetworkConfig.xml and its purpose is to define the configuration for a virtual network in Azure. Each of the three servers is given a static IP address on the virtual network so that the servers can talk to each other. The XML file also configures what is the IP address of the DNS server on the network.
The second file is the AddVirtualNetwork.ps1 and it uses what is defined in the NewVirtualNetworkConfig.xml file to create any new virtual networks that do not already exist. The script is called from the third file I will be linking to, so it doesn’t need to be run on its own.
The third file is CreateSharePointDevVMs.ps1 and it has most of the logic for creating the environment. The script does the following:
- Creates an Azure cloud service in the East US region if it doesn’t already exist.
- Creates a locally redundant storage account, also in the East US region. Locally redundant storage helps cut the costs of running the environment.
- Creates the virtual network mentioned previously
- Creates three virtual machines using the newest image available in the “Windows Server 2012 R2 Datacenter” image family.
For each of the virtual machines it also defines how many disks to create. Depending on the VM size you choose, you can add anywhere from 1 to 16 additional data disks to the VM.
After the VMs are created, there is still work to be done, and that is to:
- Create storage spaces to span all of the additional disks added to each of the servers. From that storage space you’d create a single disk that spans the entire disk space available. What that does is pool the IOPS from all the disks together, achieving something similar to a software-based RAID 0 configuration.
- Configure the first server as a domain controller in a new domain
- Add the SQL and SharePoint servers to the same domain
- Create the service accounts and user accounts you’ll need on the AD server
- Install SQL server and configure it appropriately for SharePoint installations
- Install and configure SharePoint 2013. I personally used AutoSPInstaller for that, plus some custom scripts to install Workflow Manager and do some other setup to my liking.
Do you need a three server environment for SharePoint development? You could argue that you do not, and you could deploy everything on a single VM. I’ve done that before and I will probably do it again. Having said that, I do prefer to separate the AD, SQL and SharePoint services, each to its own VM as that is a closer setup to what you would have on a client deployment. Ultimately, it depends on what type of work you need to perform and test prior to deploying to non-development environments.