Staged Deployment on Microsoft Azure Websites

When you deploy your application to Azure Websites, you can deploy to a separate deployment slot instead of the default production slot, which are actually live sites with their own hostnames.

This option is available in the Standard web hosting plan. 

Benefits

You can validate website changes in a staging deployment slot before swapping it

with the production slot.

After a swap, the slot with previously staged site now has the previous production site.

If the changes swapped into the production slot are not as you expected, you can

perform the same swap immediately to get your "last known good site" back.

Deploying a site to a slot first and swapping it into production ensures that all

instances of the slot are warmed up before being swapped into production. This

eliminates downtime when you deploy your site. The traffic redirection is seamless,

and no requests are dropped as a result of swap operations.

Deployment Slots Support DetailsFour deployment slots in addition to the production slot are supported for each website

in the Standard web hosting plan.

Multiple deployment slots are only available for sites in the Standard web hosting plan.

When your website has multiple slots, you cannot change the web hosting plan.

Scaling is not available and Linked resource management is not supported for non-

production slots.

By default, your deployment slots (sites) share the same resources as your production

slots (sites) and run on the same VMs. If you run stress testing on a stage slot, your

production environment will experience a comparable stress load.

Configuration for Deployment SlotsSettings that are swapped:

General settings - such as framework version, 32/64-bit, Web sockets

App settings (can be configured to stick to a slot)

Connection strings (can be configured to stick to a slot)

Handler mappings

Monitoring and diagnostic settings

Settings that are not swapped:

Publishing endpoints

Custom Domain Names

SSL certificates and bindings

Scale settings

Azure PowerShell cmdlets for Site SlotsGet-AzureWebsite

Get-AzureWebsite siteslotstest

New-AzureWebsite

New-AzureWebsite siteslotstest -Slot staging -Location "West US"

Publish-AzureWebsiteProject

Publish-AzureWebsiteProject -Name siteslotstest -Slot staging -Package

[path].zip

Show-AzureWebsite

Show-AzureWebsite -Name siteslotstest -Slot staging

Switch-AzureWebsiteSlot

Switch-AzureWebsiteSlot -Name siteslotstest

Remove-AzureWebsite

Remove-AzureWebsite -Name siteslotstest -Slot staging

Azure Cross-Platform Command-Line Interface (xplat-cli) commands for Site Slotsazure site list

azure site list siteslotstest

azure site create

azure site create siteslotstest --slot staging

To enable source control for the new slot, use the --git option, as in the following

example.

azure site create --git siteslotstest --slot staging

azure site swap

azure site swap siteslotstest

azure site delete

azure site delete siteslotstest --slot staging

ROLL BACK DEPLOYMENTS

Update an Azure ServiceAzure organizes your role instances into logical groupings called upgrade domains. The

default number of upgrade domains is 5. You can specify a different number of upgrade

domains by including the upgradeDomainCount attribute in the service’s definition file

(.csdef). 

When you perform an in-place update of one or more roles in your service, Azure updates

sets of role instances according to the upgrade domain to which they belong. 

Your service must define at least two instances of a role for that role to be updated in-

place without downtime. If the service consists of only one instance of one role, your

service will be unavailable until the in-place update has finished.

Allowed service changes during an update 

Operating system version

.NET trust level

Virtual machine size

Local storage settings

Add or remove roles in a service

Number of instances of a particular role

Number or type of endpoints for a service

Names and values of configuration setting

Values (but not names) of configuration settings

Add new certificates

Change existing certificates

Deploy new code

The following items are not supported during an update:

Changing the name of a role. Remove and then add the role with the new name. 

Changing of the Upgrade Domain count.

Decreasing the size of the local resources.

Rollback of an update

To test whether a rollback is allowed, check the value of the RollbackAllowed flag, returned

by Get Deployment and Get Cloud Service Properties operations, is set totrue.

Rollback of an in-progress update has the following effects on the deployment:

Any role instances which had not yet been updated or upgraded to the new version are not updated or upgraded, because those instances are already running the target version of the service.

Any role instances which had already been updated or upgraded to the new version of the service package (*.cspkg) file or the service configuration (*.cscfg) file (or both files) are reverted to the pre-upgrade version of these files.

This functionally is provided by the following features:

The Rollback Update Or Upgrade operation, which can be called on a configuration update (triggered by calling Change Deployment Configuration) or an upgrade (triggered by calling Upgrade Deployment) as long as there is at least one instance in the service which has not yet been updated to the new version.

The Locked element and the RollbackAllowed element, which are returned as part of the response body of the Get Deployment and Get Cloud Service Properties operations: 

1. The Locked element allows you to detect when a mutating operation can be invoked on a given deployment.

2. The RollbackAllowed element allows you to detect when the Rollback Update Or Upgrade operation can be called on a given deployment.

In order to perform a rollback, you do not have to check both the Locked and the RollbackAllowed elements. It suffices to confirm that RollbackAllowed is set to true. These elements are only returned if these methods are invoked by using the request header set to “x-ms-version: 2011-10-01” or a later version. For more information about versioning headers, see Service Management Versioning.

There are some situations where a rollback of an update or upgrade is not supported, these are as follows:

Reduction in local resources - If the update increases the local resources for a role the Azure platform does not allow rolling back. For more information about how to configure local resources for a role, see Configure Local Storage Resources.

Quota limitations - If the update was a scale down operation you may no longer have sufficient compute quota to complete the rollback operation. Each Windows Azure subscription has a quota associated with it that specifies the maximum number of cores which can be consumed by all hosted services that belong to that subscription. If performing a rollback of a given update would put your subscription over quota then that a rollback will not be enabled.

Race condition - If the initial update has completed, a rollback is not possible.

create hosting plans

Azure Websites Web Hosting Plans In-Depth Overview Represent a set of features and capacity that you can share across your websites.

