Data and News from Connect(); 2016

On Wednesday, November 16, 2016, Microsoft demonstrated at Connect(); 2016 its vision of enabling the future of development with solutions that serve any developer, any application and any platform.

They have also shared some very interesting data about services and products adoption:

• More than 20 million Visual Studio 2015 installs (with the free Community edition representing more than 14 million of those)
• 1 million Visual Studio Code monthly active users (MAU).
• 4.6 million registered Visual Studio Team Services users
• More than 25,000 developers from 1,700 companies have contributed to .NET Core and related open source repositories, with nearly 2/3 of the contributions coming from outside Microsoft.
• 1 million Visual Studio Dev Essentials members
• Half-a-million more Xamarin users since the acquisition, a 3x increase over the company’s previous growth rate.
• 20,000- registrations for the SQL Server on Linux private preview, including over 50% of the Fortune 500.
• 1.6 million Azure SQL Databases in the cloud and over 100 billion queries per day
• More than 120,000 new Azure subscriptions/month
• Approximately 1 out of 3 VMs on Azure are Linux
• 35% month over month growth of Microsoft Graph in past year.
• 47,000 active third party applications built using Microsoft Graph and more than 1 billion API transactions on Microsoft Graph
• More than 400M Windows 10 devices
• The Windows 10 Cortana search box now has over 141 million monthly active users

Brian Harry has written a very good blog post (read it here) with all the announcements about TFS and VSTS. Take a look at it!

VSTS - Scheduled release, Azure and XCode build

One more month, one more exciting release of Visual Studio Team Services.

These are my top 3 new features of this month:

Multiple schedules in releases

Want to schedule your releases to be created more than one time in a day? You can now configure multiple scheduled triggers in a release definition.

Simplified Azure endpoint creation

In an earlier sprint, VSTS team made it easier to create a new Azure Resource Manager service endpoint from Team Services. That experience only worked in accounts that are backed by an Azure Active Directory. In this deployment, they are bringing the same simplified experience for all the other accounts that are not backed by an AAD. So, if you are a MSA user and have an Azure subscription that you would like to deploy to from Team Services, you can create an Azure endpoint without having to run tedious Powershell scripts or following a blog.

Xcode 8 signing and exporting packages in the Xcode Build Task

The Xcode build task now supports building your projects using Xcode 8 automatic signing. You can install the certificates and provisioning profiles on the build server manually, or have the task install them by specifying the File Contents options.

Xcode 8 requires specifying an export options plist when exporting an app package (IPA) from an archive (.xcarchive). The Xcode task now automatically identifies the export method if you are using Xcode 8 or Xcode 7. You can specify the export method or specify a custom plist file from the Xcode task. If you are using an Xcode version older than Xcode 7, the task falls back to using the old tool (xcrun) for creating the app package.

VSTS - Azure, Comments & Redeploy

Here we go with my 3 favourite new VSTS features for July.

Release management - Azure deployments

Now, setting up an Azure Service endpoint is easy: you just need to select the subscription on which to create a service endpoint, and you are ready to deploy to Azure.

• Users can now automatically set up an ARM service connection by selecting the subscriptions linked with the Azure Active Directory that is backing the VSTS account.
• Note: A new Azure Service Principal will be created and assigned the Contributor role, having access to all the resources in the selected subscription. You can modify the Service Principal access from Azure portal > Subscriptions > Users > Roles.
• Prerequisites: -The VSTS account should be backed by an Azure Active Directory. For more info, see the Visual Studio article Team Services: Access with Azure Active Directory (Azure AD).
• Note: Only Azure subscriptions that are linked with the Active Directory are listed.

Comment tracking for pull requests

Pull requests in VSTS have been improved to show comments left in files on the proper line, even if those files have been changed since the comments were added. Previously, comments were always shown on the line of the file where they were originally added, even if the file contents changed—in other words, a comment on line 10 would always be shown on line 10. With the latest improvements, the comments follow the code to show what the user expects—if a comment was added on line 10, and two new lines were subsequently added to the beginning of the file, the comment will be shown on line 12.

Here's an example change with a comment on line 13.

Even after the code has changed to shift the line with the original comment from 13 to 14, the comment is appearing in the expected place (line 14).

I think this improvement is a big step forward for improving the code commenting experience in pull requests. In the near future we will have even more improvements coming, including improved comment placement for renamed or moved files.

Release – redeploy after success

When a deployment to an environment fails, you may want to be able to redeploy an older release that already succeeded once in that environment. This feature lets you do just that. 

