Hybrid Cloud Infrastructure Solution for Enterprise IT - Implementation
Published: August 23, 2013
Version: 1.0
Abstract: This article outlines the steps to implement a hybrid cloud solution for the fictional company Contoso based on the requirements set forth in the Scenario Definition article. This article is part of the Hybrid Cloud Infrastructure Solution for Enterprise IT article set.
Table of Contents
1.0 Introduction
2.0 Implementation
2.1 Provision Accounts
2.2 Configure site-to-site VPN with Windows Azure
2.3 Deploy Virtual Machines in Windows Azure
2.4 Deploy an Application in a Hybrid Cloud Infrastructure
2.5 Configure Windows Azure Load Balancing
2.6 Deploy System Center Advisor
2.7 Configure Same Sign-In
2.8 Configure Windows Azure Active Directory
2.9 Configure Windows Azure Autoscale
3.0 Summary
4.0 Technologies Discussed
To provide feedback on this article, leave a comment at the bottom of the article or send e-mail to SolutionsFeedback@Microsoft.com. To easily save, edit, or print your own copy of this article, please read How to Save, Edit, and Print TechNet Articles. When the contents of this article are updated, the version is incremented and changes are entered into the change log. The online version is the current version. For the latest information, see the Hybrid Cloud Infrastructure Solution for Enterprise IT article set. This article discusses technologies listed in the Technologies Discussed section of this article.
1.0 Introduction
This article is one of several that are included in an integrated set called Hybrid Cloud Infrastructure Solution for Enterprise IT. Before you read this article, please read Hybrid Cloud Infrastructure Solution for Enterprise IT – Introduction. It provides an overview of the article set, introduces the intended audience, and defines the articles that are contained within the set. This article provides a step-based approach to implement the design that is detailed in Hybrid Cloud Infrastructure Design Considerations in your environment. Although this article implements steps to install and configure the design solution, the steps are written at a level that assumes you already have some familiarity with the technologies that are utilized in the design.
When new technologies are utilized, more detailed implementation steps are also included. To review lower-level implementation steps, you’re encouraged to read the information that is included in the hyperlinks throughout this article. his article is most helpful to those responsible for implementing a hybrid cloud infrastructure or implementing solutions within enterprise IT organizations. If you’d like to understand all of the relevant individual design configuration options for hybrid cloud infrastructure solutions so that you can determine which options are most appropriate for your own, unique requirements, then it’s recommended that you read the Hybrid Cloud Infrastructure Design Considerations article. While the Hybrid Cloud Infrastructure Design Considerations article details all available Microsoft product and technology design options and considerations for hybrid cloud infrastructure solutions, it does not provide any example designs or recommendations for specific requirements.
Many people will find it helpful to read both the Design article for the Reference Implementation article set targeted to an organization similar to their own, as well as the Design Considerations article for the hybrid cloud infrastructure problem domain. Others will only find it necessary to read one article or the other. Though the two articles are related, there are no dependencies between them.
2.0 Implementation
The high-level implementation steps for the hybrid cloud infrastructure solution that are detailed in Hybrid Cloud Infrastructure Design of this set are summarized in the following table. Each high-level implementation step includes multiple lower-level implementation steps, which are detailed in the remainder of this article.
| Step | Task | Target |
| 2.1 | Provision Accounts | Windows Azure |
| 2.2 | Configure site-to-site VPN with Windows Azure | Windows Azure and on premises |
| 2.3 | Deploy Virtual Machines in Windows Azure | Windows Azure |
| 2.4 | Deploy an Application in a Hybrid Cloud Infrastructure | Windows Azure and on premises |
| 2.5 | Configure Windows Azure Load Balancing | Windows Azure |
| 2.6 | Deploy System Center Advisor | Windows Azure |
| 2.7 | Configure Same Sign-On | Windows Azure and on premises |
| 2.8 | Configure Windows Azure Active Directory | Windows Azure and on premises |
| 2.9 | Configure Windows Azure Autoscale | Windows Azure |
Back to section 1.0
2.1 Provision Accounts
After you make all your design decisions, it is time to implement your hybrid cloud infrastructure. During this implementation, the first step is to subscribe to Windows Azure. When you access the Windows Azure Pricing page, you will see the options to Try it now or to Buy now. For our Contoso scenario, we will choose the Pay as you Go option, which allows Contoso to have a zero upfront investment, and they can cancel anytime.
Before you subscribe to Windows Azure, it is important to define which account will be the subscriptionaccount and which accounts will be authorized to manage the Windows Azure Management Portal. The subscription account includes the credit card information that is used to pay the subscription, which is not necessarily the same account that will be used to administer the environment.
During the provisioning process, you sign up with your Microsoft account (Outlook.com, Hotmail.com, or Windows Live). Contoso created one team account and this account has the credit card information bound to it. After the subscription is completed, Contoso will create co-administrator accounts to enable authorized users to manage the portal. For more information, see section 2.8.2 Create a New User Account. After you sign in with your Microsoft account, you can follow the Windows Azure sign up process to create your account. During this time, you provide the credit card information that will be charged for the subscription.
Back to section 2.0
2.2 Configure Site-to-Site VPN with Windows Azure
After the Windows Azure account is provisioned, you should use the following steps to start the site-to-site virtual private network (VPN) configuration.
| Step | Task | Target |
| 2.2.1 | Review Prerequisites for Site-to-Site Connectivity with Windows Azure | On-Premise |
| 2.2.2 | Create a Virtual Network | Windows Azure |
| 2.2.3 | Configure Windows Azure Gateway | Windows Azure |
| 2.2.4 | Configure On-premises VPN Device | On-premises |
Back to section 2.0
2.2.1 Review Prerequisites for Site-to-Site Connectivity with Windows Azure
Ensure that the VPN device that will be used to connect to the Windows Azure Gateway has the following capabilities:
- Full support for IPsec protocol Full support for IKEv2 if the design choice for the site-to-site VPN connectivity is to use dynamic routing (recommended). For more information, see About VPN Devices for Virtual Network.
- A public and unique Internet IP address. For a list of supported VPN devices, see Known compatible VPN devices.
2.2.2 Create a Virtual Network
You must sign in to the Management Portal to perform this task. In the Management Portal, create a custom virtual network that uses the following parameters:
- Affinity group:
Create a new affinity group for the gateway. For more information, see Importance of Windows Azure Affinity Groups. - Region:
Ensure that the datacenter you select is the closest one to your on-premises resources. - DNS server:
Type the IP address of the DNS server that will be used for this connectivity. Because the servers that will be running in Windows Azure need to perform name resolution to be part of the domain, this should be the IP address of your on-premises DNS server. - Site-to-site connectivity:
Enter the public IP address of the on-premises VPN device that you selected earlier. - Virtual network address space:
Use Classless InterDomain Routing (CIDR) notation to specify the private address (for example, 0.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) to your network in Windows Azure.
For more information, see Create a Virtual Network in Windows Azure. Contoso decided to use the configuration that is shown in Figure 1.
Figure 1
When you create a network to allocate your virtual machines and your gateway, consider the following:
- Select a network ID that is different from your on-premises network ID. This is necessary to avoid routing issues between the virtual machines that are located in Windows Azure and the computers that are located on your premises.
- Select a network for your gateway that is within the same address space as the subnet where the virtual machines will reside. In this configuration, Contoso will host all virtual machines on Subnet-1, and the gateway for your site-to-site VPN Gateway will be located in the Gateway network.
For more information about the restrictions and capabilities of a virtual network in Windows Azure, see Virtual Network FAQ.
2.2.3 Configure Windows Azure Gateway
In this step, you will create a gateway to enable the site-to-site connectivity between your on-premises VPN device and Windows Azure. Use the Windows Azure Network Dashboard to create a gateway. The main parameter that must be selected during this configuration is the routing. You can choose between dynamic and static routing. For more information about dynamic and static routing, see About VPN Devices for Virtual Network. After the gateway is created, it can take up to 15 minutes for it to be operational. Then you’ll need to gather the following information, which will be used to configure the on-premises VPN device:
- IP address for the gateway
- Shared key
- VPN device configuration script template (optional)This information can be obtained in the dashboard for your network in the Management Portal.
For more information about how to obtain this information, read Create a Virtual Network for Site-to-Site Cross-Premises Connectivity.
2.2.4 Configure the On-Premises VPN Device
The on-premises VPN device must be configured by using a set of parameters that matches the Windows Azure Gateway. The IPsec connection must have the settings that are described in the following table.
| Property | Static Routing | Dynamic Routing |
| Key exchange | IKE v1 | IKE v2 |
| Encapsulation | ESP | ESP for site-to-site |
| Diffie-Hellman group | Group 2 | Group 2 |
| Encryption Algorithms |
|
|
| Hash algorithms |
|
|
| Phase 1 security association lifetime (time) | 28800 seconds | 28800 seconds |
| Phase 2 security association lifetime (time) | 3600 seconds | 3600 seconds |
| Phase 2 security association lifetime (throughput) | 102400000 KB | 102400000 KB |
Although Contoso is aware that the recommendation is to use dynamic routing because it leverages the security enhancements in IKEv2, Contoso decided to use static routing. This is due to a limitation with its on-premises VPN device, which only supports IKEv1. It was not in Contoso’s budget to upgrade the on-premises VPN device, so they decided to keep it during this phase of the project. You can get the configuration script for your VPN device from the Management Portal. For more information about routing types and the devices that are compatible with the routing configuration that you select to use in your deployment, see About VPN Devices for Virtual Network.
2.3 Deploy Virtual Machines in Windows Azure
After you create the connectivity between your on-premises VPN device and Windows Azure, you can create virtual machines that will connect to the on-premises resources. The steps in the following table are required to complete this part of the deployment.
| Step | Task | Target |
| 2.3.1 | Provision the First Virtual Machine | Windows Azure |
| 2.3.2 | Promote the Virtual Machine to Be a Domain Controller | Windows Azure |
| 2.3.3 | Configure Active Directory Sites and Services | On-Premises |
| 2.3.4 | Provision the Remaining Virtual Machines | Windows Azure |
| 2.3.5 | Remove Remote Desktop Protocol to the Public Network | Windows Azure |
Back to section 2.0
2.3.1 Provision the First Virtual Machine
You will use the Windows Azure Portal to create a new virtual machine. Use the option to create the virtual machine from the gallery, and choose the platform image that is appropriate for your scenario. In Contoso’s scenario, the platform image is Windows Server 2012. Some important parameters that will be used during the virtual machine creation are:
- DNS name:
Choose a unique name for the virtual machine. - Storage account:
Select Use Automatic Generated Storage Account. - Region:
Select the closest geographic location for the on-premises VPN device. - Availability set:
Create a new availability set to group the virtual machines that are deployed across fault domains and update domains. For more information, see Manage the Availability of Virtual Machines.
Contoso is not going to use the remote features in Windows PowerShell, so make sure to disable this option on the last page of the Create a Virtual Machine Wizard. Contoso decided to leave Remote Desktop Protocol (RDP) enabled at the beginning of the process to configure each virtual machine and test the accessibility from the VPN tunnel. This was a safety measure to ensure that the virtual machines were working before they disabled RDP. To disable RDP after you create the virtual machines, see section 2.3.5 Remove Remote Desktop Protocol and Windows PowerShell Access to the Public Network. At this point, the virtual machine will be created. The provisioning process can take up to 10 minutes to complete. For more information about how to create a virtual machine in Windows Azure, see Create a Virtual Machine Running Windows Server.
2.3.2 Promote the Virtual Machine to Be a Domain Controller
After the virtual machine is provisioned, you can use the Windows Azure Management Portal to connect to the virtual machine. When you use this option, a remote desktop connection is initiated to access the virtual machine. Before you promote the server to a domain controller, it is important to perform some validation checks to ensure that connectivity with on-premises resources is working properly. Here are some tests that you should complete at this point:
- Verify that this virtual machine received the IP address of the DNS that you created in section 2.2.2 Create a Virtual Network.
- Test the basic connectivity with the Domain Controller on-premises by simply typing a ping against the IP address of the domain controller.
- Use the nslookup or ping command by name against resources that are on-premises.
For more information if you have issues during this phase, see Troubleshooting Connectivity between Windows Azure VM and On-Premise resource. After you validate the initial configuration, join this server to the on-premises domain and promote the server to be a domain controller. For more information about how to install Active Directory Domain Services (AD DS) on a server, see Install Active Directory Domain Services (Level 100).Contoso decided to use a global catalog in all domain controllers, so it is necessary to enable the Global Catalog setting in this new domain controller. For more information, see Add or Remove the Global Catalog.
2.3.3 Configure Active Directory Sites and Services
By default, Active Directory Sites and Services has only one site called Default-First-Site-Name. Although this is not a mandatory step, ideally you should create another site to host the servers that are located in Windows Azure. You should also create a new subnet that matches the subnet that you created in Windows Azure Virtual Network. This becomes very important when you have a large environment and you need to optimize replication among domain controllers. After you create the subnet and the site that aligns with the servers located in Windows Azure, you should move the domain controller that is located in Windows Azure from the Default-First-Site-Name to the new site that you created for Windows Azure. Figure 2 shows an example for Contoso’s scenario, with the new site called Cloud.
Figure 2
If your company has more than two sites already in place, you should also consider creating site links to them and costs to optimize replication between the domain controllers that are located on-premises with domain controllers that are located in Windows Azure. For more information, see Overview of Active Directory Sites and Services. As stated in Hybrid Cloud Infrastructure Design Considerations Guide for Enterprise IT, the application's web tier is currently hosted in Contoso's perimeter network because these virtual machines accept inbound connections from the Internet. Security configuration for these virtual machines is managed by the Group Policy settings for the perimeter network. They will continue to apply security settings to the virtual machines by using Group Policy. Therefore, they will add the web-tier virtual machines that are hosted in Windows Azure to their perimeter network in AD DS.
2.3.4 Provision the Remaining Virtual Machines
When you create the remaining virtual machines in Windows Azure, ensure that they are connected with the existing virtual machine (which you created previously), and that they have the same region, affinity group, and virtual network settings as the initial virtual machine. Ensure also that they are part of the same cloud service as the other virtual machines. For more information, including information about how to choose the same cloud service, see Create a Virtual Machine Running Windows Server.
Important For this scenario, avoid using the Quick Create option while creating a new virtual machine because you won’t be able to set up some of the parameters that were mentioned in section 2.3.1 Provision the First Virtual Machine.
Therefore, your new virtual machine might not have connectivity with the other virtual machines that were already instantiated. For Contoso’s scenario, the following virtual machines must be provisioned at this point:
- One additional domain controller to use for redundancy
- Two front-end web servers
2.3.5 Remove Remote Desktop Protocol to the Public Network
After Contoso performed all the necessary tests to validate that access to the virtual machines is successful and that the initial configuration of the operating system is finished, they decided that remote desktop access to all virtual machines that are located in Windows Azure will be available only through site-to-site connectivity. They will accomplish this by using the internal, private IP address of each virtual machine. This enforces secure remote management through the encrypted tunnel that exists between Windows Azure and the on-premises VPN device.
Important It is possible to disable RDP from public access while you are creating the virtual machines. You can use the Create a Virtual Machine Wizard as explained in section 2.3.1 Provision the First Virtual Machine.
To remove public access to RDP, you need to access the virtual machine through the Windows Azure Management Portal as follows: Click Endpoints, highlight the Remote Desktop row (as shown in Figure 3), and then click Delete in the command bar.
Figure 3
2.4 Deploy an Application in a Hybrid Cloud Infrastructure
The application that will be used by Contoso will be accessed by external clients in addition to internal (on-premises) clients. The front-end web servers will be located in Windows Azure, and the database server is located on premises. The database server is already running SQL Server 2012. The steps in the following table are required to deploy the application in this hybrid environment.
| Step | Task | Target |
| 2.4.1 | Install Application Server and Web Server Roles on Front-End Servers | Windows Azure |
| 2.4.2 | Install and Configure the Application | Windows Azure |
| 2.4.3 | Configure the Database Server | On-Premises |
Back to section 2.0
2.4.1 Install Application Server and Web Server Roles on Front-End Servers
Use the Add Roles and Features Wizard in Server Manager to add the Application Server and Web Server (IIS) roles. For more information, see:
Ensure that these roles are installed on both front-end servers. Contoso followed the IIS Security Best Practices to configure both servers. This step should be performed before you configure the application so that the application will be immediately running on a secure platform.
Important Some of these settings might affect the application’s functionality. We recommend that before you deploy the application for production on a hardening Internet Information Services (IIS) server, you test all the functionalities to see if the security changes will affect the application’s behavior.
After the Application Server and Web Server roles are installed on each front-end server, you need to install the certificate that it will be used by the application on each web server. This certificate could be generated by an internal certification authority or by a trusted third-party public certification authority. Contoso decided to leverage its internal PKI infrastructure to issue a certificate to install on both front-end servers. For more information about how to install a certificate in IIS 8, see Centralized SSL Certificate Support: SSL Scalability and Manageability.
2.4.2 Install and Configure the Application
The application’s configuration will depend on the environment. For Contoso, the requirement is to validate authentication with Active Directory in a secure manner and to access the on-premises database. To validate this environment, Contoso uses a simple ASP.NET MVC4 Web Application. The application was copied to D:\Inetpub\wwwroot (which is another disk separated from the OS in order to improve performance) on both front-end servers. After the files are there, you can use IIS Manager to convert the folder to an application. Basic authentication was enabled in IIS to validate the authentication with the domain. Because the traffic will be encrypted, this method offers no harm to the user’s credential. The application used by Contoso makes a connection with the on-premises SQL Server 2012 to retrieve data and to show the results on the screen. For more information about how to enable basic authentication in IIS 8, see Authentication.
Note You can use sample applications that are available in the Windows Azure Training Kit (from the Microsoft Download Center) and a sample database from Adventure Works for SQL Server 2012 (from CodePlex).
2.4.3 Configure the Database Server
Contoso is using an existing database server, which is located on premises, to validate this hybrid deployment. The configuration of the database will depend on the application. In Contoso’s case, no additional configuration was necessary because the database was already in production for another application. For more information, see Install SQL Server 2012.
2.5 Configure a Load-Balanced Endpoint
A load-balanced endpoint in Windows Azure is a specific TCP or UDP endpoint that is used by all virtual machines that are contained in a cloud service. The load balancer in Windows Azure maps requests from external clients that are accessing the application from the Internet to Windows Azure Load Balancer, which will map the front-end server that will be used for that request. Use the following steps to configure this feature in Windows Azure.
| Step | Task | Target |
| 2.5.1 | Add an Endpoint to a Virtual Machine | Windows Azure |
| 2.5.2 | Change DNS | On-Premise DNS server |
| 2.5.3 | Validate the configuration | Client workstations |
Back to section 2.0
2.5.1 Add an Endpoint to a Virtual Machine
From the Windows Azure Management Portal, access the first front-end server (virtual machine) that will be used to load balance the web request, and add the endpoint to port 443. Include a name that makes it easy to identify the purpose of this endpoint, and ensure that the protocol in use is TCP and the public port is 443. Although is not mandatory that the private port is the same as the public port, for Contoso’s scenario the private port is the same (443). In Contoso’s scenario, the access to the application will always be through the Internet. This avoids passing traffic through the VPN tunnel, which leaves this tunnel exclusively for application traffic and remote desktop access to the virtual machines. Users will be using the external URL to access the application through a browser, and the load balancer in Windows Azure will handle the traffic. For detailed steps for creating an endpoint, see How to Set Up Communication with a Virtual Machine.
2.5.2 Change DNS
By default, Windows Azure will use the URL, cloudapp.net. However, Contoso decided to create an entry on their external DNS server to support their name schema. For more information, see Configuring a custom domain name for a Windows Azure cloud service.
2.5.3 Validate the Configuration
To validate a configuration for an endpoint, you need to access the public DNS server name of the virtual machine. You can find this name on the virtual machine dashboard in the Management Portal. To validate if the load balancing is correctly happening between servers, you can access the URL from a client workstation to verify if you can access the application. At this point, you could turn off one front-end server and refresh the browser session. If you get an error message that says the service is unavailable, refresh it again and see if you are able to access the application. In Contoso’s scenario, the validation was successful. After one refresh in the web browser, the session was established on the second front-end server.
2.6 Deploy System Center Advisor
Contoso will use Microsoft System Center Advisor as a service to proactively monitor the virtual machines that are located in Windows Azure and to mitigate potential issues due to a server misconfiguration. Use the following steps to deploy System Center Advisor.
| Step | Task | Target |
| 2.6.1 | Create or Associate a Microsoft Account with System Center Advisor | Microsoft account and System Center Advisor |
| 2.6.2 | Download the Setup and Registration Certificate | System Center Advisor |
| 2.6.3 | Deploy the Advisor Agent to the Target Servers | Target servers |
| 2.6.4 | Monitor Servers by Using System Center Advisor | System Center Advisor |
Back to section 2.0
2.6.1 Create or Associate a Microsoft Account to System Center Advisor
The first step is to create or associate an existing Microsoft account to the System Center Advisor service. If you already have a Microsoft Outlook.com, Hotmail.com, or Windows Live account, access the System Center Advisor site, and associate this account to a new advisor. If not, create an account and associate it with a new advisor. System Center Advisor will ask you to create a new password if the one you provide doesn’t meet the complexity requirements.
2.6.2 Download the Setup and Registration Certificate
The System Center Advisor Setup Wizard will install gateway and agent files. These files will be later deployed to each target server that you want to monitor. The certificate is used by the setup program to identify your System Center Advisor account. To download the gateway and agent files, sign in to the System Center Advisor portal, and download them from the dashboard. After you download the files, you will copy them to every target server that you want to monitor. In Contoso’s scenario, one of the front-end servers is used as a gateway and the other three servers (the second front-end server and two domain controllers) are configured as agents.
2.6.3 Deploy the Advisor Agent on the Target Servers
To deploy the agent on the target server first you need to install .NET Framework 3.5. If your target server is running Windows Server 2012, you can use the following command to install .NET Framework 3.5 (it requires the Windows Server 2012 DVD or the ISO file):
dism.exe /online /enable-feature /featurename:NetFX3 /Source:D:\sources\sxs
When you finish installing this prerequisite, run the AdvisorSetup.exe and follow the wizard to deploy the agent file.
Note There is also a prerequisite to install System Center 2012 Operations Manager, but you don’t need to do this separately because the System Center Advisor Setup Wizard will do it for you.
During the installation, you will have a chance to choose the following installation options:
- Gateway:
You should choose one server in your infrastructure to be the gateway. This server will be responsible for gathering information from the agents and sending it to System Center Advisor. - Agent:
This option will enable the target server to collect information and send it to the gateway server.
The gateway and agent servers communicate with each other by using port 80. If this port is not already open, it will be automatically enabled by the setup wizard. After the System Center Advisor installation is complete, the System Center Advisor Configuration Wizard will open so that you can finish the customization. During this wizard, you will be able to configure the following settings:
- Gateway Settings (if you are installing a gateway):
You will inform the location of the Personal Information Exchange (PFX) file that you downloaded in section 2.6.2 Download the Setup and Registration Certificate. You can also configure the proxy settings to restrict connections from this gateway to certain agents. - Agent Settings (if you are installing an agent):
You will inform the name of the gateway server (by using the FQDN)
When the System Center Advisor Configuration Wizard for the gateway is complete, you should see a page similar to Figure 4.
Figure 4
2.6.4 Monitor Servers by using System Center Advisor
After you configure the gateway and deploy the agent files on all the virtual machines that you want to monitor, you can manage your environment by using the System Center Advisor portal. Sign in to the System Center Advisor site, and use the options in the left pane to verify alerts, snapshots, change history, servers, and accounts. When you first deploy the agent files in your environment, it is expected to have a delay for some reports. The example shown in Figure 5 is for the Servers option. An error message shows that a new agent was detected, but it is not yet reported to the advisor.
Figure 5
For more information about how to manage your agents from the System Center Advisor portal, see System Center Advisor Help.
2.7 Configure Same Sign-On
To provide a seamless experience for users who are allowed to manage the portal, Contoso decided to implement a same sign-on process by using Active Directory Federation Services (AD FS) with Windows Azure. Use the following steps to enable this process.
| Step | Task | Target |
| 2.7.1 | Review Same Sign-On Requirements | On-Premise |
| 2.7.2 | Prepare the Infrastructure | On-Premise |
| 2.7.3 | Install and Configure the AD FS | On-Premise |
| 2.7.4 | Configure Trust Between AD FS and Windows Azure | On-Premise and Windows Azure |
Back to section 2.0
2.7.1 Review Same Sign-On Requirements
For this phase of the project, Contoso needs to ensure that the target server that will receive AD FS has a server authentication certificate installed. The subject name of this Secure Socket Layer (SSL) certificate is used to determine the federation service name for each instance of AD FS that you deploy. Contoso decided to choose a subject name that represents the name of its company. Although Contoso has only one AD FS server to deploy now, they understand that to have a more robust Same Sign-On infrastructure, they need to use the Server Farm option, which allows them to later add more servers. Contoso will leverage its internal PKI infrastructure to generate a server authentication certificate, which will be used to secure communications between federation servers, clients, and federation server proxy computers.In the future, when Contoso adds more servers to its infrastructure, it will evaluate the need to use network load balancing (NLB) to provide fault tolerance, high availability, and load balancing across multiple nodes.
2.7.2 Prepare the Infrastructure
Contoso will install AD FS on a dedicated member server running Windows Server 2012. The core steps to prepare the infrastructure for AD FS are:
- Install the Web Server role. For more information, see Web Server (IIS) Overview.
- Obtain and install a server authentication certificate on the default website for AD FS. For more information, see Centralized SSL Certificate Support: SSL Scalability and Manageability.
- Configure a dedicated service account in AD FS. Although Contoso is starting the implementation with only one server, this step is required if you plan to add more servers. This dedicated service account is necessary to ensure that all resources required by the AD FS farm are granted access to each of the federation servers in the farm.
2.7.3 Install and Configure AD FS
The process to install AD FS in Windows Server 2012 is similar to installing any other role. By installing AD FS, you are enabling the capability of that server to be a federation server, and all the configuration is done after this phase. Contoso installed AD FS on premises. For more information, see Install the AD FS software. After the installation, some important decisions must be made to configure AD FS. Contoso made the following decisions:
- Deployment Type:
As previously explained, Contoso has plans to expand the number of AD FS servers. For this reason, they selected the Farm Deployment option. - Certificate selection:
On the Specify the Federation Service Name page, the AD FS Federation Server Configuration Wizard automatically selects the certificate that it is installed on the default website in IIS. That’s why it is important to perform the steps that are described in section 2.7.2 Prepare the Infrastructure. - Service Account:
On the Specify a Service Account page, they select the account that was previously created. - Download and install Windows PowerShell for single sign-on with AD FS:
This is a necessary to configure the trust between AD FS and Windows Azure.
For more information about how to install this module, see Manage Windows Azure Active Directory by Using Windows PowerShell. For more information about configuring the AD FS server, see Configure the first federation server in the federation server farm. When you finish the installation, you can validate the AD FS configuration by following the steps described in the Verify that the federation server is operational.
2.7.4 Configure Trust Between AD FS and Windows Azure
Establishing trust between AD FS and Windows Azure is a one-time operation, which means that even if you later add more servers in the AD FS farm, you will not need to perform this step again. For information about how to set up this trust by using Windows PowerShell, see Set up a trust between AD FS and Windows Azure AD.
Important If for some reason, your AD FS server resides in Windows Azure, ensure that you create an endpoint port (443) for this AD FS server in the Windows Azure Management Portal. This step is necessary to allow the connectivity between Windows Azure and AD FS during the authentication process. If you don’t perform this step, a user who is trying to sign in into the Management Portal might receive the following error message: This page can’t be displayed. For more information, see section 2.5 Configure a Load-Balanced Endpoint.
2.8 Configure Windows Azure Active Directory
Contoso will use Windows Azure Active Directory to provide the same credential experience for users who are allowed to manage the Management Portal. Use the following steps to set up Windows Azure Active Directory:
| Step | Task | Target |
| 2.8.1 | Add a Custom Domain | Windows Azure |
| 2.8.2 | Create a New User Account | Windows Azure |
| 2.8.3 | Download and Install DirSync | Windows Azure and target server |
| 2.8.4 | Validate the Configuration | Windows Azure and On-Premise |
Back to section 2.0
2.8.1 Add a Custom Domain
The default enterprise directory in a subscription to Windows Azure comes with a basic domain (yourdomain.onmicrosoft.com). To associate the domain that you primarily use in your company to subscription to Windows Azure, you should add a custom domain. During the steps to add a custom domain, the Add Custom Domain Wizard provides the information that you need to create a TXT record in the authoritative DNS server for the domain that you want to customize. In Contoso’s scenario, the administrator created a TXT record under contoso.com zone on the DNS server. The parameters for this record are provided by the wizard. After you create the record, you can click Verify to validate the domain. When the verification is complete, the local Active Directory integration is activated. To check it in Windows Azure, click Default Directory, and then click Directory Integration. This is shown in Figure 6.
Figure 6
For more information, see the section Configure the Custom Domain in How to Map CDN Content to a Custom Domain.
2.8.2 Create a New User Account
After the custom domain is created, you should create a new user account in this domain. This user will be the co-administrator of the portal, and the account will be used to perform directory synchronization by using the DirSync tool. To create a new user account, click Active Directory in the left pane of the Management Portal, and then click Default Directory. You will see the dashboard as shown in Figure 7. Under Explore, click Add a user.
Figure 7
When you add a new user to be the co-administrator of your directory, make sure to:
- Add a user in your organization.
- Select the domain (@yourdomain) to be the suffix for the user instead of the default suffix (@yourdomain.onmicrosoft.com).
- Choose the global administrator role.
- Provide an alternative email address for the user, such as @outlook.com.
The Add User Wizard will provide a temporary password when the account is created. Safely send this temporary password to the user. The user must change the password at the first sign-in to the Management Portal. After you create this user account, you can allow the user to be a co-administrator for the Management Portal. For more information, see Add and Remove Co-Administrators for Your Windows Azure Subscriptions.
Important Assuming that you will use this user account to install the DirSync tool, this password must be changed before the next step.
2.8.3 Download and Install DirSync
The next step is to prepare the directory synchronization, which requires downloading the DirSync tool. The link to download DirSync is provided in the Management Portal. As shown in Figure 6, on the Directory Integration page, click Directory Sync. For more information about the prerequisites for installing this tool, see Prepare for directory synchronization. In Contoso’s scenario, this tool was downloaded to a member server located on premises. After downloading the tool and reviewing the prerequisites, open the DirSync tool. The Windows Azure Active Directory Sync tool Configuration Wizard will appear as shown in Figure 8.
Figure 8
On the first page of this wizard, you must type the user name that was created in the previous step and the credentials (after the password was changed). As shown in Figure 9, on the Password Synchronization page, select the Enable Password Synccheck box to enable directory synchronization.
Figure 9
As shown in Figure 10, when the configuration is finished, the wizard will ask for confirmation to perform the directory synchronization. Click Finish to confirm.
Figure 10
2.8.4 Validate the Configuration
Now that the directory is synchronized, you can create one on-premises Active Directory account, and this account will be synchronized in Windows Azure Active Directory. This will provide the same credential experience for the users. On the Default Directory page in Windows Azure, click Users (see Figure 6). You will see all the accounts—those created in Windows Azure Active Directory and those that were replicated from your on-premises Active Directory account. As shown in Figure 11, the accounts that were replicated will appear under Local Active Directory in the Sourced From column.
Figure 11
For more information if the synchronization is not success, see Verify directory synchronization.
Now you can validate the Same Sign-On scenario between a domain-joined computer and your Microsoft cloud service. Sign-in by using the same name and password that you use for your corporate credentials. Click the Password text box. If Same Sign-On is set up, the password box will be shaded, and you will be redirected as shown in Figure 12.
Figure 12
2.9 Configure Windows Azure Autoscale
Contoso will take advantage of the autoscale capability in Windows Azure to enhance the overall performance of their front end web servers. To enable autoscale you will select the Cloud Service and then click the name of the cloud service that has the availability set that contains the VMs. The autoscale option is available under scale as shown in Figure 13:
Figure 13
Contoso has a cloud service called fendweb1 and within this cloud service it has the availability set called FENDSERVERS with 5 small instances. They will be adjusting the autoscale to CPU based on the settings below:
- Minimum 3 instances of small (1 Core, 1.75 GB Memory)Contoso wants to start with 3 instances since currently those two front end web servers located on-premises are already overloaded
- Target CPU of 65 to 75Contoso wants to work on a safe range, which is based on their baseline collected when this application was running on-premise.
Scale up and down wait time of 30 minutes after last action Contoso wants to make sure that the platform is stable before make any change. It was decided that 30 minutes is a good time to make changes after other actions were done. After finishing the configuration, Contoso’s autoscale options are similar to Figure 14:
Figure 14
Read How to Scale an Application for more detailed information on the options available for this setting.
Back to section 1.0
3.0 Summary
This article detailed the steps that are required to implement the design that is detailed in Hybrid Cloud Infrastructure Design Considerations of this article set. If you haven’t read that article, and you are interested in understanding the design that the steps in this article explain, you’re encouraged to read it.
4.0 Technologies Discussed
DNS server
Active Directory Federation Services in Windows Server 2012
Active Directory Certificate Services in Windows Server 2012
Web Server (IIS) role in Windows Server 2012
Active Directory Domain Services
Windows Azure Active Directory
Windows Azure Virtual Machines
Windows Azure Cloud Services
Windows Azure Storage
Windows Azure Storage Services
Windows Azure Recovery Service
Windows Azure Virtual Network
SQL Server 2012
5.0 Authors and Reviewers
Author:
Yuri Diogenes - Microsoft
Contributor:
Tom Shinder - Microsoft
Reviewer:
Jim Dial – Microsoft
6.0 Change Log
| Version | Date Published | Change description |
| 1.0 | 08/23/2013 | Initial posting and editing complete. |
Comments
Anonymous
January 01, 2003
BTW - you can find the design guide on which this implementation was based over at http://aka.ms/hybriditdesign Thanks!Anonymous
January 01, 2003
This implementation guide provides you with a step-wise approach that you can use when implementing the hybrid cloud infrastructure design that was described in the design guide.Anonymous
January 01, 2003
Wren, I do not know of a current document that addresses this scenario to the level of depth this article does. An updated version of much of what's covered in the guides for this scenario content are addressed in the Datacenter extension reference architecture diagram (http://aka.ms/derad), and the content that it links out to though.Anonymous
May 26, 2015
Hi all (Jim) -
Is there subsequent articles to this one? I notice that it was last updated in 2013 and as we all know the cadence of change with Azure is lightning quick. I'm working with a government agency and moving them into Azure. While I do my best to keep up what is the best de facto resource for Azure evolution?
wren@cloudlasso.net