Support the 4 Azure Websites pricing tiers (Free, Shared, Basic, and Standard)

Sites in the same subscription, resource group, and geographic location can share a

web hosting plan.

All websites associated with a given web hosting plan run on the resources defined by

the web hosting plan

Websites, Web Hosting Plans, and Resource GroupsA website can be associated with only one web hosting plan at any given time. A web

hosting plan is associated with a resource group. A Resource group is a new concept in

Azure that serves as the lifecycle boundary for every resource contained within it.

Resource groups enable you to manage all the pieces of an application together. 

You can have multiple web hosting plans in a resource group and each hosting plan will

have its own set of features and capabilities that are utilized by its associated sites.

The ability to have multiple web hosting plans in a single resource group allows you to

allocate different sites to different resources, primarily virtual machines running your

websites.

Having multiple web hosting plans in a single resource group also allows you to define

an application that spans across regions. 

Since you can move websites between web hosting plans, assuming the web hosting

plans are in the same regions

you cannot move web hosting plans or websites between resource groups. Also, you

cannot move a website between two web hosting plans that are in two separate

regions. 

On top of managing websites resources and respective sites for a given application, you

can associate any related Azure resource such as SQL-Azure databases, and Team

Projects. 

When should I create a new resource group and when should I create a new web hosting plan?When creating a new website, you should consider creating a new resource group when

the website you are about to create represents a new web application.

Creating a new hosting plan allows you to allocate a new set of resource for your

websites, and provides you with greater control over resource allocation, as each web

hosting plan gets its own set of virtual machines. Since you can move websites between

web hosting plans, assuming the web hosting plans are in the same regions, the

decision of whether to create a new web hosting plan or not is of less important. If a

given website starts consuming too many resources or you just need to separate a few

websites, you can create a new web hosting plan and move your websites to it. 

If you want to create a new website in a different region, and that region doesn't have

an existing web hosting plan, you will have to create a new web hosting plan in that

region to be able to have a website associated with it. 

An important thing to keep in mind is that you cannot move web hosting plans or

websites between resource groups. Also, you cannot move a website between two web

hosting plans that are in two separate regions. 

Existing resources group in the Azure Preview portalIf you already have existing websites on Azure Websites, you will notice that all your

websites show up in the Azure preview portal. 

You will also notice that you have an auto-generated default resource group in each

region you already have websites. The auto generated resource group name for

websites is Default-Web-*where location name represents an Azure region (for example

*Default-Web-WestUS). In each resource group you will find all your existing sites for

the group's region. Each site you created in the past and will create in the future in

either the Full Azure portal or the Azure Preview Portal will be available on both portals. 

Since every website has to be associated with a web hosting plan, we have created

default web hosting plans for your existing sites according to the following convention,

in each region: 

* All your Free websites are associated with a Default web hosting plan and its pricing

tier set to Free. 

* All your Shared websites are associated with a Default web hosting plan and its

pricing tier set to Shared 

* All your Standard websites are associated with a default web hosting plan and its

pricing tier set to Standard. 

The name of this web hosting plan is DefaultServerFarm. This name was chosen to

support a legacy API. The name ServerFarm can be somewhat misleading as it refers

to a Web Hosting Plan, but it's important to notice that it is a name of a web hosting

plan and it is not an entity of its own. 

Web Hosting Plan F.A.Q.

Question: How do I create a Web Hosting Plan? 

Answer: A Web Hosting Plan is a container and as such, you can't create an empty Web

Hosting Plan. However, a new Web Hosting Plan is explicitly created during site

creation. 

To do this using the UI in the new Azure Portal Preview click NEW and

select Website, which will open the Website creation blade. In the first image below

you can see the NEW icon on the bottom left, and in the second image you can see

the Website creation blade, the Web Hosting Plan blade and thePricing Tier blade: 

t should also be noted that a Web Hosting Plan can also be created in the existing Azure

Portal. This is done as part of the quick create wizard by selectingCreate new web

hosting plan from the WEB HOSTING PLAN drop down: 

Question: How do I assign a site to a Web Hosting Plan? 

Answer: Sites are assigned to a Web Hosting Plan as part of the site creation process.

To do this using the UI in the new Azure Portal Preview, click NEWand

select Website

Question: How can I move a site to a different web hosting plan? 

Answer: You can move a site to a different web hosting plan using the Azure Preview

Portal. Websites can be moved between web hosting plans in the same geographical

region that belong to the same resource group. 

To move a site to another plan, navigate to the website blade of the site you want to

move. Then click Web Hosting Plan: 

Note that each web hosting plan has its own pricing tier. When you move a site from

a Free tier web hosting plan to a Standard web hosting plan, your website will be able

to leverage all the features and resources of the Standard tier. 

Question: How can I Scale a Web Hosting Plan? 

Answer: There are two ways to scale a Web Hosting Plan. One way is to scale up your

web hosting plan and all sites associated with that web hosting plan. By changing the

pricing tier of a web hosting plan, all sites in that web hosting plan will be subject to the

features and resources defined by that pricing tier. 

The second way to scale a plan is to scale it out by increasing the number of instances

in your Web Hosting Plan. 

Question: How Can I Delete a Web Hosting Plan? 

Answer: To delete a Web Hosting Plan you must first delete all websites associated

with it. Once all the Websites in a Web Hosting Plan have been deleted a Web Hosting

Plan can be deleted from the Web Hosting Plan blade: 

In the Full Azure Portal deleting the last website in a web hosting plan will automatically

delete the associated web hosting plan. 

Question: How Can I monitor a web hosting plan? 

Answer: Web Hosting Plans can be monitored using the Monitoring parts in the Web

Hosting Plan Blade: 

migrate websites between hosting plans

Azure Website Hosting Plans (WHP)

Configure websitesdefine and use app settings, connection strings, handlers, and virtual directories