When you try to redeploy an older release, you will be shown the list of commits as well as the list of work items that will be rolled back. You just need to make sure that the automation scripts for deployment can really handle the rollback scenario. That is still on you.

Deploy a Web App to Azure with the Visual Studio Online Build

In this post we are going to see from sratch how to deploy a solution to an Azure Web App using the new Visual Studio Online Build platform.

To do it, we will use only the web portal of VSO.

Connect Azure to VSO

First of all we have to let Visual Studio Online know that we have an Azure account we want to use as deploy endpoint for our solution. Go the the Team Peoject Settings page (clicking on the button in the upper right corner of the project page), click on the "Services" tab, then on "Add new Service Connection" and then on "Azure".

At this point a pop-up will appear and we have to insert the ID of the Azure subscription which contains or will contain the Web App to publish, a name for it and the authentication mode.

We can use either a subscription certificate or the credentials.

When done, our Azure subscription and our VSO account will be connected (for this project).

Create the build definition

Now that we have linked VSO and Azure, let's go to the Build section of the project and create a new deployment build definition.

We eant to deploy to Azure, so in the "Deployment" section click on "Azure Website" (like shown in the image).

This creates a new build definition with some steps to configure.

Let's see how to proceed step-by-step.

The first one is the "real" build task. It's completely customizable but the most important thing is to define the solution file it has to use as build source. Select it like shown in the image, near the red arrow.

In the second step we have to set the how to execute the post-build Unit Tests. If we don't have unit tests (that is bad...) or we don't want to execute them (also this is bad :) ), we can safely remove this step using the "X" button that appears when the mouse pointer is over it.

The third step is the most important one for our scenario, because it publishes the build result to the Azure Web App.

In its settings there is a drop down where to select the target Azure subscription (if the previous Azure service connection worked properly). Then, in the "Web App Name" textbox, we have to write the name of the Web App we want to deploy. In theory this also appears as a drop down itself, but currently it doesn't load the existent Web Apps names (don't forget that the new Build platform is still in preview)

For this reaso, here I've written down some notes about the Web App name

• If we use a non-existent Web App name, it will create it on our Azure subscription using the selected region
• If we use a Web App name that doesn't exist in our subscription but which already exist in the selected region, the deploy process will fail
• If we use a Web App name that already exists in our subscription but it is in a region different from the selected one, the deploy process will fail
• If we use a Web App name that already exists in our subscription and it is in the selected region, the deploy will use it as target and will update it.

So pay attention about what we write :)

The two remaining steps allow us to index and to publish the application symbols (suggested, to have more information in the case of unhandled exceptions) and to publish the build artifacts somewhere.

When all the parameters are set we can go ahead and save our build definition, giving it a name.

We can also change all the default parameters in the upper tabs to customize the build process accordingly our needs.

Let's deploy!

Now that we have completed all the customizations, it's the moment to launch the build and to verify that the deploy works fine.

To start the build, click on the "Queue build" button in the build definition toolbar or in the contextual menu.

When we click on that button, VSO will queue a build based on our build definition and will execute it either on our servers or in a Microsoft Datacenter (if we have chosen to do it with the hosted agents).

Anyway, the build progress will be shown in the real time web console that appears as soon as the build is queued.

When is starts, it firstly execute the build and test tasks:

Then, if both are successful, the deploy to Azure:

When all the tasks will successfully finish, we have our web application deployed and running on Azure. Easy!

Adding Azure Application Insights to a Web Site

If you're developing a Web Application, you can use Visual Studio 2013.3 to automatically add all the libraries and configurations that "Azure Application Insights" needs to work.

 

But what about Web Sites? If you create a Web Site (or you have to manage / update one) you'll notice that you don't have such option. So, what can we do it? How can we achieve the same results? How can we integrate Azure Application Insights to a Web Site?

 

Just follow these steps:

1. Create a new "Application Insights" service using the new Azure portal (preview)
2. Copy the JavaScript code snippet proposed by the portal and add it to all the pages you want to monitor (or to the master page, if you have one)
3. In Visual Studio 2013.3, create a new empty web application and add to it the Application Insights using the contextual menu
4. Copy the following files from the "bin" folder of the Web App to the "bin" folder of the Web Site:
   

   Microsoft.ApplicationInsights.dll
   Microsoft.ApplicationInsights.Extensibility.RuntimeTelemetry.dll
   Microsoft.ApplicationInsights.Extensibility.Web.dll
   Microsoft.Diagnostics.Tracing.EventSource.dll
   (if you want you can copy also the related .xml and .pdb files)
   

