Windows Azure Pack: Web Sites Pre-installation Steps
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.
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 /fRestart 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.