Importance of app settings in azure website portalHowever you also don't want to edit the web.config every time you publish from Visual Studio.

Nobody other than the user with portal credentials will have access to your azure portal.

This also benefits you in the way that no more you need to store your data as clear text in web.config

This way you secure your web.config data from azure portal.

Windows Azure Web Sites: How Application Strings and Connection Strings WorkWindows Azure Web Sites has a handy capability whereby developers can store key-value string pairs in Azure as part of the configuration information associated with a website.  At runtime, Windows Azure Web Sites automatically retrieves these values for you and makes them available to code running in your website. 

 since sensitive information such as Sql connection strings with passwords never show up as cleartext in a web.config or php.ini file.

Difference between appsetting and connectionstring  includes a little extra metadata telling Windows Azure Web Sites that the string value is a database connection string. 

Retrieving Key-Value Pairs as Environment Variables

Key-value can be retrieved at runtime by code running inside of a website through environment variables.

Here is what the example page output looks from the previous code snippet:

Developers can easily retrieve these values from any of the web application frameworks supported in Windows Azure Web Sites.

From the previous examples you will have noticed a naming pattern for referencing the individual keys.  For “app settings” the name of the corresponding environment variable is prepended with “APPSETTING_”.

For “connection strings”, there is a naming convention used to prepend the environment variable depending on the type of database you selected in the databases dropdown.  The sample code is using “SQLAZURECONNSTR_” since the connection string that was configured had “Sql Databases” selected in the dropdown.

The full list of database connection string types and the prepended string used for naming environment variables is shown below:

If you select “Sql Databases”, the prepended string is “SQLAZURECONNSTR_”

If you select “SQL Server” the prepended string is “SQLCONNSTR_”

If you select “MySQL” the prepended string is “MYSQLCONNSTR_”

If you select “Custom” the prepended string is “CUSTOMCONNSTR_”

Retrieving Key-Value Pairs in ASP.NET

“App settings” neatly map to the .NET Framework’s appSettings configuration.  Similarly “connection strings” correspond to the .NET Framework’s connectionStrings collection.

  If the application setting(s) happen to already exist in your web.config file, Windows Azure Web Sites will automatically override them at runtime using the values associated with your website.

code runs on a developer’s local machine, the value returned will be the one from the web.config file.  However when this code runs in Windows Azure Web Sites, the value returned will instead be overridden with the value entered in the portal

Configuring Key-Value Pairs from the Command-lineApp setting

Connection string

Note that for the property $cs.Type, you can use any of the following strings to define the type:  “Custom”, “SQLAzure”, “SQLServer”, and “MySql”.

HTTP Handlers and Windows Azure Web Roles

There are two types of storage account containers in Windows Azure – private and public.  A resource in a private container can only be viewed by specifying an access key along with the request. A public container on the other hand is viewable by anyone.  When creating a new storage account in Windows Azure, new containers are private by default. Therefore when you attempt to access a resource’s URL in the browser, you will get an HTTP 404 

Making containser public

1. CloudStorageAccount cloudStorageAccount

= CloudStorageAccount.FromConfigurationSetting(“DataConnectionString”);

2.             CloudBlobClient cloudBlobClient =

cloudStorageAccount.CreateCloudBlobClient();

3.             CloudBlobContainer cloudBlobContainer =

cloudBlobClient.GetContainerReference(“nolabel”);

4.             cloudBlobContainer.CreateIfNotExist();

5.             cloudBlobContainer.SetPermissions(

6.                 new BlobContainerPermissions {  PublicAccess  = BlobContainerPublicAccess

Type.Off }

7.                 );

use an HTTP handler to intercept jpeg requests so that I can call one of the aforementioned methods and write the jpeg to the response stream which will display the image.

1. public class JpegHandler1 : IHttpHandler

2.     {

3.         public void ProcessRequest(HttpContext context)

4.         {

5.             string imageUri = context.Request.QueryString[“imageUri”];

6.

7.             if (string.IsNullOrEmpty(imageUri) == false)

8.             {

9.                 CloudStorageAccount cloudStorageAccount =

CloudStorageAccount.FromConfigurationSetting(“DataConnectionString”);

10.                 CloudBlobClient cloudBlobClient =

cloudStorageAccount.CreateCloudBlobClient();

11.                 CloudBlob cloudBlob = cloudBlobClient.GetBlobReference(imageUri);

12.                 byte[] cloudBlobBytes = cloudBlob.DownloadByteArray();

13.

14.                 if (cloudBlobBytes != null)

15.                 {

16.                     context.Response.Clear();

17.                     context.Response.ContentType = “image/jpeg”;

18.                     context.Response.BinaryWrite(cloudBlobBytes);

19.                     context.Response.End();

20.                 }

21.             }

22.         }

23.

24.         public bool IsReusable

25.         {

26.             get

27.             {

28.                 return false;

29.             }

30.         }

31.     }

add the following section to the <system.webServer>configuration section in the site’s web.config file

1. <system.webServer>

2.     <modulesrunAllManagedModulesForAllRequests=“true“ />

3.     <handlers>

4.       

<addname=“JpegHandler“verb=“*“path=“*.jpg“type=“JpegHandler“resourceType=“U

nspecified“/>

5.     </handlers>

6.   </system.webServer>

Microsoft Azure Web Sites: Deploying wordpress to a virtual directory within the azure web site

Microsoft Azure Web Sites allows you to have a virtual directory created within the site.

y current set-up.

SiteName: Kaushal

HostName: kaushal.azurewebsites.net

Application: ASP.NET MVC

No databases are currently linked to my site

Stepst to setup wordpress

Create a virtual directory within my site called BLOG via azure portal and link a MySQL

database to this site.

On my Local Machine, download and install WordPress via WebMatrix and deploy it to the

virtual directory we created above.

Enable HTTPS for an Azure website