5. Return to the Azure portal (preview), go to the Application Insights service you've created before, click on the "Properties" button and copy the value of "Instrumentation Key" textbox
6. Copy the ApplicationInsights.config file from the root of the Web App to the root folder of the Web Site
7. In this file, replace the value of the "InstrumentationKey" key with the one copied at point 5
8.  Change the web.config of the website adding these rows:
   

   <system.web>
    [...]
       <httpModules>
      [...]
         <add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Extensibility.Web.RequestTracking.WebRequestTrackingModule, Microsoft.ApplicationInsights.Extensibility.Web" />
      [...]
       </httpModules>
    [...]
   </system.web>
   
   <system.webServer>
    [...]
       <validation validateIntegratedModeConfiguration="false" />
    [...]
    <modules runAllManagedModulesForAllRequests="true">
      [...]
         <remove name="ApplicationInsightsWebTracking" />
         <add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Extensibility.Web.RequestTracking.WebRequestTrackingModule, Microsoft.ApplicationInsights.Extensibility.Web" preCondition="managedHandler" />
      [...]
       </modules> 
    [...]
   </system.webServer> 
   

 

Now you can test your Web Site and, after few seconds, you will see you analytics data in the Application Insights blade of the new Azure portal (preview)

About Azure Websites Extensions

Each Azure Website provides an extensible management end point that allows you to leverage a powerful set of tools, deployed as site extensions. These tools range from source code editors like Visual Studio Online to management tools for connected resources such as a MySQL database connected to a website. 

Site extensions are web apps with simple metadata for extension registration. Site Extensions can be authored for any development stack supported by the Azure Websites platform.

Existing site extensions are available for each website in the Azure Preview Portal:

To add a new site extension go to the Configuration lens under the web site section, click the ADD button and select an extension from the list. Each of these extensions are made available by the publisher listed under extension name and legal terms provided by each publishers have to be accepted before installing an extension.

Once added, site extension content is copied under the %HOME%\SiteExtensions folder parallel to website root. Note that adding a site extension will restart the site.

If you need something that isn't already present, you can create new site extensions for use with your websites based on instructions at this link. 

It's also possible to submit new site extensions for availability across the Azure Websites platform through the Site Extension Gallery submission portal: http://www.siteextensions.net.

Azure Web Sites Deployment: how does it work?

Azure Web Sites supports continuous deployment from source code control and repository tools like BitBucket, CodePlex, Dropbox, Git, GitHub, Mercurial, and TFS/VSO. You can use these tools to maintain the content and code for your web site, and then quickly and easily push changes to your site when you want.

Supported Deployment types

Pushing local files to Azure by using Local Git allows you to manually push updates from a local project to your Azure Web Site, while deploying from BitBucket, CodePlex, Dropbox, GitHub, or Mercurial results in a continuous deployment process where Azure will pull in the most recent updates from your project.

While both methods result in your project being deployed to an Azure Web Site, continuous deployment is useful when you have multiple people working on a project and want to ensure that the latest version is always published regardless of who made the most recent update. Continuous deployment is also useful if you are using one of the above mentioned tools as the central repository for your application.

