Part 15 : Understanding Windows Azure Accounts and Subscriptions

In this tutorial we will look into the details of Azure account and subscriptions and see what exactly they mean. We will also see how to set the administrative roles to the users who need access to Azure to manage services.

Before going into the subject it is important to understand the user account to access Windows Azure, which is as usual an combination of email and password, used to authenticate users. Now user account, specifically User ID, comes in two forms : Microsoft accounts and organizational accounts.

• Microsoft accounts take the form <user>@outlook.com <user>@hotmail.com or <user>@live.com. It is good for single person but not for the organization.
• Organizational accounts take the form judy@contoso.onmicrosoft.com or judy@contoso.com, for    example. “Contoso” can be any domain name. Good for middle and large enterprise.

Organizational accounts are different from Microsoft accounts because they are sourced from Azure Active Directory. Because organizational accounts are created from within Azure Active Directory, you have more options for managing them. For example, Organizational accounts can be supplemented with multi-factor authentication, which requires the user to enter additional information to verify their identity.
So, as a general rule, use Organizational accounts whenever you need to assign administrative access to Azure. Every Azure subscription has a default directory that you can use to create organizational accounts.

In this tutorial I've used the microsoft account.

Windows Azure Account
Windows Azure Account is a shell to provide usage and billing reporting of the services. He is also the Account Administrator of that account.

Subscription
A Windows Azure subscription grants you access to Windows Azure services and to the Windows Azure Platform Management Portal. In order to deploy services and data to Windows Azure, you need a Windows Azure subscription. hey also help you control how resource usage is reported, billed, and paid for. Each subscription can have a different billing and payment setup, so you can have different subscriptions and different plans by department, project, regional office, and so on. Every cloud service belongs to a subscription, and the subscription ID may be required for programmatic operations.

