Deploy a SharePoint 2016 Standalone VM in Azure using PowerShell Desired State Configuration (DSC)

In the PowerShell Desired State Configuration (DSC) world, you really have two options when it comes down to configuring a machine. You can either use Push mode to manually “push” a DSC script into a machine’s Local Configuration Manager (LCM) memory, or use a Pull Server and connect your machine to it and let them obtain their DSC script themselves. In the Azure world, we have something called “Azure Automation DSC” which is effectively a PowerShell Desired State Configuration Pull Server in the cloud, managed as “Software-as-a-Service” (SaaS). With Azure Automation DSC, you can manage both on-premises and Azure VMs by having them connect back to your Azure Automation Account as if it was just a regular DSC Pull Server.

In this article, we will go through the process of setting up a SharePoint 2016 Standalone Virtual Machine using nothing but Azure Automation DSC. The idea is for people to easily create SharePoint Development machines in Azure Infrastructure-as-a-Service (IaaS).

The Scenario

In Azure IaaS I already have setup two VMs:

• SPTechCon-DC is a Windows Server 2016 VM acting as a Domain Controller for the contoso.com domain.
• SPTechCon-Share is a Windows Server 2016 VM that acts as a File Share, where I have the installation media for both SQL Server 2016 Enterprise and SharePoint Server 2016. These two shares are exposed at:
  • \\SPTechCon-Share\Share\SQL2016Media\
  • \\SPTechCon-Share\Share\SP2016Media

The Process

By following the following steps in order you will be able to deploy a new Windows Server 2016 VM in Azure IaaS, have it automatically join the contoso.com domain, and install both SQL Server 2016 and SharePoint 2016 on it. By the end of this process, you will have a fully functioning SharePoint 2016 development VM that you can simply go and install Visual Studio 2017 on to use as you main development environment for developers within your enterprise. This process is completely reusable, and can help your enterprise ensure your development team all have VMs with a configuration that matches your production environment.

1 – Create a new VM

In this article, this is the only manual process. Off course this could be automated, by for this example here, I will leave it up to you to decide how you wish to create your VM. In my case, I will be creating my VM with the following specs:

• Name: SPTechCon-Share
• OS Version: Windows Server 2016 Datacenter
• Memory: 7Gb of RAM
• CPU: 2 cores

To create the VM, start by selecting Windows Server as you Template category.

From the following screen, I select Windows Server 2016 Data Center.

Make sure you select Resource Manager as your deployment model and click Create

Fill in all the mandatory information, give your machine a meaningful name and make sure you create it as part of the same resource group where your Domain Controller and File Share servers are. Click OK.

Choose an appropriate VM size for your environment. In my case, I use a DS11_V2 Standard size. Click Select.

Leave out the default values on the Settings screen. Click OK.

Review the details for your machine. Click OK.

Wait a few minutes until you receive notification that the VM was successfully provisioned.

2 – Create a New Azure Automation Account

Remember we mentioned that Azure Automation is somewhat a DSC Pull Server in the Cloud. What we need to do next is create an instance of an Azure Automation Account to manage our DSC configurations. Azure Automation Accounts are available in the marketplace. Simply do a search for Azure Automation to find and select it.

Click on it to select it from the marketplace and then click Create.

Give your Azure Automation Account a name, make sure you select the same Resource Group as all the VMs we have created so far in this demo. Click Create.

The Azure Automation Account creation process is almost instantaneous, it should only take a few seconds to get created.

Review the Desired State Configuration Script

To configure our Standalone SharePoint box, we will be using the following PowerShell Desired State Configuration (DSC) script. I strongly encourage you quickly read through it an try to understand what is really happening under the covers. This below, is the complete script.

