Deploying Windows Azure Pack Websites–Prerequisites

In the first post of this series, we looked at the architecture of the Windows Azure Pack websites feature.  In this post we’ll look at the prerequisites for the websites feature.

The first thing you’ll need is a SQL database server for the runtime databases.  You can share the runtime databases for the websites feature with the SQL databases for the Azure Pack portal if you like.  As for the Azure Pack runtime, you can provision the databases on an AlwaysOn cluster, but the feature does not natively support AlwaysOn so you must manually add the databases to an Availability Group, and ensure the user accounts are created on each node correctly.  And similarly to the Azure Pack portal the SQL instance must allow SQL authentication, and you’ll require a SQL account that has sysadmin rights on the server.

You should also plan to provision a SQL database server to host databases for tenants to provision as part of their websites.  This database must be at the very least a separate instance of SQL server on the same SQL server that hosts the runtime databases, or, for higher security, a completely separate SQL instance.  The tenant database service does natively support AlwaysOn, although you will need to configure SQL to allow Contained Databases.  You might also choose to provision MySQL if you have that requirement – this process is documented on TechNet.

You’ll also need a number of virtual machines to host the features.  You’ll need a minimum of six VM’s (controller, management server, file server, front end, worker, publisher) but you should allow for redundancy in the front end and workers at the very least.  The great thing about the websites feature deployment is that all the deployment is either done with the Web Platform Installer, or triggered remotely, so you can start with essentially blank VM’s.  For each of the VM’s, they can be basically default installs of Windows Server 2012 R2 (or Windows Server 2012 if you need to).  The only thing you need to do them is to enable the required firewall rules and disable UAC for remote connections.  Do this for all machines that are going to be part of the websites service (technically you don’t need to do this to the controller).

Microsoft give you the netsh & reg commands for enabling the required firewall rules, but I prefer to use the equivalent PowerShell commands:

get-netfirewallrule | where {$_.DisplayGroup -eq “File and Printer Sharing”} | enable-netfirewallrule
get-netfirewallrule | where {$_.DisplayGroup -eq “Windows Management Instrumentation (WMI)”} | enable-netfirewallrule
New-ItemProperty -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system -Name LocalAccountTokenFilterPolicy -PropertyType Dword -value 1

The easiest way to execute these commands across all the machines is to use PowerShell remoting if you can (invoke-command –ComputerName <list of computer names> –ScriptBlock {<commands from above>}).

The controller is deployed using the Web Platform Installer, but all other roles are deployed by a remote push from the controller.  To do the push you need to provide administrative credentials as part of the controller configuration.  You must use two sets of credentials, one for the workers, and another for all the other roles.  The credentials could be local accounts with Administrator privilege, or domain accounts with Administrator privilege.  If you choose the local account option, ensure that the password for the accounts are the same on all the required boxes.

You will also need to have a password ready that you will use as part of the websites feature configuration, which creates a local account on the management server that the Azure Pack portal will use to perform its operations.  The account is by default called CloudAdmin.

If you have chosen to use a clustered file server, or a NAS, or some other non-Windows server to host the file server content share, you will need to preconfigure it.  This process is reasonable complex and is documented on TechNet.  It is crucial to get this part correct, if you have permission issues on the file server the websites feature will be non-functional.

Once you’ve got these things in place, and you’ve got your chosen DNS suffix you can begin deployment.  We’ll look at this in the next post.

Advertisements

One thought on “Deploying Windows Azure Pack Websites–Prerequisites

  1. […] part one of this series, we had a quick overview of the Windows Azure Pack websites feature, and in part two we looked at getting the prerequisites in place.  In this post we’ll go through the deployment […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s