HTTPS for the *.azurewebsites.net domainIf you are not planning on using a custom domain name, but are instead planning on

using the *.azurewebsites.net domain assigned to your website by Azure (for

example, contoso.azurewebsites.net) then HTTPS is already enabled on your site

with a certificate from Microsoft. You can

usehttps://mywebsite.azurewebsites.net to access your site. However,

*.azurewebsites.net is a wildcard domain. Like all wildcard domains, it is not as

secure as using a custom domain with your own certificate.

Enable SSL for your custom domainTo enable HTTPS for a custom domain, such as contoso.com, you must first register a

custom domain name with a domain name registrar. Once you have registered a

custom domain name and configured your website to respond to the custom name, you

must request an SSL certificate for the domain.

NOTE:

In order to enable HTTPS for custom domain names, you must configure your

website for Standard web hosting plan mode. This may incur additional costs if you

are currently using free or shared mode.

Get an SSL certificate

Before requesting an SSL certificate you must first determine which domain names will

be secured by the certificate. This will determine what type of certificate you must

obtain. If you just need to secure a single domain name such

as contoso.com or www.contoso.com a basic certificate is sufficient. If you need to

secure multiple domain names, such as contoso.com, www.contoso.com,

and mail.contoso.com, then you can get a wildcard certificate, or a certificate

with Subject Alternate Name (subjectAltName).

SSL certificates used with Azure Websites must be signed by a Certificate

Authority (CA).

The certificate must meet the following requirements for SSL certificates in Azure:

The certificate must contain a private key.

The certificate must be created for key exchange, exportable to a Personal

Information Exchange (.pfx) file.

The certificate's subject name must match the domain used to access the

website. If you need to serve multiple domains with this certificate, you will need to

use a wildcard value or specify subjectAltName values as discussed previously.

The certificate should use a minimum of 2048-bit encryption.

Certificates issued from private CA servers are not supported by Azure Websites.

Get a certificate using Certreq.exe (Windows only)

Get a certificate using OpenSSL

Get a certificate using the IIS Manager

Configure Standard modeAzure Websites do not enforce HTTPS. Enabling HTTPS for a custom domain is only available for the Standard web hosting plan mode of Azure websites.

To enforce HTTPS for your website, you can use the URL Rewrite module. The URL

Rewrite module is included with Azure Websites, and enables you to define rules that

are applied to incoming requests before the requests are handed to your application. It

can be used for applications written in any programming language supported

by Azure Websites. URL Rewrite rules are defined in a web.config file stored in the

root of your application.

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

<system.webServer>

<rewrite>

<rules>

<rule name="Force HTTPS" enabled="true">

<match url="(.*)" ignoreCase="false" />

<conditions>

<add input="{HTTPS}" pattern="off" />

</conditions>

<action type="Redirect" url="https://{HTTP_HOST}/{R:1}"

appendQueryString="true" redirectType="Permanent" />

</rule>

</rules>

</rewrite>

</system.webServer>

</configuration>

NOTE:

If your application is written in Node.js, PHP, Python Django, or Java, it probably

doesn't include a web.config file. However Node.js,Python Django, and Java all

actually do use a web.config when hosted on Azure Websites - Azure creates the file

automatically during deployment, so you never see it. If you include one as part of your

application, it will override the one that Azure automatically generates.

NOTE:

.NET MVC applications should use the RequireHttps filter instead of URL Rewrite. 

Elliptic Curve Cryptography (ECC) certificates are supported with Azure Websites

Microsoft Azure Portal Logon to Azure portal.

Go to the CONFIGURE page for the site and scroll to the virtual applications and directories

section at the bottom of the page.

Add an entry

Click on SAVE.

Now go to the LINKED RESOURCES page and link a MySQL database to your site.

NOTE: Choose an existing MySQL DB or create a new one. Let's say you already have a free MySQL DB associated with your subscription but you want a separate MySQL database for the application. You will have to purchase a plan from CLEARDB for this

Once, linked. Go to the DASHBOARD page.

Under quick glance section a hyperlink called View connection strings will be created.

NOTE: You could retrieve the connection string parameters from the LINKED RESOURCES page too. Click on MANAGE in the bottom pane for the site. This will redirect you to ClearDB site which will provide you with the following

Database Data Source User Id Password

Download & save the publishsettings file for the website by clicking the hyperlink "Download

the publish profile" under quick glance section of theDASHBOARD page.

Local Machine Launch Microsoft WebMatrix

Click on New -> App Gallery

Select WordPress from the App Gallery and click on Next.

This will take you to through the WordPress setup.

Accept the EULA by clicking on "I ACCEPT"

Once done it will start downloading the contents to your local machine (C:\Users\<username>\

Documents\My Web Sites\WordPress)

During these process it allows you to configure certain application parameters as shown below:

Once you specify the parameters and click on Next it proceeds with the installation.

Once installed, click on "Copy user names and passwords". This will copy the details to

clipboard which you could save in a text file.

Click on OK.

Now click on Publish

This will prompt you with another window.

Click on Import publish profile and point it to the location where we saved the

publishsettings file we downloaded earlier.

Once selected, it will auto-populate the parameters from the publishsettings file.

We need to modify the following sections as shown below:o Site name: kaushal\wordpress (physical path location relative to the root site)

o Destination URL: http://kaushal.azurewebsites.net/blog (virtual directory name)

NOTE: Don't chose FTP as the protocol as it doesn't allow you to publish databases.

Click on Validate Connection. Once validated, you will see the confirmation.

Click on Save.

This will take you to the Publish Compatibility page. Click on Continue.

Once compatibility check has been performed. Click on Continue again.

It will display the list of files that will deployed to the server.

Click on Continue to start the deployment.

Once publishing is completed you could open the log file and analyze.

Click on the hyperlink as shown below to browse to the site:

Configuring a custom domain name for an Azure WebsiteWhen you create a website, Azure assigns it to a subdomain of azurewebsites.net.

