Deploying Windows Azure Pack Websites–Deployment

In 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 process.

Although there are a lot of moving parts in the websites feature, the deployment process is very simple.  The general process goes something like this:

  1. Deploy the controller using the Web Platform Installer
  2. Configure the controller using the website, which provisions the management (REST) server and optionally configures the file server
  3. Register the management server with the Azure Pack admin portal
  4. Deploy the remaining roles (Front Ends, Workers & Publisher) from the Azure Pack admin portal

To start with part 1 you can install the Web Platform Installer and then select the controller component which is called “Windows Azure Pack: Web Sites v2”


Since I prefer to do as much as possible from the command line, to deploy the controller you can execute the following once you have WebPI installed:

Cd “C:\Program Files\Microsoft\Web Platform Installer\”
.\webpicmd.exe /install /products:HostingPrimaryControllerBootstrapper_v2 /AcceptEula

Once installation is finished, Internet Explorer will start and you will be taken to the configuration page.  The first thing you’ll need to do is ignore the certificate warnings and then get on with configuration.

Start by configuring the database connection, and your custom DNS suffix.  Be aware that there doesn’t seem to be a way to change the custom DNS suffix after installation, so make sure you get it right first.

01. Websites Config

Next define the server name for the server that is going to be the websites management server (REST API server).  Provide a username & password to configure the management server, the file server, front ends & publisher.  In the prerequisite post I mentioned that you need to set the credentials to be the same on all these roles.  You’ll also provide the credentials to install the worker roles.

02. Websites Config

You’ll also need to set the registration credentials for the REST API server – default is CloudAdmin and whatever password you want.

02s. Websites Config

For the file server, you get options about whether you’re going to let the setup process configure the file server for you (this works if you are just going to have a single server), or you are going to preconfigure a Windows file server, or if you are going to use a non-Windows file server (like a NAS or your SAN).  Either way you’ll need to provide the server name, and the three sets of credentials (FileShareOwner, FileShareUser, CertificateShareUser).  The share paths will be automatically populated for you based on the servername, but change them if you need to.

03. Websites Config

03a. Websites Config

03b. Websites Config

Choose to join the CEIP, and whether to use Microsoft Update.  You should join Microsoft Update, as updates to the websites components are provided through Windows Update.

04. Websites Config

Finalise the setup process and everything going well you’ll get three green ticks.

05. Websites Config

Now you have three configured components – the controller, the management server and the file server.

The next step is to head to the Azure Pack Admin portal and register the management server.  Log in to the Admin portal, and choose “Web Site Clouds” from the left hand bar.  Click the link below “Connect to a web site cloud”

01. WebSitesRegistration

Enter a meaningful display name, the name of your management server (prefixed with https) and then the CloudAdmin credentials you created during deployment.  Assuming you got everything right, you’ll get a green tick beside the password, and you’ll be able to connect.

02. WebSitesRegistration

Now when you click the “Clouds” link at the top you’ll see your registered web site cloud.  All that remains is to provision the rest of the roles.

03. WebSitesRegistration

To do this, click your web site cloud from the Clouds pane and you’ll be taken into the detailed view.  You’ll be able to see the current roles provisioned and what status they are in.  Note that if you chose either the preconfigured Windows file server, or non-Windows file server options during deployment, your file servers will not show here.

04. WebSitesRegistration

To provision the roles, just click the “Add Role” button at the bottom of the screen.  You can choose to add a new worker, frontend, or publisher.

05. WebSitesRegistration

Each following option is basically the same – enter the name of the server you wish to add.  The web worker role has an additional option that allows you to choose what sort of worker you wish to provision – shared or reserved.

06. WebSitesRegistration

Once you click the tick, a process will be triggered on the controller that will deploy the selected role to the selected server.  Do this for each server that you are deploying.  If you want to see where things are at with the deployment of a role, you can highlight the server in the list and click the “Role Log” button.  This will bring up a log of what the controller is attempting to do.

08. Role Log

The deployment is reasonably resilient, and if it fails it will attempt to autorepair as best it can.  It will retry a number of times, and then reboot the server if things are still failing.  This does seem to be quite normal, and if the controller is able to reboot the VM it tends to be able to finish deployment.  Where you’ll run into trouble is if you haven’t enabled the required firewall rules so the controller can’t talk to the server or transfer the required files.  The deployment is agent based – the first thing that happens is that the controller pushes the source files for the Web Farm Agent to C:\windows\temp on the destination server, and then installs it.  From then it appears to do all communication via the Web Farm Agent (which is an HTTP listener on port 8173).

That’s it for deployment, in the next post we’ll briefly look at the post-deployment tasks.


3 thoughts on “Deploying Windows Azure Pack Websites–Deployment

  1. Hi guys,

    Few undocumented pre-requirements that will prevent you from installing Web Worker:
    Never DISABLE IPv6 on Web worker server. Make sure it’s enabled when adding shared Or reserved web worker, otherwise the server will stuck in loop of auto-repair, error will be the following:

    at System.Net.HttpWebRequest.GetResponse()
    at HostingController.Helper.CheckWorkerHttpAvailability(String& errorMessage)
    Id = 12824, Date = Mon Jun 02 2014 17:45:13 GMT+0800 (Malay Peninsula Standard Time), Level = 1, Server Name = WAPSITESWWS01, Message = Failed to run operation ‘WorkerPeriodicHttpHealthCheck (7.7.10699.8)’. Operation failed to complete.
    System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. —> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. —> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
    at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
    — End of inner exception stack trace —

  2. Thanks for very helpful post. Really nice.
    An undocumented new pre-req is “FSRM” — needed on workers, publisher and file nodes.

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s