In Dec 2015, we announced specific versions of the Microsoft Azure Storage Service would be removed on August 1, 2016. Based on customer feedback, we are now extending the service availability and have decided to postpone the removal of deprecated service versions (versions 2009-07-17 and earlier) to provide more time for customers to upgrade.

We still encourage all customers using deprecated service versions to upgrade to the latest service version in order to gain the benefits of new features and performance improvements. Twelve months notice will be provided once a new service version removal date is selected.

What should I do?

To ensure your application continues to work properly with the latest version, you should do the following things.

Check your application to find what versions it is using

The first thing to do is to determine what REST versions your application is using. If your application is under your control and you are aware of all components that call Azure Storage, then you can verify this by checking the components or by inspecting your code if you have written your own code to make calls to storage.

As a stronger check, or if you are unsure which versions of the components have been deployed, you can enable logging, which will log the requests being made to your storage account. The logs have the request version used included, which can be used to find if any requests are being made using old versions.

Here is a sample log entry, with the version used highlighted. In this case, the request was an anonymous and unversioned GetBlob request which implicitly used the 2009-09-19 version:

1.0;2011-08-09T18:52:40.9241789Z;GetBlob;AnonymousSuccess;200;18;10;anonymous;;myaccount;blob;”https:// myaccount.blob.core.windows.net/thumbnails/lake.jpg?timeout=30000″;”/myaccount/thumbnails/lake.jpg”;a84aa705-8a85-48c5-b064-b43bd22979c3;0;123.100.2.10;2009-09-19;252;0;265;100;0;;;”0x8CE1B6EA95033D5″;Friday, 09-Aug-11 18:52:40 GMT;;;;”8/9/2011 6:52:40 PM ba98eb12-700b-4d53-9230-33a3330571fc”

Similar to the above, you can look at log entries to identify any references to older service versions.

What to change

If you find any log entries which show an older version, you will need to find that component and either validate that it will continue to work (unversioned requests may continue to work as their implicit version will simply increase), or take appropriate steps to change the version being used. Most commonly, one of the following two steps will be used:

1. Change the version specified in the request. If you are using client libraries, you can accomplish this by migrating to a later version of the libraries/tools. When possible, migrate to the latest version to get the most improvements and fixes.
2. Set the default service version to the latest version so that the behavior can be verified. This only applies to anonymous requests with no explicit version.

When migrating your applications to newer versions, you should test thoroughly to ensure your application is working properly after you’ve updated it. Please note, service version updates have included both included syntactic breaks (the request will receive a response that either is a failure or formed very differently) and semantic breaks (the request will receive a similar response that means something different).

Post migration validation

After migration, validate that you do not find any of the earlier versions being used in the logs. Make sure to check the logs over long enough durations of time to be sure there are no tasks/workloads running rarely that would still use the older versions (ex. scheduled tasks that run once per day).

Conclusion

We recommend users upgrade their applications to gain the benefits of new features and performance improvements. Additionally, it is considered a best practice to explicitly version all requests made to the storage service. See MSDN for a discussion of versioning in Azure Storage and best practices.