Custom domain names cannot be used with Free websites. You must configure your websites for Shared, Basic, or Standard mode, 

Here are the general steps to configure a custom domain name

1. Reserve your domain name.

2. Create DNS records that map the domain to your Azure website.

3. Add the domain name inside the Azure Management Portal.

DNS record typesThe Domain Name System (DNS) uses data records to map domain names into IP

addresses. There are several types of DNS records. For websites, you’ll create either

an A record or a CNAME record.

An A (Address) record maps a domain name to an IP address.

A CNAME (Canonical Name) record maps a domain name to another domain

name. DNS uses the second name to look up the address. Users still see the first

domain name in their browser. For example, you could map contoso.com

to <yoursite>.azurewebsites.net.

If the IP address changes, a CNAME entry is still valid, whereas an A record must be

updated. However, some domain registrars do not allow CNAME records for the root

domain or for wildcard domains. In that case, you must use an A record.

NOTE:

The IP address may change if you delete and recreate your website, or change

the website mode back to free.

Create the DNS records

Create an “awverify” record (A records only)If you create an A record, Azure websites also requires a special CNAME record, which is

used to verify that you own the domain you are attempting to use. This CNAME record

must have the following form.

If the A record maps the root domain or a wildcard domain: Create a CNAME record that

maps

from awverify.<yourdomain> to awverify.<yourwebsitename>.azurewebsites.n

et. For example, if the A record is for contoso.com, create a CNAME record

for awverify.contoso.com.

If the A record maps a specific subdomain: Create a CNAME record that maps

from awverify.<subdomain> to awverify.<yourwebsitename>.azurewebsites.n

et. For example, if the A record is for blogs.contoso.com, create a CNAME record

for awverify.blogs.contoso.com.

Visitors to your site will not see the awverify subdomain; it’s only for Azure to verify

your domain.

Enable the domain name on your websiteAfter the records for your domain name have propagated, you must associate them with

your website.

NOTE:

It can take some time for CNAME records created in the previous steps to propagate

through the DNS system. You cannot add the domain name of to your Azure Website

until the CNAME has propagated. If you are using an A record, you cannot add the A

record domain name to your Azure Website until the awverify CNAME record created in

the previous step has propagated.

Associating a custom domain and securing communication with Microsoft Azure

How to: Receive alerts from website metricsIn Standard website mode, you can receive alerts based on your website monitoring metrics. The alert feature requires that you first configure a web endpoint for monitoring, which you can do in the Monitoring section of the Configure page. On the Management Services page of the Azure Management Portal, you can then create a rule to trigger an alert when the metric you choose reaches a value that you specify. You can also choose to have email sent when the alert is triggered. 

How to: View usage quotas for a websiteWebsites can be configured to run in either Shared or Standard website mode from the website's Scale management page. Each Azure subscription has access to a pool of resources provided for the purpose of running up to 100 websites per region in Shared website mode. The pool of resources available to each Website subscription for this purpose is shared by other websites in the same geo-region that are configured to run in Shared mode. Because these resources are shared for use by other websites, all subscriptions are limited in their use of these resources. Limits applied to a subscription's use of these resources are expressed as usage quotas listed under the usage overview section of each website's Dashboard management page.

he number of Standard mode websites that can be created per region is 500.

How to: Avoid exceeding your quotasQuotas are not a matter of performance or cost, but it's the way Azure governs resource

usage in a multitenant environment by preventing tenants from overusing shared

resources. Since exceeding your quotas means downtime or reduced functionality for

your website, consider the following if you want to keep your site running when quotas

are about to be reached:

Move your website(s) to a higher-tier Web hosting plan to take advantage of a larger

quota. For example, the only quota for Basic and Standard plans is File System

Storage.

As the number of instances of a website is increased, so is the likelihood of exceeding

shared resource quotas. If appropriate, consider scaling back additional instances of a

website when shared resource quotas are being exceeded.

How to: Configure diagnostics and download logs for a websiteDiagnostics are enabled on the Configure management page for the website. There

are two types of diagnostics: application diagnostics and site diagnostics.

Application Diagnostics

The application diagnostics section of the Configure management page controls the

logging of information produced by the application, which is useful when logging events

that occur within an application. For example, when an error occurs in your application,

you may wish to present the user with a friendly error while writing more detailed error

information to the log for later analysis.

You can enable or disable the following application diagnostics:

Application Logging (File System) - Turns on logging of information produced by the

application. The Logging Level field determines whether Error, Warning, or Information

level information is logged. You may also select Verbose, which will log all information

produced by the application.

Logs produced by this setting are stored on the file system of your website, and can be

downloaded using the steps in the Downloading log files for a website section

below.

Application Logging (Table Storage) - Turns on the logging of information produced

by the application, similar to the Application Logging (File System) option. However, the

log information is stored in an Azure Storage Account in a table.

To specify the Azure Storage Account and table, choose On, select the Logging Level,

and then choose Manage Table Storage. Specify the storage account and table to

use, or create a new table.

The log information stored in the table can be accessed using an Azure Storage client.

Application Logging (Blob storage) - Turns on the logging of information produced

by the application, similar to the Application Logging (Table Storage) option. However,

the log information is stored in a blob in an Azure Storage Account.

To specify the Azure Storage Account and blob, choose On, select the Logging Level,

and then choose Manage Blob Storage. Specify the storage account, blob container,

and blob name to use, or create a new container and blob.

Application logging to table or blob storage is only supported for .NET applications.

Diagnostics can also be enabled from Azure PowerShell using the Set-

AzureWebsite cmdlet.

Site Diagnostics

The site diagnostics section of the Configure management page controls the logging

performed by the web server, such as the logging of web requests, failure to serve

pages, or how long it took to serve a page. You can enable or disable the following

options:

