Windows Azure

Introducing the Windows Azure Content Delivery Network

As part of the Windows Azure CTP, we are announcing the Windows Azure Content Delivery Network (CDN) to deliver Windows Azure Blob content. Windows Azure CDN offers developers a global solution for delivering high-bandwidth content.

Windows Azure CDN has 18 locations globally (United States, Europe, Asia, Australia and South America) and continues to expand. Windows Azure CDN caches your Windows Azure blobs at strategically placed locations to provide maximum bandwidth for delivering your content to users. You can enable CDN delivery for any storage account via the Windows Azure Developer Portal. The CDN provides edge delivery only to blobs that are in public blob containers, which are available for anonymous access.

The benefit of using a CDN is better performance and user experience for users who are farther from the source of the content stored in the Windows Azure Blob service. In addition, Windows Azure CDN provides worldwide high-bandwidth access to serve content for popular events.

When you enable CDN access for a storage account, the Windows Azure portal provides you with a domain name of the following format: http:/ /<guid>.vo.msecnd.net/. This domain name can then be used to access blobs in a public container. For example, given a public container “images” and a storage account “cohowinery”, once the storage account is enabled for CDN access, users can access the blobs in that container using either of the following two URLs:

• Windows Azure Blob service URL: http://cohowinery.blob.core.windows.net/images/
• Windows Azure CDN URL: http://<guid>.vo.msecnd.net/images/

When a request is made using the Windows Azure Blob service URL, the blob is read directly from the Windows Azure Blob service. When a request is made using the Windows Azure CDN URL, the request is redirected to the CDN endpoint closest to the location from which the request was made to provide access to the blob. If the blob is not found at that endpoint, then it is retrieved from the Blob service and cached at the endpoint, where a time-to-live (TTL) setting is maintained for the cached blob. The TTL specifies that the blob should be cached for that amount of time in the CDN until it is refreshed by the Blob service. The CDN attempts to refresh the blob from Windows Azure Blob service only once the TTL has elapsed. The default TTL is 72 hours. At PDC 2009, we will allow you to specify the standard HTTP Cache-Control header for your Windows Azure blobs. If this value is specified for a blob, then the TTL period will be set to the value specified in Cache-Control header.

The value of caching blobs in the Windows Azure CDN is realized only when the content is delivered from the CDN edge cache, so content requested only once during the blob’s TTL period will not get performance improvements from edge caching. The blob content that benefits the most from caching are blobs accessed frequently during their cached TTL period.

You may also register one custom domain name for Windows Azure CDN access per storage account in the Windows Azure Developer Portal. For example, if you wanted to access CDN content through the domain “merlot.cohowinery.com”, you can register that custom domain name for the CDN endpoint in the portal. Continuing with our example, this would allow you to then access your blobs via one of the following three URLs:

1. http://cohowinery.blob.core.windows.net/images/
2. http://<guid>.vo.msecnd.net/images/
3. http://merlot.cohowinery.com/images/

The last two URLs above would access the blobs in the “images” container via the Windows Azure CDN, whereas the first URL would access the blobs directly from the Windows Azure Blob service.

The following steps are to enable CDN access to a storage account:

1. Go to the Windows Azure Developer Portal.
2. Click on your storage account.
3. Click on “Enable CDN” for your storage account.
4. The portal provides a CDN domain name in the form of: http://<guid>.vo.msecnd.net/ .

The configuration created for this endpoint is not immediately available; it can take up to 60 minutes for the registration to propagate through the CDN network worldwide. Users who try immediately to use the CDN domain name will get a 400 error until the configuration is updated worldwide.

