Hands-On LabWindows Azure: Deploying and Monitoring Applications in Windows AzureLab version: 1.0.0

Last updated: 5/8/2023

Page | 1

CONTENTS

OVERVIEW................................................................................................................................................. 3

EXERCISE 1 - DEPLOYING AN APPLICATION USING THE WINDOWS AZURE DEVELOPER PORTAL...................................................................................................................................................... 7

Task 1 – Creating a Windows Azure Account.......................................................................................7

Task 2 – Creating a Storage Account and a Hosted Service Component..............................................9

Task 3 – Deploying the Application to the Windows Azure Developer Portal...................................15

Task 4 – Configuring the Application to Use the Storage Account.....................................................19

Task 5 – Testing the Application in the Staging Environment............................................................22

Task 6 – Promoting the Application to Production............................................................................26

EXERCISE 2 - USING POWERSHELL TO MANAGE WINDOWS AZURE APPLICATIONS..................28Task 1 – Generating a Self-Signed Certificate (Optional)...................................................................29

Task 2 – Preparing the Windows Azure Account...............................................................................29

Task 3 – Uploading a Service Package Using Windows PowerShell...................................................33

Task 4 – Upgrading a Deployment Using Windows PowerShell.........................................................37

Verification........................................................................................................................................40

EXERCISE 3 - MONITORING APPLICATIONS IN WINDOWS AZURE...................................................41Task 1 – Configuring Azure Storage for Persisting Diagnostics Data..................................................42

Task 2 – Enabling Failed Request Tracing..........................................................................................43

Task 3 – Instrumenting a Web Role...................................................................................................50

Task 4 – Monitoring Azure Services Remotely...................................................................................57

Verification........................................................................................................................................62

SUMMARY................................................................................................................................................ 67

Page | 2

Overview

In this hands-on lab, you will learn how to deploy your first application in Windows Azure. The lab walks through the process using a simple application named myTODO, which is a simple list creation and management application built using ASP.NET MVC. The lab shows the steps required for provisioning the required components in the Windows Azure Developer Portal, uploading the service package, and configuring the service. You will see how you can test your application in a staging environment and then promote it to production once you are satisfied that it is operating according to your expectations.

Figure 1The myTODO application running in Windows Azure

In the course of the lab, you will also examine how to deploy, upgrade, and configure Windows Azure applications programmatically using the Service Management API. You will use the Windows Azure Service Management Tools, which wrap the management API, to execute Windows PowerShell scripts that perform these operations.

Page | 3

Finally, you will explore the Diagnostics Management API to monitor applications and gather diagnostics information. You will instrument the myTODO application, adding performance counters and trace messages. You will then configure the diagnostics infrastructure to store this information in an Azure Storage account and examine the information it produces.

Objectives

In this Hands-On Lab, you will learn how to:

Use the Windows Azure Developer Portal to create storage accounts and hosted service components

Deploy service component packages using the Windows Azure Developer Portal user interface

Change configuration settings for a deployed application

Test deployments in a separate staging environment before deployment to final production

Use Windows PowerShell to deploy, upgrade, and configure Windows Azure services programmatically

Monitor applications and gather diagnostics information using Windows Azure Diagnostics

Prerequisites

The following is required to complete this hands-on lab:

Microsoft .NET Framework 3.5 SP1

Microsoft Visual Studio 2008 SP1 (or above)

Windows Azure Tools for Microsoft Visual Studio (November 2009)

ASP.NET MVC 1.0

IIS 7 (with ASP.NET, WCF HTTP Activation, Tracing)

Windows Azure Service Management CmdLets 1.1

Note: The source code for the Windows Azure Service Management CmdLets is included in the Assets folder and built during setup.

Setup

For convenience, much of the code used in this hands-on lab is available as Visual Studio code snippets. To check the prerequisites of the lab and install the code snippets:

Page | 4

1. Run the SetupLab.cmd script located in the lab's Source\Setup folder to check dependencies and install any missing prerequisites.

2. Once you have verified every prerequisite, follow the instructions to install the code snippets.

Using the Code Snippets

With code snippets, you have all the code you need at your fingertips. The lab document will tell you exactly when you can use them. For example,

To add this code snippet in Visual Studio, you simply place the cursor where you would like the code to be inserted, start typing the snippet name (without spaces or hyphens), in this case LabNameEx01RunmethodCS, watch as Intellisense picks up the snippet name, and then hit the TAB key twice once the snippet you want is selected. The code will be inserted at the cursor location.

Figure 2

Page | 5

Hit TAB to select the highlighted snippet.

Figure 3Hit TAB again and the snippet will expand

To insert a code snippet using the mouse rather than the keyboard, right-click where you want the code snippet to be inserted, select Insert Snippet followed by My Code Snippets and then pick the relevant snippet from the list.

To learn more about Visual Studio IntelliSense Code Snippets, including how to create your own, please see http://msdn.microsoft.com/en-us/library/ms165392.aspx.

Exercises

This hands-on lab comprises the following exercises:

1. Deploying an Application Using the Windows Azure Developer Portal

2. Using PowerShell to Manage Windows Azure Applications

3. Monitoring Applications in Windows Azure

Estimated time to complete this lab: 60 minutes.

Exercise 1 - Deploying an Application Using the Windows Azure Developer Portal

In this exercise, you deploy the myTODO application to Windows Azure using the Windows Azure Developer Portal. To do this, you register a Windows Azure developer account and provision the

Page | 6

required service components. Next, you upload the application package to the staging area and configure it. You then execute the application in this staging area to verify its operation. Finally, you promote the application to production.

Task 1 – Creating a Windows Azure Account

In this task, you create a new Windows Azure account and redeem an invitation token to enable the creation of hosted services.

1. Navigate to http://windows.azure.com using a Web browser and sign in using your Windows Live ID.

Figure 4Signing in to the Windows Azure portal

2. If this is your first visit to the Windows Azure Developer Portal, create a new account associated to your Windows Live ID. Review the Privacy Statement and click I Agree to proceed.

Figure 5Creating a new Windows Azure Developer Portal account

3. After creating the account, click Continue to proceed.

Page | 7

Figure 6Successful creation of the account

4. Enter your invitation token and click Next to redeem it.

Note: Invitation tokens are required to enable services at the Windows Azure Developer Portal. To obtain an invitation token, you will need to register at http://connect.microsoft.com to obtain a product key for the Windows Azure Platform.

Figure 7Redeeming an invitation token to enable the creation of hosted services

Task 2 – Creating a Storage Account and a Hosted Service Component

The application you deploy in this exercise requires both compute and storage services. In this task, you create a new Windows Azure storage account to allow the application to persist its data. In addition, you define a hosted service component to execute application code.

1. In My Projects, locate the project where you will deploy the application and click the Project Name link to view the list of services under it.

Note: The items in this list are projects associated with your Windows Live ID. Following commercial launch, you will see every project that you have purchased listed here.

Page | 8

Figure 8Available projects in your Windows Azure account

2. First, you create the storage account that the application will use to store its data. In the Windows Azure Summary page, click New Service.

Figure 9Creating a new Windows Azure service

3. In the Windows Azure Summary page, click Storage Account.

Page | 9

Figure 10Creating a new Windows Azure storage account

4. Enter the Service Component Label and Service Component Description and click Next to proceed. The values you enter here allow you to identify the account storage component in the portal user interface.

Figure 11Configuring the service component properties

5. In the Storage Account Name section, enter the name for your storage account, for example, <yourname>todo, where <yourname> is a unique name. Windows Azure uses this value to generate the endpoint URLs for the storage account services. To ensure that the name is valid,

Page | 10

click Check Availability to verify that the name satisfies the naming rules and is currently available.

Note: The name used for the storage account corresponds to a DNS name and is subject to standard DNS naming rules. Moreover, the name is publicly visible and must therefore be unique.

6. In the Storage Account Affinity Group section, click "Yes, this service is related to some of my other hosted services or storage accounts and needs to be stored in the same region." and then select the "Create a new Affinity Group Region" option. Set the value of the affinity group to the label mytodo and choose the region where you wish your service to run, most likely, the one that is closest to your current location.