Web Server Logging - Turn on Web Server logging to save website logs using the

W3C extended log file format. Web server logging produces a record of all incoming

requests to your website, which contains information such as the client IP address,

requested URI, HTTP status code of the response, and the user agent string of the client.

You can save the logs to an Azure Storage Account or to the File System.

To save web server logs to an Azure Storage Account, choose Storage, and then

choose manage storage to specify a storage account and an Azure Blob Container

where the logs will be kept. For more information about Azure Storage Accounts,

see How to Manage Storage Accounts.

To save web server logs to the file system, choose File System. This enables the Quota box where you can set the maximum amount of disk space for the log files. The minimum size is 25MB and the maximum is 100MB. The default size is

Advanced configuration

Diagnostics can be further modified by adding key/value pairs to the app

settings section of the Configure management page. The following settings can be

configured from app settings:

DIAGNOSTICS_TEXTTRACELOGDIRECTORY

The location in which application logs will be saved, relative to the web root.

Default value: ..\..\LogFiles\Application

DIAGNOSTICS_TEXTTRACEMAXBUFFERSIZEBYTES

The maximum buffer size to use when capturing application logs. Information is initially

written to the buffer before being flushed to file or storage. If new information is written

to the buffer before it can be flushed, you may lose previously logged information. If

your application produces large bursts of log information, consider increasing the size of

the buffer.

Default value: 10MB

DIAGNOSTICS_TEXTTRACEMAXLOGFOLDERSIZEBYTES

The maximum size of the Application folder in which application diagnostics written to

file are stored.

Default value: 1MB

35MB.

By default, web server logs are never deleted. To specify a period of time after which

the logs will be automatically deleted, select Set Retention and enter the number of

days to keep the logs in the Retention Period box. This setting is available for both

the Azure Storage and File System options.

Detailed Error Messages - Turn on detailed error logging to log additional information

about HTTP errors (status codes greater than 400).

Failed Request Tracing - Turn on failed request tracing to capture information for

failed client requests, such as a 400 series HTTP status code. Failed request tracing

produces an XML document that contains a trace of which modules the request passed

through in IIS, details returned by the module, and the time the module was invoked.

This information can be used to isolate which component the failure occurred in.

Reading log files

The log files that are generated after you have enabled logging and / or tracing for a

website vary depending on the level of logging / tracing that is set on the Configure

management page for the website. Following are the location of the log files and how

the log files may be analyzed:

Log File Type: Application Logging

Location /LogFiles/Application/. This folder contains one or more text files containing

information produced by application logging. The information logged includes the date

and time, the Process ID (PID) of the application, and the value produced by the

application instrumentation.

Read Files with: A text editor or parser that understands the values produced by your

application

Log File Type: Failed Request Tracing

Location: /LogFiles/W3SVC#########/. This folder contains an XSL file and one or

more XML files. Ensure that you download the XSL file into the same directory as the

XML file(s) because the XSL file provides functionality for formatting and filtering the

contents of the XML file(s) when viewed in Internet Explorer.

Read Files with: Internet Explorer

Log File Type: Detailed Error Logging

Location: /LogFiles/DetailedErrors/. The /LogFiles/DetailedErrors/ folder contains one or

more .htm files that provide extensive information for any HTTP errors that have

occurred.

Read Files with: Web browser

The .htm files include the following sections:

Detailed Error Information: Includes information about the error such

as Module, Handler, Error Code, and Requested URL.

Most likely causes: Lists several possible causes of the error.

Things you can try: Lists possible solutions for resolving the problem reported by the

error.

Links and More Information: Provides additional summary information about the

error and may also include links to other resources such as Microsoft Knowledge Base

articles.

Log File Type: Web Server Logging

Location: /LogFiles/http/RawLogs. The information stored in the files is formatted using

the W3C extended log format. The s-computername, s-ip and cs-version fields are not

used by Azure Websites.

Read Files with: Log Parser. Used to parse and query IIS log files. Log Parser 2.2 is

available on the Microsoft Download Center athttp://go.microsoft.com/fwlink/?

LinkId=246619.

How to: Monitor web endpoint statusThis feature, available in Standard mode, lets you monitor up to 2 endpoints from up

to 3 geographic locations.

Endpoint monitoring configures web tests from geo-distributed locations that test

response time and uptime of web URLs. The test performs an HTTP get operation on the

web URL to determine the response time and uptime from each location. Each

configured location runs a test every five minutes.

Uptime is monitored using HTTP response codes, and response time is measured in

milliseconds. Uptime is considered 100% when the response time is less than 30

seconds and the HTTP status code is lower than 400. Uptime is 0% when the response

time is greater than 30 seconds or the HTTP status code is greater than 400.

Enable diagnostic logging for Azure Websites

What is Website diagnostics?Azure Websites provide diagnostic functionality for logging information from both the

web server as well as the web application. These are logically separated into site

diagnostics and application diagnostics.

Site diagnostics

Site diagnostics allow to you enable or disable the following:

Detailed Error Logging - Logs detailed error information for HTTP status codes that

indicate a failure (status code 400 or greater). This may contain information that can

help determine why the server returned the error code.

Failed Request Tracing - Logs detailed information on failed requests, including a

trace of the IIS components used to process the request and the time taken in each

component. This can be useful if you are attempting to increase site performance or

isolate what is causing a specific HTTP error to be returned.

Web Server Logging - Logs all HTTP transactions on a website using the W3C

extended log file format. This report is useful when determining overall site metrics

such as the number of requests handled or how many requests are from a specific IP

address

What is Website diagnostics?Azure Websites provide diagnostic functionality for logging information from both the

web server as well as the web application. These are logically separated into site

diagnostics and application diagnostics.

Site diagnostics

Site diagnostics allow to you enable or disable the following:

Detailed Error Logging - Logs detailed error information for HTTP status codes that