Account Administrator
The Account Administrator for a subscription is the only person with access to the Account Center. (https://account.windowsazure.com/Home/Index)

They can create subscriptions, cancel subscriptions for their account, update the service administrator and co-administrator for an individual subscription. He is the person responsible for paying the subscription bill. Normally, the Account Administrator has financial responsibilities in your company. This person is also the default Service Administrator for the subscription.

The Account Administrator does not have any other access to services in that subscription; they need to also be the Service Administrator or a co-administrator for that. For security reasons, the Account Administrator for a subscription can only be changed with a call to Azure support. The Account Administrator can easily reassign the Service Administrator for a subscription at the Account Center at any time.

Service Administrator
Service Administrator are authorized to access Azure Management Portal for all subscriptions in the account.Normally, the Service Administrator is a developer, system administrator, or other IT person responsible for IT services in your company. By default, it is same as the Account Administrator when a subscription is created but can be changed later. The Service Administrator is the first co-administrator for a subscription. Like other co-administrators, the Service Administrator has management access to cloud resources using the Azure Management Portal, as well as tools like Visual Studio, other SDKs, and command line tools like PowerShell. The Service Administrator can also add and remove other co-administrators.

Co-Administrators
Imagine the scenario of large enterprise. There can be a big numbers of servers and application to manage and obviously a single person cannot handle it. This is the reason the service administrator can create Co-Administrators to help manage Windows Azure operations.

Co-administrators are identified by Windows Live ID.  Therefore, a person that you want to be a co-administrator of your subscription must have his or her own Windows Live ID.  If they do not have a Windows Live ID, they can create one at login.live.com.  Co-administrators have complete access to the subscription services.  They can even add or delete other co-administrators.  However, they cannot remove the Service Owner (the Service Administrator).  Also, co-administrators do not have access to payment/billing information (things managed by the Account Administrator).


Let's see an example of all of these terms.  I've sign up for free Azure trial account. I'll be the account owner (with my windows live ID username/pwd) of this account. I'm the Account Administrator for this account and by default I'm also the Service Administrator of this account.
Open Windows Azure Management Portal and scroll all the way down to "Settings" on the left side. After clicking on "Settings", go to the Administartor tab and you can see all the administrator listed for that subscription as shown in the image below.

 As I told you before by default, Service Administrator is same as the Account Administrator when a subscription is created. We can change the Service Administrator, but not from here. I'll show in a moment how to do that. You can see that the Service Administrator is the first co-administrator for a subscription.

To add a Co-Administrator , while still in Administrator tab under Settings, click on the add button at the bottom. A pop windows will get opened to add co-administrator.

Enter the email address of the co-administrator. Choose the subscription, here I only have the free subscription. The co-administrator must be either a Microsoft Account or a user account within the Default Directory directory. Click the OK button and the co-administrator will be created. You can add upto 200 co-administrator per subscription (in addition to Service Administrator).

- Co-administrators with an organizational account sign in to the portal using a password that they receive in email or that is provided by the system administrator.
-  Co-administrators with a Microsoft account sign in to the portal using the password for that account.

Crucial differences between the service administrator and co-administrators:

• Co-administrators can’t delete the Service Administrator from the Azure Management Portal. Only the Account Administrator can change this assignment at the Account Center.

• The Service Administrator is the only user authorized to change a subscription’s association with a directory in the Azure Management Portal.

To see all the subscriptions under your account, go to Account Center (https://account.windowsazure.com/Subscriptions) , or while still in Azure portal click on the account name on top right side and then click on "View my bill" , this will open Account center. Click on subscription tab and you can see all the subscriptions under your account. You can even add a new subscription from here.

Once you clicked on any subscription, you can see the details related to billing, usage, accounts related to that subscription. You can also edit some of the details related to account like Change Payment Method, Edit Subscription Details, Change Address, Cancel Subscription from here.

Let's see how you can change the Service Administrator. While still on the Subscription Summary page, go to the very end of the page, and there on the right hand side you can see a link to "Edit subscription details".
You can also see the account details in that section.

Click on that link and new pop-up windows will open that let you to change the Service Administrator.

Some best practices you should follow while creating subscriptions and administrators.

Part 14 : Windows Azure Web Sites - Scaling

In this tutorial we will see how you scale your website up or down depending on the needs.

Scalability is the ability of a system to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth

When you start developing a new web application, or when you want to test your web application, or try out the Azure WAWS, you might want to start free and small. All web sites can deploy in a free hosting mode. Then as the traffic to your website increases and as the expectations for performance and availability increases, you can scale out to meet the needs of your business.

Also if your website is already in production and you have some period of time where you expect the hits go high, for example gift shopping website during the Christmas season, you can scale up for that period of time and then scale down again later.  Consider the situation where you have your own servers in datacenter, you have to provisions the servers for the peak load and most of the times the servers will be lying ideally but incurs cost to you. With cloud, this is great feature to scale up and down depending on your needs and can save lots of money.

By adding and removing role instances to your Windows Azure application while it is running, you can balance the performance of the application against its running costs. You can add new instances when demand is high, and remove instances when you no longer need them in order to reduce running costs.

For increased performance and throughput for your websites on Microsoft Azure, you can use the Azure Management Portal to scale your Web Hosting Plan mode from Free to Shared, Basic, or Standard.

Scaling up on Azure Websites involves two related actions: changing your Web Hosting Plan mode to a higher level of service, and configuring certain settings after you have switched to the higher level of service.

Each scale operation happens quickly – typically within seconds – and does not require changes to your site’s code, nor a redeployment of your site. Scale operation have no impact on existing user sessions.
You can also scale up or down programmatically by using the Windows Azure Management API.

Before moving forward let's see what exactly is meaning of scale up and scale out.

Scale Up
Also know as scale "vertically". You can scale up by increasing the processing power by adding more processors and RAM or buying a bigger, multi-core robust server.
Pros : Less licensing cost, less power consumption than running multiple servers, less challenging to implement.
Cons : If single server fails, it brings down the whole application, price.

Scale up operations can be performed on any site without worrying about the implications of multi-instances data consistency.
Windows Azure offer servers for web sites in multiple instance sizes of small, medium and large. Scaling up in Windows azure for web sites can be achieved by changing the instance size of the server, e.g. from small to medium.

Scale Out
Also known as scale "horizontally". You can scale out by adding more servers and adding a load-balancer to distribute the demand between them.
Pros : cheaper than scaling vertically, easier to run fault tolerance
Cons : More licensing fees, higher utility cost, complex to implement.

To scale out your site in windows azure, you need to just increase the instance count for that web site. This is very easy and we see it in practical shortly.  The big advantage with Windows Azure is that when you scale out a web site in Windows Azure Web Sites there is no need to configure load balancing separately since this is already provided by the platform.

To benefit from scale OUT operations your site must be designed for concurrency. You should plan for the shared state so that request from particular user can be handled by any server under the load-balancer. Or use sticky session. Sticky session means that when a request comes into a site from a client all further requests go to the same server initial client request accessed. Load balancer will usually handle this.

One thing to understand regarding scale out is that even they can increase the total amount of traffic capacity that your site can handle, it does not always improve performance in the way that scaling up does.

Scale up and scale out operations can be combined for a website to provide hybrid scaling. The same contentions about multi-instance sites would apply to this scenario.

Let's start with a free website and we will scale it using Windows Azure Management Portal.

Scaling of Free website to Shared or Basic mode
1. Open Management portal and create a website in free mode (if not already created). Assume that your      website is currently in development mode and this is the reason we choose free mode.

 2. In the website listing page, click on the site and then go to "Scale" tab.

 3. Currently the website mode is free. Now our website goes into a test phase where business users and stakeholders are going to test the website. So we are going to scale it to Shared mode. The Web Hosting Plan Sites section shows a short list of sites in the current plan. All sites in the current plan will be changed to the Web Hosting Plan Mode that you select. Click on the Shared mode. Under capacity let the instance count be 1 instance and click on save. Note that in free mode you cannot change the instance count.

So now effectively we have scaled up the website to shared mode. 

4. Now testing is done and accepted by business users. We want to roll out the pilot site for several hundred users and we want  the website to available for most of the time. What we can do is to let the site remain in shared mode but increase the instance count. Again go to website and then scale tab and then in the instance count make it 3. You can scale out to maximum of 6 instances. Windows azure will automatically configure load balancer for you. Notice that in shared mode you can increase the instance count but not the instance size, because it is fixed in shared mode. So you can scale out but not scale up.  Also note that while changing the web hosting plan mode will change all the website under that plan , changing instance count will not affect the instance count of other sites in the same web hosting plan mode. 

Still confused :) try it out yourself and you will understand.

 5. Now our pilot phase is well received by audience and we want to go into production. But we don't want to go into production in shared mode. So we want to change it to Basic mode so that we will have dedicated servers serving only our website. Go to the scale tab again and this time choose the web hosting plan mode as Basic. You notice that there will be one more configuration item available "instance size". Now since we have our own reserved server, we can also choose the right fit size that we want. Since I just launched my website I want to start with medium size server and two of them to support availability. This is the example of hybrid scaling where we both scale up and scale out. 

Also notice that changing the instance count or size will change for all the sites in web hosting plan, which is little different that shared mode as described above.

6. Now suddenly the management decided that there are some serious business flaws in the current website and they want to fix it but at the same time they don't want to incur cost during that time. Easy, just go to scale tab again and choose the web hosting plan mode as "free" and start your development.

So we have seen how easy it is to scale up or down as required in Windows Azure and these changes take only seconds to apply.

Scaling Website to Standard Mode

Before going into this topic lets discuss Auto-scaling briefly. One of the key benefits that the Windows Azure technology platform delivers is the ability to rapidly scale your application in the cloud in response to changes in demand. If you rely on manual interventions to scale your application, you may not always achieve the optimal balance between costs and performance; an operator may respond late, or underestimate the number of role instances that you need to maintain throughput. An autoscaling solution reduces the amount of manual work involved in dynamically scaling an application. It can do this in two different ways: either preemptively by setting constraints on the number of role instances based on a timetable, or reactively by adjusting the number of role instances in response to some counter(s) or measurement(s) that you can collect from your application or from the Windows Azure environment. We will see the autoscaling feature in this topic.

NOTE: Before switching a Web Hosting Plan to Standard mode, you should remove spending caps in place for your Microsoft Azure Websites subscription. Otherwise, you risk your site becoming unavailable if you reach your caps before the billing period ends. 

1. To scale to Standard, follow the same initial steps as when scaling to Shared or Basic, and then choose Standard for Web Hosting Plan Mode. As before, the Web Hosting Plan Sites section shows a short list of sites in the current plan. In this case, all sites in the current plan will be changed to Standard mode.

2. Selecting Standard expands the Capacity section to reveal the Instance Size and Instance Count options, which are also available in Basic mode. The Edit Scale Settings for Schedule and Scale by Metric options are available only in Standard mode.

3.  Configure the Instance Size and instance count as we have seen before.

4.  If you want to automatically scale (autoscale) resources based on daytime versus nighttime, weekday versus weekend, and/or specific dates and times, choose Set up schedule times in the Edit Scale Settings for Schedule option.

5. A new dialog box called "Set up schedule times" will open.  The Set up schedule times dialog provides a number of useful configuration choices. These options let you define different scale settings during weekdays or weekends.

First checkbox is "Different scale settings for day and night". This creates two schedules. The first schedule runs from the start of the day to the end of the day. The second schedule runs from the end of one day to the start of the next day, and uses the options below to define times and the time zone.

Second checkbox is "Different scale settings for weekdays and weekends". This creates a separate profile that starts on Friday evening and ends on Monday morning. Use the options below to define start times, end times, days, and time zone.

Under Recurring Schedules, select Differing scale between Day and Night and/or Differing Scale between Weekday and Weekend to scale resources based on separate daytime and nighttime schedules and/or separate weekday and weekend schedules. For the purposes of this feature, the weekend starts at the end of day Friday (8:00 PM by default), and ends at the beginning of the day on Monday (8:00 AM by default). The weekend profile uses the same day start and end that you will define in the Time setting. 

Under Time, choose a start and end time for the day in half-hour increments, and a time zone. By default, the day starts at 8:00 AM and ends at 8:00 PM. Daylight Savings Time is respected for the time zone that you select.

Under Specific Dates, you can create one or more named time frames for which you want to scale resources. For example, you may want to provide additional resources for a sales or launch event during which you might have large peaks in web traffic. Please note that this will override your other scale settings.

After you have made your choices, click OK to close the Schedule Times dialog box.

6. The Edit Scale Settings for Schedule box now displays configurable schedules or events based on the changes you made. Select one of the recurring schedules or specific dates to configure it.

You can now use the Scale by Metric and the Instance Count features to fine tune the scaling of resources for each schedule that you choose.

7.  To dynamically adjust the number of instances that your website uses if its load changes, enable the Scale by Metric option by choosing CPU.

The graph shows the number of instances that have been used over the past week. You can use the graph to monitor scaling activity.

8. Scale by Metric modifies the Instance Count feature so that you can set the minimum and maximum number of virtual machines to be used for automatic scaling. Azure will never go above or below the limits that you set. This enable you to proactively set the number of role instances that your application can use; the minimum number of role instances helps you to meet your service level agreement (SLA) commitments, the maximum number of role instances helps you to control the running costs of your Windows Azure application.

9. Scale by Metric also enables the Target CPU option so that you can specify a target range for CPU usage. This range represents average CPU usage for your website. Windows Azure will add or remove Standard instances to keep your website in this range.

Note: When Scale by Metric is enabled, Microsoft Azure checks the CPU of your website once every five minutes and adds instances as needed at that point in time. If CPU usage is low, Microsoft Azure will remove instances once every two hours to ensure that your website remains performant.

Part 13 : Windows Azure Web Sites - Basics 2 - Web Hosting Plan mode

Windows Azure Region
We have seen in the previous tutorial that we have to select the region while creating a website in Windows Azure Management portal. Windows Azure uses the idea of regions to manage the physical distribution of your applications and data. A region represents a Microsoft data center where you can deploy your application. There are many regions available in Windows Azure like Asia, Europe, North America and it keeps on increasing.


Choosing a region will have direct impact on Network Latency. You want to deploy your application to the data-center that is closest to your user base. Also you want to replicate your data across multiple regions so that if one region or data center is offline, your application still be available. Windows Azure have options to deal with this (Traffic Manager, CDN) and we will learn  that in later tutorial.


Web Hosting Plan Mode
Web Hosting Plans can be shared across multiple web sites. Each plan has a mode associated with it. Different modes expose different sets of features and capabilities. Currently Azure Web sites is offered in four modes for hosting your websites : Free, Shared, Basic and Standard.

Shared mode is in preview feature as time of writing.  Plans in the Free and Shared modes run on a shared infrastructure with sites managed by other customers. These sites will have strict quotas for resource utilization. Plans in the Basic and Standard modes run on resources that are dedicated to your sites and have fewer restrictions.

Free
Free is the default scale for any website that is newly created in Windows Azure Websites.You can run upto 10 free websites in this mode. In Free mode your website is hosted on the same Virtual Machines as other sites (also known as multi-tenant hosting environment) and you cannot scale a single website on multiple web servers.  So the same server where your website is hosted can  be shared by many different websites. Shared means each website is taking up some amount of memory and utilizing some portion of the CPU.

Using this free mode, you can start your development and testing of websites at no cost at all. Obviously "free" comes with some limitations. In this case you can run websites that can serve 165MB of outbound traffic per day(5GB/month) , 60 minutes of CPU per day, per region. Storage is limited to 1GB.

Also with free mode, you cannot assign custom domain to the site. With free mode the site name will always be <sitename>.azurewebsites.net.

And yes one more thing, free site does not have any SLA.

Free mode is generally used by developers and testers during development.

Shared (Preview Mode)
Hosting website in this mode reduce some of the restrictive quotas associated with Free Mode, but computing resources are still shared.  Your website will still be hosted on the same Virtual Machine as other sites. In the Shared mode your CPU usage quota is 4 hours per day with storage limited to 1GB. The first 5 GB/month of bandwidth you serve with a shared web-site is free, and then you pay the standard “pay as you go” Windows Azure outbound bandwidth rate for outbound bandwidth above 5 GB.

You can scale out your website to maximum of 6 shared instances. Windows Azure will automatically configure load balancing for it.  In shared mode, you can set up multiple custom domain for your website rather than stuck up with .azurewebsites.

The price for the Shared tier during preview is $0.013 per hour (~$10/month). This price reflects a 33% preview discount.

Shared website also don't have any SLA.

Shared mode is good for personal sites or for the sites that doesn't have large amount of traffic and can withstand some duration of down time in case of crossing the quota.

I would like to point out here that it is very essential to have put quota on Free and Shared mode, so that one website should not eat up all the memory or dominate the CPU. And when I said CPU usage quota is 1 hour per day, that doesn't means that your website can be up only for 1 hour per day. That actually means is that your website can use 1 hour of CPU time in 24 hours. Your website needs CPU cycles only when it is serving some page requests, provided it's not coming from cache. Each request uses only seconds of CPU time. So it may be possible that your website is up for hours if traffic is low or use the quota in minutes if traffic is very high.

Remember that both in Free and Shared mode, once you cross the quota, any request to your website will be redirected to a page that tells that this site has exceeded the quotas. If this is your mission critical website or any website that generates revenue, you don't want this to happen. In this case you need to go for either Basic or Standard mode.

Basic
In Basic mode, you websites are guaranteed to run in a seperate VM which is dedicated for your website.
This option removes any need for the memory and CPU quotas since you are the only tenant on the machine.
You can choose the size of the VM Small, Medium or Large VM and you can run any number of web-sites within a VM. The storage is increased to 10GB for all your websites. You can also set up multiple custom domain for your website

Note that with this option all your website in that region or datacenter are hosted by the same reserved instance. There is no per site cost  in this mode. You pay only for the reserved instance you use and you can run any number of websites in that instance. You can choose between the small, medium or large instance.
So lets say you have very high traffic websites that require 2 large VM instance and another site with very low traffic, both will enjoy the benefit of 2 instance if they are in the same data-center(region).
So basically even though you are paying more, you can save by deploying multiple websites on an instance that is dedicated to you.


You can run sites on a single reserved VM instance or scale up to have multiple instance all running your websites. You can scale upto 3 dedicated VM instances. You can also scale up a single instance by increasing the size of your VM instance (small to medium or large). Windows Azure will automatically configure load balancing for it.

Standard
Everything we say about Basic mode is applicable to standard with more quota and features. In standard mode also, your websites run in a separate VM without any quota for CPU and memory. You can run any number of sites in that reserved instance. The storage is increased to 50 GB and Custom domains are supported.

You can choose between small, medium or large instance. You can scale up to 10 dedicated instances. You can also scale up a single instance by increasing the size of your VM instance. Windows Azure will automatically configure load balancing for it.

One of the biggest feature of Standard mode is Auto Scale. In other modes, you have to manually monitor the traffic and scale up or down based on the traffic (we can scale up or down through Windows Azure Management Portal, i'll show this in just a moment). Auto Scale allows you to dynamically adjust the capacity based on the load your websites is experiencing. You can set rules to trigger the scaling of your instances. For example, you can set a trigger that if CPU becomes overloaded , add one more instance, or you can also schedule it, on weekends increased the number of instance to 4. You can auto scale up or down your instances.

Also note that if you choose an option of reserved instance, all your websites under your subscription will be moved to the reserved instance. You don't have an option to run some websites in shared mode and other in reserved mode. If you wish to do that, you have to divide the websites in different subscriptions.


In the next tutorial we will see how we can scale websites up and down depending on our needs.

Part 12 : Windows Azure Web Sites - Deployment using Visual Studio 2013

This tutorial shows how to deploy an ASP.NET web application to an Azure Web Site by using Visual Studio 2013.

With the release of new Windows Azure SDK version 2.2 for Visual Studio 2013, sign in has been integrated directly within Visual Studio so that you can sign in to Windows Azure without ever leaving the IDE. This is great for developers as they now develop, debug and manage Windows Azure resouces from within Visual Studio. You no longer need to create and download the management certificates. One of the new feature is Remote Debugging, devlopers can now attach the debugger to running instance of Windows Azure cloud service right within Visual Studio. Remote debugging is great feature for developers as they can now debug a live cloud service which is very helpful if you want to track down any issues.

I believe you already has a Azure account as this is the prerequisite for this tutorial. If you don't have one please check here how to get  one.

If you are following the previous tutorials then you must have development environment setup either for visual studio 2013 or 2012/2010. If not, setup the development environment by installing Azure SDK and other related tools - refer previous tutorial here to get more details about how to setup dev environment for Azure development.

Create a web application
1. Open Visual Studio 2013.
2. Go to File menu and then New -> Project. In the new project dialog box, expand Visual C# and select      Web under Installed Template, and then select ASP.NET Web Application.  Ensure that .NET  Framework  4.5 is selected as the target framework.

 3. In the New ASP.NET Project dialog box, select the MVC  template, and then click Change    Authentication.

 4. Since this is sample application, we don't need any login. In the Change Authentication dialog box, click  No Authentication, and then click OK.

 5. If you haven't already signed in to Azure, Visual Studio prompts you to do so. Click Sign In.

     

 6. Enter the ID and password of the account that you use to manage your Azure subscription.

    

 7. When you're signed in, the Configure Azure Site Settings dialog box asks you what resources you want  to create. Visual Studio provides a default Site name, which Azure will use as the prefix for your  application's URL. If you prefer, enter a different site name.In the Region drop-down list, choose the  location that is closest to you. This setting specifies which Azure data center your web site will run in.Leave  the database fields unchanged as for this tutorial we are not using any database. Click OK.

8. In a few seconds, Visual Studio creates the web project in the folder you specified, and it creates the web  site in the Azure region you specified. You will get a message that your project has been created. The Web  Publish Activity window shows that the site has been created.

 9. If you go to the Windows Azure Management Portal, you can see the website listed under Web Sites    tab.

Though your website has been created, there are no contents yet. We need to deploy the site.

Deploy the application to Azure

 1. In the Web Publish Activity window, click Publish WebApplication1 to this site now. Publish Web  wizard will appears. The wizard creates a new publish profile that contains settings such as the web site  URL that Visual Studio needs in order to deploy your project to Azure. The profile is automatically saved  so that later when you make changes to the project you can easily redeploy the project to the same site.

 2. In the Connection tab of the Publish Web wizard, let the Publish method as Web Deploy. Change the  password if you wish and click on Validate Connection to make sure that Visual Studio can connect to  Azure in order to deploy the web project.

 3. When the connection has been validated, a green check mark is shown next to the Validate Connection  button.Click on Next button.

4. In the setting tab, you can accept the default settings on this tab. You're deploying a Release build and you  don't need to delete files at the destination server, precompile the application, or exclude files in the  App_Data folder. Click on Next button.

 5. In the Preview tab, click Start Preview. The tab displays a list of the files that will be copied to the server.  You can also skip this step and directly click on Publish button.

 6. Click on Publish Button. Visual Studio begins the process of copying the files to the Azure server. The    Output and Web Publish Activity windows show what deployment actions were taken and report successful  completion of the deployment.

7. Upon successful deployment, the default browser automatically opens to the URL of the deployed web  site, and the application that you created is now running in the cloud. The URL in the browser address bar  shows that the site is being loaded from the Internet.

How to redploy after making changes

1. Modified any file you want or add a new one.

2. In Solution Explorer, right-click the project, and choose Publish.

3. The Preview tab of the Publish Web wizard appears. If you needed to change any publish settings you  could choose a different tab, but now all you want to do is redeploy with the same settings. Click on Publish  button.

4. Visual Studio deploys the project to Azure and opens the site in the default browser.

There also a tool called Web One Click Publish tool, which is a quicker way to redploy. This toolbar is not enabled by default. To enable it go to Views-> Toolbars-> Web One Click Publish.  You can use it to select a profile, click a button to publish, or click a button to open the Publish Web wizard.

In this tutorial we have seen how we can use the integrated sign-in feature of Visual Stdio 2013 and deploy the application to Windows Azure. In the upcoming chapters we will learn more features of Visual Studio like remote debugging. 

Part 11 : Windows Azure Web Sites - Deployment using Visual Studio 2010/2012

This tutorial shows how to deploy an ASP.NET web application to an Azure Web Site by using Visual Studio 2010 or Visual studio 2012. This is the most useful and highly used by developers when they doing development of Windows Azure.

I believe you already has a Azure account as this is the prerequisite for this tutorial. If you don't have one please check here how to get  one.

If you are following the previous tutorials then you must have development environment setup either for visual studio 2013 or 2012/2010. If not, setup the development environment by installing Azure SDK and other related tools - refer previous tutorial here to get more details about how to setup dev environment for Azure development.

There will be three main steps in this tutorial.

1. Create a website in Windows Azure portal.
2. Create a Asp.net MVC application using Visual Studio.
3. Publish the application to Windows Azure.

Let's see these steps in detail. 

Create website in Windows Azure portal

If you have already created a website in Windows Azure portal and knows how to do it, you can skip this section, otherwise follow along.

1. Login to the Windows Azure management portal , click Web Sites and then click New at the bottom side.
   

2. A fly out menu will appear with website selected. It will present three option for creating an Azure Web Site :  Quick Create, Custom Create and From Gallery. Click on quick create. 

    

3. Choose a unique name for your site. If your site name is unique, there will be little green check mark  appears as shown in the figure. If it's not unique, an alert will appear and you have to choose unique  name.This setting specifies which data center your web site will run in. For now, choose the region closet    to you. 

    

4. The Management Portal returns to the Web Sites page, and the Status column shows that the site is being created. After a while (typically less than a minute), the Status column shows that the site was successfully created. In the navigation bar at the left, the number of sites you have in your account appears next to the Web Sites icon.
 

Create a Asp.net MVC application

Now our website has been created, but there is no content in it yet. In this step we are going to create a web application that we gonna publish to Azure.

1. Open Visual Studio 2010/2012. 

2. Go to File menu and then New -> Project. In the new project dialog box, expand Visual C# and select  Web under Installed Template, and then select ASP.NET MVC 4 Web Application. Ensure that .NET  Framework 4.0 or 4.5 is selected as the target framework. Name the application "testazure4" (I have given the same name as my website), and click OK.

    

3. In the New ASP.NET MVC 4 Project dialog box, select the Internet Application template and click OK.

    

4.  Visual Studio use a default template for the ASP.NET MVC project. So the application that you have  just created is working without doing any changes. Since the main purpose of this tutorial is to show how to  deploy the application right from Visual Studio, the default project with no changes is sufficient. However you can go ahead and change the content if you want and if you obviously know the MVC. Press CTRL + F5 to run your application. The application home page appears in the browser. The same page we expect to appear when we deploy our application to Windows Azure.

    

Publish the application to Windows Azure

Now the most important part of this tutorial, we are going to publish this website to Windows Azure.

In order to publish through Visual Studio, you need a publish setting file (also known as subscription file), which can be downloaded from Windows Azure Management Portal. The publish settings file is just an XML file with your subscription details (id, name, url) as well as a management certificate for authenticating management API requests. Without this file you need to create certificate in your local certificate store and export the same to Azure portal, and then you use this certificate in Visual Studio and associate your subscription ID with each operation. With publish setting file, you have to just download this file from portal and import in Visual Studio.

To can download this file from the link https://windows.azure.com/download/publishprofile.aspx .

You may need to login with your subscription account. Once downloaded save it in your local drive.

The publish seeting file name will be in this format:

<Subscription_Name>-<Download_Date>-credentials.publishsettings

Note : The .publishsettings file contains your credentials (unencoded) that are used to administer your Azure subscriptions and services. The security best practice for this file is to store it temporarily outside your source directories (for example in the Libraries\Documents folder), and then delete it once the import has completed. A malicious user who gains access to the .publishsettings file can edit, create, and delete your Azure services.

1. Go back to the Visual Studio right-click the project in Solution Explorer and select Publish from the  context menu.

    

2. This will open Publish Web Wizard. In the profile tab of Publish Web Wizard, click Import.

     

3. The Import Publish Profile dialog box appears. In the Import Publish Profile dialog box, click Import from an Azure web site, and then click Add Azure subscription.

    

    

 4. It will open Import Azure Subscriptions dialog box. We have already downloaded the subscription file.    Browse to the path where you have downloaded the file. Select the file and click on Import button.

     

 5. Once you add your subscription,drop-down list under Import from an Azure web site will include all    your web sites. Select your website from the drop down list and click OK.

     

 6. In the Connection tab, click Validate Connection to make sure that the settings are correct.

     

 7. When the connection has been validated, a green check mark is shown next to the Validate Connection       button. Click Next.

      

 8. In the Settings tab, uncheck Use this connection string at runtime option, since this application is not using a database. You can accept the default settings for the remaining items on this page. You are deploying a   Release build configuration and you don't need to delete files at the destination server, precompile the application, or exclude files in the App_Data folder. Click Next.

              

 9. In the Preview tab, click Start Preview.

     

 10. The tab displays a list of the files that will be copied to the server. Displaying the preview isn't required  to publish the application but is a useful function to be aware of. In this case, you don't need to do    anything with the list of files that is displayed.

       

 11. Click Publish. Visual Studio begins the process of copying the files to the Azure server.

 12. Upon successful deployment, the default browser automatically opens to the URL of the deployed web   site. The application you created is now running in the cloud as evident from the URL. 

       

So, that's about it, publishing website from Visual Studio 2010/2012. These are the same steps you need to perform to publish any website from Visual Studio, only import part you don't need to every time. In the next tutorial we learn how to publish using Visual Studio 2013.