ASP.NET MVC 5, Web API, and Web Pages

This week we released some great updates to Windows Azure.  These new capabilities include: Compute: New 2-CPU Core 14 GB RAM instance option Virtual Machines: Support for Oracle Software Images, Management Operations on Stopped VMs Active ... [More] Directory: Richer Directory Management and General Availability of Multi-Factor Authentication Support Spending Limit: Reset your Spending Limit, Virtual Machines are no longer deleted if it is hit Storage: New Storage Client Library 2.1 Released Web Sites: IP and Domain Restriction Now Supported All of these improvements are now available to use immediately.  Below are more details about them. Compute: New 2-CPU Core 14 GB RAM instance This week we released a new memory-intensive instance for Windows Azure. This new instance, called A5, has two CPU cores and 14 gigabytes (GB) of RAM and can be used with Virtual Machines (both Windows and Linux) and Cloud Services: You can begin using this new A5 compute option immediately.  Additional information on pricing can be found in the Cloud Services and Virtual Machines sections of our pricing details pages on the Windows Azure website. Virtual Machines: Support for Oracle Software Images Earlier this summer we announced a strategic partnership between Microsoft and Oracle, and that we would enable support for running Oracle software in Windows Azure Virtual Machines. Starting today, you can now deploy pre-configured virtual machine images running various combinations of Oracle Database, Oracle WebLogic Server, and Java Platform SE on Windows, with licenses for the Oracle software included.  These ready-to-deploy Oracle software images enable rapid provisioning of cost-effective cloud environments for development, testing, deployment, and easy scaling of enterprise applications.  The images can now be easily selected in the standard “Create Virtual Machine” wizard within the Windows Azure Management Portal: During preview, these images are offered for no additional charge on top of the standard Windows Server VM rate.  After the preview period ends, these Oracle images will be billed based on the total number of minutes the VMs run in a month.  With Oracle license mobility, existing Oracle customers that are already licensed on Oracle software also have the flexibility to deploy them on Windows Azure.  To learn more about Oracle on Windows Azure, visit windowsazure.com/oracle and read the technical walk-through documentation for the Oracle Images. Virtual Machines: Management Operations on Stopped VMs Starting with this week’s release, it is now possible to perform management operations on stopped/de-allocated Virtual Machines.  Previously a VM had to be running in order to do operations like change the VM size, attach and detach disks, configure endpoints and load balancer/availability settings.  Now it is possible to do all of these on stopped VMs without having to boot them: Active Directory: Create and Manage Multiple Active Directories Starting with this week’s release it is now possible to create and manage multiple Windows Azure Active Directories in a single Windows Azure subscription (previously only one directory was supported and once created you couldn’t delete it).  This is useful both for development/test scenarios as well as for cases where you want to have separate directory tenants or synchronize with different on-premises domains or forests.  Creating a New Active Directory Creating a new Active Directory is now really easy.  Simply select New->Application Services->Active Directory->Directory within the management portal: When prompted configure the directory name, default domain name (you can later change this to any custom domain you want – e.g. yourcompanyname.com), and the country or region to use: In a few seconds you’ll have a new Active Directory hosted within Windows Azure that is ready to use for free: You can run and manage your Windows Azure Active Directories entirely in the cloud, or alternatively sync them with an on-premises Active Directory deployment - which allows you to automatically synchronize all of your on-premises users into your Active Directory in the cloud.  This later option is very powerful, and ensures that any time you add or remove a user in your on-premises directory it is automatically reflected in the cloud as well. You can use your Windows Azure Active Directory to manage identity access to custom applications you run and host in the cloud (and there is new support within ASP.NET in the VS 2013 release that makes building these SSO apps on Windows Azure really easy).  You can also use Windows Azure Active Directory to securely manage the identity access of cloud based applications like Office 365, SalesForce.com, and other popular SaaS solutions. Additional New Features In addition to enabling the ability to create multiple directories in a single Windows Azure subscription, this week’s release also includes several additional usability enhancements to the Windows Azure Active Directory management experience: With this week’s release, we have added the ability to change the name of a directory after its created (previously it was fixed at creation time). As an administrator of a directory, you can now add users from another directory of which you’re a member. This is useful, for example, in the scenario where there are other members of your production directory who will need to collaborate on an application that is under development or testing in a non-production environment. A user can be a member of up to 20 directories. If you use a Microsoft account to access Windows Azure, and you use a different organizational account to manage another directory, you may find it convenient to manage that second directory with your Microsoft account. With this release, we’ve made it easier to configure a Microsoft account to manage an existing Active Directory. Now you can configure this even if the Microsoft account already manages a directory, and even if the administrator account for the other directory doesn’t have a subscription to Windows Azure. This is a common scenario when the administrator account for the other directory was created during signup for Office 365 or another Microsoft service. In this release, we’ve also added support to enable developers to delete single tenant applications that they’ve added to their Windows Azure AD. To delete an application, open the directory in which the application was added, click on the Applications tab, and click Delete on the command bar. An application can be deleted only when External Access is set to ‘Off’ on the configure tab. As always, if there are aspects of these new Azure AD experiences that you think are great, or things that drive you crazy, let us know by posting in our forum on TechNet. Active Directory: General Availability of Multi-Factor Authentication Service With this week’s release we are excited to ship the general availability release of a great new service: the Windows Azure Multi-Factor Authentication (MFA) Service.  Windows Azure Multi-Factor Authentication is a managed service that makes it easy to securely manage user access to Windows Azure, Office 365, Intune, Dynamics CRM and any third party cloud service that supports Windows Azure Active Directory.  You can also use it to securely control access to your own custom applications that you develop and host within the cloud. Windows Azure Multi-Factor Authentication can also be used with on-premise scenarios. You can optionally download our new Multi-Factor Authentication Server for Windows Server Active Directory and use it to protect on-premise applications as well. Getting Started To enable multi-factor authentication, sign-in to the Windows Azure Management Portal and select New->Application Services->Active Directory->Multi-Factor Auth Provider and choose the “Quick Create” option.  When you create the service you can point it at your Windows Azure Active Directory and choose from one of two billing models (per user pricing, or per authentication pricing): Once created the Windows Azure Multi-Factor Authentication service will show up within the “Multi-Factor Auth Providers” section of the Active Directory extension: You can then manage which users in your directory have multi-factor authentication enabled by drilling into the “Users” tab of your Active Directory and then click the “Manage Multi-Factor Auth” button: Once multi-factor authentication is enabled for a user within your directory they will be able to use a variety of secondary authentication techniques including verification via a mobile app, phone call, or text message to provide additional verification when they login to an app or service.  The management and tracking of this is handled automatically for you by the Windows Azure Multi-Factor Authentication Service. Learn More You can learn more about today’s release from this 6 minute video on Windows Azure Multi-Factor Authentication.  Here are some additional videos and tutorials to learn even more: Turn Multi-Factor Authentication on for Windows Azure Active Directory and Office365 – view video Add Multi-Factor Authentication to on-premises applications – view video Build Multi-Factor Authentication into your applications – view video Alex & Steve’s blog post Building Multi-Factor Authentication to Your Applications using the SDK Start making your applications and systems more secure with multi-factor authentication today!  And give us your feedback and feature requests via the MFA forum. Billing: Reset your Spending Limit on MSDN subscriptions When you sign-up for Windows Azure as a MSDN customer you automatically get a MSDN subscription created for you that enables deeply discounted prices and free “MSDN credits” (up to $150 each month) that you can spend on any resources within Windows Azure.  I blogged some details about this last week. By default MSDN subscriptions in Windows Azure are created with what is called a “Spending Limit” which ensures that if you ever use up all of the MSDN credits you still don’t get billed – as the subscription will automatically suspend when all of the free credits are gone (ensuring your bill is never more than $0). You can optionally remove the spending limit if you want to use more than the free credits and pay any overage on top of them.  Prior to this week, though, once the spending limit was removed there was no way to re-instate it for the next billing cycle. Starting with this week’s release you can now: Remove the spending limit only for the current billing cycle (ideal if you know that it is a one time spike) Remove the spending limit indefinitely if you expect to continue to have higher usage in future Reset/Turn back on the spending limit from the next billing cycle forward in case you’ve already turned it off To enable or reset your spending limit, click the “Subscription” button in the top of the Windows Azure Management Portal and the click the “Manage your subscriptions” link within it: This will take you to the Windows Azure subscription management page (which lists all of the Windows Azure subscriptions you have active).  Click your MSDN subscription to see details on your account – including usage data on how much services you’ve used on it: Above you can see usage data on my personal MSDN subscription.  I’ve done a lot of talks recently and have used up my free $150 credits for the month and have $23.64 in overages.  I was able to go above $0 on the subscription because I’ve turned off my spending limit (this is indicated in the text I’ve highlighted in red above). If I want to reapply the spending limit for the next billing cycle (which starts on October 3rd) I can now do so by clicking the “Click here to change the spending limit option” link.  This will bring up a dialog that makes it really easy for me to re-active the spending limit starting the next billing cycle: We hope this new flexibility to turn the spending limit on and off enables you to use your MSDN benefits even more, and provides you with confidence that you won’t inadvertently do something that causes you to have to pay for something you weren’t expecting to. Billing: Subscription suspension no longer deletes Virtual Machines In addition to supporting the re-enablement of the spending limit, we also made an improvement this week so that if your MSDN (or BizSpark or Free trial) subscription does trigger the spending limit we no longer delete the Virtual Machines you have running. Previously, Virtual Machines deployed in suspended subscriptions would be deleted when the spending limit was passed (the data drives would be preserved – but the VM instances themselves would be deleted). Now when a subscription is disabled, VMs deployed inside it will simply move into the stopped de-provision state we recently introduced (which allows a VM to stop without incurring any billing). This allows the Virtual Machines to be quickly restarted with all the previously attached disks and endpoints when a fresh monetary credit is applied or the subscription is converted into a paid subscription. As a result, customers don’t have to worry about losing their Virtual Machines when spending limits are reached, and they can quickly return back to business by re-starting their VMs immediately. Storage: New .NET Storage Client Library 2.1 Release Earlier this month we released a major update of our Windows Azure Storage Client Library for .NET.  The new 2.1 release includes a ton of awesome new features and capabilities: Improved Performance Async Task<T> support IQueryably<T> Support for Tables Buffer Pooling Support .NET Tracing Integration Blob Stream Improvements And a lot more… Read this detailed blog post about the Storage Client Library 2.1 Release from the Windows Azure Storage Team to learn more.  You can install the Storage Client Library 2.1 release and start using it immediately using NuGet. Web Sites: IP and Domain Restriction Now Supported This month we have also enabled the IP and Domain Restrictions feature of IIS to be used with Windows Azure Web Sites. This provides an additional security option that can also be used in combination with the recently enabled dynamic IP address restriction (DIPR) feature (http://blogs.msdn.com/b/windowsazure/archive/2013/08/27/confirming-dynamic-ip-address-restrictions-in-windows-azure-web-sites.aspx). Developers can use IP and Domain Restrictions to control the set of IP addresses, and address ranges, that are either allowed or denied access to their websites. With Windows Azure Web Sites developers can enable/disable the feature, as well as customize its behavior, using web.config files located in their website. There is an overview of the IP and Domain Restrictions feature from IIS available here:  http://www.iis.net/configreference/system.webserver/security/ipsecurity. A full description of individual configuration elements and attributes is available here: http://msdn.microsoft.com/en-us/library/ms691353(v=vs.90).aspx The example configuration snippet below shows an ipSecurity configuration that only allows access to addresses originating from the range specified by the combination of the ipAddress and subnetMask attributes. Setting allowUnlisted to false means that only those individual addresses, or address ranges, explicitly specified by a developer will be allowed to make HTTP requests to the website. Setting the allowed attribute to true in the child add element indicates that the address and subnet together define an address range that is allowed to access the website.   <system.webServer>       <security>       <ipSecurity allowUnlisted="false" denyAction="NotFound">         <add allowed="true" ipAddress="123.456.0.0" subnetMask="255.255.0.0"/>       </ipSecurity>     </security>      </system.webServer> If a request is made to a website from an address outside of the allowed IP address range, then an HTTP 404 not found error is returned as defined in the denyAction attribute. One final note, just like the companion DIPR feature, Windows Azure Web Sites ensures that the client IP addresses “seen” by the IP and Domain Restrictions module are the actual IP addresses of Internet clients making HTTP requests. Summary Today’s release includes a bunch of great features that enable you to build even better cloud solutions.  If you don’t already have a Windows Azure account, you can sign-up for a free trial and start using all of the above features today.  Then visit the Windows Azure Developer Center to learn more about how to build apps with it. Hope this helps, Scott P.S. In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu [Less]

This week we released some great updates to Windows Azure.  These new capabilities include: Compute: New 2-CPU Core 14 GB RAM instance option Virtual Machines: Support for Oracle Software Images, Management Operations on Stopped VMs Active ... [More] Directory: Richer Directory Management and General Availability of Multi-Factor Authentication Support Spending Limit: Reset your Spending Limit, Virtual Machines are no longer deleted if it is hit Storage: New Storage Client Library 2.1 Released Web Sites: IP and Domain Restriction Now Supported All of these improvements are now available to use immediately.  Below are more details about them. Compute: New 2-CPU Core 14 GB RAM instance This week we released a new memory-intensive instance for Windows Azure. This new instance, called A5, has two CPU cores and 14 gigabytes (GB) of RAM and can be used with Virtual Machines (both Windows and Linux) and Cloud Services: You can begin using this new A5 compute option immediately.  Additional information on pricing can be found in the Cloud Services and Virtual Machines sections of our pricing details pages on the Windows Azure website. Virtual Machines: Support for Oracle Software Images Earlier this summer we announced a strategic partnership between Microsoft and Oracle, and that we would enable support for running Oracle software in Windows Azure Virtual Machines. Starting today, you can now deploy pre-configured virtual machine images running various combinations of Oracle Database, Oracle WebLogic Server, and Java Platform SE on Windows, with licenses for the Oracle software included.  These ready-to-deploy Oracle software images enable rapid provisioning of cost-effective cloud environments for development, testing, deployment, and easy scaling of enterprise applications.  The images can now be easily selected in the standard “Create Virtual Machine” wizard within the Windows Azure Management Portal: During preview, these images are offered for no additional charge on top of the standard Windows Server VM rate.  After the preview period ends, these Oracle images will be billed based on the total number of minutes the VMs run in a month.  With Oracle license mobility, existing Oracle customers that are already licensed on Oracle software also have the flexibility to deploy them on Windows Azure.  To learn more about Oracle on Windows Azure, visit windowsazure.com/oracle and read the technical walk-through documentation for the Oracle Images. Virtual Machines: Management Operations on Stopped VMs Starting with this week’s release, it is now possible to perform management operations on stopped/de-allocated Virtual Machines.  Previously a VM had to be running in order to do operations like change the VM size, attach and detach disks, configure endpoints and load balancer/availability settings.  Now it is possible to do all of these on stopped VMs without having to boot them: Active Directory: Create and Manage Multiple Active Directories Starting with this week’s release it is now possible to create and manage multiple Windows Azure Active Directories in a single Windows Azure subscription (previously only one directory was supported and once created you couldn’t delete it).  This is useful both for development/test scenarios as well as for cases where you want to have separate directory tenants or synchronize with different on-premises domains or forests.  Creating a New Active Directory Creating a new Active Directory is now really easy.  Simply select New->Application Services->Active Directory->Directory within the management portal: When prompted configure the directory name, default domain name (you can later change this to any custom domain you want – e.g. yourcompanyname.com), and the country or region to use: In a few seconds you’ll have a new Active Directory hosted within Windows Azure that is ready to use for free: You can run and manage your Windows Azure Active Directories entirely in the cloud, or alternatively sync them with an on-premises Active Directory deployment - which allows you to automatically synchronize all of your on-premises users into your Active Directory in the cloud.  This later option is very powerful, and ensures that any time you add or remove a user in your on-premises directory it is automatically reflected in the cloud as well. You can use your Windows Azure Active Directory to manage identity access to custom applications you run and host in the cloud (and there is new support within ASP.NET in the VS 2013 release that makes building these SSO apps on Windows Azure really easy).  You can also use Windows Azure Active Directory to securely manage the identity access of cloud based applications like Office 365, SalesForce.com, and other popular SaaS solutions. Additional New Features In addition to enabling the ability to create multiple directories in a single Windows Azure subscription, this week’s release also includes several additional usability enhancements to the Windows Azure Active Directory management experience: With this week’s release, we have added the ability to change the name of a directory after its created (previously it was fixed at creation time). As an administrator of a directory, you can now add users from another directory of which you’re a member. This is useful, for example, in the scenario where there are other members of your production directory who will need to collaborate on an application that is under development or testing in a non-production environment. A user can be a member of up to 20 directories. If you use a Microsoft account to access Windows Azure, and you use a different organizational account to manage another directory, you may find it convenient to manage that second directory with your Microsoft account. With this release, we’ve made it easier to configure a Microsoft account to manage an existing Active Directory. Now you can configure this even if the Microsoft account already manages a directory, and even if the administrator account for the other directory doesn’t have a subscription to Windows Azure. This is a common scenario when the administrator account for the other directory was created during signup for Office 365 or another Microsoft service. In this release, we’ve also added support to enable developers to delete single tenant applications that they’ve added to their Windows Azure AD. To delete an application, open the directory in which the application was added, click on the Applications tab, and click Delete on the command bar. An application can be deleted only when External Access is set to ‘Off’ on the configure tab. As always, if there are aspects of these new Azure AD experiences that you think are great, or things that drive you crazy, let us know by posting in our forum on TechNet. Active Directory: General Availability of Multi-Factor Authentication Service With this week’s release we are excited to ship the general availability release of a great new service: the Windows Azure Multi-Factor Authentication (MFA) Service.  Windows Azure Multi-Factor Authentication is a managed service that makes it easy to securely manage user access to Windows Azure, Office 365, Intune, Dynamics CRM and any third party cloud service that supports Windows Azure Active Directory.  You can also use it to securely control access to your own custom applications that you develop and host within the cloud. Windows Azure Multi-Factor Authentication can also be used with on-premise scenarios. You can optionally download our new Multi-Factor Authentication Server for Windows Server Active Directory and use it to protect on-premise applications as well. Getting Started To enable multi-factor authentication, sign-in to the Windows Azure Management Portal and select New->Application Services->Active Directory->Multi-Factor Auth Provider and choose the “Quick Create” option.  When you create the service you can point it at your Windows Azure Active Directory and choose from one of two billing models (per user pricing, or per authentication pricing): Once created the Windows Azure Multi-Factor Authentication service will show up within the “Multi-Factor Auth Providers” section of the Active Directory extension: You can then manage which users in your directory have multi-factor authentication enabled by drilling into the “Users” tab of your Active Directory and then click the “Manage Multi-Factor Auth” button: Once multi-factor authentication is enabled for a user within your directory they will be able to use a variety of secondary authentication techniques including verification via a mobile app, phone call, or text message to provide additional verification when they login to an app or service.  The management and tracking of this is handled automatically for you by the Windows Azure Multi-Factor Authentication Service. Learn More You can learn more about today’s release from this 6 minute video on Windows Azure Multi-Factor Authentication.  Here are some additional videos and tutorials to learn even more: Turn Multi-Factor Authentication on for Windows Azure Active Directory and Office365 – view video Add Multi-Factor Authentication to on-premises applications – view video Build Multi-Factor Authentication into your applications – view video Alex & Steve’s blog post Building Multi-Factor Authentication to Your Applications using the SDK Start making your applications and systems more secure with multi-factor authentication today!  And give us your feedback and feature requests via the MFA forum. Billing: Reset your Spending Limit on MSDN subscriptions When you sign-up for Windows Azure as a MSDN customer you automatically get a MSDN subscription created for you that enables deeply discounted prices and free “MSDN credits” (up to $150 each month) that you can spend on any resources within Windows Azure.  I blogged some details about this last week. By default MSDN subscriptions in Windows Azure are created with what is called a “Spending Limit” which ensures that if you ever use up all of the MSDN credits you still don’t get billed – as the subscription will automatically suspend when all of the free credits are gone (ensuring your bill is never more than $0). You can optionally remove the spending limit if you want to use more than the free credits and pay any overage on top of them.  Prior to this week, though, once the spending limit was removed there was no way to re-instate it for the next billing cycle. Starting with this week’s release you can now: Remove the spending limit only for the current billing cycle (ideal if you know that it is a one time spike) Remove the spending limit indefinitely if you expect to continue to have higher usage in future Reset/Turn back on the spending limit from the next billing cycle forward in case you’ve already turned it off To enable or reset your spending limit, click the “Subscription” button in the top of the Windows Azure Management Portal and the click the “Manage your subscriptions” link within it: This will take you to the Windows Azure subscription management page (which lists all of the Windows Azure subscriptions you have active).  Click your MSDN subscription to see details on your account – including usage data on how much services you’ve used on it: Above you can see usage data on my personal MSDN subscription.  I’ve done a lot of talks recently and have used up my free $150 credits for the month and have $23.64 in overages.  I was able to go above $0 on the subscription because I’ve turned off my spending limit (this is indicated in the text I’ve highlighted in red above). If I want to reapply the spending limit for the next billing cycle (which starts on October 3rd) I can now do so by clicking the “Click here to change the spending limit option” link.  This will bring up a dialog that makes it really easy for me to re-active the spending limit starting the next billing cycle: We hope this new flexibility to turn the spending limit on and off enables you to use your MSDN benefits even more, and provides you with confidence that you won’t inadvertently do something that causes you to have to pay for something you weren’t expecting to. Billing: Subscription suspension no longer deletes Virtual Machines In addition to supporting the re-enablement of the spending limit, we also made an improvement this week so that if your MSDN (or BizSpark or Free trial) subscription does trigger the spending limit we no longer delete the Virtual Machines you have running. Previously, Virtual Machines deployed in suspended subscriptions would be deleted when the spending limit was passed (the data drives would be preserved – but the VM instances themselves would be deleted). Now when a subscription is disabled, VMs deployed inside it will simply move into the stopped de-provision state we recently introduced (which allows a VM to stop without incurring any billing). This allows the Virtual Machines to be quickly restarted with all the previously attached disks and endpoints when a fresh monetary credit is applied or the subscription is converted into a paid subscription. As a result, customers don’t have to worry about losing their Virtual Machines when spending limits are reached, and they can quickly return back to business by re-starting their VMs immediately. Storage: New .NET Storage Client Library 2.1 Release Earlier this month we released a major update of our Windows Azure Storage Client Library for .NET.  The new 2.1 release includes a ton of awesome new features and capabilities: Improved Performance Async Task<T> support IQueryably<T> Support for Tables Buffer Pooling Support .NET Tracing Integration Blob Stream Improvements And a lot more… Read this detailed blog post about the Storage Client Library 2.1 Release from the Windows Azure Storage Team to learn more.  You can install the Storage Client Library 2.1 release and start using it immediately using NuGet. Web Sites: IP and Domain Restriction Now Supported This month we have also enabled the IP and Domain Restrictions feature of IIS to be used with Windows Azure Web Sites. This provides an additional security option that can also be used in combination with the recently enabled dynamic IP address restriction (DIPR) feature (http://blogs.msdn.com/b/windowsazure/archive/2013/08/27/confirming-dynamic-ip-address-restrictions-in-windows-azure-web-sites.aspx). Developers can use IP and Domain Restrictions to control the set of IP addresses, and address ranges, that are either allowed or denied access to their websites. With Windows Azure Web Sites developers can enable/disable the feature, as well as customize its behavior, using web.config files located in their website. There is an overview of the IP and Domain Restrictions feature from IIS available here:  http://www.iis.net/configreference/system.webserver/security/ipsecurity. A full description of individual configuration elements and attributes is available here: http://msdn.microsoft.com/en-us/library/ms691353(v=vs.90).aspx The example configuration snippet below shows an ipSecurity configuration that only allows access to addresses originating from the range specified by the combination of the ipAddress and subnetMask attributes. Setting allowUnlisted to false means that only those individual addresses, or address ranges, explicitly specified by a developer will be allowed to make HTTP requests to the website. Setting the allowed attribute to true in the child add element indicates that the address and subnet together define an address range that is allowed to access the website.   <system.webServer>       <security>       <ipSecurity allowUnlisted="false" denyAction="NotFound">         <add allowed="true" ipAddress="123.456.0.0" subnetMask="255.255.0.0"/>       </ipSecurity>     </security>      </system.webServer> If a request is made to a website from an address outside of the allowed IP address range, then an HTTP 404 not found error is returned as defined in the denyAction attribute. One final note, just like the companion DIPR feature, Windows Azure Web Sites ensures that the client IP addresses “seen” by the IP and Domain Restrictions module are the actual IP addresses of Internet clients making HTTP requests. Summary Today’s release includes a bunch of great features that enable you to build even better cloud solutions.  If you don’t already have a Windows Azure account, you can sign-up for a free trial and start using all of the above features today.  Then visit the Windows Azure Developer Center to learn more about how to build apps with it. Hope this helps, Scott P.S. In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu [Less]

Earlier this summer we announced a number of great changes to Windows Azure that make it a fantastic cloud environment to use for Dev/Test scenarios .  These Dev/Test capabilities work great even for scenarios where you are building apps that ... [More] ultimately will still be deployed using on-premises servers. Some of the dev/test changes we announced for Windows Azure included: No Charge for Stopped VMs Pay by the Minute Billing MSDN Use Rights Support on Windows Azure Heavily Discounted MSDN Dev/Test Rates – up to 97% discount off standard rates We also introduced a new MSDN Monthly Monetary Credit program – which allows you to use up to $150 per month of free monetary credits on Windows Azure for dev/test scenarios.  These credits renew every month – enabling you to use $1000+ of free dev/test capacity every year.  You can spend these dev/test credits on anything in Windows Azure – VMs, Web Sites, Mobile Backends, Cloud Services, Databases, Storage, Hadoop, Media, and more.  They enable you to never have to wait on your IT department for dev/test capacity again. No Credit Card Required for MSDN Users to Sign-Up to Windows Azure Earlier this summer we also modified the Windows Azure sign-up process to no longer require credit card validation when you are a MSDN user and create your account on Windows Azure.  Simply sign-up to Windows Azure using the same Microsoft ID (formerly Live ID) registered with your MSDN account and you’ll be able to activate your MSDN Benefits on Windows Azure in seconds with no credit card or payment details required. Once activated you can immediately start using your free MSDN credits on any Windows Azure resource – enabling $1000+ of free dev/test capacity every year.  Special Aston Martin Sweepstakes through Sept 30th As an added incentive to try out your free MSDN benefits we are currently holding a special Aston Martin Sweepstakes offer through Sept 30th.  The lucky winner will win a 2013 Aston Martin V8 Vantage:   No purchase is necessary to enter the sweepstakes (and we cover both the tax and shipping costs!).  To enroll for a chance to win the offer, all you need to do is: Sign-up for Windows Azure and activate your MSDN Benefits Create and deploy a Windows Azure Web Site or Windows Azure Virtual Machine (both cost you nothing with your MSDN benefits) Once you do the above we’ll automatically enroll you in the sweepstakes draw and if you are lucky you might drive away in your very own 2013 Aston Martin V8 Vantage.  Click here to learn more and activate your MSDN Windows Azure Benefits today. Activate Your MSDN Benefits Today If you are a MSDN subscriber and haven’t tried out Windows Azure you should really give it a try.  In addition to enabling you to build great cloud, web and mobile apps, it also enables you to leverage the cloud to quickly spin up (and down) virtual machines, web sites, databases and more that you can use to make your development and testing much more productive – even if you ultimately are deploying the production apps on-premises. Activate your MSDN benefits and try out Windows Azure before Sept 30th and you might also drive away in your dream car.  Even if you don’t win the car you’ll be able to use up to $1000+ of free dev/test capacity every year. Hope this helps, Scott P.S. In addition to blogging, I also use Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu [Less]

Earlier this summer we announced a number of great changes to Windows Azure that make it a fantastic cloud environment to use for Dev/Test scenarios .  These Dev/Test capabilities work great even for scenarios where you are building apps that ... [More] ultimately will still be deployed using on-premises servers. Some of the dev/test changes we announced for Windows Azure included: No Charge for Stopped VMs Pay by the Minute Billing MSDN Use Rights Support on Windows Azure Heavily Discounted MSDN Dev/Test Rates – up to 97% discount off standard rates We also introduced a new MSDN Monthly Monetary Credit program – which allows you to use up to $150 per month of free monetary credits on Windows Azure for dev/test scenarios.  These credits renew every month – enabling you to use $1000+ of free dev/test capacity every year.  You can spend these dev/test credits on anything in Windows Azure – VMs, Web Sites, Mobile Backends, Cloud Services, Databases, Storage, Hadoop, Media, and more.  They enable you to never have to wait on your IT department for dev/test capacity again. No Credit Card Required for MSDN Users to Sign-Up to Windows Azure Earlier this summer we also modified the Windows Azure sign-up process to no longer require credit card validation when you are a MSDN user and create your account on Windows Azure.  Simply sign-up to Windows Azure using the same Microsoft ID (formerly Live ID) registered with your MSDN account and you’ll be able to activate your MSDN Benefits on Windows Azure in seconds with no credit card or payment details required. Once activated you can immediately start using your free MSDN credits on any Windows Azure resource – enabling $1000+ of free dev/test capacity every year.  Special Aston Martin Sweepstakes through Sept 30th As an added incentive to try out your free MSDN benefits we are currently holding a special Aston Martin Sweepstakes offer through Sept 30th.  The lucky winner will win a 2013 Aston Martin V8 Vantage:   No purchase is necessary to enter the sweepstakes (and we cover both the tax and shipping costs!).  To enroll for a chance to win the offer, all you need to do is: Sign-up for Windows Azure and activate your MSDN Benefits Create and deploy a Windows Azure Web Site or Windows Azure Virtual Machine (both cost you nothing with your MSDN benefits) Once you do the above we’ll automatically enroll you in the sweepstakes draw and if you are lucky you might drive away in your very own 2013 Aston Martin V8 Vantage.  Click here to learn more and activate your MSDN Windows Azure Benefits today. Activate Your MSDN Benefits Today If you are a MSDN subscriber and haven’t tried out Windows Azure you should really give it a try.  In addition to enabling you to build great cloud, web and mobile apps, it also enables you to leverage the cloud to quickly spin up (and down) virtual machines, web sites, databases and more that you can use to make your development and testing much more productive – even if you ultimately are deploying the production apps on-premises. Activate your MSDN benefits and try out Windows Azure before Sept 30th and you might also drive away in your dream car.  Even if you don’t win the car you’ll be able to use up to $1000+ of free dev/test capacity every year. Hope this helps, Scott P.S. In addition to blogging, I also use Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu [Less]

This morning we released some great updates to Windows Azure.  These new capabilities include: Dedicated Cache Service: Announcing the preview of our new distributed, dedicated, high performance cache service AutoScale: Schedule-based ... [More] auto-scaling for Web Sites and Virtual Machines and richer AutoScale history logs Web Sites: New Web Server Logging Support to save HTTP Logs to Storage Accounts Operation Logs: New Filtering options on top of Operation Logs All of these improvements are now available to use immediately (note: some are still in preview).  Below are more details about them. Windows Azure Cache Service: Preview of our new Distributed Cache Service I’m excited today to announce the preview release of the new Windows Azure Cache Service – our latest service addition to Windows Azure. The new Windows Azure Cache Service enables you to easily deploy dedicated, high performance, distributed caches that you can use from your Windows Azure applications to store data in-memory and dramatically improve their scalability and performance. The new Windows Azure Cache Service can be used by any type of Windows Azure application – including those hosted within Windows or Linux Virtual Machines, as well as those deployed as a Windows Azure Web Site and Windows Azure Cloud Services.  Support for Windows Azure Mobile Services will also be enabled in the future. You can instantiate a dedicated instance of a Windows Azure Cache Service for each of your apps, or alternatively share a single Cache Service across multiple apps.  This later scenario is particularly useful when you wish to partition your cloud backend solutions into multiple deployment units – now they can all easily share and work with the same cached data. Benefits of the Windows Azure Cache Service Some of the benefits of the new Windows Azure Cache Service include: Ability to use the Cache Service from any app type (VM, Web Site, Mobile Service, Cloud Service) Each Cache Service instance is deployed within dedicated VMs that are separated/isolated from other customers – which means you get fast, predictable performance.  There are no quotas or throttling behaviors with the Cache Service – you can access your dedicated Cache Service instances as much or as hard as you want.  Each Cache Service instance you create can store (as of today’s preview) up to 150GB of in-memory data objects or content.  You can dynamically increase or shrink the memory used by a Cache Service instance without having to redeploy your apps.  Web Sites, VMs and Cloud Service can retrieve objects from the Cache Service on average in about 1ms end-to-end (including the network round-trip to the cache service and back).  Items can be inserted into the cache in about ~1.2ms end-to-end (meaning the Web Site/VM/Cloud Service can persist the object in the remote Cache Service and gets the ACK back in 1.2ms end-to-end).  Each Cache Service instance is run as a highly available service that is distributed across multiple servers.  This means that your Cache Service will remain up and available even if a server on which it is running crashes or if one of the VM instances needs to be upgraded for patching. The VMs that the cache service instances run within are managed as a service by Windows Azure – which means we handle patching and service lifetime of the instances.  This allows you to focus on building great apps without having to worry about managing infrastructure details. The new Cache Service supports the same .NET Cache API that we use today with the in-role cache option that we support with Cloud Services.  So code you’ve already written against that is compatible with the new managed Cache Service. The new Cache Service comes with built-in provider support for ASP.NET Session State and ASP.NET Output Page Caching.  This enables you to easily scale-out your ASP.NET applications across multiple web servers and still share session state and/or cached page output regardless of which customer hit which server.  The new Cache Service supports the ability to either use a separate Cache Service instance for each of your apps, or instead share a single Cache Service instance across multiple apps at once (which enables easy data sharing as well as app partitioning). This can be very useful for scenarios where you want to partition your app up across several deployment units. Creating a Cache Service You can easily create a new Cache Service by going to the Windows Azure Management Portal and using the NEW -> DATA SERVICES -> CACHE option: In the screenshot above, we specified that we wanted to create a new Premium cache of 5 GB named “scottgucache” in the “North Europe” region. Once we click the “Create a New Cache” button it will take about a few minutes to provision: Once provisioned, the cache will show up in the Windows Azure Management Portal just like all of the other Windows Azure services (Web Sites, VMs, Databases, Storage Accounts, etc) within our subscription.  We can click the DASHBOARD tab to see more details about it: We can use the cache as-is (it comes with smart defaults and doesn’t require changes to get started).  Or we can also optionally click the CONFIGURE tab to manage custom settings - like creating named cache partitions and configuring expiration behavior, evicition policy, availability settings (which means a cached item will be saved across multiple VM instances within the cache service so that they will survive even if a server crashes), and notification settings (which means our cache can call back our app when an item it updated or expired): Once you make a change to one of these settings just click the “Save” button and it will be applied immediately (no need to redeploy). Using the Cache Now that we have created a Cache Service, let’s use it from within an application.  To access the Cache Service from within an app, we’ll need to retrieve the endpoint URL for the Cache Service and retrieve an access key that allows us to securely access it.  We can do both of these by navigating to the DASHBOARD view of our Cache Service within the Windows Azure Management Portal: The endpoint URL can be found in the “quick glance” view of the service, and we can retrieve the API key for the service by clicking the “Manage Keys” button: Once we have saved the endpoint URL and access key from the portal, we’ll update our applications to use them. Using the Cache Service Programmatically from within a .NET application Using the Cache Service within a .NET or ASP.NET applications is easy.  Simply right-click on your project within Visual Studio, choose the “Manage NuGet Packages” context menu, search the NuGet online gallery for the “Windows Azure Caching” NuGet package, and then add it to your application: After you have installed the NuGet Windows Azure Caching package, open up your web.config/app.config file and replace the cache Service EndPoint URL and access key in the dataCacheClient section of your application’s config file: Once you do this, you can now programmatically put and get things from the Cache Service using a .NET Cache API with code like below: The objects we programmatically add to the cache will be automatically persisted within the Cache Service and can then be shared across any number of VMs, Web Sites, Mobile Services and Cloud Services that are using the same Cache Service instance.  Because the cache is so fast (retrievals take on average about 1ms end-to-end across the wire and back) and because it can save 100s of GBs of content in-memory, you’ll find that it can dramatically improve the scalability, performance and availability of your solutions.  Visit our documentation center to learn more about the Windows Azure Caching APIs. Enabling ASP.NET Session State across a Web Farm using the Cache Service The new Windows Azure Cache Service also comes with a supported ASP.NET Session State Provider that enables you to easily use the Cache Service to store ASP.NET Session State.  This enables you to deploy your ASP.NET applications across any number of servers and have a customer’s session state be available on any of them regardless of which web server the customer happened to hit last in the web farm. Enabling the ASP.NET Session State Cache Provider is really easy.  Simply add the below configuration to your web.config file: Once enabled your customers can hit any web server within your application’s web farm and the session state will be available.  Visit our documentation center to learn more about the ASP.NET session state provider as well as the Output caching provider that we also support for ASP.NET. Monitoring and Scaling the Cache Once your Cache Service is deployed, you can track the activity and usage of the cache by going to its MONITOR tab in the Windows Azure Management Portal. You can get useful information like bandwidth used, cache miss percentage, memory used, read requests/sec, write requests/sec etc. so that you can make scaling decisions based on your real-world traffic patterns: You can also customize the monitoring page to see other metrics of interest instead of or in addition to the default ones.  Clicking the “Add Metrics” button above provides an easy UI to configure this: If you need to scale your cache due to increased traffic to your application, you can go to the SCALE tab and easily change the cache offering or cache size depending on your requirements.  For this example we had initially created a 5GB Premium Cache.  If we wanted to scale it up we could simply expand the slider below to be 140GB and then click the “Save” button.  This will dynamically scale our cache without it losing any of the existing data already persisted within it: This makes it really easy to scale out your cache if your application load increases, or reduce your cache size if you find your application doesn’t need as much memory and you want to save costs. Learning More The new Windows Azure Cache Service enables you to really super-charge your Windows Azure applications.  It provides a dedicated Cache that you can use from all of your Windows Azure applications – regardless of whether they are implemented within Virtual Machines or as Windows Azure Web Sites, Mobile Services, or Cloud Services.  You’ll find that it can help really speed up your applications, improve your app scalability, and make your apps even more robust. Review our Cache Service Documentation to learn more about the service.  Visit here to learn more about more the details about the various cache offering sizes and pricing.  And then use the Windows Azure Management Portal to try out the Windows Azure Cache Service today. AutoScale: Schedule Updates for Web Sites + VMs, Weekend Schedules, AutoScale History Three weeks ago we released scheduled AutoScale support for Cloud Services. Today, we are adding scheduled AutoScale support to Web sites and Virtual Machines as well, and we are also introducing support for setting up different time schedule rules depending on whether it is a weekday or weekend. Time Scheduled AutoScale Support for Web Sites and Virtual Machines Just like for Cloud Services, you can now go to the Scale tab for a Virtual Machines or a Web site, and you’ll see a new button to Set up schedule times: Scheduled AutoScale works the same way now for Web Sites and Virtual Machines as for Cloud Services. You can still choose to scale the same way at all times (by selecting No scheduled times), but you can now click the “Set up schedule times” dialog to setup scale rules that run differently depending on the time of day: Once you define the start and stop of the day using the dialog above, you can then go back to the main scale tab and setup different rules for each time segment.  For example, below I’ve setup rules so that during Week Days we’ll have between 2 and 5 small VMs running for our Web Site.  I want AutoScale to scale-up/down the exact number depending on the CPU percentage of the VMs: On Week Nights, though, I don’t want to have as many VMs running, so I’ll configure it to AutoScale only between 1 and 3 VMs.  All I need to do to do this is to change the drop down from “Week Day” to “Week Night” and then edit a different set of rules and hit Save: This makes it really easy to setup different policies and rules to use depending on the time of day – which can both improve your performance during peak times and save you more money during off-peak times. AutoScale History Previously, we supported an instance count graph on the scale tab so you can see the history of actions for your service. With today’s release we’ve improved this graph to now show the sum of CPU usage across all of your instances: This means that if you have one instance, the sum of the CPU can go from 0 to 1, but if you have three instances, it can go from 0 to 3. You can use this to get a sense of the total load across your entire role, and to see how well AutosSale is performing. Finally, we’ve also improved the Operation Log entry for AutoscaleAction: it now shows you the exact Schedule that was used to scale your service, including the settings that were in effect during that specific scale action (it’s in the section called ActiveAutoscaleProfile): Web Sites: Web Server Logging to Storage Accounts With today’s release you can now configure Windows Azure Web Sites to write HTTP logs directly to a Windows Azure Storage Account.  This makes it really easy to persist your HTTP logs as text blobs that you can store indefinitely (since storage accounts can maintain huge amounts of data) and which you can also use to later perform rich data mining/analysis on them.  Storing HTTP Log Files as Blobs in Windows Azure Storage To enable HTTP logs to be written directly to blob storage, navigate to a Web Site using the Windows Azure Management Portal and click the CONFIGURE tab.  Then navigate to the SITE DIAGNOSTICS section.  Starting today, when you turn “Web Server Logging” ON, you can choose to store your logs either on the file system or in a storage account (support for storage accounts is new as of today): Logging to a Storage Account When you choose to keep your web server logs in a storage account, you can specify both the storage account and the blob container that you would like to use by clicking on the green manage storage button.  This brings up a dialog that you can use to configure both: By default, logs stored within a storage account are never deleted. You can override this by selecting the Set Retention checkbox in the site diagnostics section of the configure tab.  You can use this to instead specify the number of days to keep the logs, after which they will be automatically deleted: Once you’ve finished configuring how you want the logs to be persisted, and hit save within the portal to commit the settings, Windows Azure Web Sites will begin to automatically upload HTTP log data to the blob container in the storage account you’ve specified.  The logs are continuously uploaded to the blob account – so you’ll quickly see the log files appear and then grow as traffic hits the web site.  Analysis of the Logs The HTTP log files are persisted in a blob container using a naming scheme that makes it easy to identify which log file correlates to which activity.  The log format name scheme is: [sitename]/[year]/[month]/[day]/[hour]/[VMinstancename].log The HTTP logs themselves are plain text files that store many different settings in a standard HTTP log file format: You can easily download the log files using a variety of tools (Visual Studio Server Explorer, 3rd Party Storage Tools, etc) as well as programmatically write scripts or apps to download and save them on a machine.  Because the content of the files are in a standard HTTP log format you can then use a variety of tools (both free and commercial) to parse and analyze their content. For more advanced scenarios, you can also now spin up your own Hadoop cluster using the Windows Azure HDInsight service.  HDInsight enables you to easily spin up, as well as quickly tear down, Hadoop clusters on Windows Azure that you can use to perform MapReduce and analytics jobs with.  Because HDInsight natively supports Windows Azure Blob Storage, you can now use HDInsight to perform custom MapReduce jobs on top of your Web Site Log Files stored there.  This provides an even richer way to understand and analyze your site traffic and obtain rich insights from it. Operation Logs: Richer Filtering Today’s release adds some improvements to the Windows Azure OPERATION LOGS feature (which you can now access in the Windows Azure Portal within the MANAGEMENT SERVICES section of the portal).  We now support filtering based on several additional fields: STATUS, TYPE and SERVICE NAME. This is in addition to the two filters we already support – filter by SUBSCRIPTION and TIME. This makes it even easier to filter to the specific log item you are looking for quickly. Summary Today’s release includes a bunch of great features that enable you to build even better cloud solutions.  If you don’t already have a Windows Azure account, you can sign-up for a free trial and start using all of the above features today.  Then visit the Windows Azure Developer Center to learn more about how to build apps with it. Hope this helps, Scott P.S. In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu [Less]

This morning we released some great updates to Windows Azure.  These new capabilities include: Dedicated Cache Service: Announcing the preview of our new distributed, dedicated, high performance cache service AutoScale: Schedule-based ... [More] auto-scaling for Web Sites and Virtual Machines and richer AutoScale history logs Web Sites: New Web Server Logging Support to save HTTP Logs to Storage Accounts Operation Logs: New Filtering options on top of Operation Logs All of these improvements are now available to use immediately (note: some are still in preview).  Below are more details about them. Windows Azure Cache Service: Preview of our new Distributed Cache Service I’m excited today to announce the preview release of the new Windows Azure Cache Service – our latest service addition to Windows Azure. The new Windows Azure Cache Service enables you to easily deploy dedicated, high performance, distributed caches that you can use from your Windows Azure applications to store data in-memory and dramatically improve their scalability and performance. The new Windows Azure Cache Service can be used by any type of Windows Azure application – including those hosted within Windows or Linux Virtual Machines, as well as those deployed as a Windows Azure Web Site and Windows Azure Cloud Services.  Support for Windows Azure Mobile Services will also be enabled in the future. You can instantiate a dedicated instance of a Windows Azure Cache Service for each of your apps, or alternatively share a single Cache Service across multiple apps.  This later scenario is particularly useful when you wish to partition your cloud backend solutions into multiple deployment units – now they can all easily share and work with the same cached data. Benefits of the Windows Azure Cache Service Some of the benefits of the new Windows Azure Cache Service include: Ability to use the Cache Service from any app type (VM, Web Site, Mobile Service, Cloud Service) Each Cache Service instance is deployed within dedicated VMs that are separated/isolated from other customers – which means you get fast, predictable performance.  There are no quotas or throttling behaviors with the Cache Service – you can access your dedicated Cache Service instances as much or as hard as you want.  Each Cache Service instance you create can store (as of today’s preview) up to 150GB of in-memory data objects or content.  You can dynamically increase or shrink the memory used by a Cache Service instance without having to redeploy your apps.  Web Sites, VMs and Cloud Service can retrieve objects from the Cache Service on average in about 1ms end-to-end (including the network round-trip to the cache service and back).  Items can be inserted into the cache in about ~1.2ms end-to-end (meaning the Web Site/VM/Cloud Service can persist the object in the remote Cache Service and gets the ACK back in 1.2ms end-to-end).  Each Cache Service instance is run as a highly available service that is distributed across multiple servers.  This means that your Cache Service will remain up and available even if a server on which it is running crashes or if one of the VM instances needs to be upgraded for patching. The VMs that the cache service instances run within are managed as a service by Windows Azure – which means we handle patching and service lifetime of the instances.  This allows you to focus on building great apps without having to worry about managing infrastructure details. The new Cache Service supports the same .NET Cache API that we use today with the in-role cache option that we support with Cloud Services.  So code you’ve already written against that is compatible with the new managed Cache Service. The new Cache Service comes with built-in provider support for ASP.NET Session State and ASP.NET Output Page Caching.  This enables you to easily scale-out your ASP.NET applications across multiple web servers and still share session state and/or cached page output regardless of which customer hit which server.  The new Cache Service supports the ability to either use a separate Cache Service instance for each of your apps, or instead share a single Cache Service instance across multiple apps at once (which enables easy data sharing as well as app partitioning). This can be very useful for scenarios where you want to partition your app up across several deployment units. Creating a Cache Service You can easily create a new Cache Service by going to the Windows Azure Management Portal and using the NEW -> DATA SERVICES -> CACHE option: In the screenshot above, we specified that we wanted to create a new Premium cache of 5 GB named “scottgucache” in the “North Europe” region. Once we click the “Create a New Cache” button it will take about a few minutes to provision: Once provisioned, the cache will show up in the Windows Azure Management Portal just like all of the other Windows Azure services (Web Sites, VMs, Databases, Storage Accounts, etc) within our subscription.  We can click the DASHBOARD tab to see more details about it: We can use the cache as-is (it comes with smart defaults and doesn’t require changes to get started).  Or we can also optionally click the CONFIGURE tab to manage custom settings - like creating named cache partitions and configuring expiration behavior, evicition policy, availability settings (which means a cached item will be saved across multiple VM instances within the cache service so that they will survive even if a server crashes), and notification settings (which means our cache can call back our app when an item it updated or expired): Once you make a change to one of these settings just click the “Save” button and it will be applied immediately (no need to redeploy). Using the Cache Now that we have created a Cache Service, let’s use it from within an application.  To access the Cache Service from within an app, we’ll need to retrieve the endpoint URL for the Cache Service and retrieve an access key that allows us to securely access it.  We can do both of these by navigating to the DASHBOARD view of our Cache Service within the Windows Azure Management Portal: The endpoint URL can be found in the “quick glance” view of the service, and we can retrieve the API key for the service by clicking the “Manage Keys” button: Once we have saved the endpoint URL and access key from the portal, we’ll update our applications to use them. Using the Cache Service Programmatically from within a .NET application Using the Cache Service within a .NET or ASP.NET applications is easy.  Simply right-click on your project within Visual Studio, choose the “Manage NuGet Packages” context menu, search the NuGet online gallery for the “Windows Azure Caching” NuGet package, and then add it to your application: After you have installed the NuGet Windows Azure Caching package, open up your web.config/app.config file and replace the cache Service EndPoint URL and access key in the dataCacheClient section of your application’s config file: Once you do this, you can now programmatically put and get things from the Cache Service using a .NET Cache API with code like below: The objects we programmatically add to the cache will be automatically persisted within the Cache Service and can then be shared across any number of VMs, Web Sites, Mobile Services and Cloud Services that are using the same Cache Service instance.  Because the cache is so fast (retrievals take on average about 1ms end-to-end across the wire and back) and because it can save 100s of GBs of content in-memory, you’ll find that it can dramatically improve the scalability, performance and availability of your solutions.  Visit our documentation center to learn more about the Windows Azure Caching APIs. Enabling ASP.NET Session State across a Web Farm using the Cache Service The new Windows Azure Cache Service also comes with a supported ASP.NET Session State Provider that enables you to easily use the Cache Service to store ASP.NET Session State.  This enables you to deploy your ASP.NET applications across any number of servers and have a customer’s session state be available on any of them regardless of which web server the customer happened to hit last in the web farm. Enabling the ASP.NET Session State Cache Provider is really easy.  Simply add the below configuration to your web.config file: Once enabled your customers can hit any web server within your application’s web farm and the session state will be available.  Visit our documentation center to learn more about the ASP.NET session state provider as well as the Output caching provider that we also support for ASP.NET. Monitoring and Scaling the Cache Once your Cache Service is deployed, you can track the activity and usage of the cache by going to its MONITOR tab in the Windows Azure Management Portal. You can get useful information like bandwidth used, cache miss percentage, memory used, read requests/sec, write requests/sec etc. so that you can make scaling decisions based on your real-world traffic patterns: You can also customize the monitoring page to see other metrics of interest instead of or in addition to the default ones.  Clicking the “Add Metrics” button above provides an easy UI to configure this: If you need to scale your cache due to increased traffic to your application, you can go to the SCALE tab and easily change the cache offering or cache size depending on your requirements.  For this example we had initially created a 5GB Premium Cache.  If we wanted to scale it up we could simply expand the slider below to be 140GB and then click the “Save” button.  This will dynamically scale our cache without it losing any of the existing data already persisted within it: This makes it really easy to scale out your cache if your application load increases, or reduce your cache size if you find your application doesn’t need as much memory and you want to save costs. Learning More The new Windows Azure Cache Service enables you to really super-charge your Windows Azure applications.  It provides a dedicated Cache that you can use from all of your Windows Azure applications – regardless of whether they are implemented within Virtual Machines or as Windows Azure Web Sites, Mobile Services, or Cloud Services.  You’ll find that it can help really speed up your applications, improve your app scalability, and make your apps even more robust. Review our Cache Service Documentation to learn more about the service.  Visit here to learn more about more the details about the various cache offering sizes and pricing.  And then use the Windows Azure Management Portal to try out the Windows Azure Cache Service today. AutoScale: Schedule Updates for Web Sites + VMs, Weekend Schedules, AutoScale History Three weeks ago we released scheduled AutoScale support for Cloud Services. Today, we are adding scheduled AutoScale support to Web sites and Virtual Machines as well, and we are also introducing support for setting up different time schedule rules depending on whether it is a weekday or weekend. Time Scheduled AutoScale Support for Web Sites and Virtual Machines Just like for Cloud Services, you can now go to the Scale tab for a Virtual Machines or a Web site, and you’ll see a new button to Set up schedule times: Scheduled AutoScale works the same way now for Web Sites and Virtual Machines as for Cloud Services. You can still choose to scale the same way at all times (by selecting No scheduled times), but you can now click the “Set up schedule times” dialog to setup scale rules that run differently depending on the time of day: Once you define the start and stop of the day using the dialog above, you can then go back to the main scale tab and setup different rules for each time segment.  For example, below I’ve setup rules so that during Week Days we’ll have between 2 and 5 small VMs running for our Web Site.  I want AutoScale to scale-up/down the exact number depending on the CPU percentage of the VMs: On Week Nights, though, I don’t want to have as many VMs running, so I’ll configure it to AutoScale only between 1 and 3 VMs.  All I need to do to do this is to change the drop down from “Week Day” to “Week Night” and then edit a different set of rules and hit Save: This makes it really easy to setup different policies and rules to use depending on the time of day – which can both improve your performance during peak times and save you more money during off-peak times. AutoScale History Previously, we supported an instance count graph on the scale tab so you can see the history of actions for your service. With today’s release we’ve improved this graph to now show the sum of CPU usage across all of your instances: This means that if you have one instance, the sum of the CPU can go from 0 to 1, but if you have three instances, it can go from 0 to 3. You can use this to get a sense of the total load across your entire role, and to see how well AutosSale is performing. Finally, we’ve also improved the Operation Log entry for AutoscaleAction: it now shows you the exact Schedule that was used to scale your service, including the settings that were in effect during that specific scale action (it’s in the section called ActiveAutoscaleProfile): Web Sites: Web Server Logging to Storage Accounts With today’s release you can now configure Windows Azure Web Sites to write HTTP logs directly to a Windows Azure Storage Account.  This makes it really easy to persist your HTTP logs as text blobs that you can store indefinitely (since storage accounts can maintain huge amounts of data) and which you can also use to later perform rich data mining/analysis on them.  Storing HTTP Log Files as Blobs in Windows Azure Storage To enable HTTP logs to be written directly to blob storage, navigate to a Web Site using the Windows Azure Management Portal and click the CONFIGURE tab.  Then navigate to the SITE DIAGNOSTICS section.  Starting today, when you turn “Web Server Logging” ON, you can choose to store your logs either on the file system or in a storage account (support for storage accounts is new as of today): Logging to a Storage Account When you choose to keep your web server logs in a storage account, you can specify both the storage account and the blob container that you would like to use by clicking on the green manage storage button.  This brings up a dialog that you can use to configure both: By default, logs stored within a storage account are never deleted. You can override this by selecting the Set Retention checkbox in the site diagnostics section of the configure tab.  You can use this to instead specify the number of days to keep the logs, after which they will be automatically deleted: Once you’ve finished configuring how you want the logs to be persisted, and hit save within the portal to commit the settings, Windows Azure Web Sites will begin to automatically upload HTTP log data to the blob container in the storage account you’ve specified.  The logs are continuously uploaded to the blob account – so you’ll quickly see the log files appear and then grow as traffic hits the web site.  Analysis of the Logs The HTTP log files are persisted in a blob container using a naming scheme that makes it easy to identify which log file correlates to which activity.  The log format name scheme is: [sitename]/[year]/[month]/[day]/[hour]/[VMinstancename].log The HTTP logs themselves are plain text files that store many different settings in a standard HTTP log file format: You can easily download the log files using a variety of tools (Visual Studio Server Explorer, 3rd Party Storage Tools, etc) as well as programmatically write scripts or apps to download and save them on a machine.  Because the content of the files are in a standard HTTP log format you can then use a variety of tools (both free and commercial) to parse and analyze their content. For more advanced scenarios, you can also now spin up your own Hadoop cluster using the Windows Azure HDInsight service.  HDInsight enables you to easily spin up, as well as quickly tear down, Hadoop clusters on Windows Azure that you can use to perform MapReduce and analytics jobs with.  Because HDInsight natively supports Windows Azure Blob Storage, you can now use HDInsight to perform custom MapReduce jobs on top of your Web Site Log Files stored there.  This provides an even richer way to understand and analyze your site traffic and obtain rich insights from it. Operation Logs: Richer Filtering Today’s release adds some improvements to the Windows Azure OPERATION LOGS feature (which you can now access in the Windows Azure Portal within the MANAGEMENT SERVICES section of the portal).  We now support filtering based on several additional fields: STATUS, TYPE and SERVICE NAME. This is in addition to the two filters we already support – filter by SUBSCRIPTION and TIME. This makes it even easier to filter to the specific log item you are looking for quickly. Summary Today’s release includes a bunch of great features that enable you to build even better cloud solutions.  If you don’t already have a Windows Azure account, you can sign-up for a free trial and start using all of the above features today.  Then visit the Windows Azure Developer Center to learn more about how to build apps with it. Hope this helps, Scott P.S. In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu [Less]

This morning we released some major updates to Windows Azure.  These new capabilities include: SQL Server AlwaysOn Support: General Availability support with Windows Azure Virtual Machines (enables both high availability and disaster recovery) ... [More] Notification Hubs: General Availability Release of Windows Azure Notification Hubs (broadcast push for Windows 8, Windows Phone, iOS and Android) AutoScale: Schedule-based AutoScale rules and richer logging support Virtual Machines: Load Balancer Configuration and Management Management Services: New Portal Extension for Operation logs + Alerts All of these improvements are now available to use immediately (note: AutoScale is still in preview – everything else is general availability).  Below are more details about them. SQL Server AlwaysOn Support with Windows Azure Virtual Machines I’m excited to announce the general availability release of SQL Server AlwaysOn Availability Groups support within Windows Azure.  We have updated our official documentation to support Availability Group Listeners for SQL Server 2012 (and higher) on Windows Server 2012. SQL Server AlwaysOn Availability Group support, which was introduced with SQL Server 2012, is Microsoft’s premier solution for enabling high availability and disaster recovery with SQL Server.  SQL Server AlwaysOn Availability Groups support multi-database failover, multiple replicas (5 in SQL Server 2012, 9 in SQL Server 2014), readable secondary replicas (which can be used to offload reporting and BI applications), configurable failover policies, backups on secondary replicas, and easy monitoring.  Today, we are excited to announce that we support the complete SQL Server AlwaysOn Availability Groups technology stack with Windows Azure Virtual Machines - including enabling support for SQL Server Availability Group Listeners.  We are really excited to be the first cloud provider to support the full range of scenarios enabled with SQL Server AlwaysOn Availability Groups – we think they are going to enable a ton of new scenarios for customers. High Availability of SQL Servers running in Virtual Machines You can now use SQL Server AlwaysOn within Windows Azure Virtual Machines to achieve high availability and global business continuity.  As part of this support you can now deploy one or more readable database secondaries – which not only improves availability of your SQL Servers but also improves efficiency by allowing you to offload BI reporting tasks and backups to the secondary machines. Today’s Windows Azure release includes changes to better support SQL Server AlwaysOn functionality with our Windows Azure Network Load Balancers.  With today’s update you can now connect to your SQL Server deployment with a single client connection string using the Availability Group Listener endpoint.  This will automatically route database connections to the primary replica node – and our network load balancer will automatically update to route requests to a secondary replica node in the event of an automatic or manual failover scenario: This new SQL Server Availability Group Listener support enables you to easily deploy SQL Databases in Windows Azure Virtual Machines in a high-availability configuration, and take full advantage of the full SQL Server feature-set.  It can also be used to ensure no downtime during upgrade operations or when patching the virtual machines. Disaster Recovery of an on-premises SQL Server using Windows Azure In addition to enabling high availability solutions within Windows Azure, the new SQL Server AlwaysOn support can also be used to enable on-premise SQL Server solutions to be expanded to have one or more secondary replicas running in the cloud using Windows Azure Virtual Machines.  This allows companies to enable high-availability disaster recovery scenarios – where in the event of a local datacenter being down (for example: due to a hurricane or natural disaster, or simply a network HW failure on-premises) they can failover and continue operations using Virtual Machines that have been deployed in the cloud using Windows Azure. The diagram above shows a scenario where an on-premises SQL Server AlwaysOn Availability Group has been defined with a 2 database replicas - a primary and secondary replica (S1).  One more secondary replica (S2) has then been configured to run in the cloud within a Windows Azure Virtual Machine.  This secondary replica (S2) will continuously synchronize transactions from the on-premises primary replica.  In the event of a disaster on-premises, the company can failover to the replica in the cloud and continue operations without business impact.  In addition to enabling disaster recovery, the secondary replica(s) can also be used to offload reporting applications and backups. This is valuable for companies that require maintaining backups outside of the data center for compliance reasons, and enables customers to leverage the replicas for compute scenarios even in non-disaster scenarios.  Learn more about SQL Server AlwaysOn support in Windows Azure You can learn more about how to enable SQL Server AlwaysOn Support in Windows Azure by reading the High Availability and Disaster Recovery for SQL Server in Windows Azure Virtual Machines documentation.  Also review this TechEd 2013 presentation: SQL Server High Availability and Disaster Recovery on Windows Azure VMs.  We are really excited to be the first cloud provider to enable the full range of scenarios enabled with SQL Server AlwaysOn Availability Groups – we think they are going to enable a ton of new scenarios for customers. Windows Azure Notification Hubs I’m excited today to announce the general availability release of Windows Azure Notification Hubs.  Notification Hubs enable you to instantly send personalized, cross-platform, broadcast push notifications to millions of Windows 8, Windows Phone 8, iOS, and Android mobile devices.  I first blogged about Notification Hubs starting with the initial preview of Notification Hubs in January.  Since the initial preview, we have added many new features (including adding support for Android and Windows Phone devices in addition to Windows 8 and iOS ones) and validated that the system is ready for any amount of scale that your next app requires. You can use Notification Hubs from both Windows Azure Mobile Services or any other custom Mobile Backend you have already built (including non-Azure hosted ones) – which makes it really easy to start taking advantage of from any existing app. Notification Hubs: Personalized cross platform broadcast push at scale Push notifications are a vital component of mobile applications.  They’re the most powerful customer engagement mechanism available to mobile app developers.  Sending a single push notification message to one mobile user is relatively straight forward (and is already easy to-do with Windows Azure Mobile Services today).  But sending simultaneous push notifications in a low-latency way to millions of mobile users, and handling real world requirements such as localization, multiple platform devices, and user personalization is much harder. Windows Azure Notification Hubs provide you with an extremely scalable push notification infrastructure that helps you efficiently route cross-platform, personalized push notification messages to millions of users: Cross-platform. With a single API call using Notification Hubs, your app’s backend can send push notifications to your users running on Windows Store, Windows Phone 8, iOS, or Android devices. Highly personalized. Notification Hubs' built-in templating functionality allows you to let the client chose the shape, format and locale of the notifications it wants to see, while keep your backend code platform independent and really clean. Device token management. Notification Hubs relieves your backend from the need to store and manage channel URIs and device tokens used by Platform Notification Services (WNS, MPNS, Apple PNS, or Google Cloud Messaging Service). We securely handle the PNS feedback, device token expiry, etc. for you. Efficient tag-based multicast and pub/sub routing. Clients can specify one or more tags when registering with a Notification Hub thereby expressing user interest in notifications for a set of topics (favorite sport/teams, geo location, stock symbol, logical user ID, etc.). These tags do not need to be pre-provisioned or disposed, and provide a very easy way for apps to send targeted notifications to millions of users/devices with a single API call, without you having to implement your own per-user notification routing infrastructure. Extreme scale. Notification Hubs are optimized to enable push notification broadcast to thousands or millions of devices with low latency. Your server back-end can fire one message into a Notification Hub, and thousands/millions of push notifications can automatically be delivered to your users, without you having to re-architect or shard your application. Usable from any backend. Notification Hubs can be easily integrated into any back-end server app using .NET or Node.js SDK, or easy-to-use REST APIs. It works seamlessly with apps built with Windows Azure Mobile Services. It can also be used by server apps hosted within IaaS Virtual Machines (either Windows or Linux), Cloud Services or Web-Sites. Bing News: Using Windows Azure Notification Hubs to Deliver Breaking News to Millions of Devices A number of big apps started using Windows Azure Notification Hubs even before today’s General Availability Release.  One of them is the Bing News app included on all Windows 8 and Windows Phone 8 devices. The Bing News app needs the ability to notify their users of breaking news in an instant. This can be a daunting task for a few reasons: Extreme scale: Every Windows 8 user has the News app installed, and the Bing backend needs to deliver hundreds of millions of breaking news notifications to them every month Topic-based multicast: Broadcasting push notifications to different markets, based on interests of individual users, requires efficient pub sub routing and topic-based multicast logic Cross-platform delivery: Notification formats and semantics vary between mobile platforms, and tracking channels/tokens across them all can be complicated Windows Azure Notification Hubs turned out to be a perfect fit for Bing News, and with the most recent update of the Bing News app they now use Notification Hubs to deliver push notifications to millions of Windows and Windows Phone devices every day. The Bing News app on the client obtains the appropriate ChannelURIs from the Windows Notification Service (WNS) and the Microsoft Push Notification Service (MPNS), for the Windows 8 and Windows versions respectively, and then registers them with a Windows Azure Notification Hub . When a breaking news alert for a particular market has to be delivered, the Bing News app uses the Notification Hubs to instantly broadcast appropriate messages to all the individual devices.  With a single REST call to the Notification Hub they can automatically filter the customers interested in the topic area (e.g. sports update) and instantly deliver the message to millions of customers: Windows Azure handles all of the complex pub/sub filtering logic for them, and efficiently handles deliver of the messages in a low-latency way. Create your first Notification Hubs Today Notification Hubs support a free tier of usage that allows you to send 100,000 operations every month to 500 registered devices at no cost – which makes it really easy to get started.  To create a new Notification Hub simply choose  New->App Services->Service Bus->Notification Hub within the Windows Azure Management Portal: Creating a new Notification Hub takes less than a minute, and once created you can drill into it to see a dashboard view of activity with it.  Among other things, the dashboard allows you to see how many devices have been registered with it, how many messages have been pushed to it, how many messages have been successfully delivered via it, and how many have failed: Once your hub is created, click the “Configure” tab to enter your app credentials for the various push notifications services (Windows Store/Phone, iOS, and Android) that your Notification Hub will coordinate with: And with that your notification hub is ready to go! Registering Devices and Sending out Broadcast Notifications Now that a Notification Hub is created, we’ll want to register device apps with it.  Doing this is really easy – we have device SDKs for Windows 8, Windows Phone 8, Android, and iOS.  Below is the code you would write within a C# Windows 8 client app to register a user’s interest in broadcast notifications sent to the “myTag” or “myOtherTags” tags/topics: await hub.RegisterNativeAsync(channel.Uri, new string[] { "myTag", "myOtherTag" }); Once a device is registered, it will automatically receive a push notification message when your app backend sends a message to topics/tags it is registered with.   You can use Notification Hubs from a Windows Azure Mobile Service, a custom .NET back-end app, or any other app back-end with our Node.js SDK or REST API.  The below code illustrates how to send a message to the Notification Hub from a custom .NET backend using the .NET SDK: var toast = @"<toast><visual><binding template=""ToastText01""><text id=""1"">Hello everybody!</text></binding></visual></toast>"; await hub.SendWindowsNativeNotificationAsync(toast); A single call like the one above from your app backend will now securely deliver the message to any number of devices registered with your Notification Hub.  The Notification Hub will handle all of the details of the delivery irrespective of how many users you are sending it to (even if there are 10s of millions of them).  Scaling and Monitoring your Notification Hub Once you’ve built your app, you can easily scale it to millions of users directly from the Windows Azure management portal.  Just click the “scale” tab in your Notification Hub within the management portal to configure the number of devices and messages you want to support: In addition to scaling capacity, you can also monitor and track nearly 50 different metrics about your notifications and their delivery to your customers: Learn More about Notification Hubs Learn more about Notification Hubs using the Notification Hubs service page, where you will find video tutorials, in-depth scenario guidance, and link to SDK references. We are happy to continue offering Notification Hubs at no charge to all Windows Azure subscribers through September 30, 2013.  We will begin billing for Notification Hubs consumption in the Basic and Standard tiers on October 1, 2013.  A Free Tier will continue to also be available and supports 100,000 notifications with 500 registered devices each month at no cost. AutoScale: Scheduled AutoScale Rules and Richer Logging This summer we introduced new AutoScale support to Windows Azure that enables you to automatically scale Web Sites, Cloud Services, Mobile Services and Virtual Machines.  AutoScale enables you to configure Windows Azure to automatically scale your application dynamically on your behalf (without any manual intervention required) so that you can achieve the ideal performance and cost balance. Once configured, AutoScale will regularly adjust the number of instances running in response to the load in your application. Today, we are introducing even more AutoScale features – including the ability to proactively adjust your Cloud Service instance count using time scheduled rules. Schedule AutoScale Rules If you click on the Scale tab of a Cloud Service, you’ll see that we’ve now added support for you to configure/control different scaling rules based on schedule rules. By default, you’ll edit scale settings for No scheduled times – this means that your scale settings will always be the same regardless of the time/day. You can scale manually by selecting None in the Scale by Metric section – this will give you the traditional Instance Count slider that you are familiar with: Or you can AutoScale dynamically by reacting to CPU activity or Queue Depth.  The below screen-shot demonstrates configuring an auto-scale rule based on the CPU of the WebTier role and indicates to scale between 1 and 3 instances – depending on the aggregate CPU: With today’s release, we also now allow you to setup different scale settings for different times of the day.  You can enable this by clicking the “Set up Schedule Times” button above.  This brings up a new dialog: With today’s release we now offer the ability to define two different recurring schedules: Day and Night. The first schedule, Day Time, runs from the start of the day to the end of the day (which I’ve defined above as being between 8am and 8pm). The second schedule, Night Time, runs from the end of one day to the start of the next day. Both use the options in Time to define start and end of a day, and the time zone. This schedule respects daylight savings time, if it is applicable to that timezone. In the future we will add other types of time based schedules as well. Once you’ve setup a day/night schedule, you can return to the Scale page and see that the schedule dropdown now has the two schedules you created populated within it: You can now select each schedule from the list and edit scaling rules specific to it within it. For example, you can select the Day Time Schedule and set Instance Count on a Cloud Service role to 5, and then select Night Time and set Instance Count to 3.  This will ensure that Windows Azure scales up your service to 5 instances during the day, and then cycles them down to 3 instances overnight. You can also combine Scheduled Autoscale rules and the Metric Based AutoScale rules together.  Select the CPU or Queue toggle and you can configure AutoScale rules that apply differently during the day or night. For example, you could set the Instance Range from 5 to 10 during the day, and 3 to 6 at night based on CPU activity. Today’s release only supports Scheduled AutoScale rules on Cloud Services – but you’ll see us enable these with all types of compute resources (including Web Sites, Mobile Services + VMs) shortly. AutoScale History It’s now easy to know and log exactly what AutoScale has done for your service: there are four new AutoScale history features with today’s release to help with this. First, we have added two new operations to Windows Azure’s Operation Log capability: AutoscaleAction and PutAutoscaleSetting. We now record each time that AutoScale takes a scale up or scale down action, and include the new and previous instance counts in the details. In addition, we record each time anyone changes autoscale settings – you can use this to see who on your team changed autoscale options and when.  These are both now exposed in the Operation Logs tab of the new Management Services node within the Windows Azure Management Portal: For Cloud Services, we are also adding a historical graph that shows of the number of instances over the past 7 days. This way, you can see trends in AutoScale over the span of a week: Third, if AutoScale ever fails for more than 2 hours at a time, we will automatically notify the Service Administrator and Co-Admin of the subscription via email: Fourth, if you are the Account Administrator for your subscription, we will now show you billing information about Autoscale in your account’s currency: If AutoScale is on, it will show you the difference between your current instance count, and the maximum instance count – and how much you are saving by using it. If AutoScale is off, we will show you how much we predict you could save if you were to turn on AutoScale.  Put another way - we are updating your bill to include suggestions on how you can pay us less in the future (please don’t tell my boss about this… <g>) Virtual Machines: Support for Configuring Load Balancer Probes Every Virtual Machine, Cloud Service, Web Site and Mobile Service you deploy in Windows Azure comes with built-in load balancer support that you can use to both scale out your app and enable high availability.  This load balancer support is built-into Windows Azure and included at no extra charge (most other cloud providers make you pay extra for it). Today’s update of Windows Azure includes some nice new features that make it even easier to configure and manage load balancing support for Virtual Machines – and includes support for customizing the network probe logic that our load balancers use to determine whether your Virtual Machines are healthy and should be kept in the load balancer rotation. Understanding Load Balancer Probes Load-balancing network traffic across multiple Virtual Machine instances is important, both to enable scale-out of your traffic across multiple VMs, as well as to enable high availability of your app’s front-end or back-end virtual machines (as discussed in the SQL Server AlwaysOn section earlier). A network probe is how the Windows Azure load balancer detects failure of one or more of your virtual machine instances - whether due to software or hardware failure.  If the network probe detects there is an issue with a specific virtual machine instance it will automatically failover traffic to your healthy virtual machine instances, and prevent customers thinking your application is down. The default configuration for a network probe from the Windows Azure load balancer is simply using TCP on the same port your application is load-balancing.  As shown in the below example, each Virtual Machine in a load-balanced set is receiving TCP traffic on port 80 from the public internet (likely a website or web service). With a simple TCP probe, the load-balancer sends an ongoing message, every 15 seconds by default, on that same port to each Virtual Machine, checking for health. Because the Virtual Machine is running a website, if the Virtual Machine and web service is healthy, it will automatically reply back to the TCP probe with a simple ACK to the load balancer. While this ACK continues, the load-balancer will continue to send traffic, knowing the website is responsive.  In any situation where the website is unhealthy, the load balancer will not receive a response from the website.  When this happens the load balancer will stop sending traffic to the virtual machine that is having problems, and instead direct traffic to the other two instances, as shown for Virtual Machine 2 below. This simple high availability option will work without having to write any special code inside the VM to respond to the network probes and can protect you from failure due to the application, the virtual machine, or the underlying hardware (note: if Windows Azure detects a hardware failure we’ll automatically migrate your Virtual Machine instance to a new server).   Windows Azure allows you to configure both the time interval for sending each network probe (15 seconds is the default) and the number of probe attempts that must fail before the load balancer takes the instance offline (the default is 2). Thus, with the defaults, after 30 seconds of receiving no response from a web service, the load balancer will consider it unresponsive and stop sending traffic to it until a healthy response is received later (15 seconds per probe * 2 probes). You can also now configure custom HTTP probes – which is a more advanced option. With HTTP probes, you can configure the load balancer’s network probe request to be sent to a separate network port than the one you are load-balancing (and this port does not have to be open to the Internet – the recommendation is for it to be a private port that only the load balancer can access). This will require your service or application to be listening on this separate port and respond to the probe request, based upon the health of the application. With HTTP probes, the load balancer will continue to send traffic to your Virtual Machine if it receives an HTTP 200 OK response from the network probe request. Similar to the above TCP intervals, with the defaults, when a Virtual Machine does not respond with an HTTP 200 OK after 30 seconds (2 x 15 second probes), the load balancer will automatically take the machine out of traffic rotation until hearing a 200 OK back on the next probe. This advanced option does require the creation of code to listen and respond on a separate port, but gives you a lot more control over traffic being delivered to your service: Configuring Load Balancer Probe Settings Before today’s release, configuring custom network probe settings used to require you to use PowerShell, our Cross Platform CLI tools, or write code against our REST Management API.  With today’s Windows Azure release we’ve added support to configure these settings using the Windows Azure Management Portal as well.  You can configure load-balanced sets for new or existing endpoints on your virtual machines.  You can do this by adding or editing an endpoint on a Virtual Machine.  To do this with an existing Virtual Machine, select the VM within the portal and navigate to the Endpoints tab within it.  Then add or edit the endpoint you want to open to external callers: The Edit Endpoint dialog allows you to view or change a port that is open to the Internet (and existed before today’s release):  Selecting the “Create Load-Balanced Set” or “Reconfigure the Load-Balanced Set” checkbox within the dialog above will now allow you to proceed to another page within the wizard that surfaces the load balanced set and network probe properties: Using the screen above you can now change the network probe settings to be either TCP or HTTP based, configure which internal port you wish to probe on (if you want your network probe to be private and different than the port you use to serve public traffic), configure the probe interval (default is every 15 seconds), as well as configure the number of times the network probe is allowed to fail before the machine is automatically removed from network rotation (default is 2 failures). Identifying Network Probe Problems In addition to allowing you to create/edit the network probe settings, today’s Windows Azure Management Portal release also now surfaces cases where network probes are misconfigured or having problems.  For example, if during the Virtual Machine Preview you created a VM and configured a load-balanced sets prior to probes being a required configuration item, we will show an error icon that indicates missing probe configuration under the load-balanced set name column to indicate that the load-balanced set is not configured correctly: Operation Logs and Alerts Now in “Management Services” section of Portal Previously “Alerts” and “Operation Logs” tabs were under the “Settings” extension in the Windows Azure Management Portal.  With today’s update, we are moving these cross cutting management and monitoring functionality to a new extension in the Windows Azure Portal named “Management Services”. The goal is to increase discoverability of common management services as well as to provide better categorization of functionality that cuts across all Windows Azure services. We will continue to enrich and add to such cross cutting functionality in Windows Azure over the next few releases. Note that this change will not affect existing alert rules that were previously configured, only the location where they show up in the portal is different. Additions to Operation Logs Prior to today, you could find operation history for Cloud Services and Storage operations. With this release, we are adding additional operation history data for the following additional areas: Disk operations – add and delete Virtual Machine Disks Autoscale: Autoscale settings changes, autoscale actions Alerts SQL Backup configuration changes We’ll add to this list in later updates this year to include all other services/operations as well. Summary Today’s release includes a bunch of great features that enable you to build even better cloud solutions.  If you don’t already have a Windows Azure account, you can sign-up for a free trial and start using all of the above features today.  Then visit the Windows Azure Developer Center to learn more about how to build apps with it. Hope this helps, Scott P.S. In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu [Less]

This morning we released some major updates to Windows Azure.  These new capabilities include: SQL Server AlwaysOn Support: General Availability support with Windows Azure Virtual Machines (enables both high availability and disaster recovery) ... [More] Notification Hubs: General Availability Release of Windows Azure Notification Hubs (broadcast push for Windows 8, Windows Phone, iOS and Android) AutoScale: Schedule-based AutoScale rules and richer logging support Virtual Machines: Load Balancer Configuration and Management Management Services: New Portal Extension for Operation logs + Alerts All of these improvements are now available to use immediately (note: AutoScale is still in preview – everything else is general availability).  Below are more details about them. SQL Server AlwaysOn Support with Windows Azure Virtual Machines I’m excited to announce the general availability release of SQL Server AlwaysOn Availability Groups support within Windows Azure.  We have updated our official documentation to support Availability Group Listeners for SQL Server 2012 (and higher) on Windows Server 2012. SQL Server AlwaysOn Availability Group support, which was introduced with SQL Server 2012, is Microsoft’s premier solution for enabling high availability and disaster recovery with SQL Server.  SQL Server AlwaysOn Availability Groups support multi-database failover, multiple replicas (5 in SQL Server 2012, 9 in SQL Server 2014), readable secondary replicas (which can be used to offload reporting and BI applications), configurable failover policies, backups on secondary replicas, and easy monitoring.  Today, we are excited to announce that we support the complete SQL Server AlwaysOn Availability Groups technology stack with Windows Azure Virtual Machines - including enabling support for SQL Server Availability Group Listeners.  We are really excited to be the first cloud provider to support the full range of scenarios enabled with SQL Server AlwaysOn Availability Groups – we think they are going to enable a ton of new scenarios for customers. High Availability of SQL Servers running in Virtual Machines You can now use SQL Server AlwaysOn within Windows Azure Virtual Machines to achieve high availability and global business continuity.  As part of this support you can now deploy one or more readable database secondaries – which not only improves availability of your SQL Servers but also improves efficiency by allowing you to offload BI reporting tasks and backups to the secondary machines. Today’s Windows Azure release includes changes to better support SQL Server AlwaysOn functionality with our Windows Azure Network Load Balancers.  With today’s update you can now connect to your SQL Server deployment with a single client connection string using the Availability Group Listener endpoint.  This will automatically route database connections to the primary replica node – and our network load balancer will automatically update to route requests to a secondary replica node in the event of an automatic or manual failover scenario: This new SQL Server Availability Group Listener support enables you to easily deploy SQL Databases in Windows Azure Virtual Machines in a high-availability configuration, and take full advantage of the full SQL Server feature-set.  It can also be used to ensure no downtime during upgrade operations or when patching the virtual machines. Disaster Recovery of an on-premises SQL Server using Windows Azure In addition to enabling high availability solutions within Windows Azure, the new SQL Server AlwaysOn support can also be used to enable on-premise SQL Server solutions to be expanded to have one or more secondary replicas running in the cloud using Windows Azure Virtual Machines.  This allows companies to enable high-availability disaster recovery scenarios – where in the event of a local datacenter being down (for example: due to a hurricane or natural disaster, or simply a network HW failure on-premises) they can failover and continue operations using Virtual Machines that have been deployed in the cloud using Windows Azure. The diagram above shows a scenario where an on-premises SQL Server AlwaysOn Availability Group has been defined with a 2 database replicas - a primary and secondary replica (S1).  One more secondary replica (S2) has then been configured to run in the cloud within a Windows Azure Virtual Machine.  This secondary replica (S2) will continuously synchronize transactions from the on-premises primary replica.  In the event of a disaster on-premises, the company can failover to the replica in the cloud and continue operations without business impact.  In addition to enabling disaster recovery, the secondary replica(s) can also be used to offload reporting applications and backups. This is valuable for companies that require maintaining backups outside of the data center for compliance reasons, and enables customers to leverage the replicas for compute scenarios even in non-disaster scenarios.  Learn more about SQL Server AlwaysOn support in Windows Azure You can learn more about how to enable SQL Server AlwaysOn Support in Windows Azure by reading the High Availability and Disaster Recovery for SQL Server in Windows Azure Virtual Machines documentation.  Also review this TechEd 2013 presentation: SQL Server High Availability and Disaster Recovery on Windows Azure VMs.  We are really excited to be the first cloud provider to enable the full range of scenarios enabled with SQL Server AlwaysOn Availability Groups – we think they are going to enable a ton of new scenarios for customers. Windows Azure Notification Hubs I’m excited today to announce the general availability release of Windows Azure Notification Hubs.  Notification Hubs enable you to instantly send personalized, cross-platform, broadcast push notifications to millions of Windows 8, Windows Phone 8, iOS, and Android mobile devices.  I first blogged about Notification Hubs starting with the initial preview of Notification Hubs in January.  Since the initial preview, we have added many new features (including adding support for Android and Windows Phone devices in addition to Windows 8 and iOS ones) and validated that the system is ready for any amount of scale that your next app requires. You can use Notification Hubs from both Windows Azure Mobile Services or any other custom Mobile Backend you have already built (including non-Azure hosted ones) – which makes it really easy to start taking advantage of from any existing app. Notification Hubs: Personalized cross platform broadcast push at scale Push notifications are a vital component of mobile applications.  They’re the most powerful customer engagement mechanism available to mobile app developers.  Sending a single push notification message to one mobile user is relatively straight forward (and is already easy to-do with Windows Azure Mobile Services today).  But sending simultaneous push notifications in a low-latency way to millions of mobile users, and handling real world requirements such as localization, multiple platform devices, and user personalization is much harder. Windows Azure Notification Hubs provide you with an extremely scalable push notification infrastructure that helps you efficiently route cross-platform, personalized push notification messages to millions of users: Cross-platform. With a single API call using Notification Hubs, your app’s backend can send push notifications to your users running on Windows Store, Windows Phone 8, iOS, or Android devices. Highly personalized. Notification Hubs' built-in templating functionality allows you to let the client chose the shape, format and locale of the notifications it wants to see, while keep your backend code platform independent and really clean. Device token management. Notification Hubs relieves your backend from the need to store and manage channel URIs and device tokens used by Platform Notification Services (WNS, MPNS, Apple PNS, or Google Cloud Messaging Service). We securely handle the PNS feedback, device token expiry, etc. for you. Efficient tag-based multicast and pub/sub routing. Clients can specify one or more tags when registering with a Notification Hub thereby expressing user interest in notifications for a set of topics (favorite sport/teams, geo location, stock symbol, logical user ID, etc.). These tags do not need to be pre-provisioned or disposed, and provide a very easy way for apps to send targeted notifications to millions of users/devices with a single API call, without you having to implement your own per-user notification routing infrastructure. Extreme scale. Notification Hubs are optimized to enable push notification broadcast to thousands or millions of devices with low latency. Your server back-end can fire one message into a Notification Hub, and thousands/millions of push notifications can automatically be delivered to your users, without you having to re-architect or shard your application. Usable from any backend. Notification Hubs can be easily integrated into any back-end server app using .NET or Node.js SDK, or easy-to-use REST APIs. It works seamlessly with apps built with Windows Azure Mobile Services. It can also be used by server apps hosted within IaaS Virtual Machines (either Windows or Linux), Cloud Services or Web-Sites. Bing News: Using Windows Azure Notification Hubs to Deliver Breaking News to Millions of Devices A number of big apps started using Windows Azure Notification Hubs even before today’s General Availability Release.  One of them is the Bing News app included on all Windows 8 and Windows Phone 8 devices. The Bing News app needs the ability to notify their users of breaking news in an instant. This can be a daunting task for a few reasons: Extreme scale: Every Windows 8 user has the News app installed, and the Bing backend needs to deliver hundreds of millions of breaking news notifications to them every month Topic-based multicast: Broadcasting push notifications to different markets, based on interests of individual users, requires efficient pub sub routing and topic-based multicast logic Cross-platform delivery: Notification formats and semantics vary between mobile platforms, and tracking channels/tokens across them all can be complicated Windows Azure Notification Hubs turned out to be a perfect fit for Bing News, and with the most recent update of the Bing News app they now use Notification Hubs to deliver push notifications to millions of Windows and Windows Phone devices every day. The Bing News app on the client obtains the appropriate ChannelURIs from the Windows Notification Service (WNS) and the Microsoft Push Notification Service (MPNS), for the Windows 8 and Windows versions respectively, and then registers them with a Windows Azure Notification Hub . When a breaking news alert for a particular market has to be delivered, the Bing News app uses the Notification Hubs to instantly broadcast appropriate messages to all the individual devices.  With a single REST call to the Notification Hub they can automatically filter the customers interested in the topic area (e.g. sports update) and instantly deliver the message to millions of customers: Windows Azure handles all of the complex pub/sub filtering logic for them, and efficiently handles deliver of the messages in a low-latency way. Create your first Notification Hubs Today Notification Hubs support a free tier of usage that allows you to send 100,000 operations every month to 500 registered devices at no cost – which makes it really easy to get started.  To create a new Notification Hub simply choose  New->App Services->Service Bus->Notification Hub within the Windows Azure Management Portal: Creating a new Notification Hub takes less than a minute, and once created you can drill into it to see a dashboard view of activity with it.  Among other things, the dashboard allows you to see how many devices have been registered with it, how many messages have been pushed to it, how many messages have been successfully delivered via it, and how many have failed: Once your hub is created, click the “Configure” tab to enter your app credentials for the various push notifications services (Windows Store/Phone, iOS, and Android) that your Notification Hub will coordinate with: And with that your notification hub is ready to go! Registering Devices and Sending out Broadcast Notifications Now that a Notification Hub is created, we’ll want to register device apps with it.  Doing this is really easy – we have device SDKs for Windows 8, Windows Phone 8, Android, and iOS.  Below is the code you would write within a C# Windows 8 client app to register a user’s interest in broadcast notifications sent to the “myTag” or “myOtherTags” tags/topics: await hub.RegisterNativeAsync(channel.Uri, new string[] { "myTag", "myOtherTag" }); Once a device is registered, it will automatically receive a push notification message when your app backend sends a message to topics/tags it is registered with.   You can use Notification Hubs from a Windows Azure Mobile Service, a custom .NET back-end app, or any other app back-end with our Node.js SDK or REST API.  The below code illustrates how to send a message to the Notification Hub from a custom .NET backend using the .NET SDK: var toast = @"<toast><visual><binding template=""ToastText01""><text id=""1"">Hello everybody!</text></binding></visual></toast>"; await hub.SendWindowsNativeNotificationAsync(toast); A single call like the one above from your app backend will now securely deliver the message to any number of devices registered with your Notification Hub.  The Notification Hub will handle all of the details of the delivery irrespective of how many users you are sending it to (even if there are 10s of millions of them).  Scaling and Monitoring your Notification Hub Once you’ve built your app, you can easily scale it to millions of users directly from the Windows Azure management portal.  Just click the “scale” tab in your Notification Hub within the management portal to configure the number of devices and messages you want to support: In addition to scaling capacity, you can also monitor and track nearly 50 different metrics about your notifications and their delivery to your customers: Learn More about Notification Hubs Learn more about Notification Hubs using the Notification Hubs service page, where you will find video tutorials, in-depth scenario guidance, and link to SDK references. We are happy to continue offering Notification Hubs at no charge to all Windows Azure subscribers through September 30, 2013.  We will begin billing for Notification Hubs consumption in the Basic and Standard tiers on October 1, 2013.  A Free Tier will continue to also be available and supports 100,000 notifications with 500 registered devices each month at no cost. AutoScale: Scheduled AutoScale Rules and Richer Logging This summer we introduced new AutoScale support to Windows Azure that enables you to automatically scale Web Sites, Cloud Services, Mobile Services and Virtual Machines.  AutoScale enables you to configure Windows Azure to automatically scale your application dynamically on your behalf (without any manual intervention required) so that you can achieve the ideal performance and cost balance. Once configured, AutoScale will regularly adjust the number of instances running in response to the load in your application. Today, we are introducing even more AutoScale features – including the ability to proactively adjust your Cloud Service instance count using time scheduled rules. Schedule AutoScale Rules If you click on the Scale tab of a Cloud Service, you’ll see that we’ve now added support for you to configure/control different scaling rules based on schedule rules. By default, you’ll edit scale settings for No scheduled times – this means that your scale settings will always be the same regardless of the time/day. You can scale manually by selecting None in the Scale by Metric section – this will give you the traditional Instance Count slider that you are familiar with: Or you can AutoScale dynamically by reacting to CPU activity or Queue Depth.  The below screen-shot demonstrates configuring an auto-scale rule based on the CPU of the WebTier role and indicates to scale between 1 and 3 instances – depending on the aggregate CPU: With today’s release, we also now allow you to setup different scale settings for different times of the day.  You can enable this by clicking the “Set up Schedule Times” button above.  This brings up a new dialog: With today’s release we now offer the ability to define two different recurring schedules: Day and Night. The first schedule, Day Time, runs from the start of the day to the end of the day (which I’ve defined above as being between 8am and 8pm). The second schedule, Night Time, runs from the end of one day to the start of the next day. Both use the options in Time to define start and end of a day, and the time zone. This schedule respects daylight savings time, if it is applicable to that timezone. In the future we will add other types of time based schedules as well. Once you’ve setup a day/night schedule, you can return to the Scale page and see that the schedule dropdown now has the two schedules you created populated within it: You can now select each schedule from the list and edit scaling rules specific to it within it. For example, you can select the Day Time Schedule and set Instance Count on a Cloud Service role to 5, and then select Night Time and set Instance Count to 3.  This will ensure that Windows Azure scales up your service to 5 instances during the day, and then cycles them down to 3 instances overnight. You can also combine Scheduled Autoscale rules and the Metric Based AutoScale rules together.  Select the CPU or Queue toggle and you can configure AutoScale rules that apply differently during the day or night. For example, you could set the Instance Range from 5 to 10 during the day, and 3 to 6 at night based on CPU activity. Today’s release only supports Scheduled AutoScale rules on Cloud Services – but you’ll see us enable these with all types of compute resources (including Web Sites, Mobile Services + VMs) shortly. AutoScale History It’s now easy to know and log exactly what AutoScale has done for your service: there are four new AutoScale history features with today’s release to help with this. First, we have added two new operations to Windows Azure’s Operation Log capability: AutoscaleAction and PutAutoscaleSetting. We now record each time that AutoScale takes a scale up or scale down action, and include the new and previous instance counts in the details. In addition, we record each time anyone changes autoscale settings – you can use this to see who on your team changed autoscale options and when.  These are both now exposed in the Operation Logs tab of the new Management Services node within the Windows Azure Management Portal: For Cloud Services, we are also adding a historical graph that shows of the number of instances over the past 7 days. This way, you can see trends in AutoScale over the span of a week: Third, if AutoScale ever fails for more than 2 hours at a time, we will automatically notify the Service Administrator and Co-Admin of the subscription via email: Fourth, if you are the Account Administrator for your subscription, we will now show you billing information about Autoscale in your account’s currency: If AutoScale is on, it will show you the difference between your current instance count, and the maximum instance count – and how much you are saving by using it. If AutoScale is off, we will show you how much we predict you could save if you were to turn on AutoScale.  Put another way - we are updating your bill to include suggestions on how you can pay us less in the future (please don’t tell my boss about this… <g>) Virtual Machines: Support for Configuring Load Balancer Probes Every Virtual Machine, Cloud Service, Web Site and Mobile Service you deploy in Windows Azure comes with built-in load balancer support that you can use to both scale out your app and enable high availability.  This load balancer support is built-into Windows Azure and included at no extra charge (most other cloud providers make you pay extra for it). Today’s update of Windows Azure includes some nice new features that make it even easier to configure and manage load balancing support for Virtual Machines – and includes support for customizing the network probe logic that our load balancers use to determine whether your Virtual Machines are healthy and should be kept in the load balancer rotation. Understanding Load Balancer Probes Load-balancing network traffic across multiple Virtual Machine instances is important, both to enable scale-out of your traffic across multiple VMs, as well as to enable high availability of your app’s front-end or back-end virtual machines (as discussed in the SQL Server AlwaysOn section earlier). A network probe is how the Windows Azure load balancer detects failure of one or more of your virtual machine instances - whether due to software or hardware failure.  If the network probe detects there is an issue with a specific virtual machine instance it will automatically failover traffic to your healthy virtual machine instances, and prevent customers thinking your application is down. The default configuration for a network probe from the Windows Azure load balancer is simply using TCP on the same port your application is load-balancing.  As shown in the below example, each Virtual Machine in a load-balanced set is receiving TCP traffic on port 80 from the public internet (likely a website or web service). With a simple TCP probe, the load-balancer sends an ongoing message, every 15 seconds by default, on that same port to each Virtual Machine, checking for health. Because the Virtual Machine is running a website, if the Virtual Machine and web service is healthy, it will automatically reply back to the TCP probe with a simple ACK to the load balancer. While this ACK continues, the load-balancer will continue to send traffic, knowing the website is responsive.  In any situation where the website is unhealthy, the load balancer will not receive a response from the website.  When this happens the load balancer will stop sending traffic to the virtual machine that is having problems, and instead direct traffic to the other two instances, as shown for Virtual Machine 2 below. This simple high availability option will work without having to write any special code inside the VM to respond to the network probes and can protect you from failure due to the application, the virtual machine, or the underlying hardware (note: if Windows Azure detects a hardware failure we’ll automatically migrate your Virtual Machine instance to a new server).   Windows Azure allows you to configure both the time interval for sending each network probe (15 seconds is the default) and the number of probe attempts that must fail before the load balancer takes the instance offline (the default is 2). Thus, with the defaults, after 30 seconds of receiving no response from a web service, the load balancer will consider it unresponsive and stop sending traffic to it until a healthy response is received later (15 seconds per probe * 2 probes). You can also now configure custom HTTP probes – which is a more advanced option. With HTTP probes, you can configure the load balancer’s network probe request to be sent to a separate network port than the one you are load-balancing (and this port does not have to be open to the Internet – the recommendation is for it to be a private port that only the load balancer can access). This will require your service or application to be listening on this separate port and respond to the probe request, based upon the health of the application. With HTTP probes, the load balancer will continue to send traffic to your Virtual Machine if it receives an HTTP 200 OK response from the network probe request. Similar to the above TCP intervals, with the defaults, when a Virtual Machine does not respond with an HTTP 200 OK after 30 seconds (2 x 15 second probes), the load balancer will automatically take the machine out of traffic rotation until hearing a 200 OK back on the next probe. This advanced option does require the creation of code to listen and respond on a separate port, but gives you a lot more control over traffic being delivered to your service: Configuring Load Balancer Probe Settings Before today’s release, configuring custom network probe settings used to require you to use PowerShell, our Cross Platform CLI tools, or write code against our REST Management API.  With today’s Windows Azure release we’ve added support to configure these settings using the Windows Azure Management Portal as well.  You can configure load-balanced sets for new or existing endpoints on your virtual machines.  You can do this by adding or editing an endpoint on a Virtual Machine.  To do this with an existing Virtual Machine, select the VM within the portal and navigate to the Endpoints tab within it.  Then add or edit the endpoint you want to open to external callers: The Edit Endpoint dialog allows you to view or change a port that is open to the Internet (and existed before today’s release):  Selecting the “Create Load-Balanced Set” or “Reconfigure the Load-Balanced Set” checkbox within the dialog above will now allow you to proceed to another page within the wizard that surfaces the load balanced set and network probe properties: Using the screen above you can now change the network probe settings to be either TCP or HTTP based, configure which internal port you wish to probe on (if you want your network probe to be private and different than the port you use to serve public traffic), configure the probe interval (default is every 15 seconds), as well as configure the number of times the network probe is allowed to fail before the machine is automatically removed from network rotation (default is 2 failures). Identifying Network Probe Problems In addition to allowing you to create/edit the network probe settings, today’s Windows Azure Management Portal release also now surfaces cases where network probes are misconfigured or having problems.  For example, if during the Virtual Machine Preview you created a VM and configured a load-balanced sets prior to probes being a required configuration item, we will show an error icon that indicates missing probe configuration under the load-balanced set name column to indicate that the load-balanced set is not configured correctly: Operation Logs and Alerts Now in “Management Services” section of Portal Previously “Alerts” and “Operation Logs” tabs were under the “Settings” extension in the Windows Azure Management Portal.  With today’s update, we are moving these cross cutting management and monitoring functionality to a new extension in the Windows Azure Portal named “Management Services”. The goal is to increase discoverability of common management services as well as to provide better categorization of functionality that cuts across all Windows Azure services. We will continue to enrich and add to such cross cutting functionality in Windows Azure over the next few releases. Note that this change will not affect existing alert rules that were previously configured, only the location where they show up in the portal is different. Additions to Operation Logs Prior to today, you could find operation history for Cloud Services and Storage operations. With this release, we are adding additional operation history data for the following additional areas: Disk operations – add and delete Virtual Machine Disks Autoscale: Autoscale settings changes, autoscale actions Alerts SQL Backup configuration changes We’ll add to this list in later updates this year to include all other services/operations as well. Summary Today’s release includes a bunch of great features that enable you to build even better cloud solutions.  If you don’t already have a Windows Azure account, you can sign-up for a free trial and start using all of the above features today.  Then visit the Windows Azure Developer Center to learn more about how to build apps with it. Hope this helps, Scott P.S. In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu [Less]

Today we released the v2.1 update of the Windows Azure SDK for .NET.  This is a major refresh of the Windows Azure SDK and it includes some great new features and enhancements. These new capabilities include: Visual Studio 2013 Preview Support: ... [More] The Windows Azure SDK now supports using the new VS 2013 Preview Visual Studio 2013 VM Image: Windows Azure now has a built-in VM image that you can use to host and develop with VS 2013 in the cloud Visual Studio Server Explorer Enhancements: Redesigned with improved filtering and auto-loading of subscription resources Virtual Machines: Start and Stop VM’s w/suspend billing directly from within Visual Studio Cloud Services: New Emulator Express option with reduced footprint and Run as Normal User support Service Bus: New high availability options, Notification Hub support, Improved VS tooling PowerShell Automation: Lots of new PowerShell commands for automating Web Sites, Cloud Services, VMs and more All of these SDK enhancements are now available to start using immediately and you can download the SDK from the Windows Azure .NET Developer Center.  Visual Studio’s Team Foundation Service (http://tfs.visualstudio.com/) has also been updated to support today’s SDK 2.1 release, and the SDK 2.1 features can now be used with it (including with automated builds + tests). Below are more details on the new features and capabilities released today: Visual Studio 2013 Preview Support Today’s Window Azure SDK 2.1 release adds support for the recent Visual Studio 2013 Preview. The 2.1 SDK also works with Visual Studio 2010 and Visual Studio 2012, and works side by side with the previous Windows Azure SDK 1.8 and 2.0 releases. To install the Windows Azure SDK 2.1 on your local computer, choose the “install the sdk” link from the Windows Azure .NET Developer Center. Then, chose which version of Visual Studio you want to use it with.  Clicking the third link will install the SDK with the latest VS 2013 Preview: If you don’t already have the Visual Studio 2013 Preview installed on your machine, this will also install Visual Studio Express 2013 Preview for Web. Visual Studio 2013 VM Image Hosted in the Cloud One of the requests we’ve heard from several customers has been to have the ability to host Visual Studio within the cloud (avoiding the need to install anything locally on your computer). With today’s SDK update we’ve added a new VM image to the Windows Azure VM Gallery that has Visual Studio Ultimate 2013 Preview, SharePoint 2013, SQL Server 2012 Express and the Windows Azure 2.1 SDK already installed on it.  This provides a really easy way to create a development environment in the cloud with the latest tools. With the recent shutdown and suspend billing feature we shipped on Windows Azure last month, you can spin up the image only when you want to do active development, and then shut down the virtual machine and not have to worry about usage charges while the virtual machine is not in use. You can create your own VS image in the cloud by using the New->Compute->Virtual Machine->From Gallery menu within the Windows Azure Management Portal, and then by selecting the “Visual Studio Ultimate 2013 Preview” template: Visual Studio Server Explorer: Improved Filtering/Management of Subscription Resources With the Windows Azure SDK 2.1 release you’ll notice significant improvements in the Visual Studio Server Explorer. The explorer has been redesigned so that all Windows Azure services are now contained under a single Windows Azure node.  From the top level node you can now manage your Windows Azure credentials, import a subscription file or filter Server Explorer to only show services from particular subscriptions or regions. Note: The Web Sites and Mobile Services nodes will appear outside the Windows Azure Node until the final release of VS 2013. If you have installed the ASP.NET and Web Tools Preview Refresh, though, the Web Sites node will appear inside the Windows Azure node even with the VS 2013 Preview. Once your subscription information is added, Windows Azure services from all your subscriptions are automatically enumerated in the Server Explorer. You no longer need to manually add services to Server Explorer individually. This provides a convenient way of viewing all of your cloud services, storage accounts, service bus namespaces, virtual machines, and web sites from one location: Subscription and Region Filtering Support Using the Windows Azure node in Server Explorer, you can also now filter your Windows Azure services in the Server Explorer by the subscription or region they are in.  If you have multiple subscriptions but need to focus your attention to just a few subscription for some period of time, this a handy way to hide the services from other subscriptions view until they become relevant. You can do the same sort of filtering by region. To enable this, just select “Filter Services” from the context menu on the Windows Azure node: Then choose the subscriptions and/or regions you want to filter by. In the below example, I’ve decided to show services from my pay-as-you-go subscription within the East US region: Visual Studio will then automatically filter the items that show up in the Server Explorer appropriately: With storage accounts and service bus namespaces, you sometimes need to work with services outside your subscription. To accommodate that scenario, those services allow you to attach an external account (from the context menu). You’ll notice that external accounts have a slightly different icon in server explorer to indicate they are from outside your subscription. Other Improvements We’ve also improved the Server Explorer by adding additional properties and actions to the service exposed. You now have access to most of the properties on a cloud service, deployment slot, role or role instance as well as the properties on storage accounts, virtual machines and web sites. Just select the object of interest in Server Explorer and view the properties in the property pane. We also now have full support for creating/deleting/update storage tables, blobs and queues from directly within Server Explorer.  Simply right-click on the appropriate storage account node and you can create them directly within Visual Studio: Virtual Machines: Start/Stop within Visual Studio Virtual Machines now have context menu actions that allow you start, shutdown, restart and delete a Virtual Machine directly within the Visual Studio Server Explorer. The shutdown action enables you to shut down the virtual machine and suspend billing when the VM is not is use, and easily restart it when you need it: This is especially useful in Dev/Test scenarios where you can start a VM – such as a SQL Server – during your development session and then shut it down / suspend billing when you are not developing (and no longer be billed for it). You can also now directly remote desktop into VMs using the “Connect using Remote Desktop” context menu command in VS Server Explorer.  Cloud Services: Emulator Express with Run as Normal User Support You can now launch Visual Studio and run your cloud services locally as a Normal User (without having to elevate to an administrator account) using a new Emulator Express option included as a preview feature with this SDK release.  Emulator Express is a version of the Windows Azure Compute Emulator that runs a restricted mode – one instance per role – and it doesn’t require administrative permissions and uses 40% less resources than the full Windows Azure Emulator. Emulator Express supports both web and worker roles. To run your application locally using the Emulator Express option, simply change the following settings in the Windows Azure project. On the shortcut menu for the Windows Azure project, choose Properties, and then choose the Web tab. Check the setting for IIS (Internet Information Services). Make sure that the option is set to IIS Express, not the full version of IIS. Emulator Express is not compatible with full IIS. On the Web tab, choose the option for Emulator Express. Service Bus: Notification Hubs With the Windows Azure SDK 2.1 release we are adding support for Windows Azure Notification Hubs as part of our official Windows Azure SDK, inside of Microsoft.ServiceBus.dll (previously the Notification Hub functionality was in a preview assembly). You are now able to create, update and delete Notification Hubs programmatically, manage your device registrations, and send push notifications to all your mobile clients across all platforms (Windows Store, Windows Phone 8, iOS, and Android). Learn more about Notification Hubs on MSDN here, or watch the Notification Hubs //BUILD/ presentation here. Service Bus: Paired Namespaces One of the new features included with today’s Windows Azure SDK 2.1 release is support for Service Bus “Paired Namespaces”.  Paired Namespaces enable you to better handle situations where a Service Bus service namespace becomes unavailable (for example: due to connectivity issues or an outage) and you are unable to send or receive messages to the namespace hosting the queue, topic, or subscription. Previously,to handle this scenario you had to manually setup separate namespaces that can act as a backup, then implement manual failover and retry logic which was sometimes tricky to get right. Service Bus now supports Paired Namespaces, which enables you to connect two namespaces together. When you activate the secondary namespace, messages are stored in the secondary queue for delivery to the primary queue at a later time. If the primary container (namespace) becomes unavailable for some reason, automatic failover enables the messages in the secondary queue. For detailed information about paired namespaces and high availability, see the new topic Asynchronous Messaging Patterns and High Availability. Service Bus: Tooling Improvements In this release, the Windows Azure Tools for Visual Studio contain several enhancements and changes to the management of Service Bus messaging entities using Visual Studio’s Server Explorer. The most noticeable change is that the Service Bus node is now integrated into the Windows Azure node, and supports integrated subscription management. Additionally, there has been a change to the code generated by the Windows Azure Worker Role with Service Bus Queue project template. This code now uses an event-driven “message pump” programming model using the QueueClient.OnMessage method. PowerShell: Tons of New Automation Commands Since my last blog post on the previous Windows Azure SDK 2.0 release, we’ve updated Windows Azure PowerShell (which is a separate download) five times. You can find the full change log here. We’ve added new cmdlets in the following areas: China instance and Windows Azure Pack support Environment Configuration VMs Cloud Services Web Sites Storage SQL Azure Service Bus China Instance and Windows Azure Pack We now support the following cmdlets for the China instance and Windows Azure Pack, respectively: China Instance: Web Sites, Service Bus, Storage, Cloud Service, VMs, Network Windows Azure Pack: Web Sites, Service Bus We will have full cmdlet support for these two Windows Azure environments in PowerShell in the near future. Virtual Machines: Stop/Start Virtual Machines Similar to the Start/Stop VM capability in VS Server Explorer, you can now stop your VM and suspend billing: If you want to keep the original behavior of keeping your stopped VM provisioned, you can pass in the -StayProvisioned switch parameter. Virtual Machines: VM endpoint ACLs We’ve added and updated a bunch of cmdlets for you to configure fine-grained network ACL on your VM endpoints. You can use the following cmdlets to create ACL config and apply them to a VM endpoint: New-AzureAclConfig Get-AzureAclConfig Set-AzureAclConfig Remove-AzureAclConfig Add-AzureEndpoint -ACL Set-AzureEndpoint –ACL The following example shows how to add an ACL rule to an existing endpoint of a VM. Other improvements for Virtual Machine management includes Added -NoWinRMEndpoint parameter to New-AzureQuickVM and Add-AzureProvisioningConfig to disable Windows Remote Management Added -DirectServerReturn parameter to Add-AzureEndpoint and Set-AzureEndpoint to enable/disable direct server return Added Set-AzureLoadBalancedEndpoint cmdlet to modify load balanced endpoints Cloud Services: Remote Desktop and Diagnostics Remote Desktop and Diagnostics are popular debugging options for Cloud Services. We’ve introduced cmdlets to help you configure these two Cloud Service extensions from Windows Azure PowerShell. Windows Azure Cloud Services Remote Desktop extension: New-AzureServiceRemoteDesktopExtensionConfig Get-AzureServiceRemoteDesktopExtension Set-AzureServiceRemoteDesktopExtension Remove-AzureServiceRemoteDesktopExtension Windows Azure Cloud Services Diagnostics extension New-AzureServiceDiagnosticsExtensionConfig Get-AzureServiceDiagnosticsExtension Set-AzureServiceDiagnosticsExtension Remove-AzureServiceDiagnosticsExtension The following example shows how to enable Remote Desktop for a Cloud Service. Web Sites: Diagnostics With our last SDK update, we introduced the Get-AzureWebsiteLog –Tail cmdlet to get the log streaming of your Web Sites. Recently, we’ve also added cmdlets to configure Web Site application diagnostics: Enable-AzureWebsiteApplicationDiagnostic Disable-AzureWebsiteApplicationDiagnostic The following 2 examples show how to enable application diagnostics to the file system and a Windows Azure Storage Table: SQL Database Previously, you had to know the SQL Database server admin username and password if you want to manage the database in that SQL Database server. Recently, we’ve made the experience much easier by not requiring the admin credential if the database server is in your subscription. So you can simply specify the -ServerName parameter to tell Windows Azure PowerShell which server you want to use for the following cmdlets. Get-AzureSqlDatabase New-AzureSqlDatabase Remove-AzureSqlDatabase Set-AzureSqlDatabase We’ve also added a -AllowAllAzureServices parameter to New-AzureSqlDatabaseServerFirewallRule so that you can easily add a firewall rule to whitelist all Windows Azure IP addresses. Besides the above experience improvements, we’ve also added cmdlets get the database server quota and set the database service objective. Check out the following cmdlets for details. Get-AzureSqlDatabaseServerQuota Get-AzureSqlDatabaseServiceObjective Set-AzureSqlDatabase –ServiceObjective Storage and Service Bus Other new cmdlets include Storage: CRUD cmdlets for Azure Tables and Queues Service Bus: Cmdlets for managing authorization rules on your Service Bus Namespace, Queue, Topic, Relay and NotificationHub Summary Today’s release includes a bunch of great features that enable you to build even better cloud solutions.  All the above features/enhancements are shipped and available to use immediately as part of the 2.1 release of the Windows Azure SDK for .NET. If you don’t already have a Windows Azure account, you can sign-up for a free trial and start using all of the above features today.  Then visit the Windows Azure Developer Center to learn more about how to build apps with it. Hope this helps, Scott P.S. In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu [Less]

Today we released the v2.1 update of the Windows Azure SDK for .NET.  This is a major refresh of the Windows Azure SDK and it includes some great new features and enhancements. These new capabilities include: Visual Studio 2013 Preview Support: ... [More] The Windows Azure SDK now supports using the new VS 2013 Preview Visual Studio 2013 VM Image: Windows Azure now has a built-in VM image that you can use to host and develop with VS 2013 in the cloud Visual Studio Server Explorer Enhancements: Redesigned with improved filtering and auto-loading of subscription resources Virtual Machines: Start and Stop VM’s w/suspend billing directly from within Visual Studio Cloud Services: New Emulator Express option with reduced footprint and Run as Normal User support Service Bus: New high availability options, Notification Hub support, Improved VS tooling PowerShell Automation: Lots of new PowerShell commands for automating Web Sites, Cloud Services, VMs and more All of these SDK enhancements are now available to start using immediately and you can download the SDK from the Windows Azure .NET Developer Center.  Visual Studio’s Team Foundation Service (http://tfs.visualstudio.com/) has also been updated to support today’s SDK 2.1 release, and the SDK 2.1 features can now be used with it (including with automated builds + tests). Below are more details on the new features and capabilities released today: Visual Studio 2013 Preview Support Today’s Window Azure SDK 2.1 release adds support for the recent Visual Studio 2013 Preview. The 2.1 SDK also works with Visual Studio 2010 and Visual Studio 2012, and works side by side with the previous Windows Azure SDK 1.8 and 2.0 releases. To install the Windows Azure SDK 2.1 on your local computer, choose the “install the sdk” link from the Windows Azure .NET Developer Center. Then, chose which version of Visual Studio you want to use it with.  Clicking the third link will install the SDK with the latest VS 2013 Preview: If you don’t already have the Visual Studio 2013 Preview installed on your machine, this will also install Visual Studio Express 2013 Preview for Web. Visual Studio 2013 VM Image Hosted in the Cloud One of the requests we’ve heard from several customers has been to have the ability to host Visual Studio within the cloud (avoiding the need to install anything locally on your computer). With today’s SDK update we’ve added a new VM image to the Windows Azure VM Gallery that has Visual Studio Ultimate 2013 Preview, SharePoint 2013, SQL Server 2012 Express and the Windows Azure 2.1 SDK already installed on it.  This provides a really easy way to create a development environment in the cloud with the latest tools. With the recent shutdown and suspend billing feature we shipped on Windows Azure last month, you can spin up the image only when you want to do active development, and then shut down the virtual machine and not have to worry about usage charges while the virtual machine is not in use. You can create your own VS image in the cloud by using the New->Compute->Virtual Machine->From Gallery menu within the Windows Azure Management Portal, and then by selecting the “Visual Studio Ultimate 2013 Preview” template: Visual Studio Server Explorer: Improved Filtering/Management of Subscription Resources With the Windows Azure SDK 2.1 release you’ll notice significant improvements in the Visual Studio Server Explorer. The explorer has been redesigned so that all Windows Azure services are now contained under a single Windows Azure node.  From the top level node you can now manage your Windows Azure credentials, import a subscription file or filter Server Explorer to only show services from particular subscriptions or regions. Note: The Web Sites and Mobile Services nodes will appear outside the Windows Azure Node until the final release of VS 2013. If you have installed the ASP.NET and Web Tools Preview Refresh, though, the Web Sites node will appear inside the Windows Azure node even with the VS 2013 Preview. Once your subscription information is added, Windows Azure services from all your subscriptions are automatically enumerated in the Server Explorer. You no longer need to manually add services to Server Explorer individually. This provides a convenient way of viewing all of your cloud services, storage accounts, service bus namespaces, virtual machines, and web sites from one location: Subscription and Region Filtering Support Using the Windows Azure node in Server Explorer, you can also now filter your Windows Azure services in the Server Explorer by the subscription or region they are in.  If you have multiple subscriptions but need to focus your attention to just a few subscription for some period of time, this a handy way to hide the services from other subscriptions view until they become relevant. You can do the same sort of filtering by region. To enable this, just select “Filter Services” from the context menu on the Windows Azure node: Then choose the subscriptions and/or regions you want to filter by. In the below example, I’ve decided to show services from my pay-as-you-go subscription within the East US region: Visual Studio will then automatically filter the items that show up in the Server Explorer appropriately: With storage accounts and service bus namespaces, you sometimes need to work with services outside your subscription. To accommodate that scenario, those services allow you to attach an external account (from the context menu). You’ll notice that external accounts have a slightly different icon in server explorer to indicate they are from outside your subscription. Other Improvements We’ve also improved the Server Explorer by adding additional properties and actions to the service exposed. You now have access to most of the properties on a cloud service, deployment slot, role or role instance as well as the properties on storage accounts, virtual machines and web sites. Just select the object of interest in Server Explorer and view the properties in the property pane. We also now have full support for creating/deleting/update storage tables, blobs and queues from directly within Server Explorer.  Simply right-click on the appropriate storage account node and you can create them directly within Visual Studio: Virtual Machines: Start/Stop within Visual Studio Virtual Machines now have context menu actions that allow you start, shutdown, restart and delete a Virtual Machine directly within the Visual Studio Server Explorer. The shutdown action enables you to shut down the virtual machine and suspend billing when the VM is not is use, and easily restart it when you need it: This is especially useful in Dev/Test scenarios where you can start a VM – such as a SQL Server – during your development session and then shut it down / suspend billing when you are not developing (and no longer be billed for it). You can also now directly remote desktop into VMs using the “Connect using Remote Desktop” context menu command in VS Server Explorer.  Cloud Services: Emulator Express with Run as Normal User Support You can now launch Visual Studio and run your cloud services locally as a Normal User (without having to elevate to an administrator account) using a new Emulator Express option included as a preview feature with this SDK release.  Emulator Express is a version of the Windows Azure Compute Emulator that runs a restricted mode – one instance per role – and it doesn’t require administrative permissions and uses 40% less resources than the full Windows Azure Emulator. Emulator Express supports both web and worker roles. To run your application locally using the Emulator Express option, simply change the following settings in the Windows Azure project. On the shortcut menu for the Windows Azure project, choose Properties, and then choose the Web tab. Check the setting for IIS (Internet Information Services). Make sure that the option is set to IIS Express, not the full version of IIS. Emulator Express is not compatible with full IIS. On the Web tab, choose the option for Emulator Express. Service Bus: Notification Hubs With the Windows Azure SDK 2.1 release we are adding support for Windows Azure Notification Hubs as part of our official Windows Azure SDK, inside of Microsoft.ServiceBus.dll (previously the Notification Hub functionality was in a preview assembly). You are now able to create, update and delete Notification Hubs programmatically, manage your device registrations, and send push notifications to all your mobile clients across all platforms (Windows Store, Windows Phone 8, iOS, and Android). Learn more about Notification Hubs on MSDN here, or watch the Notification Hubs //BUILD/ presentation here. Service Bus: Paired Namespaces One of the new features included with today’s Windows Azure SDK 2.1 release is support for Service Bus “Paired Namespaces”.  Paired Namespaces enable you to better handle situations where a Service Bus service namespace becomes unavailable (for example: due to connectivity issues or an outage) and you are unable to send or receive messages to the namespace hosting the queue, topic, or subscription. Previously,to handle this scenario you had to manually setup separate namespaces that can act as a backup, then implement manual failover and retry logic which was sometimes tricky to get right. Service Bus now supports Paired Namespaces, which enables you to connect two namespaces together. When you activate the secondary namespace, messages are stored in the secondary queue for delivery to the primary queue at a later time. If the primary container (namespace) becomes unavailable for some reason, automatic failover enables the messages in the secondary queue. For detailed information about paired namespaces and high availability, see the new topic Asynchronous Messaging Patterns and High Availability. Service Bus: Tooling Improvements In this release, the Windows Azure Tools for Visual Studio contain several enhancements and changes to the management of Service Bus messaging entities using Visual Studio’s Server Explorer. The most noticeable change is that the Service Bus node is now integrated into the Windows Azure node, and supports integrated subscription management. Additionally, there has been a change to the code generated by the Windows Azure Worker Role with Service Bus Queue project template. This code now uses an event-driven “message pump” programming model using the QueueClient.OnMessage method. PowerShell: Tons of New Automation Commands Since my last blog post on the previous Windows Azure SDK 2.0 release, we’ve updated Windows Azure PowerShell (which is a separate download) five times. You can find the full change log here. We’ve added new cmdlets in the following areas: China instance and Windows Azure Pack support Environment Configuration VMs Cloud Services Web Sites Storage SQL Azure Service Bus China Instance and Windows Azure Pack We now support the following cmdlets for the China instance and Windows Azure Pack, respectively: China Instance: Web Sites, Service Bus, Storage, Cloud Service, VMs, Network Windows Azure Pack: Web Sites, Service Bus We will have full cmdlet support for these two Windows Azure environments in PowerShell in the near future. Virtual Machines: Stop/Start Virtual Machines Similar to the Start/Stop VM capability in VS Server Explorer, you can now stop your VM and suspend billing: If you want to keep the original behavior of keeping your stopped VM provisioned, you can pass in the -StayProvisioned switch parameter. Virtual Machines: VM endpoint ACLs We’ve added and updated a bunch of cmdlets for you to configure fine-grained network ACL on your VM endpoints. You can use the following cmdlets to create ACL config and apply them to a VM endpoint: New-AzureAclConfig Get-AzureAclConfig Set-AzureAclConfig Remove-AzureAclConfig Add-AzureEndpoint -ACL Set-AzureEndpoint –ACL The following example shows how to add an ACL rule to an existing endpoint of a VM. Other improvements for Virtual Machine management includes Added -NoWinRMEndpoint parameter to New-AzureQuickVM and Add-AzureProvisioningConfig to disable Windows Remote Management Added -DirectServerReturn parameter to Add-AzureEndpoint and Set-AzureEndpoint to enable/disable direct server return Added Set-AzureLoadBalancedEndpoint cmdlet to modify load balanced endpoints Cloud Services: Remote Desktop and Diagnostics Remote Desktop and Diagnostics are popular debugging options for Cloud Services. We’ve introduced cmdlets to help you configure these two Cloud Service extensions from Windows Azure PowerShell. Windows Azure Cloud Services Remote Desktop extension: New-AzureServiceRemoteDesktopExtensionConfig Get-AzureServiceRemoteDesktopExtension Set-AzureServiceRemoteDesktopExtension Remove-AzureServiceRemoteDesktopExtension Windows Azure Cloud Services Diagnostics extension New-AzureServiceDiagnosticsExtensionConfig Get-AzureServiceDiagnosticsExtension Set-AzureServiceDiagnosticsExtension Remove-AzureServiceDiagnosticsExtension The following example shows how to enable Remote Desktop for a Cloud Service. Web Sites: Diagnostics With our last SDK update, we introduced the Get-AzureWebsiteLog –Tail cmdlet to get the log streaming of your Web Sites. Recently, we’ve also added cmdlets to configure Web Site application diagnostics: Enable-AzureWebsiteApplicationDiagnostic Disable-AzureWebsiteApplicationDiagnostic The following 2 examples show how to enable application diagnostics to the file system and a Windows Azure Storage Table: SQL Database Previously, you had to know the SQL Database server admin username and password if you want to manage the database in that SQL Database server. Recently, we’ve made the experience much easier by not requiring the admin credential if the database server is in your subscription. So you can simply specify the -ServerName parameter to tell Windows Azure PowerShell which server you want to use for the following cmdlets. Get-AzureSqlDatabase New-AzureSqlDatabase Remove-AzureSqlDatabase Set-AzureSqlDatabase We’ve also added a -AllowAllAzureServices parameter to New-AzureSqlDatabaseServerFirewallRule so that you can easily add a firewall rule to whitelist all Windows Azure IP addresses. Besides the above experience improvements, we’ve also added cmdlets get the database server quota and set the database service objective. Check out the following cmdlets for details. Get-AzureSqlDatabaseServerQuota Get-AzureSqlDatabaseServiceObjective Set-AzureSqlDatabase –ServiceObjective Storage and Service Bus Other new cmdlets include Storage: CRUD cmdlets for Azure Tables and Queues Service Bus: Cmdlets for managing authorization rules on your Service Bus Namespace, Queue, Topic, Relay and NotificationHub Summary Today’s release includes a bunch of great features that enable you to build even better cloud solutions.  All the above features/enhancements are shipped and available to use immediately as part of the 2.1 release of the Windows Azure SDK for .NET. If you don’t already have a Windows Azure account, you can sign-up for a free trial and start using all of the above features today.  Then visit the Windows Azure Developer Center to learn more about how to build apps with it. Hope this helps, Scott P.S. In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu [Less]