Installing and configuring Windows Azure for Windows Server 2012 – Part 1

This blog series on enabling the Cloud OS with Windows Server and System Center for Hosting Service Providers consists of the following parts

In the previous part of this blog series we enabled multitenant access to the Cloud OS through an ODATA web service by installing and configuring System Center Service Provider Foundation.

My previous blog on the technical preview of Windows Azure Services for Windows Server includes an installation guide. The new features and bug fixes in the official release combined with numerous installations resulted in an updated installation and configuration guide.

<img src=”/images/2013-02-12/register-spf-main-menu.png” width=720”>

This blog describes part 1 of the installation and configuration of the Service Management Portal and API.

Scenarios

Single servers or distributed installation

The Service Management Portal and API consist of two sites and three APIs. These web services can be divides into two categories. Services that should be publicly accessible and services that should be secured to internal access only.

  • Publicly accessible
  • Service Management Tenant Site
  • Service Management Tenant Public API
  • Secure internal access
  • Service Management Admin Site
  • Service Management Admin API
  • Service Management Tenant API

All the components can be installed on a single server using the Express installer. It is also possible to run a distributed installation and select the location for each individual component. This blog will describe both installation procedures.

Single domain, Workgroup or Multiple Domains

The Service Management Portal and API can be installed in the same domain as System Center Virtual Machine Manager 2012 SP1 and System Center Service Provider Foundation 2012 SP1 is running in. It is also possible to install the Service Management Portal and API in a workgroup or in a separate (dedicated) domain. This can be useful when you have a single Service Management Portal environment that connects to multiple stamps in different domains. The only connection between the Service Management Portal and API and the System Center VMM 2012 SP1 environment is a local user account on the Service Provider Foundation that is user for registering and authenticating to the Service Provider Foundation ODATA web service.

Prerequisites

Operating system

All Service Management Portal and API components must be installed on Windows Server 2012.

Microsoft Web Platform Installer

The Service Management Portal and API installation files are integrated in the Microsoft Web Platform Installer.

The Microsoft Web Platform Installer (Web PI) is a free tool that makes getting the latest components of the Microsoft Web Platform, including Internet Information Services (IIS), SQL Server Express, .NET Framework and Visual Web Developer easy. The Web PI also makes it easy to install and run the most popular free web applications for blogging, content management and more with the built-in Windows Web Application Gallery.

SQL Server version and authentication

The Service Management Portal and API uses SQL Server for its databases. There is no version requirement in the installation guide. I will use SQL Server 2012 SP1 running on Windows Server 2012 for this blog. In the beta of the Service Management Portal and API there was no distinction between SQL authentication and Windows Integrated in the Database Setup step of the configuration wizard.

In the final release this has changed. You can choose between SQL authentication and Windows Integrated Authentication in the configuration wizard. This blog will not describe the installation of SQL server but we will need to configure the authentication settings.

For SQL authentication the SQL Server must be configured in Mixed Mode. The SQL Server system administrator (sa) account will be used to configure the databases in the Service Management Portal and API configuration wizard.

It is also possible to use Windows Integrated authentication for the database creation and connection. This is more complicated. When you specify a domain service account with the sysadmin role in SQL Server the Service Management Portal configuration the database creation will fail. In the event viewer an event is generated that the Service Management Portal computer account needs sysadmin permissions in SQL Server. When you try to assign permissions to a computer account in SQL Server you will find this is impossible.

You can set permission on the computer account in SQL Server with a workaround. First create a domain group. Add the Service Management Portal computer account to this domain group.

<img src=”/images/2013-02-12/Windows-Integrated-Authentication-Add-Computer-Account.png” width=500”>

Specify the sysadmin role in SQL server for the domain group. This enables Windows Authentication for the database creation and configuration in the Express installation.

Using this procedure in the distributed scenario (even with all Service Mangement Portal computer accounts added to the domain group) the configuration of the database will succeed. But opening the Admin Site will fail with the following error.

<img src=”/images/2013-02-12/windows-integrated-auth-distributed-installation.png” width=600”>

For an express installation you have the possibility to choose between SQL authentication and Windows Integrated Authentication. For the distributed installation you can only use SQL authentication.