indicate a failure (status code 400 or greater). This may contain information that can

help determine why the server returned the error code.

Failed Request Tracing - Logs detailed information on failed requests, including a

trace of the IIS components used to process the request and the time taken in each

component. This can be useful if you are attempting to increase site performance or

isolate what is causing a specific HTTP error to be returned.

Web Server Logging - Logs all HTTP transactions on a website using the W3C

extended log file format. This report is useful when determining overall site metrics

such as the number of requests handled or how many requests are from a specific IP

address

Application diagnostics

Application diagnostics allows you to capture information produced by a web

application. ASP.NET applications can use the System.Diagnostics.Trace class to log

information to the application diagnostics log. For example:

System.Diagnostics.Trace.TraceError("If you're seeing this, something bad happened");

Application diagnostics allows you to troubleshoot your running application by emitting

information when certain pieces of code are used. This is most useful when you are

trying to determine why a specific path is being taken by the code, usually when the

path results in an error or other undesirable behavior.

Unlike changing the web.config file, enabling Application diagnostics or changing

diagnostic log levels does not recycle the app domain that the application runs within.

Azure Websites also logs deployment information when you publish an application to a

website. This happens automatically and there are no configuration settings for

deployment logging. Deployment logging allows you to determine why a deployment

failed.

How to: Enable diagnosticsDiagnostics can be enabled by visiting the Configure page of your Azure Website in

the Azure Management Portal. On the Configure page, use theapplication

diagnostics and site diagnostics sections to enable logging.

When enabling application diagnostics you must also select the logging level and

whether to enable logging to the file system, table storage, or blob storage. While

all three storage locations provide the same basic information for logged events, table

storage and blob storage log additional information such as the instance ID, thread

ID, and a more granular timestamp (tick format) than logging to file system.

When enabling site diagnostics, you must select storage or file system for web

server logging. Selecting storage allows you to select a storage account, and then a

blob container that the logs will be written to. All other logs for site diagnostics are

written to the file system only.

nformation stored in table storage or blob storage can only be accessed using a

storage client or an application that can directly work with these storage systems.

The following are the settings available when enabling application diagnostics:

Logging level - allows you to filter the information captured

to informational, warning or error information. Setting this to verbose will log all

information produced by the application. Logging level can be set differently for file

system, table storage, and blob storage logging.

File system - stores the application diagnostics information to the website file system.

These files can be accessed by FTP, or downloaded as a Zip archive by using the Azure

PowerShell or Azure Command-Line Tools.

Table storage - stores the application diagnostics information in the specified Azure

Storage Account and table name.

Blob storage - stores the application diagnostics information in the specified Azure

Storage Account and blob container.

Retention period - by default, logs are not automatically deleted from blob storage.

Select set retention and enter the number of days to keep logs if you wish to

automatically delete logs.

Diagnostics can also be enabled from Azure PowerShell using the Set-

AzureWebsite cmdlet.

How to: Download logsDiagnostic information stored to the website file system can be accessed directly using

FTP. It can also be downloaded as a Zip archive using Azure PowerShell or the Azure

Command-Line Tools.

The directory structure that the logs are stored in is as follows:

Application logs - /LogFiles/Application/. This folder contains one or more text files

containing information produced by application logging.

Failed Request Traces - /LogFiles/W3SVC#########/. This folder contains an XSL

file and one or more XML files. Ensure that you download the XSL file into the same

directory as the XML file(s) because the XSL file provides functionality for formatting

and filtering the contents of the XML file(s) when viewed in Internet Explorer.

Detailed Error Logs - /LogFiles/DetailedErrors/. This folder contains one or more .htm

files that provide extensive information for any HTTP errors that have occurred.

Web Server Logs - /LogFiles/http/RawLogs. This folder contains one or more text files

formatted using the W3C extended log file format.

Deployment logs - /LogFiles/Git. This folder contains logs generated by the internal

deployment processes used by Azure Websites, as well as logs for Git deployments.

How to: Stream logsWhile developing an application, it is often useful to see logging information in near-real

time. This can be accomplished by streaming logging information to your development

environment using either Azure PowerShell or the Azure Command-Line Tools.

og streaming will also stream information written to any text file stored in the D:\home\

LogFiles\ folder.

How to: Understand diagnostics logsApplication diagnostics logs

Application diagnostics stores information in a specific format for .NET applications,

depending on whether you store logs to the file system, table storage, or blob storage.

The base set of data stored is the same across all three storage types - the date and

time the event occurred, the process ID that produced the event, the event type

(information, warning, error,) and the event message.

File system

Each line logged to the file system or received using streaming will be in the following

format:

{Date} PID[{process id}] {event type/level} {message}

For example, an error event would appear similar to the following:

2014-01-30T16:36:59 PID[3096] Error Fatal error on the page!

Logging to the file system provides the most basic information of the three available

methods, providing only the time, process id, event level, and message.

Table storage

When logging to table storage, additional properties are used to facilitate searching the

data stored in the table as well as more granular information on the event. The

following properties (columns) are used for each entity (row) stored in the table.

PROPERTY NAME VALUE/FORMAT

PARTITIONKEY DATE/TIME OF THE EVENT IN YYYYMMDDHH FORMAT

RowKey A GUID value that uniquely identifies this entity

Timestamp The date and time that the event occurred

EventTickCount The date and time that the event occurred, in Tick format (greater precision)

ApplicationName The website name

Level Event level (e.g. error, warning, information)

EventId The event ID of this event

PROPERTY NAME VALUE/FORMAT

PARTITIONKEY DATE/TIME OF THE EVENT IN YYYYMMDDHH FORMAT

Defaults to 0 if none specified

InstanceId Instance of the website that the even occurred on

Pid Process ID

Tid The thread ID of the thread that produced the event

Message Event detail message

Blob storage

When logging to blob storage, data is stored in comma-separated values (CSV) format.

