Detailed instructions/procedure for setting up a SharePoint 2016 development or test farm. This is a multi-part article. The following posts are part of this series:
- Part 1: Introduction
- This page – Part 2: Domain Controller
- Part 3: SQL Server
- Part 4: SharePoint 2016 Installation
In this article, we will be creating and configuring a new Azure virtual network and a domain controller. We will use Azure PowerShell.
Login to Azure
From Windows PowerShell, sign in to your Azure account using the following command:
A browser-like window will open requesting your Azure credentials. Enter them and sign in.
The following command will list the names of all your Azure subscriptions:
Get-AzureRMSubscription | Sort Name | Select Name
The output will be something like this:
Select the subscription you want to work with using the following commands:
$subscr="<subscription name>" Get-AzureRmSubscription -SubscriptionName $subscr | Select-AzureRmSubscription
For the $subscr variable above, replace everything inside the quotes with the name of the subscription you will be working with as was earlier displayed.
So in my case, the first of the above two commands could be something like this:
$subscr="Visual Studio Enterprise with MSDN (MPN)"
Create a resource group
Now, let’s create a resource group. We will put all the resources (VMs, etc.) associated with our SharePoint 2016 development environment inside this resource group.
You need to choose a new resource group name (one that you have not already used). This command will list the names of all your existing resource groups (if any).
Get-AzureRMResourceGroup | Sort ResourceGroupName | Select ResourceGroupName
If you’re new to Azure and haven’t added any resources or resource groups to your subscription yet, the above command will return nothing. Let’s name our resource group SP2016RGroup.
A note on Azure locations…
Before actually creating the resource group, now is a good time to decide which Azure location you want to use. Amongst other things, two of my main considerations when making this decision are: Pricing, and Service availability. Depending on your subscription, you may not even be able to deploy VMs in certain regions. I remember building a VM on top the cheapest location I could find sometime ago only to discover later that a service I needed (the Azure Recovery Services vault) was not supported in my chosen location. If I remember correctly, the location I originally chose was East US 2. As of this writing, I haven’t confirmed if Azure Recovery Services vault is NOW supported in the East US 2 region… My point is just that you should choose your location carefully to avoid wasting time and perhaps needing to redo some work.
Besides price and service availability, organizations may also want to consider other factors like Data residency and sovereignty and Customer compliance needs when choosing an Azure region.
For our SharePoint 2016 development environment, we will be working with the East US region.
Create the resource group with these three commands:
$rgName="SP2016RGroup" $locName="East US" New-AzureRMResourceGroup -Name $rgName -Location $locName
Now, if you have a look at the resource groups section in the Azure portal, you should should see something like this:
Create an Azure virtual network
Next, we will create the SP2016Vnet Azure Virtual Network that will host the SP2016Subnet subnet. Execute the following commands (enter the correct value you chose for your resource group name in the $rgName variable).
$rgName="SP2016RGroup" $locName=(Get-AzureRmResourceGroup -Name $rgName).Location $spSubnet=New-AzureRMVirtualNetworkSubnetConfig -Name SP2016Subnet -AddressPrefix 10.0.0.0/24 New-AzureRMVirtualNetwork -Name SP2016Vnet -ResourceGroupName $rgName -Location $locName -AddressPrefix 10.0.0.0/16 -Subnet $spSubnet -DNSServer 10.0.0.4
When you run that command (and some other commands in this series of articles), you may get a message like this:
WARNING: The output object type of this cmdlet will be modified in a future release.
Just ignore the message and continue.
From the Azure portal, in the all resources section, you should now see a new virtual network has been created:
Secure the virtual network with a security group
Let’s protect this virtual network with a security group. We will create two security rules (to allow web and RDP traffic to the network). We will then add the rules to a network security group. And then, we will apply the network security group to the virtual network we created above. Execute the following commands:
$rule1=New-AzureRMNetworkSecurityRuleConfig -Name "RDPTraffic" -Description "Allow RDP to all VMs on the subnet" -Access Allow -Protocol Tcp -Direction Inbound -Priority 100 -SourceAddressPrefix Internet -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 3389 $rule2 = New-AzureRMNetworkSecurityRuleConfig -Name "WebTraffic" -Description "Allow HTTP to the SharePoint server" -Access Allow -Protocol Tcp -Direction Inbound -Priority 101 -SourceAddressPrefix Internet -SourcePortRange * -DestinationAddressPrefix "10.0.0.6/32" -DestinationPortRange 80 New-AzureRMNetworkSecurityGroup -Name SP2016Subnet -ResourceGroupName $rgName -Location $locName -SecurityRules $rule1, $rule2 $vnet=Get-AzureRMVirtualNetwork -ResourceGroupName $rgName -Name SP2016Vnet $nsg=Get-AzureRMNetworkSecurityGroup -Name SP2016Subnet -ResourceGroupName $rgName Set-AzureRMVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name SP2016Subnet -AddressPrefix "10.0.0.0/24" -NetworkSecurityGroup $nsg
From the all resources section of your Azure portal, you should now see that a network security group has been added:
Create a managed availability set for domain controller virtual machines
We will now create a managed availability set inside of which we will eventually put our domain controller virtual machine. All our VMs in this article series (adVM, sqlVM, and spVM) will be put inside their individual availability sets. The purpose of this is to allow us to easily add new VMs to the current basic configuration if we ever decide to do this later.
Note that it is important for this availability set be a “managed” one, otherwise, we will receive an error later when attempting to create the VM. Our availability set is defined as “managed” by adding the -sku aligned flag in the command below.
If our availability set is not managed, the error we will get when trying to create the VM will look like this:
New-AzureRMVM : Addition of a VM with managed disks to non-managed Availability Set or addition of a VM with blob based disks to managed Availability Set is not supported. Please create an Availability Set with ‘Aligned’ SKU in order to add a VM with managed disks to it.
Create the availability set with the following command lines:
$rgName="SP2016RGroup" $locName=(Get-AzureRmResourceGroup -Name $rgName).Location New-AzureRMAvailabilitySet -Name dcAvailabilitySet -ResourceGroupName $rgName -Location $locName -sku aligned -PlatformFaultDomainCount 2 -PlatformUpdateDomainCount 2
I’m not too sure what the purpose of these two flags are:
-PlatformFaultDomainCount 2 and -PlatformUpdateDomainCount 2
However, once you set the -sku aligned flag, the -PlatformFaultDomainCount flag becomes mandatory. So I borrowed their usage from here: How to use availability sets.
Prepare to create the domain controller virtual machine
At this point, we will define all of the configuration settings that we want for the domain controller virtual machine and save them in variables. We will also perform other preliminary tasks like creating a dynamic IP address, adding a disk drive, etc.
When you run the Get-Credential command (part of the next block of code below), you will be prompted for a user name and password. Let’s refer to this user name as ADM_NAME. Use a strong password. The password that you specify cannot be “[email protected]”. It must be between 8-123 characters long and must satisfy at least 3 of the following password complexity requirements:
- Contains an uppercase letter
- Contains an lowercase letter
- Contains a numeric digit
- Contains a special character
Execute this block of code after creating the availability set (same PowerShell session):
$vmName="adVM" $vmSize="Standard_D1_v2" $vnet=Get-AzureRMVirtualNetwork -Name SP2016Vnet -ResourceGroupName $rgName $pip = New-AzureRMPublicIpAddress -Name ($vmName + "-PIP") -ResourceGroupName $rgName -Location $locName -AllocationMethod Dynamic $nic = New-AzureRMNetworkInterface -Name ($vmName + "-NIC") -ResourceGroupName $rgName -Location $locName -SubnetId $vnet.Subnets.Id -PublicIpAddressId $pip.Id -PrivateIpAddress 10.0.0.4 $avSet=Get-AzureRMAvailabilitySet -Name dcAvailabilitySet -ResourceGroupName $rgName $vm=New-AzureRMVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetId $avSet.Id $vm=Set-AzureRmVMOSDisk -VM $vm -Name ($vmName +"-OS") -DiskSizeInGB 128 -CreateOption FromImage -StorageAccountType "StandardLRS" $diskConfig=New-AzureRmDiskConfig -AccountType "StandardLRS" -Location $locName -CreateOption Empty -DiskSizeGB 20 $dataDisk1=New-AzureRmDisk -DiskName ($vmName + "-DataDisk1") -Disk $diskConfig -ResourceGroupName $rgName $vm=Add-AzureRmVMDataDisk -VM $vm -Name ($vmName + "-DataDisk1") -CreateOption Attach -ManagedDiskId $dataDisk1.Id -Lun 1 $cred=Get-Credential -Message "Type the name and password of the local administrator account for adVM." $vm=Set-AzureRMVMOperatingSystem -VM $vm -Windows -ComputerName adVM -Credential $cred -ProvisionVMAgent -EnableAutoUpdate $vm=Set-AzureRMVMSourceImage -VM $vm -PublisherName MicrosoftWindowsServer -Offer WindowsServer -Skus 2012-R2-Datacenter -Version "latest" $vm=Add-AzureRMVMNetworkInterface -VM $vm -Id $nic.Id
Among other things, the above block of commands accomplishes the following:
- Sets the virtual machine name.
- Sets the virtual machine size. We will be using the Standard_D1_v2 VM size.
- Creates a new dynamically allocated public IP address. We will be using dynamic IP addresses for all the VMs in our development environment. This saves a little cost, but we will be doing without the extra benefits of working with static IP addresses (since this is only a development farm, we should be fine). Microsoft has some official information here on IP address types and allocation methods in Azure.
- Allocate a disk drive for use with our VM.
- Sets the administrator’s user name and password.
- Sets the desired operating system SKU to 2012-R2-Datacenter.
Create the domain controller virtual machine (adVM)
Next, we create the adVM virtual machine in Azure. adVM will be a domain controller for the sp.ehikioya.com Windows Server Active Directory (AD) domain and a DNS server for all the virtual machines of the SP2016Vnet virtual network. Of course, you would want to choose your own custom domain name instead of sp.ehikioya.com.
Run this command:
New-AzureRMVM -ResourceGroupName $rgName -Location $locName -VM $vm
You may get this warning:
WARNING: Since the VM is created using premium storage, new standard storage account, visuasp2016advm012215490, is created for boot diagnostics.
It can take a few minutes for Azure to build the virtual machine. If the process succeeds, you should see a message like this:
Let’s go back to the Azure portal and view all the new resources that we have added/configured programmatically:
Connect to the new VM via RDP
Once the virtual machine has been built, use these steps to connect to it using the local administrator account credentials which you set in the previous step:
In the Azure portal, go to Resource Groups, select the name of your resource group, select adVM and press Connect.
A file named adVM.rdp will be downloaded.
Run the downloaded file. If prompted, click Connect.
In Windows Security, enter the user name as adVM\<ADM_NAME>
In Password, type the password of the ADM_NAME account, and then click OK. If prompted, click Yes.
Configure adVM as a domain controller
First, add an extra data disk as a new volume with the drive letter E:
Run this command at an administrator-level Windows PowerShell command prompt (inside of your RDP session on adVM).
Get-Disk | Where PartitionStyle -eq "RAW" | Initialize-Disk -PartitionStyle GPT -PassThru | New-Partition -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem NTFS -NewFileSystemLabel "WSAD Data"
You will get a prompt like this:
Confirm Are you sure you want to perform this action? Warning, all data on the volume will be lost! [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):
Answer Yes. The new E: drive will be formatted.
You may also get a Windows Explorer prompt to format the E: drive. You can ignore (cancel) that.
Now, to actually configure adVM as a domain controller and DNS server for the sp.ehikioya.com domain, run these commands at an administrator-level Windows PowerShell command prompt on adVM.
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools Install-ADDSForest -DomainName sp.ehikioya.com -DatabasePath "E:\NTDS" -SysvolPath "E:\SYSVOL" -LogPath "E:\Logs"
These commands may take a few minutes to complete. The machine may also restart. The output of the first command should look like:
When you run the second command, you will be prompted to enter and confirm the SafeModeAdministratorPassword. You will also get a prompt like this:
The target server will be configured as a domain controller and restarted when this operation is complete. Do you want to continue with this operation? [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):
This will start the process of promoting adVM to a domain controller. Quite a few warnings may be generated. Ignore them. The machine will restart automatically.
Connect to the domain controller virtual machine using domain credentials
After adVM restarts, re-run the adVM.rdp file. But this time, in Windows security, press “use a different account” and use the following user name SP\<ADM_NAME>
The value “SP” depends on your domain name. Remember that mine was sp.ehikioya.com.
In Password, type the password of the ADM_NAME account, and then click OK. When prompted, click Yes.
Additional domain controller configuration
From the desktop on adVM, open an administrator-level Windows PowerShell command prompt and run the following commands:
Add-WindowsFeature RSAT-ADDS-Tools New-ADUser -SamAccountName sp_farm_db -AccountPassword (read-host "Set user password" -assecurestring) -name "sp_farm_db" -enabled $true -PasswordNeverExpires $true -ChangePasswordAtLogon $false
The first command will add Remote Server Administration Tools to adVM.
The next command just creates a farm database active directory account (sp_farm_db) which we will use later. You will again be prompted to enter a password. If this is a personal development environment, it might be safe to just use the same password for all the user accounts across the board.
This concludes our setup and configuration of the domain controller part of our SharePoint 2016 development farm. Let’s proceed to setting up the SQL server machine.
Since most of the information in this article also applies to the next two articles (they all involve VM setup and config), I will be omitting some details in the next two articles since I have already covered them here. But of course shoot me a question in the comments section if anything is unclear.
Continue reading this series: Setting up a SharePoint 2016 development farm in Azure – Part 3: SQL Server