Configuration SharePoint2016StandAlone
{
    param(
        [String]$ParamDomain,
        [String]$ParamInternalDomainControllerIP,
        [String]$ParamMachineName,
        [String]$ParamProductKey,
        [String]$ParamUsername,
        [String]$ParamPassword,
        [String]$ParamShareName
	)

    Import-DSCResource -ModuleName xDSCDomainJoin
    Import-DSCResource -ModuleName xNetworking
    Import-DSCResource -ModuleName SharePointDSC
    Import-DSCResource -ModuleName xSQLServer    

    $secdomainpasswd = ConvertTo-SecureString $ParamPassword -AsPlainText -Force
    $ParamCredsJoindomain = New-Object System.Management.Automation.PSCredential($ParamUsername, $secdomainpasswd)

    Node $ParamMachineName
    {
        xFireWall SQLFirewallRule
        {
            Name = "AllowSQLConnection"
            DisplayName = 'Allow SQL Connection'
            Group = 'DSC Configuration Rules'
            Ensure = 'Present'
            Enabled = 'True'
            Profile = ('Domain')
            Direction = 'InBound'
            LocalPort = ('1433')
            Protocol = 'TCP'
            Description = 'Firewall Rule to allow SQL communication'
        }

        xDNSServerAddress DNS
        {
            Address = $ParamInternalDomainControllerIP
            AddressFamily = "IPv4"
            InterfaceAlias = "Ethernet 2"
        }

        xDSCDomainJoin Join
        {
            Domain = $ParamDomain
            Credential = $ParamCredsJoindomain
            DependsOn = "[xDNSServerAddress]DNS"
        }		

        xSQLServerSetup SQLSetup
        {
            SetupCredential = $ParamCredsJoindomain
            InstanceName = "MSSQLServer"
            SourcePath = "\\$ParamShareName\Share\SQL2016Media\"
            Features = "SQLENGINE,FULLTEXT,RS,AS,IS"
            InstallSharedDir = "C:\Program Files\Microsoft SQL Server"
            SQLSysAdminAccounts = $ParamCredsJoindomain.UserName
            DependsOn = "[xDSCDomainJoin]Join"
        }

        SPInstallPrereqs SP2016Prereqs
        {
            InstallerPath = "\\$ParamShareName\Share\SP2016Media\prerequisiteinstaller.exe"
            OnlineMode = $true
            DependsOn = "[xSQLServerSetup]SQLSetup"
        }

        SPInstall InstallSharePoint
        {
             Ensure = "Present"
             BinaryDir = "\\$ParamShareName\Share\SP2016Media\"
             ProductKey = $ParamProductKey
             DependsOn = @("[SPInstallPrereqs]SP2016Prereqs", "[xFirewall]SQLFirewallRule")
        } 

        SPCreateFarm CreateSPFarm
        {
            DatabaseServer           = $ParamMachineName
            FarmConfigDatabaseName   = "SP_Config"
            Passphrase               = $ParamCredsJoindomain
            FarmAccount              = $ParamCredsJoindomain
            AdminContentDatabaseName = "SP_AdminContent"
            PsDSCRunAsCredential     = $ParamCredsJoindomain
            ServerRole               = "SingleServerFarm"
            CentralAdministrationPort = 7777
            DependsOn                = "[SPInstall]InstallSharePoint"
        }

        SPManagedAccount FarmAccount
        {
            AccountName = $ParamCredsJoindomain.UserName
            Account = $ParamCredsJoindomain
            PsDSCRunAsCredential = $ParamCredsJoindomain
            DependsOn = "[SPCreateFarm]CreateSPFarm"
        }

        SPServiceAppPool SharePoint80
        {
            Name = "SharePoint - 80"
            ServiceAccount = $ParamCredsJoinDomain.UserName
            PsDSCRunAsCredential = $ParamCredsJoindomain
            DependsOn = "[SPManagedAccount]FarmAccount"
        }

        SPWebApplication RootWebApp
        {
            Name = "RootWebApp"
            ApplicationPool = "SharePoint - 80"
            ApplicationPoolAccount = $ParamCredsJoinDomain.UserName
            Url = "http://$ParamMachineName"
            DatabaseServer = $ParamMachineName
            DatabaseName = "WebApp-SharePoint-80"
            Port = 80
            PsDSCRunAsCredential = $ParamCredsJoinDomain
            DependsOn = "[SPServiceAppPool]SharePoint80"
        }

        SPSite RootSite
        {
            Url = "http://$ParamMachineName"
            OwnerAlias = $ParamCredsJoinDomain.UserName
            Template = "STS#0"
            PsDSCRunAsCredential = $ParamCredsJoinDomain
            DependsOn = "[SPWebApplication]RootWebApp"
        }
    }
}