In the Technical Preview of Windows Azure for Windows Server the SQL collation of the SQL Server used for the Service Management Portal databases needed to be adjusted to SQL_Latin1_General_CP1_CI_AS during installation. In the final release the product is compatible with the default SQL Server 2012 SP1 default collation Latin1_General_CI_AS.

<img src=”/images/2013-02-12/sql-server-default-collation.png” width=720”>

The SQL collation no longer needs to be adjusted.

Service account for registering System Center Service Provider Foundation

In previous installations I have used the Service Provider Foundation Application Pool ID for the registration in the Service Management Portal. When I used another account than the domain administrator account for the Application Pool ID in the Service Provider Foundation and the registration in the Service Management Portal, the registration would succeed. Creating a user and assign a required plan to this user in the Service Management Portal would fail.

Working with Hans Vredevoort, the product team provided us with the required steps.

There is one additional user account that must be created on the Service Provider Foundation server. This user account is used to register the Service Provider Foundation in the Service Management Portal. Since this account is only required for the Service Management Portal I decided to describe the required steps in this blog.

Create a local user account on the Service Provider Foundation server (for example SVC_SPF_REG)

<img src=”/images/2013-02-12/local-user-for-spf-registration.png” width=400”>

Add this local account to following local groups on the Service Provider Foundation server.

  • SPF_Admin
  • SPF_Provider
  • SPF_VMM

<img src=”/images/2013-02-12/add-user-for-spf-registration-to-local-groups.png” width=400”>

This account is used for registering the Service Provider Foundation in the Service Management Portal.

Installation

Single server installation

Run the Microsoft Web Platform Installer on the server that will host all Service Management Portal and API components.

Select the products tab and in the left menu select Windows Azure.

The main menu will display the Service Management Portal and Service Management API Express installer and the individual Service Management Portal components for a distributed installation.

Add the Service Management Portal and Service Management API Express and select install. The installer will prompt once for the additional downloads.

Depending on your download bandwidth and server capacity the installer will run for a couple of minutes.

After installation completes and you select finish the installer will open URL https://localhost:30101/, which enables the configuration wizard. You can ignore the certificate warning for now.

In the configuration wizard you need to specify the SQL server name, the authentication method and the Configuration Store Passphrase. For the Express installer you can choose between SQL authentication and Windows integrated authentication (see note in the prerequisites section of this blog). The Configuration Store Passphrase is used in a distributed scenario to authenticate additional servers with individual Service Management Portal and API components to the environment.

With the prerequisites in place the configuration of the Service Management Portal should complete successfully.

After the configuration is complete the Portal Admin Site opens on https://localhost:30091

Distributed installation

You can use a single server for all Service Management Portal and API components. It is also possible to install each individual component on a different server in a distributed installation. Any combination of one or more components on a server is supported, as long as all components are installed.

It is recommended that the Service Management Tenant Site and the Service Management Tenant Public API should be publicly accessible. The Service Management Admin Site, the Service Management Admin API and the Service Management Tenant API should not be publically accessible.

For the distributed installation in this blog we will use two servers for the Service Management Portal and API components. One server will be publically accessible, with the Service Management Tenant Site and the Service Management Tenant Public API installed. The other server will only be accessible internally, with the Service Management Admin Site, the Service Management Admin API and the Service Management Tenant API installed.

Internal access

The initial configuration of the Service Management Portal and API will be executed from the internal access server. This is the first server to install.

Run the Microsoft Web Platform Installer on the internal only accessible server. Select the Products tab and select Windows Azure in the left menu. In the main menu add the following components.

  • Service Management Admin Site
  • Service Management Admin API
  • Service Management Tenant API

<img src=”/images/2013-02-12/web-installer-internal-access.png” width=720”>

Select install and confirm the additional downloads. The installer will run for a couple of minutes. When the installation is complete start the configuration wizard. The configuration wizard will create the databases en configure the services that are installed on this server. For a distributed installation you should use SQL authentication for validation to the SQL server. I have tried to use Windows Integrated Authentication (see prerequisites) this failed in a distributed scenario.