After you’ve followed the steps listed above, you have to designate the containers you want to provide access to as a public container (http://msdn.microsoft.com/en-us/library/dd179391.aspx). You can then access blobs in that container using the CDN URL. The CDN domain name represents the storage account, so any public blob container within that storage account can be accessed via the CDN URL.

You can also register a custom domain name for the Windows Azure CDN endpoint. Follow these steps to register and use a custom storage domain name for your CDN content:

1. Go to the Windows Azure Developer Portal
2. Click on your storage account
3. Click on “Manage” for your http://<guid>.vo.msecnd.net/ endpoint.
4. Enter your custom domain name.
5. To complete the register of your custom domain name you will be asked to verify that you own the domain. You will be asked to register for your “custom.domain.name” a CNAME record from “<guid>.custom.domain.name” to “domainnameverification.windows.azure.com”, where the <guid> is specified by us in the portal.
6. Once you have registered that CNAME, click on validate in the portal for the CDN endpoint. Windows Azure will then validate that the CNAME record exists, and if successful your custom domain name will be registered.

To use the custom storage domain name:

1. Create a CNAME record from “custom.domain.name” to “<guid>.vo.msecnd.net”
2. Make the containers you want to provide anonymous access for public containers using the following blob API:
   http://msdn.microsoft.com/en-us/library/dd179391.aspx
3. You can then begin providing anonymous access to your blobs with http://custom.domain.name/ via the Windows Azure CDN.

If you no longer wish to cache a blob in the CDN, you can:

• Delete the blob from the public container
• Make the container private instead of public using the blob API:
  http://msdn.microsoft.com/en-us/library/dd179391.aspx
• Remove the Windows Azure CDN endpoint from your storage account in the Windows Azure Developer Portal.

Blobs already cached in the CDN will remain cached until the TTL for each blob expires. When the TTL expires, the Windows Azure CDN will check to see whether the CDN endpoint is still valid and the Windows Azure blob is still anonymously accessible. If it is not, then the blob will no longer be cached. This means that if you want to change the content of the blob and the blob is currently cached in the CDN, the new content will not be available via the CDN until the CDN refreshes its content when the cached content TTL expires.

Additional information:

• At this time there is no charge for CDN access to your blobs while in CTP. Information on pricing for the Windows Azure CDN offering will be provided in the future.
• For best performance, we recommend caching blobs less than 10 GB in size.
• Windows Azure CDN access only works for anonymous access and for HTTP. HTTPS is not supported for CDN access.
• A custom domain name can be registered for only one storage account endpoint at a time. For example, one could not register the domain name “merlot.cohowinery.com” for two different Windows Azure CDN endpoints at the same time.
• You can register overlapping domain names for different endpoints. For example, the following domain names can be registered at the same time for different storage accounts or endpoints:
  • http://merlot.cohowinery.com/
  • http://vintage.merlot.cohowinery.com/

Stay tuned for more information about the Windows Azure CDN and additional new and exciting features at PDC 2009.

Brad Calder
Windows Azure Storage

Accessing Windows Azure Blobs Using Custom Storage Domain Names

Today we are releasing the ability to access Windows Azure Blobs using custom domain names. Windows Azure Blob storage enables applications to store and manipulate large objects and files in the cloud.

The custom storage domain name feature allows you to register a custom domain name for a given storage account for anonymous blob access using that domain name. Currently we provide access to blob storage using the following domain name:

http://<account>.blob.core.windows.net/<container>/<blobname>

But if I owned a domain called “toddlers.wingtiptoys.com”, I may instead want my blobs accessible via:

http://toddlers.wingtiptoys.com/<container>/<blobname>

When registering a custom storage domain name, you can use that domain name to access the contents of a public container instead of http://<account>.blob.core.windows.net/. For example, given a public container “images” for a storage account named “toys”, we register the custom domain name “toddlers.wingtiptoys.com” for that storage account. This allows us to access the blobs in that container using either:

• http://toys.blob.core.windows.net/images/
• http://toddlers.wingtiptoys.com/images/

If we also had additional public containers for our “toys” storage account called “onsale” and “blogs” they could also be accessed via:

• http://toddlers.wingtiptoys.com/onsale/
• http://toddlers.wingtiptoys.com/blogs/

Follow these steps to register and use a custom storage domain name:

1. Go to the Windows Azure Developer Portal
2. Click on your storage account
3. Click on “Manage” your domain name for your storage account endpoint.
4. Enter your custom domain name.
5. To complete the register of your custom domain name you will be asked to verify that you own the domain. You will be asked to register for your “custom.domain.name” a CNAME record from “<guid>.custom.domain.name” to “domainnameverification.windows.azure.com”, where the <guid> is specified by us in the portal.
6. Once you have registered that CNAME, then click on validate in the portal for the storage account endpoint. Windows Azure will then validate that the CNAME record exists, and if successful your custom domain name will be registered.

To use the custom storage domain name:

1. Create a CNAME record from “custom.domain.name” to “<account>.blob.core.windows.net”
2. Make the containers you want to provide anonymous access for public containers using the following blob API:
   http://msdn.microsoft.com/en-us/library/dd179391.aspx
3. You can then begin providing access to your blobs with http://custom.domain.name/

Additional information:

• A storage account can have only one custom domain name registered for it.
• The custom domain name currently can only be used to access blobs that are in public blob containers, which are made available for anonymous access. At PDC 2009, we will allow custom domain access to also be used for authenticated access to Windows Azure Blobs.
• Custom storage domain name access only works for HTTP. HTTPS access is not supported.
• A custom domain name can be registered for only one storage account at a time. For example, one cannot register the domain name “toddlers.wingtiptoys.com” for two different Windows Azure storage accounts at the same time.
• You can register overlapping domain names for different storage accounts. For example, the following domain names can be registered at the same time for different storage accounts:
  • http://toddlers.wingtiptoys.com/
  • http://age3.toddlers.wingtiptoys.com/

Stay tuned for more information about Windows Azure Blobs and additional new and exciting features at PDC 2009.

Brad Calder
Windows Azure Storage

Windows Azure Platform Launch Update

In October 2008 at our Professional Developer Conference we opened the Community Technology Preview (CTP) for the Windows Azure platform (Windows Azure, SQL Azure and .NET Services).  The CTP has been invaluable in terms of shaping many aspects of the Windows Azure platform.

PDC 2009 is an exciting event for all of us who are working on the Windows Azure platform as it’s our opportunity to show you the work that we’ve done over the past year, including some brand new features. The conference also marks the beginning of our transition from a CTP to a business.  For your planning purposes, this post maps out the key stages of that transition that you should be aware of.

• At PDC 2009, on November 17^th, 2009, a number of new features in Windows Azure will be made available for the first time.  The CTP will remain open through December 31^st, allowing you to experiment with the full feature platform and to give us any final feedback.
• Beginning January, 2010, new customers will have to sign up for an offer to access services on the Windows Azure platform. Usage during the month of January will be at no charge, so you can see your exact usage while still enjoying free service.
• On February 1, 2010, we will begin charging customers for using the Windows Azure platform.

Making the transition in these three steps accomplishes a few goals.  First, it gives you a chance to explore our full feature set for free.  Second, it allows our team time to get your feedback on the new features and address any issues that arise.  Finally, it lets you preview exactly how billing will work before you need to start paying.

We’d like to thank everyone who has participated in our Community Technology Preview.  Windows Azure, SQL Azure and .NET Services are better products because of you. We look forward to seeing you next month at PDC 2009!

Updated 10/30/2009: Clarified that January is free of charge.

New Eclipse, PHP, and Java Tools for Windows Azure

Yesterday at the Eclipse Summit Europe in Ludwigsburg, Germany, Microsoft announced two exciting new open source projects that will make it easier for PHP and Java developers to work with Windows Azure.  Both projects were created in collaboration with Soyatec, a France-based IT solutions provider.

The first project, Windows Azure Tools for Eclipse, helps PHP developers to use Eclipse to author Windows Azure projects.  From the Interoperability @ Microsoft blog:

Windows Azure Tools for Eclipse provides a series of wizards and utilities that allow developers to write, debug, and configure for and deploy PHP applications to Windows Azure. It is available for download at www.windowsazure4e.org

…

The plug-in also bundles the existing Windows Azure SDK for PHP, which we introduced a few months ago.

The second project, Windows Azure SDK for Java, is a client library for accessing Windows Azure storage from Java.  This library was used in the creation of the “Storage Explorer” feature of the Eclipse extension.

We on the Windows Azure team are excited about both of these projects, which are part of our ongoing work to provide a great platform experience for all developers.

The announcements yesterday also included an enhanced Eclipse experience on Windows 7 and version 1.0 of the Eclipse Tools for Silverlight.  Read more on the  Interoperability @ Microsoft blog.

Upcoming Changes to Windows Azure Logging

At commercial launch, Windows Azure will feature an improved logging system.  The new system will give users greater flexibility over what information is logged and how it is collected.

In preparation for the new logging system rollout, next week we will disable the ability to retrieve logs via the Windows Azure Portal.  Your existing applications will continue to run without modification.

Why a New Logging System?

In our initial Community Technology Preview, we provided a logging API that allowed developers to write custom messages to an append-only log.  The API was built on top of the efficient event tracing capabilities of Windows.

We’re expanding the functionality of the logging system to simplify common use cases.  In the new logging system, you’ll have the ability to collect other kinds of data, such as performance counters.  You’ll have the ability to automatically push your logs to Windows Azure storage at an interval you specify, in a structured format that’s easy to query.  You’ll have the ability to reconfigure your logging on the fly, so you don’t have to decide up-front exactly what data you’ll need to debug problems.

The new logging system retains the best attributes of our initial logging API (simplicity and efficiency) while adding important features to help you build robust and reliable applications on Windows Azure.

Microsoft, Zend and others announce Simple API for Cloud Application Services

Yesterday Microsoft, Zend and others launched the Simple API for Cloud Application Services project, a new open source initiative that allows developers to use common application services in the cloud, while enabling them to unlock value-added features available from individual providers.

In essence, this project will allow developers to write basic cloud applications that work in all of the major cloud platforms. More specifically, it gives developers who use the PHP scripting language a “speed dial” to develop basic cloud applications that can be deployed across all major cloud platforms, including Windows Azure, while making it easier to complement software vendors’ fully-featured technology interfaces in a harmonious way.

This is good for our customers because we know they work in mixed environments and this should make it easier to access new technologies from cloud vendors. And its good for our industry because while we’re still in the early stages of collaborating on cloud interoperability issues, we’ve made great progress with our own products and standards support, as well as through industry collaboration such as this project announced today with Zend, IBM, Rackspace and others.

To read more about the “Simple API” project, please read today’s blog post from Vijay Rajagopalan, principal architect, Microsoft at: http://blogs.msdn.com/interoperability/archive/2009/09/22/microsoft-zend-and-others-announce-simple-api-for-cloud-application-services.aspx

To read the full release, go here: http://www.businesswire.com/portal/site/home/permalink/?ndmViewId=news_view&newsId=20090922006086&newsLang=en

And please feel free to post a comment here with your thoughts or questions; we’d love to hear from you.

Introducing a New Upgrade Option: In-Place

Today we are introducing a new upgrade mechanism, called “in-place upgrade,” which enables you to incrementally roll a new version of your service over the existing version without first deploying the new version to staging. With this new mechanism, you can upgrade your entire application or just a single role (e.g. web role) without disturbing the other roles in your application. Note that you will still have the option to upgrade as before, by first deploying the new version to staging and then swapping it with the production deployment.

To ensure application availability during an in-place upgrade, Windows Azure stops only a subset of your instances at a time to upgrade them, while keeping the remaining instances running. To achieve this, Windows Azure logically partitions your application into “upgrade domains” and updates one domain at a time. During the Community Technology Preview, Windows Azure uses two upgrade domains for each application. This means that half of your role instances will be offline at a time during an in-place upgrade. In the future, you will be able to choose how many upgrade domains you want.

You can perform in-place upgrades using the Windows Azure Portal or the new Service Management API. Note that you cannot use an in-place upgrade when the upgrade involves changes to your service definition (e.g., new roles or endpoints). For further details please refer to the MSDN documentation.

Do let us know your feedback!

Thanks,

Tushar Shanbhag

Introducing the Windows Azure Service Management API

Today, we are releasing a preview of the Windows Azure Service Management API to help you manage your deployments, hosted services and storage accounts. This is a REST-based API which users can code against in their toolset of choice to manage their services.

API Details at a glance

• You can find the documentation (along with the rest of the Windows Azure documentation) here.
• This is a REST-based API which uses X509 client certificates for authentication. Users can upload any valid X509 certificate in .cer format to the Windows Azure developer portal and then use it as a client certificate when making API requests.
• The following operations are currently supported.
  • Deployments – Viewing, creating, deleting, swapping, modifying configuration settings, changing instance counts, and updating the deployment.
  • Listing and viewing properties for hosted services, storage accounts and affinity groups
• We’ve put together a small tool called csmanage.exe to help you interact with this API and manage your deployments. You can find csmanage here along with our other samples.

How do I get started?

The documentation has detailed information on this but here’s a quick starter.

1. The first step is to get hold of a valid X509 certificate with a key size of at least 2048 bits. One quick way is to use IIS 7 to generate a self-signed certificate. Another option is to use makecert.exe (which ships with the Windows SDK) and use a command like the below:
   makecert -r -pe -a sha1 -n "CN=Windows Azure Authentication Certificate" -ss My -len 2048 -sp "Microsoft Enhanced RSA and AES Cryptographic Provider" -sy 24 testcert.cer
2. The next step is to upload the .cer file to the developer portal to let Windows Azure know that it should trust the certificate for API operations on your projects. The portal now has a new section called “API Certificates” under the Account tab where one can do this.
3. Use the certificate from step  #1 for any API request you make. The csmanage tool is a handy way to play and explore the functionality offered by the API. For users rolling their own tools, almost all mainstream programming platforms have support for client certificates. .NET users should use the ClientCertificates property of System.Net.HttpWebRequest. We’ll also be publishing client libraries to simplify this task soon.

In the pipeline

Over the next few weeks, we’ll publishing a sample .NET client library and samples, all with source code, to show how to use the API’s functionality.  This API is currently in CTP form and users should expect changes as we improve the service based on feedback.

As always, we welcome any feedback. Play with the API and tell us what you think!

Congrats to Dennis Palmer, Winner of the Twilio + Windows Azure Developer Contest!

Hats off to Dennis Palmer, who won a Netbook for winning last week’s Twilio + Windows Azure Developer Contest for his Cloud Call Me application for Facebook! Cloud Call Me allows Facebook users to call friends using Twilio and Azure, while keeping phone numbers completely private. Read more about the contest, as well as a few words from Dennis on his development experience here: http://blog.twilio.com/2009/09/cloud-call-me-wins-the-twilio-windows-azure-developer-contest.html

Federal Government Embraces Cloud Computing; Outlines Long-term Cloud Computing Strategy

In a press event on Tuesday at NASA Ames Research Center in California, Federal Chief Information Officer (CIO) Vivek Kundra unveiled apps.gov, an online storefront for federal agencies to browse and purchase cloud-based IT services. The Obama administration has long touted cloud computing as an effective means to take advantage of technology for less money, and promises this first project should streamline IT costs, while also demonstrating a strong commitment to embracing innovation to tackle increasingly complex IT issues.
 
We at Microsoft are very excited about this announcement and what it means for the public sector AND the role of cloud computing  in the overall technology industry.  Amitabh Srivastava, SVP Windows Azure at Microsoft, who was present at the industry roundtable following the press event, put it this way, “if there was any doubt that the era of cloud computing is alive in government, Kundra put those doubts to rest today in his announcement. Microsoft feels the White House is taking the correct approach by making cloud services available to government agencies, which will ultimately better serve citizens by leveraging technology innovations to run their organizations at lower costs, procure information technology more easily, and in a way that reduces government's ecological footprint.  Microsoft looks forward to working with the federal government to make the cloud computing vision a reality.   Government customers today seek -- and deserve -- a broad set of technology choices and solutions that address their diverse needs, which in most cases include both on-premise and cloud computing scenarios. As we work together to meet these needs, the industry must do so with the highest standards of interoperability, manageability and security safeguards.”

Yes, as Amitabh notes, cloud computing has applications far beyond apps.gov, the federal government’s first cloud computing project.   Teresa Carlson, vice president, Microsoft Federal, recently wrote a blog post discussing the broad implications of cloud computing in the public sector that you should read to learn more about some of the work already underway: http://microsoftontheissues.com/cs/blogs/mscorp/default.aspx

Microsoft has also started a project to help government agencies and developers publish and interact with their data in Windows Azure.  Announced May 7, 2009, the Open Government Data Initiative (OGDI), led by the Microsoft Public Sector Developer Evangelism team, is a cloud-based approach to housing public government data in Windows Azure making it accessible in a programmatic manner via open standard protocols and application programming interfaces, such as Silverlight, Flash, JavaScript, PHP, Python, Ruby, mapping web sites, etc..  For more information, please go to: http://ogdisdk.cloudapp.net/Default.aspx

Get Started with Windows Azure TODAY!

Steve Marx To Talk about Cloud Computing at XIX GeneXus International Meeting in Montevideo, Uruguay Monday, 9/14/09

Build a Windows Azure Application Using Twilio and Win a Netbook!

UPDATE [9/3/2009 @ 10:14AM]: Twilio has extended the deadline an extra week to accommodate Labor Day weekend in the USA.

Window Azure is joining forces with Twilio to bring you Week #16 of the Twilio Developer contest.  For those of you who don’t know, Twilio is a web service API for making and receiving phone calls using simple HTTP requests.  We thought it would appeal to a lot of the same developers who use Windows azure, so this week we’re challenging you to build an application that combines the two.

Participants to the contest have until midnight on Sunday, September 6th to submit their applications for a chance to win a free copy of Windows 7, $500 in Windows Azure credit (that kicks in in November when we reach our commercial launch), and a Netbook from Twilio.  To learn more or see submissions from previous weeks, visit the Twilio contest page.

New Windows Azure Blob Features – August 2009

Today we are releasing a new set of features for Windows Azure Blob. Windows Azure Blob enables applications to store and manipulate large objects and files in the cloud. The blobs (files) can be up to 50GB in size for the CTP.

All changes for this release are versioned changes, using “x-ms-version: 2009-07-17”. All prior versions of commands executed against the storage system will continue to work, as we extend the capabilities of the existing commands and introduce new commands.

The features for this release are:

• Update Blob with PutBlockList – We have added the ability to update the contents of a blob The prior version of Azure Blob required you to re-upload the whole blob in order to change a single block of a blob. With this new version, PutBlockList now allows you to add blocks, remove blocks, replace blocks, shuffle the order or existing blocks, or any combination of these for an existing blob. The benefit of this new feature is that to perform these changes you only have to upload the blocks you want to add or change. PutBlockList now allows you to create a new version of the blob by choosing blocks from a combination of (a) the existing set of blocks that comprise the current blob from the committed block list and (b) the newly uploaded blocks from the uncommitted block list.
  
• Root Blob Container – We have provided the ability for all storage accounts to have a single root blob container.  This allows applications to store and reference blobs right off the domain address.    This allows you to store and access blobs using a sample URL as follows:

http://myaccount.blob.core.windows.net/picture.jpg

With this versioned change, we also changed the way applications perform operations on containers to make it explicit that it is a container operation instead of a blob operation.  For example, to create a container called pictures, this now looks like:

PUT http://myaccount.blob.core.windows.net/pictures?restype=container

Note, to use the root blob container “x-ms-version: 2009-07-17” must be specified.   Support for anonymous requests that do not require a x-ms-version HTTP header to be specified will be added in the future.

• Shared Access Signatures for Signed URLs – It is now possible to create signatures, with an expiration date, that can be given out to provide access to Azure Blobs without having to give out your private key or make the blob container public. Applications can now create these Signed Access Signatures and add these to requests to Azure Blobs to create Signed URLs. The below is an example showing a signature (all of the fields after the “?”) giving read access to all of the blobs in the pictures container up until July 20^th. The URL then shows using this signature to access the blob profile.jpg in the pictures container.
  
  GET http://myaccount.blob.core.windows.net/pictures/profile.jpg?se=2009-07-20&sr=c&sp=r&sig=xUXi%2f%2fxnETUHQoV0MGS06OkEiTo%3d
  
  You create a signature computing a hash over a canonicalization of the request using your storage account secret key. The signature can then be used as part of the URL to provide read, write, or delete access for blob requests. Note, Shared Access Signatures do not require the use of x-ms-version.

In addition to the above new features we made the following semantic changes as part of this versioned CTP release:

• Conditional Headers for Windows Azure Blobs and Queues – Previous versions left it ambiguous as to the meaning of a request that specified multiple conditional headers (e.g., If-Match, If-None-Match, If-Modified-Since and If-Unmodified-Since). We now only allow a single conditional header to be specified, or one of the two following combinations: (1) If-Match and If-Unmodified-Since, or (2) If-None-Match and If-Modified-Since.
  
• Windows Azure Blobs and “/” – Prior versions of Azure Blobs would trim off slashes from a blob name if multiple slashes occurred in a row and could misinterpret the request if the container name was empty. We changed this behavior and now use the blob name as is, without trimming off preceding or trailing slashes, and correctly fail a request with an empty container name.
  
• Table Query and All List Operations – The max timeout is now 30 seconds for listing Blobs, Blob Containers and Queues and for performing Table Queries.

Note that the above features for this new release are currently only available via the Windows Azure Storage REST interface. They will be part of a future release of the Windows Azure SDK and storage client library.

For more information, details about these new features can be found in the MSDN documentation here later today:

http://msdn.microsoft.com/en-us/library/dd135733.aspx

In addition, Steve Marx will have some examples on using the above new functionality on his blog soon:

http://blog.smarx.com/

As always, we appreciate any feedback you might have.

Brad Calder
Windows Azure Storage

Migrating from “USA - Northwest”

Windows Azure offers users the option of choosing the geographic region in which their application runs.  During our current Community Technology Preview (CTP), the options available to users are “USA - Northwest,” “USA - Southwest,” and “USA - Anywhere.”  This list will grow as we expand into more geographies.

In the next few weeks, we’re going to disable the “USA - Northwest” option for new applications.  Existing applications will continue to run unaffected, and you’ll continue to be able to modify and update your existing applications.

Why the change?

This change is in preparation for our migration out of the northwest region.  Due to a change in local tax laws, we’ve decided to migrate Windows Azure applications out of our northwest data center prior to our commercial launch this November.  This means that all applications and storage accounts in the “USA - Northwest” region will need to move to another region in the next few months, or they will be deleted.  Around the time that the “USA - Northwest” option is removed, we will also provide an automated tool available on the Windows Azure portal to migrate projects.  We’ll update this blog and send email to CTP participants when that tool is available.  No action is currently required.

Is my application or storage account in “USA - Northwest”?  How can I tell?

If you explicitly chose a region when creating your application, you’ll see something like this (You may or may not have an affinity group name.):

If the geographic location reads “USA - Northwest,” then your application/storage will need to be migrated.  If it reads “USA - Southwest,” then it won’t be affected by the migration.

If you see the location “USA - Anywhere,” you can use a special tool called “Where’s My App?” (wheresmyapp.cloudapp.net) to determine where your application or storage account is actually running.

What do I need to do?

For now, you don’t need to do anything.  When the migration tool comes online, you’ll need to use it if you want to preserve your applications that are currently running in “USA - Northwest.”  This blog will be updated with details when the migration tool is available.