Let’s take a closer look at what the script actually defines. Note that the Configuration script actually expects 7 parameters to be passed at compilation time. These parameters are:



Parameter Name
Value
Description


ParamDomain
contoso.com
Specifies the domain name that our machine will be joining.


ParamInternalDomainControllerIP
10.0.10.5
Internal IP address of our Domain Controller VM. (Note that this will likely differ for you).


ParamMachineName
SPTechCon-SA
Name of the Azure VM we created at Step 1 above.


ParamProductKey
XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
Your own SharePoint 2016 (Standard or Enterprise) Product Key.


ParamUsername
contoso\sp_farm
Username for your SharePoint Farm Account.


ParamPassword
pass@word1
Password for the SharePoint Farm Account used.


ParamShareName
SPTechCon-Share
Name of the File Share VM.



We will now break down each resource block an give you a quick overview of what it actually does.
The following creates a Domain Firewall rule on port 1433, to allow connections to our SQL Server (in our case hosted on the local machine) in case we wished to add more servers to our farm.
[cc language="PowerShell"]
xFireWall SQLFirewallRule
{
    Name = "AllowSQLConnection"
    DisplayName = 'Allow SQL Connection'
    Group = 'DSC Configuration Rules'
    Ensure = 'Present'
    Enabled = 'True'
    Profile = ('Domain')
    Direction = 'InBound'
    LocalPort = ('1433')
    Protocol = 'TCP'
    Description = 'Firewall Rule to allow SQL communication'
}
[/cc]
This block changes the DNS Server IP address to point to our domain controller.

[cc language=”PowerShell”]

xDNSServerAddress DNS

{

Address = $ParamInternalDomainControllerIP

AddressFamily = “IPv4”

InterfaceAlias = “Ethernet 2”

}

[/cc]

