Share via

Windows Azure Pack: Web Sites Pre-installation Steps

  • Article

 

Applies To: Windows Azure Pack

The steps in this chapter are important for a successful installation of Windows Azure Pack: Web Sites. Be sure to read each section carefully and perform the actions as required. The sections are as follows:

Domain vs. non-Domain considerations

Create Servers for the Web Sites Roles

Advice for Preparing your VHDs or Servers

Prepare a SQL Server to hold the Windows Azure Pack Web Sites Runtime Database

Provision SQL Server and MySQL Application Databases for Tenant Use

Web Sites Roles Firewall Configuration

Configure the Front End, Publisher, Web Worker, Management Server, and non-preconfigured File Server (optional) roles for inbound access from the Internet

Configure Windows Azure Pack: Web Sites to use Proxy Servers

Modify User Account Control for Remote Access

Configure DNS mappings for the Web Sites Cloud

Domain vs. non-Domain considerations

Windows Azure Pack: Web Sites can be installed in either a domain-joined or non-domain joined (workgroup) environment. While a workgroup environment might be appropriate for development or test scenarios, we recommend that you use a domain-joined environment for the following reasons:

  • Users can leverage Kerberos for authentication handshakes, which is much more secure than either NTLM or NTLM v2.

  • Simplified user and credential management.

  • Improved management through group policy

Create Servers for the Web Sites Roles

Prior to installing the Web Sites cloud, prepare one Windows Server 2012 R2 server per Web Site role (the servers can be either physical or virtual machines). Later, for High Availability, you should add more than one server per role. For ease of maintenance, use descriptive computer names such as those below. The naming convention suggested here is that you replace the "x" in each name with "1" (padding with zeros as needed), and then increment that number as you add server instances to a role.

  • SitesCNx – Web Sites Cloud Controller

  • SitesMNx – Web Sites Cloud Management Server

  • SitesFEx – Web Sites Cloud Front End

  • SitesPBx – Web Sites Cloud Publisher

  • SitesWWSx – Web Sites Cloud Shared Web Worker

  • SitesWWRx – Web Sites Cloud Reserved Web Worker

  • SitesFSx – Web Sites Cloud File Server

Advice for Preparing your VHDs or Servers

  • Use clean installations of Windows Server 2012 (Windows Server 2012 R2 is recommended).

  • Do not co-locate Web Sites roles; each Web Site role should have its own VM or Server.

  • Do not co-locate Web Sites roles with the Admin or Tenant Portal or API servers. For example, the Web Sites Cloud Controller and the Admin API roles must be on separate machines.

  • It is recommended that you use domain-joined servers, as noted previously.

  • If you are using VMs, it is a good idea to take snapshots for each role at the following junctures:

    • Pre installation

    • Post installation

    • Post configuration

Note

To avoid NetBIOS errors and automatic name truncation, make sure the computer names you choose are no longer than 15 characters.

Prepare a SQL Server to hold the Windows Azure Pack Web Sites Runtime Database

For the Web Sites runtime database, prepare a SQL Server database. As a best practice, all SQL Server roles, including the Web Sites runtime database, the Service Management API database that is part of should be on separate machines.

  • For testing, development, or "proof of concept" purposes, you can use SQL Express 2012 SP1 or later. For download information, see Download SQL Server 2012 Express with SP1.

  • For production purposes, you should use a full version of SQL 2012 SP1 or later. For information on installing SQL Server, see Installation for SQL Server 2012.

  • Mixed Mode authentication should be enabled.

  • The Web Sites runtime SQL Server should be accessible from all Web Sites roles.

  • For any of the SQL Server roles, you can use a default instance or a named instance. However, if you use a named instance, be sure that you manually start the SQL Browser Service and open port 1434.

For more information, see Using SQL Server or MySQL with Windows Azure Pack.

Provision SQL Server and MySQL Application Databases for Tenant Use

Your environment may require that you support tenant SQL Server and/or MySQL database applications. If so, you should install and configure separate SQL Server and MySQL instances dedicated for tenant application database use.

SQL Server tenant application database server requirements:

  • Mixed Mode authentication should be enabled.

  • The SQL server should be accessible from the Web Worker and Publisher roles

  • The SQL server should be accessible from the Admin and Tenant API Roles

MySQL tenant application database server requirements:

  • Using the MySQL command line interface, the root user should be enabled for remote access with a password. Example syntax:

    GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;
FLUSH PRIVILEGES;

    For more information on the MySQL command line interface, see the MySQL Documentation.

  • The MySQL server should be accessible from the Web Worker and Publisher roles

  • The MySQL server should be accessible from the Admin and Tenant API Roles

  • For IPv6 support, use MySQL version 5.5.30 or later

For more information, see Configure SQL Server and MySQL Application databases for tenant use. For information on scaling up SQL Server for production use, see Configuring SQL Server for High Availability.

