• Pay attention to the comments in the article.  A trick to deal with changing locations is to just create a VM - even if you delete it later - so you can grab the right geo in your storage container.  I set mine to "US East" for example.
• Also, note the comment that you have to change your working directory from the default c:\ to something you can actually write to.
• During the copy, the % complete doesn't work properly.  I saw someone say this in the article comments as well.  It will climb, but the % complete is incorrect and can be ignored.
• I also had to change the Get-AzureSubscription -Current | Set-AzureSubscription -CurrentStorageAccountName $destStorageName line to Set-AzureSubscription -CurrentStorageAccountName $destStorageName -SubscriptionName "Visual Studio Ultimate with MSDN".
• When it was done, I then had to set up RDP like this:  https://blogs.msdn.com/b/mast/archive/2014/03/06/enable-rdp-or-reset-password-with-the-vm-agent.aspx

Here's the article:  https://blogs.msdn.com/b/microsoft_press/archive/2014/01/29/from-the-mvps-copying-a-virtual-machine-from-one-windows-azure-subscription-to-another-with-powershell.aspx

Library must be named “Podcasts”

Library must be of type “Music”

To change library type:

1. 
   Right click library
   in Explorer
2. 
   Choose Properties
3. 
   In Library
   tab change Optimize this library for to Music

Hat Tip to Peter Jausovec and Hein Htat.  Thanks!

Have you granted yourself rights to the impersonation administrator role?

Then, you're almost certainly misspelling your username and/or password.  Double check by logging into OWA with the same creds.  Fight it, if you will, but this is almost certainly the case.  Check again.

HTH!

But percent complete seems to be a common method to track status on tasks.  It may have been reinforced by Microsoft Project, as percent complete is prominently displayed in the interface, in the default toolbar, for example.  This might make sense for construction projects and the like, as each task is more decomposable.  Despite never having been involved in a major construction project, the idea seems to be that a staircase needing to be built of 10 stairs - when 4 stairs are complete, that's 40% there.  This does not apply to technical projects however.  It is a well known precept in computer science for example, that percent complete is independent of the number of lines of code.  In my programming days, a project manager would ask for a percent complete; I would stare blankly and come up with a guess.  The same applies to infrastructure projects.  Unless you need to install the same patch or software on 10 different, but equal nodes in a cluster, there is very little applicability to the concept of percent complete.  When configuring a server for a particular function - take an Exchange server for example - it's not done until it's tested and complete.  Until email flow is validated, clicking next, next, next is irrelevant.  I have heard this described by one of my first PMs at Microsoft as "the onion problem".  You have no idea how long is left until you have peeled back the layers of the onion and reached its core.  Because all it takes is one bad layer and the entire task goes from 99% complete to 1% complete.

We can see this clearly in progress bars in software.  People joke about how little they align to reality.  They seem to be going backward in some cases.  And progress bars are built upon an algorithm designed to model the progress.  Yet they still fail miserably.  Compare that to an engineer making a value judgment on percent complete - off the cuff... and making these assessments in rapid succession as they report status on all their tasks.  When Windows 7 loads now, there is no longer a progress bar... just an ever-looping indicator that the operating system is loading.  Which makes more sense and aligns closer to reality.

My Project Management instructor at Microsoft Services University had it right.  From a technical project management standpoint, there are three states:

• Not started.
• In progress.
• Complete.

In my experience, this is absolute truth.  Most projects that are large enough to justify a project plan, rather than an agile approach, have enough lines in them that percent complete is irrelevant.  The real questions are - have you started?  And are you complete?  Every status in the middle is irrelevant.

And even technical projects require time estimates.  But the other point I have learned at Microsoft is - if we missed the mark, do not simply move the date up.  Wait until you have a reason to believe something will be done by that date.  Project Managers don't like to hear that.  But that is their job - to push individual contributors to come up with estimates, and report on percent complete.  By all means, project managers, do that.  But focusing on percent complete is a waste of time in technical project management.  There are three states that matter.  Focus on those and let the workers get it done.

Example error:

Summary: 1 item(s). 0 succeeded, 1 failed.
Elapsed time: 00:21:53

First Name Last Name
Failed

Error:
The call to 'net.tcp://sn2prd0502ca011.namprd05.prod.outlook.com/Microsoft.Exchange.MailboxReplicationService SN2PRD0502CA011.namprd05.prod.outlook.com (14.1.225.56 caps:07)' failed. Error details: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:01:00'. --> The write operation failed, see inner exception. --> The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:01:00'. --> An existing connection was forcibly closed by the remote host.

The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:01:00'.

The write operation failed, see inner exception.

The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:01:00'.

An existing connection was forcibly closed by the remote host
Click here for help... https://technet.microsoft.com/en-US/library/ms.exch.err.default(EXCHG.141).aspx?v=14.1.218.11&t=exchgf1&e=ms.exch.err.Ex8FE8AAExchange

Exchange

Management Shell command attempted:
'c7f56df8-ec48-4935-b066-1a8505835f46' | New-MoveRequest -Remote -RemoteHostName 'ex10.ourdomain.com' -RemoteCredential 'System.Management.Automation.PSCredential' -TargetDeliveryDomain 'service.ourdomain.com'

Elapsed Time: 00:21:53