The following joins the machine to the contoso.com domain.
[cc language="PowerShell"]
xDSCDomainJoin Join
{
    Domain = $ParamDomain
    Credential = $ParamCredsJoindomain
    DependsOn = "[xDNSServerAddress]DNS"
}
[/cc]
This block installs SQL Server 2016 from our Shared Media Installation location.
[cc language="PowerShell"]
xSQLServerSetup SQLSetup
{
    SetupCredential = $ParamCredsJoindomain
    InstanceName = "MSSQLServer"
    SourcePath = "\\$ParamShareName\Share\SQL2016Media\"
    Features = "SQLENGINE,FULLTEXT,RS,AS,IS"
    InstallSharedDir = "C:\Program Files\Microsoft SQL Server"
    SQLSysAdminAccounts = $ParamCredsJoindomain.UserName
    DependsOn = "[xDSCDomainJoin]Join"
}
[/cc]
This block installs the SharePoint 2016 pre-requisites. The server will automatically reboot itself once it reaches that step and will automatically resume the DSC configuration process.
[cc language="PowerShell"]
SPInstallPrereqs SP2016Prereqs
{
    InstallerPath = "\\$ParamShareName\Share\SP2016Media\prerequisiteinstaller.exe"
    OnlineMode = $true
    DependsOn = "[xSQLServerSetup]SQLSetup"
}
[/cc]
This block installs the actual SharePoint 2016 bits on the machine.
[cc language="PowerShell"]
SPInstall InstallSharePoint
{
    Ensure = "Present"
    BinaryDir = "\\$ParamShareName\Share\SP2016Media\"
    ProductKey = $ParamProductKey
    DependsOn = @("[SPInstallPrereqs]SP2016Prereqs", "[xFirewall]SQLFirewallRule")
}
[/cc]
This block creates the SharePoint Farm. Think of it as being the equivalent of running PSConfig.
[cc language="PowerShell"]
SPCreateFarm CreateSPFarm
{
    DatabaseServer           = $ParamMachineName
    FarmConfigDatabaseName   = "SP_Config"
    Passphrase               = $ParamCredsJoindomain
    FarmAccount              = $ParamCredsJoindomain
    AdminContentDatabaseName = "SP_AdminContent"
    PsDSCRunAsCredential     = $ParamCredsJoindomain
    ServerRole               = "SingleServerFarm"
    CentralAdministrationPort = 7777
    DependsOn = "[SPInstall]InstallSharePoint"
}
[/cc]
This block creates a SharePoint Managed Account for our farm admin.
[cc language="PowerShell"]
SPManagedAccount FarmAccount
{
    AccountName = $ParamCredsJoindomain.UserName
    Account = $ParamCredsJoindomain
    PsDSCRunAsCredential     = $ParamCredsJoindomain
    DependsOn = "[SPCreateFarm]CreateSPFarm"
}
[/cc]
This block creates a SharePoint Application Pool for our Web Application to be.
[cc language="PowerShell"]
SPServiceAppPool SharePoint80
{
    Name = "SharePoint - 80";
    ServiceAccount = $ParamCredsJoinDomain.UserName
    PsDSCRunAsCredential     = $ParamCredsJoindomain
    DependsOn = "[SPManagedAccount]FarmAccount";
}
[/cc]
this block should be self explanatory. It creates a SharePoint Web Application on port 80.
[cc language="PowerShell"]
SPWebApplication RootWebApp
{
    Name = "RootWebApp"
    ApplicationPool = "SharePoint - 80"
    ApplicationPoolAccount = $ParamCredsJoinDomain.UserName
    Url = "http://$ParamMachineName"
    DatabaseServer = $ParamMachineName
    DatabaseName = "WebApp-SharePoint-80"
    Port = 80
    PsDSCRunAsCredential = $ParamCredsJoinDomain
    DependsOn = "[SPServiceAppPool]SharePoint80"
}
[/cc]ode]
This last block simply creates a Site Collection at the root of our Web Application.

[cc language=”PowerShell”]

SPSite RootSite

{

Url = “http://$ParamMachineName”

OwnerAlias = $ParamCredsJoinDomain.UserName

Template = “STS#0”

PsDSCRunAsCredential = $ParamCredsJoinDomain

DependsOn = “[SPWebApplication]RootWebApp”

}

[/cc]

What we need to do now, is upload this DSC configuration into our Azure Automation Account. To do this, start by navigating to your Automation Account and click on DSC Configurations.

Click on Add a configuration.

Click on the folder icon and browse to the .ps1 script above. Note that you will need to copy the complete script and save it locally first. Click on OK.

Our DSC Configuration Script is now in the Cloud, contained within our Azure Automation Account.
4 – Import the Required DSC Module
If you paid close attention to our full script above, you’ve realized that it needs to import 4 different DSC modules:

xDSCDomainJoin
xNetworking
SharePointDSC
xSQLServer

However, by default Azure Automation knows nothing about these modules. We need to import them first for Azure Automation to be able to properly configure our servers. Think of this as being the equivalent of putting the required modules and resources on a Pull Server for your registered nodes to consume (in an on-premises type of scenario). To import a resource, you need to go back to the main Azure Automation screen and click on Assets.

On the next screen, select Modules.

From here we have two choices: upload the required resources as individual .zip files from our local machine, or Import them from the PowerShellGallery.com repository. In my case, I choose to import them from the gallery, therefore I need to click on Browse gallery.

In the search box, type in the name of the first module we are trying to import: xDSCDomainJoin. Select the proper module from the search results by clicking on it.

To finalize the import process, click on the Import icon.

On the next screen, simply click OK.