Please take note of the Configuration Passphrase. You will need to specify this passphrase when you configure the additional Service Management Portal components.

<img src=”/images/2013-02-12/features-setup-internal-access.png” width=720”>

After the configuration wizard is finished and the Admin Site is opened the Service Management Portal will present the error that not all components are installed.

Before we can access the Admin Site all services should be installed and configured. We will install the remaining components on the public accessible server.

Public access

Run the Microsoft Web Platform Installer on the publically accessible server. Select the Products tab and select Windows Azure in the left menu. In the main menu add the following components.

  • Service Management Tenant Site
  • Service Management Tenant Public API

<img src=”/images/2013-02-12/web-installer-public-access.png” width=720”>

Select install and accept the additional downloads.

In the configuration wizard specify the same SQL Server, SQL authentication credentials and Configuration Passphrase as used in the configuration wizard of the internal access server. The configuration wizard connects to the SQL Server using the credentials specified and verifies the Configuration Passphrase.

<img src=”/images/2013-02-12/database-server-setup-distributed-installation.png” width=720”>

When the values are validated you can complete the configuration.

<img src=”/images/2013-02-12/features-setup-public-access.png” width=720”>

After the configuration is complete, logon to the Internal Access server again and connect to the Admin Site on https://localhost:30091

Service Management Admin Site

I’ve noticed some people are having trouble accessing the Service Management Admin Site. Please take note that the installation guide on TechNet contains an entry that the required Operating System for the Service Management Portal and API is Windows Server 2012.

When you access the Service Management Admin Site you should use the local administrator account. To force the local account store for validation enter the credentials in the .administrator format.

<img src=”/images/2013-02-12/local-administrator-login-on-30091.png” width=720”>

Service Provider Foundation registration

To enable IaaS in the Service Management Portal you should register the Service Provider Foundation.

Registering the Service Provider Foundation

In the prerequisites section of this blog we created a local user account on the Service Provider Foundation server. We will use this account to register the Service Provider Foundation. In the Service Management Admin Site select VM clouds in the left menu.

Select Register Service Provider Foundation in the main menu. Provide the URL for the Service Provider Foundation we created in the previous blog and specify the credentials for the local user account created on the SPF server.

<img src=”/images/2013-02-12/register-spf.png” width=400”>

The registration will take a couple of seconds.

Re-registering the Service Provider Foundation

Since the Technical Preview I reverted about a 100 snapshots, to get all things tested and functioning properly. Most snapshots were used to test the Service Provider Foundation Registration. Once the registration is done you are unable to redo the registration from the Service Management Portal.

Fortunately the product team provided us with a procedure to “un-register” the Service Provider Foundation.

Please note – Any existing plans with System Center might fail if you un-register and register again. Other plans are not impacted.

To un-register the Service Provider Foundation:

A record in Service Managament Portal SQL database must be deleted

  • Database: Microsoft.MgmtSvc.Store
  • Table: mp.ResourceProviders
  • Record : systemcenter

You can delete the record by right clicking the row in the table and select delete.

<img src=”/images/2013-02-12/unregister-spf-delete-row.png” width=720”>

You can also delete the record by running the following query on the Microsoft.MgmtSvc.Store database on Service Managament Portal SQL server.

DELETE FROM mp.ResourceProviders 
Where Name = ‘systemcenter’

When the record is deleted you must run IISReset.exe on the Service Management Portal. You can now register the Service Provider Foundation again.

Register System Center Cloud Provider

Finally the System Center VMM 2012 SP1 environment needs to be registered in the Service Management Portal. Open the Service Management Admin Site on https://localhost:30091 and open VM Clouds in the left menu. Select Register System Center Cloud Provider in the main menu specify a friendly name for the Cloud Provider and enter the name of the System Center VMM 2012 SP1 server.

<img src=”/images/2013-02-12/register-cloud-provider.png” width=720”>

Select Register. When registration is complete the number in the VM Clouds entry on the left menu should match the number of clouds available in your System Center 2012 SP1 environment.

<img src=”/images/2013-02-12/vm-clouds-number.png” width=720”>

What is next?

The next part of this blog series describes Service Management Portal certificates, System Center VMM mappings and tenant experience.