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.
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.
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.
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.
Back to section 1.0
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 subscription account 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
After the Windows Azure account is provisioned, you should use the following steps to start the site-to-site virtual private network (VPN) configuration.
Ensure that the VPN device that will be used to connect to the Windows Azure Gateway has the following capabilities:
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:
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:
For more information about the restrictions and capabilities of a virtual network in Windows Azure, see Virtual Network FAQ.
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:
For more information about how to obtain this information, read Create a Virtual Network for Site-to-Site Cross-Premises Connectivity.
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.
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.
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.
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:
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.
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:
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.
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.
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:
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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:
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:
When the System Center Advisor Configuration Wizard for the gateway is complete, you should see a page similar to Figure 4.
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.
For more information about how to manage your agents from the System Center Advisor portal, see System Center Advisor Help.
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.
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.
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:
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:
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.
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.
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:
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.
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:
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.
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.
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 Sync check box to enable directory synchronization.
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.
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
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:
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:
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.
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.
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
Author: Yuri Diogenes - Microsoft
Contributor: Tom Shinder - Microsoft
Reviewer: Jim Dial – Microsoft
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.
BTW - you can find the design guide on which this implementation was based over at http://aka.ms/hybriditdesign Thanks!