Repeat the same import process with the remaining missing modules: xNetworking, SharePointDSC, and xSQLServer.
5 – Initiate Compilation Job
In an on-premises scenario, you need to call the Configuration keyword of your DSC script in order for it to get “compiled” as a .MOF file. In Azure Automation, this is normally done by clicking on your DSC Configuration (uploaded at Step 3 above), and by clicking on Compile. However, in our case, we have credentials that need to be passed to our configuration. Therefore, instead of manually initiating the compilation job from the Azure Portal, we will use a local PowerShell script to remotely initiate the compilation job, allowing us to pass in parameters.
We will be using the following PowerShell script to remotely initiate that compilation job. Note that these are all the parameters we mentioned previously that are simply passed up to my Azure Automation Account.

[cc language=”PowerShell”]

$ProductKey = Read-Host “Please enter your SharePoint 2016 Product Key”

$MachineName = “SPTechCon-SA”

$ConfigData = @{

AllNodes = @(

@{

NodeName = $MachineName

PSDscAllowPlainTextPassword = $True

}

)

}
$Parameters = @{

ParamDomain = “contoso.com”

ParamInternalDomainControllerIP = “10.0.10.5”

ParamMachineName= $MachineName

ParamProductKey = $ProductKey

ParamUsername = “contoso\sp_farm”

ParamPassword = “pass@word1″

ParamShareName =”SPTechCon-Share”

}
Login-AzureRMAccount

Start-AzureRmAutomationDscCompilationJob -ResourceGroupName “SPTechCon” -AutomationAccountName “SPTechCon-Automation” -ConfigurationName “SharePoint2016StandAlone” -ConfigurationData $ConfigData -Parameters $Parameters
[/cc]

Upon executing this script, you will get prompted to enter your Azure Credentials, which you’ll need to do in order for the compilation jo to get queued up.

The script should only take a second or two to execute and will automatically initiate a compilation job in Azure.

Give Azure about5 minutes to initiate and finalize the compilation. Once the job has completed, the compilation status will get updated to Completed.

6 – Register a DSC Node
If we recap what we have done so far, we started off by creating a new Azure IaaS VM that we wish to configure as a SharePoint 2016 Standalone development machine. We have then wrote the Desired State Configuration script for it, and have uploaded and compiled it into Azure. Now what we need to do is actually associate the VM we created with the DSC script we’ve uploaded. To do this, you need to go back to your Azure Automation’s account main page, and this time click on DSC Nodes.

Azure Automation gives you the option of managing both Azure and on-premises Virtual Machines. On-premises Virtual Machines will be covered in another article, when time permits. In our case we want to register an existing Azure VM. Click on Add Azure VM.

Azure Automation will then ask you for two things: The VM you wish to register, and the DSC Configuration to associate with it. Start off by clicking on Virtual Machines, and select the Virtual Machine we created from the list (in my case SPTechCon-SA). Click OK. One thing that is interesting to note here, is that because we have generalized our DSC script (meaning not valus are hardcoded in it), we can easily select multiple VMs in this step and they will each get assigned the exact same configuration.

Now that you have selected your VM, it’s time to pick the DSC Configuration we wish to deploy onto it. Click on Registration. From the Node Configuration Name, pick the Node Configuration we compiled previously. The rest of the properties listed on the page should look familiar to you. They represent the LCM settings that can normally be set via PowerShell in on-premises scenarios. Leave everything as default, with the exception of the Reboot Node if Needed checkbox that absolutely need to be checked for the installation to complete properly. Click OK.

The last thing left for us to do now is initiate the registration process by clicking on Create.

Now sit back and relax, your machine is going to go and configure itself. Depending on several factors (machine size, region, etc.) the process may take up to 45 minutes to complete
How does it Work?
If you were to connect to your VM before registering it to the Azure Automation Account and run the Get-DSCLocalConfigurationManager cmdlet on it, you would see that by default the machine’s LCM is set to PUSH mode.

Upon registering your machine against the Azure Automation Account, a DSC Extension is assigned to your VM. That extension will automatically change the configuration of the machine’s LCM to set it in PULL mode and register it against your Azure Automation’s Pull Server endpoint.

Share this:
Facebook
Twitter
LinkedIn
Email
Print
Pinterest
Like this:
Like Loading...


	
Related