Figure 12Configuring the storage account URL and affinity group

Page | 11

Note: The reason that you are creating a new affinity group is to deploy both the hosted service and storage account to the same location, thus ensuring high bandwidth and low latency between the application and the data it depends on.

7. Click Create to register your new storage account. Wait until the account provisioning process completes and updates the Summary page. Notice the available Endpoints and the Access Keys assigned to the storage account. Record the Storage Account Name and the value assigned to the Primary Access Key. You will use these values later on to configure the application.

Note: The Endpoints specify the URLs of the blob, queue, and table storage services for this account.

The Primary Access Key and Secondary Access Key both provide a shared secret that you can use to access storage. The secondary key gives the same access as the primary key and is used for backup purposes. You can regenerate each key independently in case either one is compromised.

Figure 13Successful creation of the storage account

Page | 12

8. Next, create the compute component that executes the application code. Click New Service once again to create a hosted services account for the application. In the Project section, click Hosted Services.

Figure 14Creating a new hosted service

9. Enter the Service Label and Service Description and click Next to proceed. The values you enter here allow you to identify the hosted service in the portal user interface.

Figure 15Configuring the service properties

Page | 13

10. In the Hosted Service URL section, enter the name for your hosted service, for example, <yourname>todo, where <yourname> is a unique name. Windows Azure uses this value to generate the endpoint URL of the hosted service. To ensure that the name is valid, click Check Availability to verify that the name satisfies the naming rules and is currently available.

Note: If possible, choose the same name for both the storage account and hosted service. However, you may need to choose a different name if the one you select is unavailable.

11. In the Storage Account Affinity Group section, click "Yes, this service is related to some of my other hosted services or storage accounts and needs to be stored in the same region." and then select the "Use existing Affinity Group Region" option. Select mytodo in the affinity group drop down list; this is the affinity group that you created earlier.

Note: By choosing mytodo as the affinity group, you ensure that the hosted service is deployed to the same data center as the storage account that you provisioned earlier.

Figure 16Page | 14

Configuring the hosted service URL and affinity group

12. Click Create to register the hosted service and wait until the provisioning process completes.

Task 3 – Deploying the Application to the Windows Azure Developer Portal

A hosted service is a service that runs your code in the Windows Azure environment. It has two separate deployment states: staging and production. A staging deployment allows you to test your service in the Windows Azure environment before you deploy it to production.

In this task, you create a service package for the myTODO application and then deploy it to the staging environment using the Windows Azure Developer Portal.

1. Open Microsoft Visual Studio 2008 in elevated administrator mode, in Start | All Programs | Microsoft Visual Studio 2008, by right clicking the Microsoft Visual Studio 2008 shortcut and choosing Run as Administrator.

