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 Details

Four 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 Slots

Settings 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

Slots
Get-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 Slots
azure 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 Service

Azure 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 services 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 inplace 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 Groups
A 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 portal
If 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

create

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

assign

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 websites
define and use app settings, connection strings, handlers, and virtual directories

Importance of app settings in

azure website portal
However 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 Work
Windows Azure Web Sites has a handy capability whereby developers can store keyvalue 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 Frameworks appSettings configuration. Similarly
connection strings correspond to the .NET Frameworks 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 developers 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-line

App 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
resources 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 = BlobContainerPublicAcce

ssType.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 sites web.config file
1.

<system.webServer>

2.

<modulesrunAllManagedModulesForAllRequests=true />

3.

<handlers>

4.

<addname=JpegHandlerverb=*path=*.jpgtype=JpegHandlerresourceTyp
e=Unspecified/>

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

domain
If 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 domain

To 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 mode

Azure 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)

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 Website
When 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 types

The Domain Name System (DNS) uses data records to map domain names into IP
addresses. There are several types of DNS records. For websites, youll 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.ne
t. 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; its only for Azure to verify your
domain.

Enable the domain name on your

website
After 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

metrics
In 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

website
Websites 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

quotas
Quotas 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 website
Diagnostics 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 SetAzureWebsite 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

status
This 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 diagnostics

Diagnostics 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 SetAzureWebsite cmdlet.

How to: Download logs

Diagnostic 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 logs

While 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 logs

Application 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 YYYYMM

RowKey

A GUID value that uniquely identifies

Timestamp

The date and time that the event occ

EventTickCount

The date and time that the event occ

precision)

ApplicationName

The website name

Level

Event level (e.g. error, warning, infor

EventId

The event ID of this event

Defaults to 0 if none specified

InstanceId

Instance of the website that the even

Pid

Process ID

PROPERTY NAME

VALUE/FORMAT

PARTITIONKEY

DATE/TIME OF THE EVENT IN YYYYMM

Tid

The thread ID of the thread that prod

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 occ

Level

Event level (e.g. error, warning, infor

ApplicationName

The website name

InstanceId

Instance of the website that the even

EventTickCount

The date and time that the event occ

precision)

EventId

The event ID of this event

Defaults to 0 if none specified

Pid

Process ID

Tid

The thread ID of the thread that prod

PROPERTY NAME

VALUE/FORMAT

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 doesnt 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 its
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 youve created your ATM profile, youll 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),

youll 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 doesnt support A records. Therefore, you cant 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 doesnt 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
Interface
The 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.