Similar to table storage, additional fields are logged to provide more granular

information about the event. The following properties are used for each row in the CSV:

PROPERTY NAME VALUE/FORMAT

Date The date and time that the event occurred

Level Event level (e.g. error, warning, information)

ApplicationName The website name

InstanceId Instance of the website that the even occurred on

EventTickCount The date and time that the event occurred, in Tick format (greater precision)

EventId The event ID of this event

PROPERTY NAME VALUE/FORMAT

Defaults to 0 if none specified

Pid Process ID

Tid The thread ID of the thread that produced the event

Message Event detail message

The data stored in a blob would similar to the following:

date,level,applicationName,instanceId,eventTickCount,eventId,pid,tid,message

2014-01-30T16:36:52,Error,mywebsite,6ee38a,635266966128818593,0,3096,9,An error

occurred

NOTE:

The first line of the log will contain the column headers as represented in this example.

Failed request traces

Failed request traces are stored in XML files named fr######.xml. To make it easier

to view the logged information, an XSL stylesheet named freb.xsl is provided in the

same directory as the XML files. Opening one of the XML files in Internet Explorer will

use the XSL stylesheet to provide a formatted display of the trace information. This will

appear similar to the following:

Detailed error logs

Detailed error logs are HTML documents that provide more detailed information on

HTTP errors that have occurred. Since they are simply HTML documents, they can be

viewed using a web browser.

Web server logs

The web server logs are formatted using the W3C extended log file format. This

information can be read using a text editor or parsed using utilities such asLog Parser.

Windows Azure Web Sites: SSL Support and configuration

Windows Azure Web Sites provide native support for SSL, which includes both SNI SSL and IP based SSL for custom web site domain names. . Before this the only way of doing SSL was via Cloud Service & Rewriting the URL.

This feature is not available to sites which are running in either Free or Shared mode.

ssl bindings section is enabled when the user has a valid custom domain name added for that site. 

NOTE: If there are multiple bindings for the site then the domain names must be unique. Irrespective of whether they are IP based SSL bindings or SNI SSL bindings. In simple words, the rules that are applicable while configuring a SSL binding on IIS are still applicable here.                         Also Non-SNI compliant browsers will not be able to browse to the website if it is configured to use SNI SSL bindings.

The users have to shell out more money when they configure the website to use IP Based SSL. This is very obvious, as this requires a dedicated IP (a resource) to be allocated for the website. This is also an expensive resource.

SNI SSL is comparatively cheaper as it doesn’t need a dedicated IP Address. However, it has own limitations as the non-SNI compliant browsers will not be able to access the site.

How to configure PHP in Azure Websites

What is Azure Websites?Azure Websites allows you to build highly scalable websites on Azure. You can

quickly and easily deploy sites to a highly scalable cloud environment that allows you to

start small and scale as traffic grows. Azure Websites uses the languages and open

source apps of your choice and supports deployment with Git, FTP, and TFS. You can

easily integrate other services like MySQL, SQL Database, Caching, CDN, and Storage.

manage websites by using the API, Windows PowerShell, and Xplat-CLI

Service Management REST API Reference

Using Azure Traffic Manager with Azure Web Sites

Azure Traffic Manager (ATM) is a DNS-based service for managing traffic to Azure services, and it’s

recently been made available to Web Sites users. You can use ATM to:

Route visitors to your site to a region that will provide the best performance.

Automatically route traffic to a secondary region if there is a problem in the primary region

where your site is hosted.

Spread load evenly across multiple copies of your website hosted in multiple regions.

In order to use ATM with Web Sites, you will need to have two or more sites and each of them must be running in a different region. You can only add one website per region to ATM, so this requirement is important.

You must run your sites in Standard mode or Basic mode in order to use ATM with Web Sites.

ATM will route traffic based on a profile that you create.

Once you’ve created your ATM profile, you’ll want to add your endpoints.

 ATM will use the path in the Monitoring Settings section to check the endpoints you configured. It performs that check once every 30 seconds, and only an HTTP 200 status is considered healthy. Therefore, if your application is designed in a way that causes a non-200 response to the root of the site (e.g. an ASP.NET forms authentication site that might return a 302 redirect to the login page), you’ll want to configure a path and file name for your ATM profile that points to an unprotected file so that a 200 response is returned.

Web Sites knows how to route the ATM URL to your site because it adds your ATM URL to the custom domains for your site automatically ie when you add endpoint in your ATM profile.

To use custom domain name first need to create a www CNAME entry at your domain registrar that points to your ATM URL

Note: Your subdomain may not be “www”. In that case, create a CNAME record for the subdomain you want to use. 

Note: ATM is CNAME based and doesn’t support A records. Therefore, you can’t use a naked domain (mydomain.com) with ATM. It requires that you set up a CNAME record.

Load Balancing Methods

Performance – When this method is used, ATM will send users to the region where he or she

will get the best performance. This prevents situations where, for example, a user who is in the

Central US region is directed to a site running in West Europe.

Failover – This method will redirect traffic to a secondary region if there is a problem in the

primary region. For example, you may have a site in a “backup” region that doesn’t handle

any traffic unless your primary site is offline for some reason.

Round Robin – This method will evenly distribute traffic across the endpoints configured in

your ATM profile using a round robin load balancing methodology. You can use this method, for

example, to “ramp up” traffic to a particular endpoint without allowing it to receive all of your

traffic immediately. (In the future, ATM will include enhanced functionality to make this kind of

scenario even easier to configure.)

Install and Configure the Azure Cross-Platform Command-Line InterfaceThe Azure Cross-Platform Command-Line Interface (xplat-cli) provides a set of open source, cross-platform commands for working with the Azure Platform. 

The xplat-cli is written in JavaScript, and requires Node.js. It is implemented using the Azure SDK for Node.js, and released under an Apache 2.0 license.