2. In the File menu, choose Open and then Project/Solution. In the Open Project dialog, browse to Ex01-DeployingUsingWAZPortal\Begin in the Source folder of the lab, select MyTodo.sln in the folder for the language of your preference (Visual C# or Visual Basic) and click Open.

The solution contains the following projects:

MyTodo A standard cloud service project configured to support a single web role named MyTodo.WebUx

MyTodo.Data.WindowsAzure A class library project that contains data contracts for the MyTodo.WebUx application for table storage

AspProviders An implementation of ASP.NET Membership, Role, and SessionState providers for Azure Storage

MyTodo.WebUx A web role that hosts the MyTODO ASP.NET MVC application in Windows Azure

3. Ensure that the System.Web.MVC assembly is included in the service package that you deploy to Windows Azure. To do this, for a Visual C# project, expand the References node in Solution Explorer for the MVCAzureStore project, right-click the System.WebMVC assembly and select Properties. For a Visual Basic project, right-click the MVCAzureStore project and select Properties. In the Project Properties window, switch to the References tab, select the System.Web.MVC assembly, and press F4.

To add the assembly to the service package, in the Properties window for the System.Web.Mvc assembly, change the value of the Copy Local setting to True.

Page | 15

Figure 17Including assemblies in the service package deployed to Windows Azure

Note: In general, you need to set Copy Local = True for any assembly that is not installed by default in the Windows Azure VMs to ensure that it is deployed with your application.

4. To create a service package, right-click the cloud service project and select Publish. This opens Windows Explorer to the Publish folder in your solution folders, and opens up the Windows Azure Developer Portal in your browser

5. Open the Summary page for the project that you created in the previous task.

6. In the hosted service Summary page, click Deploy to upload the service package to the portal.

Page | 16

Figure 18Hosted service summary page

7. In the Staging Deployment page, under the App Package section, click "Upload a file from your local storage" to select it. Click Browse to navigate to the Publish folder in your solution, which should already be open in a Windows Explorer window, and select MyTodo.cspkg.

Note: The .cspkg file is an archive file that contains the binaries and files required to run a service, in this case, the myTODO ASP.NET MVC application. Visual Studio 2008 creates the service package for you when you select Build | Publish for your cloud project.

8. In the Configuration Settings section, once again select "Upload a file from your local storage", click Browse and select ServiceConfiguration.cscfg using the same folder that you used in the previous step.

Note: The .cscfg file contains configuration settings for the application, including storage settings that you will update later in the exercise.

9. Finally, in the Properties section, enter a label to identify the deployment; for example, use v1.0.

Note: The portal displays the label in its user interface for staging and production, which allows you to identify the version currently deployed in each environment.

Page | 17

Figure 19Configuring service package deployment

10. Click Deploy to start uploading the package to the Windows Azure Developer Portal.

Figure 20Uploading a service package to the Windows Azure Developer Portal

Page | 18

11. Wait until the deployment process finishes, which may take several minutes. At this point, you have already uploaded the package and it is in an Allocated state. Notice that the portal assigned this deployment a Web Site URL that includes a unique identifier. Shortly, you will access this URL to test the application and determine whether it operates correctly in the Windows Azure environment, but first you need to configure it.

Note: During deployment, Windows Azure analyzes the configuration file and copies the service to the correct number of machines, ready to start. Load balancers, network devices and monitoring are also configured during this time.

Figure 21Package successfully deployed

Task 4 – Configuring the Application to Use the Storage Account

Before you can test the deployed application, you need to configure it. In this task, you define the storage account settings for the application.

1. In the Summary page, under the Hosted Service section, click Configure for the Staging environment.

Page | 19

Figure 22Configuring application settings

2. In the Service Tuning page, under Configuration Settings, update the value of the AccountName setting by replacing the placeholder labeled [YOUR_ACCOUNT_NAME] with the Storage Account Name that you chose when you configured the storage account in Task 2. If you followed the recommendation, the name should follow the pattern <yourname>todo, where <yourname> is a unique name.

3. Next, update the AccountSharedKey setting by replacing the placeholder labeled [YOUR_ACCOUNT_KEY] with the Primary Shared Key value that you recorded earlier when you created the storage account in Task 2.

4. Finally, locate the Instances element and change the count attribute to a value of 2.

Note: The Instances setting controls the number of roles that Windows Azure starts and is used to scale the service. Currently, it is limited to a maximum of two instances. However, once the service is commercially available, you will be able to change it to any number that you are willing to pay for.

Page | 20

Figure 23Setting the storage account name and shared key

Note: The configuration is simply an XML document that contains the value of the settings declared in the service definition file and its initial content is determined by the ServiceConfiguration.cscfg file that you uploaded earlier when you deployed the package in Task 3.

5. Click Save to update the configuration and wait for the hosted service to apply the new settings.

Note: The portal displays a legend "Package is updating..." while the settings are applied.

Page | 21

Task 5 – Testing the Application in the Staging Environment

In this task, you run the application in the staging environment and access its Web Site URL to test that it operates correctly.

1. In the Summary page, under the Hosted Service section, click Run for the deployment in the Staging environment.

Figure 24Running the application in the staging environment

2. Wait until the status of the service is shown first as Initializing and then as Ready.

Note: The process may take several minutes during which Windows Azure provisions servers, load balancers and other network devices, as well as preparing to monitor the application. Once the application is running, it takes care of patching the OS, recovering from hardware failure, and ensuring that storage is available.

Page | 22

Figure 25Application initialization process

3. Once the service has started, click the Web Site URL link to open a new browser window that points to the application.

Note: The address URL is shown as <guid>.cloudapp.net, where <guid> is some random identifier. This is different from the address where the application will run once it is in production. Although the application executes in a staging area that is separate from the production environment, there is no actual physical difference between staging and production – it is simply a matter of where the load balancer is connected.

In the future, you will be able to have multiple “virtual” areas, for test, QA, pre-production, etc...

4. Click Start to prepare the application for first time use, which requires you to register a new account.

Page | 23

Figure 26Application running in the staging environment

5. Complete the account details by entering a user name, email address, and password and then click Register. You can omit the remaining fields for this test.

Note: Account information is stored in the storage account created earlier. Data is not shared between to do lists.

Page | 24

Figure 27Creating a new account

6. Next, the application enumerates the lists that you have currently defined. Since this is your first use, no lists should appear.

Page | 25

Figure 28Application ready to be used

7. If you wish to explore the application, create a new TODO list and enter some items.

Task 6 – Promoting the Application to Production

Now that you have verified that the service is working correctly in the staging environment, you are ready to promote it to final production. When you deploy the application to production, Windows Azure reconfigures its load balancers so that the application is available at its production URL.

1. In the Summary page, under the Hosted Service section, click the Swap button (this is the circular button located between the Production and Staging areas). When prompted, click OK to confirm that you wish to promote to the production deployment.

Page | 26

Figure 29Promoting the application to the production deployment

2. Wait for the promotion process to complete, which typically takes a few seconds. Notice that the Production service status is now shown as Ready and that the Web Site URL corresponds to the URL that you chose earlier, when you configured the hosted service in Task 2.

Figure 30Application successfully deployed to production

Page | 27

3. Click the Web Site URL link to open the production site in a browser window and notice the URL in the address bar.

Figure 31Application running in the production environment

Note: If you visit the production site shortly after its promotion, the DNS name might not be ready. If you encounter a DNS error (404), wait a few minutes and try again. Keep in mind that Windows Azure creates DNS name entries dynamically and that the changes might take few minutes to propagate.

Exercise 2 - Using PowerShell to Manage Windows Azure Applications

Page | 28

Typically, during its lifetime, an application undergoes changes that require it to be re-deployed. In the previous exercise, you saw how to use the Windows Azure Developer Portal to deploy applications. As an alternative, the Service Management API provides programmatic access to much of the functionality available through the Developer Portal. Using the Service Management API, you can manage your storage accounts and hosted services, your service deployments, and your affinity groups.

The Windows Azure Service Management PowerShell Cmdlets wrap the Windows Azure Service Management API. These cmdlets make it simple to automate the deployment, upgrade, and scaling of your Windows Azure application. By pipelining commands, you compose complex scripts that use the output of one command as the input to another.

In this exercise, you will learn how to deploy and upgrade a Windows Azure application using the Azure Services Management Cmdlets.

Task 1 – Generating a Self-Signed Certificate (Optional)

To ensure that access to the Service Management API is secure, you must first associate a certificate with your subscription. The management service uses the certificate to authenticate requests. You can use a self-signed certificate or one signed by a certification authority. Any valid X.509 v3 is suitable as long as its key length is at least 2048 bits.

In this task, you generate a certificate that you can upload to the Windows Azure Developer Portal. This step is optional if you already have a certificate signed by a certificate authority.

1. Open a Visual Studio 2008 Command Prompt in elevated administrator mode, from Start | All Programs | Microsoft Visual Studio 2008 | Tools by right clicking the Visual Studio 2008 Command Prompt shortcut and choosing Run as Administrator.

2. Change the current directory to the location where you wish to store your certificate file.

3. At the prompt, type the following command to generate a local certificate file.

Visual Studio Command Prompt

makecert -r –pe -n "CN=AzureMgmt" -a sha1 -len 2048 -ss My "AzureMgmt.cer"

Note: This command creates a new self-signed certificate with a key length of 2048 bits, writes it to the "AzureMgmt.cer" file in the current directory and saves it to the My certificate store for the current user.

Task 2 – Preparing the Windows Azure Account

To use the Windows Azure Service Management API, you have to upload the certificate to your Windows Azure account to provide the required authentication. In addition, the management API, and

Page | 29

the PowerShell cmdlets that wrap it, require you to provide several pieces of information, including the name of your service, the thumbprint of the certificate, and the subscription ID of your Windows Azure account.

In this task, you upload the certificate to your Windows Azure Account and obtain the required information, including the certificate thumbprint and the subscription ID.

1. Navigate to https://windows.azure.com using a Web browser and sign in using your Windows Live ID.

Figure 32Signing in to the Windows Azure portal

2. Select the Account tab and then click Manage My API Certificates

Page | 30

Figure 33Managing API certificates in the Windows Azure Developer Portal

3. Upload the new certificate from your local storage. To do this, select Browse, locate the certificate file in your local disk and then click Upload. Note that you can only associate a maximum of five certificates with your subscription.

Figure 34Uploading a certificate to the Windows Azure Developer Portal

Note: The Service Management API accepts any valid X.509 v3 certificate for authentication purposes provided its key length is at least 2048 bits. You can use the self-signed certificate you created in the previous task or one signed by a certificate authority.

Page | 31

If you submit a self-signed certificate immediately after you generate it, the Windows Azure portal could reject it due to timing differences with your computer if the server’s time is ahead of the Valid From date of the certificate. If you receive a ”Certificate is not yet valid” error when you upload the certificate, you can either wait a few minutes to account for the time skew and re-submit the certificate or use makecert to generate a new certificate that specifies a validity period with a start date that is in the past.

4. Make a note of the value shown in the Thumbprint column for the certificate that you just installed.

5. Select the Account tab in the Developer Portal UI and record the value shown for Subscription ID under Support Information.

Figure 35Determining the subscription ID for a Windows Azure account

6. Select the Summary tab for your hosted service. You can retrieve the service name from the Web Site URL shown in this page, which has the format http://<SERVICE_NAME>.cloudapp.net.

Page | 32

Figure 36Retrieving the name of the hosted service

Note: You will use the certificate Thumbprint, account Subscription ID, and Service Name in the next task, when you deploy the service package.

Task 3 – Uploading a Service Package Using Windows PowerShell

In the previous exercise, you uploaded the service package for the myTODO application using the Windows Azure Developer Portal. In this task, you deploy the package using the Windows Azure Service Management PowerShell cmdlets instead.

1. If it is not already open, launch Microsoft Visual Studio 2008 in elevated administrator mode, from Start | All Programs | Microsoft Visual Studio 2008 by right clicking the Microsoft Visual Studio 2008 shortcut and choosing Run as Administrator.

2. In the File menu, choose Open and then Project/Solution. In the Open Project dialog, browse to Ex02-DeployingUsingPSCmdlets\Begin in the Source folder of the lab, select MyTodo.sln in the folder for the language of your preference (Visual C# or Visual Basic) and click Open.

3. Configure the storage account connection strings. To do this, expand the Roles node in the MyTodo project and double-click the MyTodo.WebUX role. In the role properties window, select the Settings tab, select the DataConnectionString setting, ensure that the Type is set to ConnectionString, and then click the button labeled with an ellipsis.

Page | 33

Figure 37Defining storage account connection settings

4. In the Storage Connection String dialog, choose the Enter storage credentials option. Complete your storage Account Name and storage Account Key and click OK.

Figure 38Configuring the storage account name and account key

Note: This information is available in the Summary section of your storage account in the Windows Azure Developer Portal. You used the same settings in Exercise 1, when you deployed and configured the application. In that instance, because you were running the application in Windows Azure, you updated the configuration at the Developer Portal.

Page | 34

5. Repeat the previous steps to configure the DiagnosticsConnectionString setting using the same account information.

6. Create the service package. To do this, right-click the cloud service project and select Publish. This opens Windows Explorer to the Publish folder in your solution folders, and opens up the Windows Azure Developer Portal in your browser. You do not require the portal to upload the deployment using the PowerShell cmdlets so you may close the browser window.

7. Open a Windows PowerShell command prompt. On Windows Vista, Windows Server 2008, and later versions of Windows, in the Start menu, open All Programs | Accessories | Windows PowerShell, and then select Windows PowerShell. On Windows XP and Windows Server 2003, in the Start menu, open Programs | Accessories | Windows PowerShell, and then select Windows PowerShell.

8. At the PowerShell prompt, enter the following command to add support for the Azure Services Management cmdlets to the current session.

PowerShell Console

Add-PSSnapin AzureManagementToolsSnapIn

9. Change the current directory to the location where you generated the service package for the myTODO application in Step 6.

10. Next, enter the command shown below. Use the following command line arguments ensuring that you replace the parameter placeholders with the settings that apply to your service account, which you determined in Task 1 of this exercise.

PowerShell Console

New-Deployment -serviceName <YOUR_SERVICE_NAME_LOWER_CASE> -subscriptionId <YOUR_SUBSCRIPTION_ID> -certificate (get-item cert:\CurrentUser\MY\<YOUR_CERTIFICATE_THUMPRINT>) -slot staging –package <PACKAGE_LOCATION> -configuration <CONFIGURATION_LOCATION> -label "v2.0"

<YOUR_SERVICE_NAME_LOWER_CASE>

The service name chosen when configuring the hosted service URL in Exercise 1, not its Service Label.

<YOUR_SUBSCRIPTION_ID> The subscription ID of the Windows Azure account where the service will be deployed.

<YOUR_CERTIFICATE_THUMPRINT> The thumbprint value (in upper case) for the certificate uploaded previously.

< PACKAGE_LOCATION> A path to a local file or the URL of the blob in Azure Storage that contains the service package.

Page | 35

< CONFIGURATION_LOCATION> A path to a local file or the public URL of the blob that contains the service configuration file.

Note: The command shown above uses the New-Deployment cmdlet to upload a service package and create a new deployment in the staging environment. It assigns a "v2.0" label to identify this deployment.

Note that the certificate parameter expects a certificate object. In order to retrieve the required certificate, you can use get-item and the PowerShell certificate provider to obtain the certificate given its thumbprint value. Be aware that you need to specify the thumbprint in upper case for this method to succeed.

For example, to deploy a hosted service named “yournametodo”, using an account with a subscription ID of 12abb234-45c9-4b37-8179-e7d88617cb5e, a certificate thumbprint 6062B026CF12FE6CD1E3A2CE22893E5CD1DA59C7, for a package named MyTodo.cspkg and a configuration file named ServiceConfiguration.cscfg stored in the current directory, and to assign this deployment a label v2.0, use the following command.

Figure 39New-Deployment command line

11. Press ENTER to execute the command. Because New-Deployment is an asynchronous operation, the command returns immediately. Meanwhile, the operation continues in the background.

Figure 40Deploying a new service package to Windows Azure using PowerShell

12. In the Windows Azure Developer Portal, open the Summary page and notice how the deployment for the staging environment shows its status with the message "Package is updating..." in the UI. It may take a few seconds for the service status to refresh. Wait for the deployment operation to complete and display the status as Allocated.

Page | 36

Note: Normally, you will not use the portal to view the status and determine the outcome of your deployment operations. Here, it is shown to highlight the fact that you can use the management API to execute the same operations that are available in the portal. In the next task, you will see how to use a cmdlet to wait for the operation to complete and retrieve its status.

13. Keep the Microsoft Visual Studio 2008 and PowerShell console open. You will need them for the next task.

Task 4 – Upgrading a Deployment Using Windows PowerShell

In this task, you use the Windows Azure Service Management PowerShell cmdlets to upgrade an existing deployment. First, you change the original solution by making minor changes to its source code to produce an updated version of the application. Next, you build the application and create a new service package that contains the updated binaries. Finally, using the management cmdlets, you re-deploy the package to Windows Azure.

1. Go back to Microsoft Visual Studio 2008.

2. Open the master page of the application for editing. To do this, in Solution Explorer, double-click Site.Master in the Views\Shared folder of the MyTodo.WebUx project. Switch to source mode.

3. Insert a new caption in the footer area of the page. Go to the bottom of the master page and update the copyright notice with the text “(Deployed with the PowerShell CmdLets)” as shown below.

HTML

... </div> <div id="footer"> <hr /> <p class="copyright"> &copy; 2009 Microsoft Corporation. All rights reserved. (Deployed with the PowerShell CmdLets)</p> <p class="powered"><a href="http://www.microsoft.com/azure/windowsazure.mspx"><img src="<%=Url.Content("~/Content/images/powered-by-azure.png")%>" width="188" height="38" alt="Powered by Windows Azure" /></a></p> </div> <asp:ContentPlaceHolder ID="ScriptsContent" runat="server" /> </div></body></html>

Page | 37

4. Generate a new service package. To do this, in Solution Explorer, right-click the MyTodo project and select Publish. This creates the .cspkg file with all the service components, opens Windows Explorer to the Publish folder in your solution folders and opens up the Windows Azure Developer Portal in your browser. You can close the browser window because you are not going to use it.

5. Switch to the PowerShell console and enter the command shown below, specifying the settings that apply to your service account where indicated by the placeholder parameters. Do not execute the command yet.

PowerShell Console

Get-HostedService <YOUR_SERVICE_NAME> -subscriptionId <YOUR_SUBSCRIPTION_ID> -certificate (get-item cert:\CurrentUser\MY\<YOUR_CERTIFICATE_THUMPRINT>) | Get-Deployment staging | Set-Deployment -package <PACKAGE_LOCATION> -label "v2.1"

<YOUR_SERVICE_NAME_LOWER_CASE>

The service name chosen when configuring the hosted service URL in Exercise 1, not its Service Label.

<YOUR_SUBSCRIPTION_ID> The subscription ID of the Windows Azure account where the service will be deployed.

<YOUR_CERTIFICATE_THUMPRINT> The thumbprint value (in upper case) for the certificate uploaded previously.

< PACKAGE_LOCATION> A path to a local file or the URL of the blob in Azure Storage that contains the service package.

The command line shown above concatenates a sequence of cmdlets. First, it obtains a reference to the hosted service using Get-HostedService, then it uses Get-Deployment to retrieve its staging environment, and finally it uploads the package using Set-Deployment. This is done to illustrate how to compose a complex command using the PowerShell pipeline. In fact, in this particular case, you could instead provide all the required information to Set-Deployment to achieve the same result. For example:

Set-Deployment -subscriptionId <YOUR_SUBSCRIPTION_ID> -certificate <YOUR_CERTIFICATE> -serviceName <YOUR_SERVICE_NAME_LOWER_CASE> -slot staging -package <PACKAGE_LOCATION> -label <LABEL>

Page | 38

6. If you were to run the command as described above, the operation runs asynchronously. To show the operation’s progress while the deployment is taking place, you can pipe the output of the command into the Get-OperationStatus cmdlet and specify the WaitToComplete parameter. Add this cmdlet to the end of the command line entered previously making sure that you include the pipeline character ‘|’, as shown below.

PowerShell Console

Get-HostedService <YOUR_SERVICE_NAME_LOWER_CASE> -subscriptionId <YOUR_SUBSCRIPTION_ID> -certificate (get-item cert:\CurrentUser\MY\<YOUR_CERTIFICATE_THUMPRINT>) | Get-Deployment staging | Set-Deployment -package <PACKAGE_LOCATION> -label "v2.1" | Get-OperationStatus -WaitToComplete

Figure 41Using the PowerShell pipeline to upgrade a deployment

7. Press ENTER to execute the command. Wait until the deployment process finishes, which may take several minutes. When the operation ends, it displays a message with the outcome of the operation; if the deployment completed without errors, you will see the message “Succeeded”.

Figure 42PowerShell console showing the status of the package deployment operation

Note: Deploying a package using the steps described above does not change its state. If the service is not running prior to deployment, it will remain in that state. To start the service, you need to update its deployment status using the Set-DeploymentStatus cmdlet.

8. To change the status of the service to a running state, in the PowerShell console, enter the following command.

Page | 39

PowerShell Console

Get-Deployment staging -serviceName <YOUR_SERVICE_NAME_LOWER_CASE> -subscriptionId <YOUR_SUBSCRIPTION_ID> -certificate (get-item cert:\CurrentUser\MY\<YOUR_CERTIFICATE_THUMPRINT>) | Set-DeploymentStatus running | Get-OperationStatus –WaitToComplete

9. Finally, swap the deployments in the staging and production environments. To do this, in the PowerShell console, use the Get-Deployment and Move-Deployment cmdlets, as shown below, ensuring that you replace the placeholder parameters, <YOUR_SERVICE_NAME>, <YOUR_SUBSCRIPTION_ID>, and <YOUR_CERTIFICATE_THUMBPRINT> with the same values used previously, when you deployed the package.

PowerShell Console

Get-HostedServices -subscriptionId <YOUR_SUBSCRIPTION_ID> -certificate (get-item cert:\CurrentUser\MY\<YOUR_CERTIFICATE_THUMPRINT>) | where {$_.ServiceName –eq “<YOUR_SERVICE_NAME>”} | Get-Deployment staging | Move-Deployment | Get-OperationStatus –WaitToComplete

Verification

Now that you have deployed your updated solution to Window Azure, you are now ready to test it. You will launch the application to determine if the deployment succeeded and ensure that the service is working correctly and is available at its production URL.

1. In the Summary page of the development portal, under the Hosted Service section, click the Web Site URL link to open the production site in a browser window. Notice the footer of the page. It should reflect the updated text that you entered in the last task.

Page | 40

Figure 43New deployment showing the updated footer text

Note: If you visit the production site shortly after its promotion, the DNS name might not be ready. If you encounter a DNS error (404), wait a few minutes and try again. Keep in mind that Windows Azure creates DNS name entries dynamically and that the changes might take few minutes to propagate.

Exercise 3 - Monitoring Applications in Windows Azure

Page | 41

Windows Azure Diagnostics allow you to collect rich diagnostic data to assist you in trouble shooting your service. It provides support for a variety of diagnostic features including Windows Azure logs, Windows Event logs, IIS logs, Failed Request Tracing (commonly known as FREB) logs, application crash dumps, and performance counters, in addition to Windows Azure Diagnostic Monitor logs with data about the diagnostic feature itself.

The diagnostics infrastructure collects data in local storage for every diagnostic type that you enable and can transfer the data it gathers to an Azure Storage account for permanent storage. You can schedule to push the collected data to storage at regular intervals or you can request an on-demand transfer whenever you require this information.

You can configure any given instance of a running service using a Diagnostics Management API provided in the Windows Azure SDK, including enabling individual diagnostic features and performing transfers of diagnostics data to Azure Storage. The API allows you to modify the configuration of a service remotely and without interrupting its execution.

During this exercise, you will instrument the MyTODO application and monitor its operation. This involves adding performance counters, scheduling tasks to transfer diagnostic data to an Azure Storage account and adding code to manage these operations from outside the cloud, more precisely, from a console application running in your desktop.

Task 1 – Configuring Azure Storage for Persisting Diagnostics Data

The myTODO application uses two separate storage settings. The first one, DataConnectionString, points to the storage account for the application's data. In addition, Windows Azure Diagnostics collects data locally for each instance of the application. To store this data permanently, the diagnostics monitor needs a second setting, DiagnosticsConnectionString, to point to the store for the information it gathers. It uses the configured storage account to persist performance counter data and event log information.

In this task, you configure the data and diagnostics storage settings for the application.

1. Open Microsoft Visual Studio 2008 in elevated administrator mode, from Start | All Programs | Microsoft Visual Studio 2008 by right clicking the Microsoft Visual Studio 2008 shortcut and choosing Run as Administrator.

2. In the File menu, choose Open and then Project/Solution. In the Open Project dialog, browse to Ex03-Monitoring\Begin in the Source folder of the lab, select MyTodo.sln in the folder for the language of your preference (Visual C# or Visual Basic) and click Open.

Page | 42

3. Now, configure the storage account connection strings for the application data and the diagnostics information it produces. To do this, expand the Roles node in the MyTodo project and double-click the MyTodo.WebUX role. In the role properties window, select the Settings tab, select the DataConnectionString setting, ensure that the Type is set to ConnectionString, and then click the button labeled with an ellipsis. In the Storage Connection String dialog, choose the Enter storage credentials option, complete your storage Account Name and storage Account Key and click OK.

Note: This information is available in the Summary section of your storage account in the Windows Azure Developer Portal. You used the same settings in Exercise 1, when you deployed and configured the application. In that instance, because you were running the application in Windows Azure, you updated the configuration at the Developer Portal.

4. Repeat the previous steps to configure the DiagnosticsConnectionString setting using the same account information.

Task 2 – Enabling Failed Request Tracing

Failed Request Tracing produces detailed trace logs according to filters established within a web role’s configuration.

You can customize Failed Request Tracing in several ways. You can specify what content to trace, for example, all *.css files or a specific document such as “About”. You can also choose what conditions cause tracing to write a request to the log. This includes a particular response status code (e.g. 401) or a range of codes (e.g. 400-500), an event with a certain severity (e.g. critical), or the time taken to process a request (e.g. all requests that exceed 5 seconds).

For more information on Failed Request Tracing, see Troubleshooting Failed Requests Using Tracing in IIS 7.0.

In this task, you configure the web role to capture failed request information for all supported trace areas. To do so, you will modify the application to introduce an arbitrary delay into one of its responses and configure a failure condition that causes Failed Request Tracing to write the request to the log when the response time exceeds a specified limit.

Note: The development environment supports the use of the Failed Request Tracing feature. To enable it, you must install the Tracing feature in IIS.

1. Open the Web.config file in the MyTodo.WebUx project. Locate the system.webServer section and insert the following tracing section into it, as shown (highlighted) in the following configuration fragment.

Page | 43

Web.config

<system.webServer> <validation ... /> <modules ... > ... </modules> <handlers> ... </handlers> <tracing> <traceFailedRequests> <add path="*"> <traceAreas> <add provider="ASP" verbosity="Verbose" /> <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" /> <add provider="ISAPI Extension" verbosity="Verbose" /> <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module" verbosity="Verbose" /> </traceAreas> <failureDefinitions timeTaken="00:00:15" statusCodes="400-599" /> </add> </traceFailedRequests> </tracing></system.webServer>

Note: The failureDefintions element shown above will result in logging for any requests that take longer than 15 seconds or that result in a response status code in the range 400 to 599.

2. Now, modify the application to introduce an arbitrary delay when it processes the response to the About page of the application. Open the HomeController.cs file (for C# projects) or HomeController.vb file (for Visual Basic projects) in the Controllers folder of the MyTodo.WebUx project.

3. Locate the About action and insert the following (highlighted) code to temporarily suspend the thread that processes the request for several seconds.

C#

public ActionResult About()

Page | 44

{ System.Threading.Thread.Sleep(18000); return this.View();}

Visual Basic

Public Function About() As ActionResult System.Threading.Thread.Sleep(18000) Return Me.View()End Function

4. Press F5 to launch the cloud project in the development fabric.

5. Switch to the development fabric UI and ensure that the service has started successfully.

6. Open the local store to examine the diagnostic files. To do this, in the Development Fabric, expand the Service Deployments tree view to locate the node for the MyTodo.WebUx role, expand this node to display its running instances and right-click the single instance under it to select Open local store.

Figure 44Opening the local store in the development fabric

Page | 45

Note: Currently, opening the Local Store from the Development Fabric UI is not possible when you log in as non-administrative user, even after launching Visual Studio in elevated mode by providing credentials for the administrator.

If you are unable to open the local store from the Development Fabric, execute this task logged in as an administrator or, as an alternative, carry out the following procedure to start the Development Fabric service manually, using a path to the local store that is accessible to the current user.

1. If necessary, press SHIFT + F5 to stop the running application.

2. Stop the Development Fabric service if it is currently running. To do this, right-click its icon in the task bar and select Shutdown Development Fabric service.

3. Open a Windows Azure SDK command prompt elevated as an administrator. In the Start menu, choose All Programs | Windows Azure SDK v1.0, right-click Windows Azure SDK Command Prompt and select Run as administrator.

4. At the command prompt, enter bin\devfabric\dfservice -sp "<LOCAL_STORE_PATH>". Replace the placeholder with the path to a folder where you have access, for example, bin\devfabric\dfservice -sp "C:\DevFabric".

5. To view the local store, open a Windows Explorer window pointing at the path chosen in the previous step. In this folder, select the subdirectory for the current deployment, which you can determine from the Service Deployments tree view in the Development Fabric, and navigate to the res\deployment(XXX).MyTodo.MyTodo.WebUx.0 folder.

7. In the folders tree view of the newly opened Windows Explorer window, expand directory | DiagnosticStore | FailedReqLogFiles.

8. Now, make a request that triggers a failure based on the tracing rules that you configured earlier and cause it to be written to the log. To bring this about, click the About link in the browser window to navigate to this page. Recall that you inserted a delay in the processing of the corresponding controller action that is greater than the timeTaken limit set in the tracing configuration.

9. Switch to the Windows Explorer window and expand the FailedReqLogFiles folder where you will find a W3SVC1 folder that contains the log files.

10. Inside this folder, locate the log file corresponding to the failed request to the About page.

Note: The W3SVC1 directory contains Failed Request Tracing log files in XML format, one file for each failed request. It should contain at least one log file for the failed request that you induced. A second log file might be present in this folder if the response time for the initial

Page | 46

page of the site was greater than the configured limit as the result of a slow start up time of the web role. In addition, the folder contains an XSL style sheet file that allows you to view each log file in an easily comprehensible format.

Figure 45Viewing Failed Request Tracing logs in the local store

11. Double-click the XML log file in Windows Explorer to open the file in your browser. Notice that the Request Summary tab shows the URL of the failed request as well as a reason for the failure, in this case TIME_TAKEN. The summary also shows the response status code and the time taken to process the request.

Page | 47

Figure 46Summary view for the failed request

Note: Each log file contains a wealth of information about a request that can prove invaluable when troubleshooting an application. It is beyond the scope of this lab to analyze this feature in detail but you might want to spend some time examining the various views available in the trace report.

12. (Optional) The failureDefinitions element that you configured in the tracing section of the Web.config file not only specifies a timeTaken attribute to capture requests that exceeded a certain time to be processed, but also includes a statusCodes attribute to log requests that have response status code in the range 400 to 599. To see this in action, enter an invalid URL in the address bar of the browser, for example http://127.0.0.1:81/Home/BadURL, and press ENTER. Examine the failed request log file generated as a result of the 404 status code. Notice that this time the failure reason is STATUS_CODE.

13. In addition to failed traced requests, Windows Azure Diagnostics collects Internet Information Server logs by default and stores them locally for each instance of the web role. To view the IIS logs, in Windows Explorer, locate the LogFiles folder inside DiagnosticStore. Inside this folder, you will find a W3SVC1 folder that contains the log files.

Page | 48

Figure 47Viewing IIS logs in the local store

14. Open any one of the log files in this folder in a text editor, for example, Notepad. Notice that it is a standard IIS log file with details about every request made to the application, including its date and time, the request URL, and the response status.

Figure 48Internet Information Server log file

Page | 49

In this task, you examined several logging features by browsing the information captured locally by the Development Fabric. When you deploy your application to Windows Azure, you will no longer have direct access to these files in the local store. Instead, you need to configure the diagnostics infrastructure to transfer the information to table and blob storage in your Azure Storage account. In the next task, you will see how you can achieve this.

Task 3 – Instrumenting a Web Role

Using the Diagnostics Management API, an application can define the information that it needs to collect at role start up time.

In this task, you add code to the myTODO application to enable Windows Azure logs and set up a transfer schedule that automatically copies the logs to an Azure Storage account at regular intervals. In addition, you enable logging and use the standard .NET tracing API to write messages to the log.

1. Open the WebRole.cs file (for C# projects) or WebRole.vb file (for Visual Basic projects) in the MyTodo.WebUx project. This file contains the role entry point of the web role.

2. In the OnStart method of WebRole class, first delete the call to DiagnosticsMonitor.Start at the start of the method and then insert the following (highlighted) code to replace it. This code schedules the transfer of the error logs produced in the web role to Azure Storage.

(Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex 3 Web Role Diagnostic Monitor Configuration – C#)

C#

public override bool OnStart(){ // Get the factory configuration so that it can be edited DiagnosticMonitorConfiguration config = DiagnosticMonitor.GetDefaultInitialConfiguration();

// Set scheduled transfer interval for infrastructure logs to 1 minute config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = System.TimeSpan.FromMinutes(1);

// Specify a logging level to filter records to transfer config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = LogLevel.Error;

// Set scheduled transfer interval for user's Windows Azure Logs to 1 minute config.Logs.ScheduledTransferPeriod = System.TimeSpan.FromMinutes(1);

DiagnosticMonitor.Start("DiagnosticsConnectionString", config);

Page | 50

RoleEnvironment.Changing += this.RoleEnvironmentChanging;

...

return base.OnStart();}

(Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex 3 Web Role Diagnostic Monitor Configuration – VB)

Visual Basic

Public Overrides Function OnStart() As Boolean

' Get the factory configuration so that it can be edited Dim config As DiagnosticMonitorConfiguration = DiagnosticMonitor.GetDefaultInitialConfiguration()

' Set scheduled transfer interval for infrastructure logs to 1 minute config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = System.TimeSpan.FromMinutes(1)

' Specify a logging level to filter records to transfer config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = LogLevel.Error

' Set scheduled transfer interval for user's Windows Azure Logs to 1 minute config.Logs.ScheduledTransferPeriod = System.TimeSpan.FromMinutes(1)

DiagnosticMonitor.Start("DiagnosticsConnectionString", config)

AddHandler RoleEnvironment.Changing, AddressOf RoleEnvironmentChanging CloudStorageAccount.SetConfigurationSettingPublisher(Function(configName, configSetter) AnonymousMethod1(configName, configSetter)) Return MyBase.OnStart()End Function

Note: For projects created in Visual Studio, the role template generates code to initialize the Diagnostic Monitor with default settings. Typically, you will not need to change these settings, as you would normally request an on-demand transfer of diagnostics information whenever you require it for troubleshooting purposes.

Page | 51

In the code shown above, the role uses custom settings to set up a schedule that transfers the Windows Azure and Diagnostics Infrastructure logs to storage once every minute and creates a logging level filter to select only those records with an error level equal to or greater than Error. Setting up an automatic transfer schedule in this manner allows you to examine the information contained in the Azure Storage diagnostic tables later in the exercise.

3. Next, update the application to write a warning to the log whenever a user fails authentication using the standard .NET tracing API in System.Diagnostics. To do this, open AccountMembershipService.cs (for Visual C# projecs) or AccountMembershipService.vb (for Visual Basic projects) in the Authentication folder of the MyTodo.WebUx project, locate the ValidateUser method and replace its body with the following (highlighted) code.

(Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex 3 ValidateUser method – C#)

C#

public bool ValidateUser(string userName, string password){ bool valid = this.provider.ValidateUser(userName, password);

if (!valid) { System.Diagnostics.Trace.TraceWarning("Invalid login: {0}", userName); }

return valid;}

(Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex 3 ValidateUser method – VB)

Visual Basic

Public Function ValidateUser(ByVal userName As String, ByVal password As String) As Boolean Implements IMembershipService.ValidateUser Dim valid As Boolean = Me.provider.ValidateUser(userName, password)

If (Not valid) Then System.Diagnostics.Trace.TraceWarning("Invalid login: {0}", userName) End If

Return validEnd Function

Page | 52

Note: The updated method writes a warning event to the log whenever the authentication module detects a failed login attempt.

4. Finally, enable tracing in the configuration file by configuring a trace listener specific to Windows Azure Diagnostics. To configure the listener, open the Web.config file in the MyTodo.WebUx project and insert the following (highlighted) configuration block.

Web.config

<configuration> ... <system.diagnostics> <trace autoflush="false" indentsize="4"> <listeners> <add name="AzureDiagnostics" type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> </listeners> </trace> </system.diagnostics></configuration>

Note: The System.Diagnostics.Trace class provides a set of methods and properties that help you trace the execution of your code.

To use the methods in this class to record information in the Windows Azure logs, you need to configure a trace listener specific to Windows Azure in the system.diagnostics section of the configuration file (Web.config file for a web role or App.config file for a worker role).

This step is usually unnecessary for roles created in Visual Studio because they already include the necessary settings in their role templates.

5. Press F5 to build and run the application in the development fabric.

Note: In this task, for convenience, you execute the application locally in the development fabric but you configure it to use Azure Storage. Instead, you may wish to deploy the application and run it in Windows Azure. In that case, use the procedure that you learnt in Exercise 1 to deploy the application using the Windows Azure Developer Portal or, alternatively, take advantage of the PowerShell cmdlets from the Windows Azure Service Management tools that you saw in Exercise 2 to do the same thing.

Page | 53

6. In the browser window, click Sign In. In the Log On page, enter any username and password and attempt to sign in using invalid credentials. Recall that previously, you modified the application to log a warning for authentication failures.

Figure 49Signing in to the application with invalid credentials

7. Switch to the Development Fabric UI and display the log for the web role to verify that the failed login attempt resulted in a warning message in the log.

Page | 54

Figure 50Web role log showing the failed login attempt

8. Next, examine the logs that the Diagnostics Monitor pushes to Windows Azure table storage. To do this, you will take advantage of the Windows Azure TableBrowser, which is a publicly available Web application that allows you to browse your Azure Storage tables and create, edit, delete, and copy entities. To use it, open your browser and navigate to http://myazurestorage.com.

9. In the home page for the TableBrowser, enter the Account Name and Primary Access Key of your Azure Storage account and click Log In. Specify the same settings that you used previously, when you configured the DiagnosticConnectionString setting for the web role.

Page | 55

Figure 51Signing in to the Windows Azure TableBrowser tool

10. After you sign in, the tool presents you with a list of tables in your account. There should be at least five tables. The first three contain information for the ASP.NET providers used by the application. The remaining two tables hold the log information that the Diagnostics Manager transferred based on the schedule configured in the OnStart method of the web role.

Membership Contains membership information for the Azure TableStorageMembershipProvider.

Roles Contains role information for the Azure TableStorageRoleProvider.

Sessions Contains session information for the TableStorageSessionStateProvider.

WADInfrastructureLogsTable Contains logs from the diagnostic infrastructure, which help the user troubleshoot issues with the diagnostic monitoring system itself.

WADLogsTable Contains the logs generated by the application using the standard .NET tracing API.

Page | 56

Figure 52Table storage showing the application and diagnostics tables

11. Click the link for the WADLogsTable to examine its content. This table holds the application logs. It should contain at least one row corresponding to the failed login attempt. To expand or collapse the contents of the row, click the green / red icon to its left. Notice the Message column showing the information logged by the TraceInformation call that you added to the ValidateUser method earlier in the task.

Page | 57

Figure 53Log message showing the failed login attempt

Task 4 – Monitoring Azure Services Remotely

The Diagnostics Management API allows you to change the diagnostics configuration of any role instance in a running service from outside the cloud, without stopping the service. This includes adding performance counters, collecting Windows Event and other custom logs, and triggering the transfer of diagnostics information to Azure Storage.

In this task, you execute a console application in your desktop to update the role diagnostic configuration and add a performance counter. Then, you use the same tool to trigger an on-demand transfer of the collected performance data to Azure Storage. You can find the source code for the diagnostics tool in the MyTodo.Diagnostics.Client project of the solution.

Page | 58

Figure 54Console application to configure diagnostics for an Azure Service remotely

1. Open the AzureDiagnosticConfiguration.cs file (for C# projects) or AzureDiagnosticConfiguration.vb file (for Visual Basic projects) in the MyTodo.Diagnostics.Client project.

2. Implement the AddPerformanceCounter method by inserting code that uses the Diagnostics Management API to add a performance counter to the configuration of an Azure Service.

(Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex3 Add Performance Counter – C#)

C#

public void AddPerformanceCounter(PerformanceCounterConfiguration performanceCounter){ // Create a new DeploymentDiagnosticManager for the given deployment id var diagnosticManager = new DeploymentDiagnosticManager(this.storageAccount, this.deploymentId);

// Get the role instance diagnostics manager for all instance of the role var roleInstanceManagers = diagnosticManager.GetRoleInstanceDiagnosticManagersForRole(this.roleName);

// Set the new configuration for each instance of the role

Page | 59

foreach (var roleInstanceManager in roleInstanceManagers) { DiagnosticMonitorConfiguration diagnosticConfiguration = roleInstanceManager.GetCurrentConfiguration();

// Add the new performance counter to the configuration diagnosticConfiguration.PerformanceCounters.DataSources.Add(performanceCounter);

// Update the configuration roleInstanceManager.SetCurrentConfiguration(diagnosticConfiguration); }}

(Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex3 Add Performance Counter – VB)

Visual Basic

Public Sub AddPerformanceCounter(ByVal performanceCounter As PerformanceCounterConfiguration) ' Create a new DeploymentDiagnosticManager for the given deployment id Dim diagnosticManager = New DeploymentDiagnosticManager(Me.storageAccount, Me.deploymentId)

' Get the role instance diagnostics manager for all instance of the role Dim roleInstanceManagers = diagnosticManager.GetRoleInstanceDiagnosticManagersForRole(Me.roleName)

' Set the new configuration for each instance of the role For Each roleInstanceManager In roleInstanceManagers Dim diagnosticConfiguration As DiagnosticMonitorConfiguration = roleInstanceManager.GetCurrentConfiguration()

' Add the new performance counter to the configuration diagnosticConfiguration.PerformanceCounters.DataSources.Add(performanceCounter)

' Update the configuration roleInstanceManager.SetCurrentConfiguration(diagnosticConfiguration) Next roleInstanceManagerEnd Sub

Page | 60

Note: The code obtains a reference to the Diagnostics Manager for all instances of a role, then loops through each instance adding a new performance counter to the role instance configuration, and then saves the changes. When you execute the diagnostics tool specifying the AddPerformanceCounter operation in its command line, it invokes this method to add the new performance counter and update the diagnostics configuration of the service.

3. Next, in the AzureDiagnosticConfiguration class, implement the PerformOnDemandTransfer method to transfer all diagnostic data from the local storage of the role instance to Azure Storage.

(Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex3 PerformOnDemandTransfer – C#)

C#

public void PerformOnDemandTransfer(DataBufferName dataBufferName){ // Create a new DeploymentDiagnosticManager for the given deployment id var diagnosticManager = new DeploymentDiagnosticManager(this.storageAccount, this.deploymentId);

// Get the role instance diagnostics manager for all instance of the a role var roleInstanceManagers = diagnosticManager.GetRoleInstanceDiagnosticManagersForRole(this.roleName);

var transferOptions = new OnDemandTransferOptions(); transferOptions.From = DateTime.UtcNow - TimeSpan.FromMinutes(5); transferOptions.To = DateTime.UtcNow; transferOptions.NotificationQueueName = this.transferQueueName .ToLowerInvariant();

var queueClient = this.storageAccount.CreateCloudQueueClient(); queueClient.RetryPolicy = RetryPolicies.Retry(3, TimeSpan.FromSeconds(1)); var queue = queueClient.GetQueueReference(transferOptions.NotificationQueueName); queue.CreateIfNotExist();

foreach (var roleInstanceManager in roleInstanceManagers) { CancelAllPreviousTransfers(roleInstanceManager);

Page | 61

// Start the transfer for each instance of the role roleInstanceManager.BeginOnDemandTransfer(dataBufferName, transferOptions);

// Poll the feedback queue every 15 sec for 10 min to see if the transfer is complete. PollAndConfirmTransfer(roleInstanceManager, queue); }}

(Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex3 PerformOnDemandTransfer – VB)

Visual Basic

Public Sub PerformOnDemandTransfer(ByVal dataBufferName As DataBufferName) ' Create a new DeploymentDiagnosticManager for the given deployment id Dim diagnosticManager = New DeploymentDiagnosticManager(Me.storageAccount, Me.deploymentId)

' Get the role instance diagnostics manager for all instance of the a role Dim roleInstanceManagers = diagnosticManager.GetRoleInstanceDiagnosticManagersForRole(Me.roleName)

Dim transferOptions = New OnDemandTransferOptions() transferOptions.From = DateTime.UtcNow - TimeSpan.FromMinutes(5) transferOptions.To = DateTime.UtcNow transferOptions.NotificationQueueName = Me.transferQueueName.ToLowerInvariant()

Dim queueClient = Me.storageAccount.CreateCloudQueueClient() queueClient.RetryPolicy = RetryPolicies.Retry(3, TimeSpan.FromSeconds(1)) Dim queue = queueClient.GetQueueReference(transferOptions.NotificationQueueName) queue.CreateIfNotExist()

For Each roleInstanceManager In roleInstanceManagers CancelAllPreviousTransfers(roleInstanceManager)

' Start the transfer for each instance of the role roleInstanceManager.BeginOnDemandTransfer(dataBufferName, transferOptions)

Page | 62

' Poll the feedback queue every 15 sec for 10 min to see if the transfer is complete. PollAndConfirmTransfer(roleInstanceManager, queue) Next roleInstanceManagerEnd Sub

4. Save the AzureDiagnosticConfiguration.cs file (for C# projects) or AzureDiagnosticConfiguration.vb file (for Visual Basic projects).

5. Next, update the application to display the deployment ID of the service in its page title. You will need to supply this information to the diagnostics tool later, when you use it to configure your deployment. To add the deployment ID to the title, open the Site.Master file in the Views\Shared folder of the MyTodo.WebUx project. Locate the title tag inside the head of the page and insert the following code to append the DeploymentId property to the page title.

Note that this step is not strictly necessary when you run the application in the Development Fabric, because you can obtain the deployment ID from corresponding node in the Service Deployments tree view.

ASP.NET

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

...

<html xmlns="http://www.w3.org/1999/xhtml"><head runat="server"> <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> <meta http-equiv="X-UA-Compatible" content="IE=8" /> <title> <asp:ContentPlaceHolder ID="TitleContent" runat="server" /> | DeploymentId: <%= Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.DeploymentId %> </title> <link href="<%=Url.Content("~/Content/styles/site.css")%>" rel="stylesheet" type="text/css" /> <asp:ContentPlaceHolder ID="StylesContent" runat="server"></asp:ContentPlaceHolder></head><body> <div id="container"> ...

Page | 63

Note: The Diagnostics Management API requires the storage account used to store diagnostics information and the deployment ID of your service.

Verification

Now, you test the remote diagnostic monitoring capabilities of Windows Azure. First, you configure a new performance monitor counter to measure “% Processor Time” and then you trigger an on-demand transfer of performance counter data to Azure Storage. Finally, you inspect the table that received the performance records collected by the counter.

1. Press F5 to build and run the application.

2. Obtain the deployment ID of the running service. To retrieve the ID, switch to the browser window showing the start page of the application and record the DeploymentId value shown in the title bar. Alternatively, if you are running the application in the Development Fabric, you can obtain the Deployment ID from the corresponding label in the Service Deployments tree view.

Figure 55Obtaining the deployment ID of the service

3. Open a command prompt and change the current directory to the Source\Assets\MyTodo.Diagnostics.Client folder.

4. At the command prompt, execute myTodoMonitorClient.exe indicating the AddPerformanceCounter operation. Use the following command line arguments ensuring that you replace the parameter placeholders with the settings that apply to your service account.

Command Prompt

Page | 64

myTodoMonitorClient.exe AddPerformanceCounter /accountName:<YOUR_STORAGE_NAME> /accountKey:<YOUR_STORAGE_KEY> /roleName:MyTodo.WebUx /deploymentId:<YOUR_DEPLOYMENT_ID> /counter:"\Processor(_Total)\% Processor Time" /sampleRate:5

Note: The command receives parameters for your Azure Storage account credentials, the name of the role to configure, the deployment ID of the service, the name of the counter to add, and the sampling rate (in seconds), and then updates the configuration of the role instances to add a new performance counter to measure % Processor Time.

If you are using the tool to configure an application that uses Development Storage, omit the accountName and accountKey parameters from the command line above.

To obtain a list of performance counter names, open a command prompt and enter the following command:

typeperf -q | more

Note that this command lists the performance counters available in your workstation and while many performance counters are common to every system, the list might contain some items that are not available in your Azure role depending on the software that you have installed.

Figure 56Remotely adding performance counters to a running service

5. Now, you transfer the diagnostics data saved in local storage to your Azure Storage account. At the command prompt, once again execute the myTodoMonitorClient command, this time

Page | 65

specifying the OnDemandTransfer operation. Remember to replace the parameter placeholders with your service account information.

Command Prompt

myTodoMonitorClient.exe OnDemandTransfer /accountName:<YOUR_STORAGE_NAME> /accountKey:<YOUR_STORAGE_KEY> /roleName:MyTodo.WebUx /deploymentId:<YOUR_DEPLOYMENT_ID> /bufferName:PerformanceCounters

Figure 57Pushing diagnostics data to Azure Storage

Note: The bufferName parameter specifies which information you are transferring to Azure Storage. You can specify the following values: DiagnosticInfrastructureLogs, Directories, Logs, PerformanceCounters, and WindowsEventLogs.

6. Now that you have triggered the transfer of performance data to your Azure Storage account, it is time to verify that the operation succeeded. Again, open your browser and navigate to http://myazurestorage.com.

7. In the home page for the TableBrowser, enter the Account Name and Primary Access Key of your Azure Storage account and click Log In.

8. If you recall the tables that existed in your account after completing the previous task, you will notice that there is now an additional table named WADPerformanceCountersTable. This table contains the performance data that was collected by the counter that you added earlier in this task.

Page | 66

Figure 58Azure Table Storage showing the new performance counters table

9. Click the WADPerformanceCountersTable link to view the contents of this table. In the table, you will find the performance data collected during the interval prior to the on-demand transfer. Expand any one of the rows to view the information it contains. To do this, click the green icon next to the row.

Page | 67

Figure 59Performance counter data table containing records for “% Processor Time”

Note: You examine the information in the TableBrowser to review its format and see how it is stored in an Azure Storage table. In a more common scenario, you would use an application to process the information in these tables and generate reports and statistics.

Summary

Page | 68

By completing this hands-on lab, you learnt how to create a storage account and a hosted service at the Windows Azure Developer Portal. Using the portal, you deployed a service package that contained the application binaries, configured its storage and defined the number of instances to run.

You also saw how to achieve this programmatically using the Service Management API and in particular, how to use the Windows Azure Service Management cmdlets to deploy, update, and manage applications using Windows PowerShell.

Finally, you examined Windows Azure Diagnostics and how to collects diagnostics data from your application and store it in an Azure Storage account. You reviewed the various logs that it produces, and instrumented an application to produce performance data and trace information.

Page | 69