Web Sites Roles Firewall Configuration

If you implement Windows Azure Pack: Web Sites entirely in an intranet environment, public internet access is not necessary. (Even if internet access is necessary, a well-planned network topology can prevent the exposure of the Web Sites roles directly to the internet.)

A server’s firewall settings should be configured before you add a Web Sites role to the server. The following list summarizes internet access requirements for each Web Site role:

  • Management Server - does not require public internet access.

  • File Server - does not require internet access and should never be internet accessible.

  • Web Sites Controller - requires outbound HTTP access but not inbound. The Controller requires outbound access so it can download software dependencies for the installation of Web Sites roles.

  • Web Workers - never need inbound internet access, but may require outbound access if (for example) a web application consumes an external web service.

  • Front End servers may or may not require direct inbound network access to accept client requests for websites, depending on network topology.

  • Publishers may or may not require direct inbound access to accept FTP and WebDeploy publishing requests, depending on network topology.

For the Front End and Publisher roles, you can avoid direct internet access if you have upstream load balancers or upstream NAT devices that handle network address translation between public and private addresses.

Configure the Front End, Publisher, Web Worker, Management Server, and non-preconfigured File Server (optional) roles for inbound access from the Internet

On the servers that will become the Front End, Publisher, Web Worker, and Management Server roles, allow inbound access to the following services. You should also apply these settings to the File Server role if you are using the non-preconfigured File Server option.

  • File and printer sharing (SMB-In)

  • Windows Management Instrumentation (WMI-In)

To configure inbound access, you can use the following netsh commands:

netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes
netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes

Note

The network adapters for the Front End and Publisher roles should be configured in Windows Firewall to use the Public Profile.

Configure Windows Azure Pack: Web Sites to use Proxy Servers

If you are using a proxy address for outbound access to the internet, you must enable Web Sites to use the proxy address before you can install and run Windows Azure Pack: Web Sites.

Note

Web Farm authentication through a proxy server is not currently supported. This section describes steps that must be taken to install and run Windows Azure Pack: Web Sites behind a proxy server. It does not describe how to configure proxy servers.

To enable the farm to communicate through a proxy without authentication, run the following PowerShell commands with administrative privileges on the Controller. Replace <ProxyAddress> with the address of the proxy

Import-Module WebSites

Set-WebSitesConfig Global -ProxyEnabled True -ProxyAddress <ProxyAddress>

Note

When installing the Web Sites service for Windows Azure Pack, run the Web Platform Installer using an account that can authenticate against the proxy.

Allow Microsoft Updates access to Windows Azure Pack: Web Sites behind the proxy

As an optional step when Windows Azure Pack: Web Sites is behind a proxy, it is suggested that you enable Microsoft Updates so that they can work correctly with Windows Azure Pack: Web Sites. To do so, run the following PowerShell commands with administrative privileges on the Controller, where user <ProxyUser> with password <ProxyUserPassword> can authenticate against the proxy:

Import-Module WebSites

New-WebSitesConfig Credential -CredentialName ProxyUserCredential -UserName <ProxyUser> -Password <ProxyUserPassword> -CredentialType SystemCredential

Modify User Account Control for Remote Access

On each server to be used for a Windows Azure Pack: Web Sites role, disable User Account Control (UAC) for remote connections as described below. This will allow remote administration to be carried out.

Note

Local UAC configuration will remain unchanged.

  1. Run the following command from an elevated command prompt:

    reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

  2. Restart the server.

Configure DNS mappings for the Web Sites Cloud

During Web Sites Cloud setup, when configuring the Web Sites Controller, you will be prompted for the default domain name to be used for end user web sites.

By default, web sites are created under a default domain. Once a web site is created, users can add custom domain names to each web site. While tenant web sites can be configured to support custom domains, Windows Azure Pack: Web Sites does not update custom DNS records. To ensure that all internet-facing web sites are configured with the appropriate IP address assignments, follow the guidance below.

For a given domain such as Contoso.com, create the following DNS A records:

Host name

IP Address for

*

Front End Server(s)

*.scm

Front End Server(s)

ftp

Publishing Server(s)

publish

Publishing Server(s)

This mapping scheme allows users to log on to both https://www.contoso.com and https://contoso.com to manage their sites. The Management Portal for Administrators and the Management Portal for Tenants are described in Deploy Windows Azure Pack for Windows Server.

In the sample configuration above, user-created web sites are created using child domains such as site1.contoso.com, site2.contoso.com.

When users publish content to their web sites via Web Deploy or FTP, they will use publish.contoso.com or ftp.contoso.com respectively. Content publishing via Git uses *.scm.contoso.com.

Note

There is no requirement for a special domain for this deployment. You can use a subdomain like my.yourdomain.com under an existing domain.

See Also

Deploy Windows Azure Pack: Web Sites