On the net there are plenty of articles explaining how to deploy an Azure WebSite (i.e. http://azure.microsoft.com/en-us/documentation/articles/web-sites-deploy/) or how to implement Continuous Deployment strategies (i. e. http://azure.microsoft.com/en-us/documentation/articles/web-sites-publish-source-control/).

But how does it work behind the scenes?

Well, the answer is "Kudu".

Kudu is the engine behind deployments in Azure Web Sites, but it can also run outside of Azure.

It has a somewhat unusual architecture, in the sense that it is a single-tenant rather than multi-tenant service. What this means is that each Azure Web Site has its own instance of the Kudu service, completely distinct from the Kudu service sites used for other Azure sites.

It stays active in background and "watches" for checkins, commits, new files, completed builds and so on. When it detects something, KuduSync starts and do the "dirty work".

It's a great tool, because:

• it’s an open source project available on GitHub (https://github.com/projectkudu/kudu)
• it's automatically installed on all Windows Azure Web Sites
• it can use a custom deployment script

But the most important thing (imho) is this:

The deployment is created in your website’s folder structure and the new deployment is copied to your site’s root, leaving old deployments intact.

This means you can "rollback" to any deploy you've done in the past. This, for me, it's a killer feature!

It's also possible to have access to the Kudu web dashboard, using an url like "https://your_website_name.scm.azurewebsites.net/" and your deployment credentials or your Azure service admin credentials.

Kudu Dashboard

In the Kudu dashboard you can find a lot of useful informations about your website's environment together with a set of tools to manage your website and, last but not least, a complete set of REST APIs. There is also the possibility to manage WebSites extensions.

There is also a great video where David Ebbo and Scott Guthrie explain how Kudu works: http://channel9.msdn.com/Shows/Azure-Friday/What-is-Kudu-Azure-Web-Sites-Deployment-with-David-Ebbo

Azure WebSite, Cloud Service and Virtual Machine: which to choose?

Sometimes it happens to start a new development project or to plan a deploy on the cloud, on Azure, but you don't know what kind of service is better to use: a WebSite, a Cloud Service or a Virtual Machine? What pros and cons do they have?

Let's deiscover the main differences.

Warning: this post is updated with the information available to August 5th, 2014.

First of all, a diagram (the same that Microsoft uses in the Azure official docs), to compare our three services:

Courtesy of Microsoft

In this image the "simplicity / control" ratio between services is quite clear. To be extremely synthetic:

• WebSite: 
• Solution extremely simple to use, it offers a good set of tools to support (monitoring, alerts, stairs, etc) but at the expense of the level of customization and control over the configuration. 
• In multi-tier applications, it provides support to the only web tier
• Cloud Service:
• Less simple to use and deploy compared to Websites, provides a much greater level of control.
• Also in this case there are several tools for monitoring and support already included
• You can use both WebRoles (that actually are dedicated VMs with IIS installed) as well as WorkerRoles (always dedicated VMs, but without IIS. You can think about WorkerRole as a Windows Service)
• In multi-tier scenarios, you can use a combination of WebRole and WorkerRole to implement the web tier, the middle-tier and the backend
• In multi-tier, you can scale the frontend and the backend independently
• Virtual Machine:
• Leaves the configuration and customization completely to the user, so it's more complicated to manage but provides the highest level of control possible, as with the on-premises server.
• You can use it for any kind of application and architecture
• You need to manually deal with the management of the system, including upgrades, security policies, etc. etc.
• It's the ideal choice in complex scenarios or when you need to host software or services that are not supported in WebSites or Cloud Servives.

This is the official services features comparison table:

FEATURE	WEB SITES	CLOUD SERVICES (WEB ROLES)	VIRTUAL MACHINES
Access to services like Service Bus, Storage, SQL Database	X	X	X
Host web or web services tier of a multi-tier architecture	X	X	X
Host middle tier of a multi-tier architecture		X	X
Integrated MySQL-as-a-service support	X	X 1	X
Support for ASP.NET, classic ASP, Node.js, PHP, Python	X	X	X
Scale out to multiple instances without redeploy	X	X	X 2
Support for SSL	X 3	X	X
Visual Studio integration	X	X	X
Remote Debugging	X	X	X
Deploy code with TFS	X	X	X
Deploy code with GIT, FTP	X		X
Deploy code with Web Deploy	X	4	X
WebMatrix support	X		X
Near-instant deployment	X
Instances share content and configuration	X
Scale up to larger machines without redeploy	X
Multiple deployment environments (production and staging)	X	X
Network isolation with Azure Virtual Network		X	X
Support for Azure Traffic Manager	X	X	X
Remote desktop access to servers		X	X
Ability to define/execute start-up tasks		X	X
Automatic OS update management	X	X
Integrated Endpoint Monitoring	X	X	X
Seamless platform switching (32bit/64bit)	X	X

1 Web or worker roles can integrate MySQL-as-a-service through ClearDB's offerings, but not as part of the Management Portal workflow.

2 Although Virtual Machines can scale out to multiple instances, the services running on these machines must be written to handle this scale-out. An additional load balancer must be configured to route requests across the machines. Finally, an Affinity Group should be created for all machines participating in the same role to protect them from simultaneous restarts from maintenance or hardware failures.

3 For Web Sites, SSL for custom domain names is only supported for standard mode. For more information on using SSL with Web Sites, see Configuring an SSL certificate for an Azure Web Site.

4 Web Deploy is supported for cloud services when deploying to single-instance roles. However, production roles require multiple instances to meet the Azure SLA. Therefore, Web Deploy is not a suitable deployment mechanism for cloud services in production.

If you want to take a llok at the complete services comparison, see the guide on the official Azure documentation.

Dedicated IP address on Azure Websites

When you share the IP address with some other websites / clients / customers (like it happens on a multi-tenant environment), you could have some problems like, for instance, have your IP blacklisted because of other sites' content.

The only reliable way to resolve this and protect your site from a recurrence is to configure your site with a dedicated IP. This means that the site will be using its own IP, which would not be shared with other sites. 

In Azure, you can easily get a dedicated IP by configuring IP SSL. This option is available only to the sites in the Standard tier, but if you’re using a custom Domain on your site, there are some extra considerations.

If you are using a custom domain and have a CNAME record pointing from it to the site’s name in Azure (for example, mysite.azurewebsites.net), then it’s rather simple – just change the record with your DNS provider and then configure IP-SSL.

If, on the other hand, you are using an A-record to resolve the host name to an IP, it's recommended to follow these steps:

1. Change your hostname mapping (i.e. www.mysite.com) from an A record to a CNAME pointing to your Microsoft Azure Web Site (i.e. mysite.azurewebsites.net).  This should have no downtime as it will be pointing to the same IP. Wait some time for DNS replication to take place.
   
2. Upload a certificate for www.mysite.com to your website. This can be accomplished under Domain names in the Configure tab. Usually, you would have to purchase the Certificate from a Certificate provider, but if you don’t intend to actually use SSL, you can use a self-signed certificate which is easy to generate and won’t cost you a dime.
   
3. Configure an IP Based SSL binding for www.mysite.com. This option is available under SSL Binding in the Configure tab. See the section Configure SSL in the Azure guide for SSL.

Autoscale Virtual Machines on Microsoft Azure

One of the key benefits that the Windows Azure platform delivers is the ability to rapidly scale your application in the cloud in response to fluctuations in demand.

Normally people scale their website or cloud services, but what if you have your applications hosted on an Azure VM and you want to be able to horizontally scale it? Well, it also possible!

You have to do basically 2 steps: create a Load Balanced Web Farm and then configure the AutoScale.

Here you will find a step-by-step guide on how to do it.

Necessary Steps:

1. Create a Standard Tier VM and assign it to an availability set
2. Configure the machine as you need (IIS, Application server, ftp, and so on...)
3. Clone the VM
1. Sysprep 
2. Capture
3. Recreate the original VM, adding all the needed endpoints
4. Create the second  VM with no "extra endpoints"
5. Optional - repeat point 3.4 to create additional VMs
4. Balance VMs
1. Change the endpoint on the first VM  to create a Load-Balanced set
2. Add the endpoint to the second (third, ...) VM to the created Load-Balanced set
3. Repeat 4.1 and 4.2 for all the endpoints you need to be balanced
4. Takes care of session state (if needed)
5. Configure Autoscale

Details:

3.1 - Sysprep

The first thing to do when cloning a VM is "sysprepping" it. On Linux, there’s a similar option in the Azure agent. Sysprep ensures the machine can be cloned into a new machine, getting it’s own settings like a hostname and IP address. A non-sysprepped machine can thus never be cloned.

After sysprepping the machine, shut it down. If you’ve selected the option during sysprep, the machine will automatically shutdown. Otherwise you can do so through remote desktop or SSH, or simply through the Azure portal.

3.2 - Capture

On the Windows Azure portal go to the VM dashboard page. Next, click the "Capture" button to create a disk image from this machine. Give it a name and check the "Yes, I’ve sysprepped the machine" checkbox in order to be able to continue.

After clicking the "OK" button, Azure will create an image of our first server.

3.3 - Recreate the original VM, adding all the needed endpoints

After the image has been created, you’ll notice that your first VM has disappeared! This is normal: the machine has been disemboweled in order to create a template from it. You can now simply re-create this machine using the same settings as before, except you can now base it on this newly created VM image instead of basing it off a VM template Microsoft provides.

In the endpoints configuration, make sure to add the HTTP endpoint again listening on port 80 or, however, all the endpoints you need to access your applications.

3.4 - Create the second  VM with no "extra endpoints"

To create the second machine in your webfarm, create a fresh virtual machine. As before, choose the image we’ve created earlier.

In step 4 of the machine creation, be sure to select the same "Cloud Service" of the first server and locate the VM in the same availability set. 

Don’t add the HTTP endpoint (or other endpoints configured in the step 3.3) to this machine just yet.

You now have two machines running, yet they aren’t load balanced at this moment. You’ll notice that both machines are already behind the same hostname and that they share the same public virtual IP address. This is due to the fact that we "linked" the machines earlier. If you don’t, you will never be able to use the out-of-the-box load balancer that comes with Azure. This also means that the public remote desktop endpoint for both machines will be different: there’s only one IP address exposed to the outside world so you’ll have to think about endpoints.

4.1 - Change the endpoint on the first VM  to create a Load-Balanced set

The last part of setting up our webfarm will be load balancing.  This is in fact really, really easy. 

As first point, go the "Endpoints" page of the first (original) VM, choose the Endpoint you want to balance and edit it.

Just check the "Create a Load-Balance set" checkbox.

In the step 2 of the edit, give the Load-Balanced set a name and configure the probe parameters (in my example, I'm configuring an HTTPS endpoint, so I want to check every 15 second if the port 443 answers. After 2 fails, the balancer switch to the other endpoint)

4.2 - Add the endpoint to the second (third, ...) VM to the created Load-Balanced set

Simply go to second machine’s dashboard in the Azure portal and navigate to the Endpoints tab. We’ve already added public HTTPS endpoint on our first machine, which means for our second machine we can just subscribe to load balancing:

Now we have free round-robin load balancing with checks every few seconds to ensure that all machines are up and running. And since we linked these machines through an availability set, they are on different fault domains in the datacenter reducing the chance of errors due to malfunctioning hardware or maintenance. You can safely shut down a machine too. In short: anything you’d expect from a load balancer (except sticky sessions).

4.4 - Takes care of session state (if needed)

Now that you have the VMs balanced, you have to think about how your applications manage the session state.

If you are deploying web servers with Asp.Net applications, for example, you’ll have to configure machine keys and sessione state in the same way you would do it on-premise. On Azure you can choose to user the "normal" database way (Session state stored on Azure database), you can use the Azure storage or the new Azure cache.

You can visit this link on msdn (http://blogs.msdn.com/b/cie/archive/2013/05/17/session-state-management-in-windows-azure-web-roles.aspx) to have an overview about Session State management on Azure.

5 - Configure Autoscale

Ok, finally let's configure the autoscale! Now we have some VMs running, balanced. But do we need all the VMs running at the same time? Maybe not. We maybe need to have it running on some time periods, or maybe only if under load.

If you remember when you've created the VMs you have choosen the same cloud service for all of them. To configure the autoscale on the VMs, just go to the Cloud Service related to them and navigate to the "Scale" page.

Here you can choose the type of scale you want: None (no scale...), by Cpu or by Queue. 

In my case, I decided to scale using the CPU percentage as parameter. The "Target CPU" slider says that I want to scale up when the average CPU is over 80% and to scale down when it is under 60%. 

I have only 2 VMs, so I can configure that normally only 1 is active and the second will be activate to scale up.

You can also choose to scale based on time settings.

Azure Updates: Web Sites, VMs, Mobile Services, Notification Hubs, Storage, VNets, Scheduler, AutoScale and More

It has been a really busy last 10 days for the Azure team. This blog post quickly recaps a few of the significant enhancements they’ve made.  These include:

Web Sites: SSL included, Traffic Manager, Java Support, Basic Tier

Virtual Machines: Support for Chef and Puppet extensions, Basic Pricing tier for Compute Instances

Virtual Network: General Availability of DynamicRouting VPN Gateways and Point-to-Site VPN

Mobile Services: Preview of Visual Studio support for .NET, Azure Active Directory integration and Offline support

Notification Hubs: Support for Kindle Fire devices and Visual Studio Server Explorer integration

Autoscale: General Availability release

Storage: General Availability release of Read Access Geo Redundant Storage

Active Directory Premium: General Availability release

Scheduler service: General Availability release

Automation: Preview release of new Azure Automation service

All of these improvements are now available to use immediately (note that some features are still in preview).

See this Scott Guthrie's blog post to discover all the details

Windows Azure Database dimensions in Mb

If you use a Windows Azure database, you know that you can't easily know its dimension (in term of used space) by the Sql Management Studio, you have to use the Azure Portal. But the portal is not update in real time... So, if you wanna know the database used space, you can use this query:

/*Database dimension in MB*/
SELECT SUM(reserved_page_count) * 8.0 / 1024
FROM sys.dm_db_partition_stats

Instead, if you wanna know the dimension in MB for each table in the Database, use the query below:

/* Tables Dimensions in MB */
SELECT sys.objects.name AS 'Table Name', SUM(reserved_page_count) * 8.0 / 1024 AS 'Mb'
FROM sys.dm_db_partition_stats
INNER JOIN sys.objects ON sys.dm_db_partition_stats.object_id = sys.objects.object_id
WHERE sys.objects.type = 'U'
GROUP BY sys.objects.name