Don’t toss your PowerShell results for your high-speed migration

Don’t toss your PowerShell results for your high-speed migration

Updated July 2nd: Recently published information on MSDN does a good job of explaining what the powershell commandlets are doing when they’re submitting the Migration Jobs to the Service provided by Office 365. It also goes into futher detail about the SAS tokens and the required permissions. Find the Article Here: CreateMigrationJob

Some users of the High Speed Migration commandlets for Powershell have been complaining that they’re unable to get the final step to work if they toss the results from the Set-SPOMigrationPackageAzureSource (that’s a mouthful) command when running the scripts. There is a very good reason for this which I am exploring here.

 

At this point I have created a small migration job which uploads the packages output from step 2 to Azure. As you can see here I am capturing the result of the upload in the variable $uploadresult

 

 

At first glance in the summary view when looking at the object in powershell it is just a set of URLs pointing to our blobg storage container and our queue

migration_ps_results01

 

However on further inspection, each of these URI’s contains a special kind of magic that is easily overlooked if you’re just submitting the job to the SharePoint Online Migration service directly after the upload. What happens is that the tool creates Signed URLs (Shared Access Signatures) to each of the URI’s generated by the tool.

 

Specifically if you look at the URI Details you’ll see in the query string. This query string specifies the Expiration of the URL along with the permissions granted with the string.

migration_ps_results02

The most important sections are the full string and then mainly the query which tells you more about the access.

OriginalString : https://hsmigrationtest.blob.core.windows.net/migrationfilesall2?sv=2014-02-14&sr=c&sig=OHoeYfIr%2FDNKVncLRSFiCDgXxtJm6AUx6m%2FB2OkjiD4%3D&se=2015-07-10T20%3A00%3A53Z&sp=rl

AbsolutePath   : /migrationfilesall2

Query         : ?sv=2014-02-14&sr=c&sig=OHoeYfIr%2FDNKVncLRSFiCDgXxtJm6AUx6m%2FB2OkjiD4%3D&se=2015-07-10T20%3A00%3A53Z&sp=rl

 

If we look at the query string for the $uploadresult.FileContainer you’ll see that its composed of five sections

sv=2014-02-14 Query Service Version
sr=c Not sure
sig=OHoeYfIr%2FDNKVncLRSFiCDgXxtJm6AUx6m%2FB2OkjiD4%3D The secured hash signature
se=2015-07-10T20%3A00%3A53Z Request Expiration July 10th, 2015 at 8PM Date/Time
sp=rl Rights Associated Read/Write/Update/List

 

Also valid but not listed

St= Valid Start Date/Time
Si= Access Policy definition

migration_ps_results03

And again at the query string for the $uploadresult.FileContainerUploadUri these five sections are listed

Query         : ?sv=2014-02-14&sr=c&sig=r24UhGA2R3aOUk7DwuBKlL6JEuWy%2BfX%2BXz83A6eVsng%3D&se=2015-07-10T20%3A00%3A53Z&sp=rw

sv=2014-02-14 Query Service Version
sr=c Still not sure
sig=r24UhGA2R3aOUk7DwuBKlL6JEuWy%2BfX%2BXz83A6eVsng%3D The Secured has signature
se=2015-07-10T20 Request Expiration July 10th, 2015 at 8PM Date/Time
sp=rw Rights Associated Read/Write/Update/List

You can see that the difference here is that the upload uri has only Read and Write permissions via its Shared URL.

migration_ps_results04

Digging in now to the query string for the uploaded package $uploadresult.PackageContainerUri you get this in the query string.

Query         : ?sv=2014-02-14&sr=c&sig=iYNNrcYt7GLEvomiQ6VoVuQwK7UxfcjPY%2FSCeydo6e8%3D&se=2015-07-10T20%3A00%3A53Z&sp=rwl

 

sv=2014-02-14 Query Service Version
sr=c Still not sure
sig=iYNNrcYt7GLEvomiQ6VoVuQwK7UxfcjPY%2FSCeydo6e8%3D The Secured has signature
se=2015-07-10T20 Request Expiration July 10th, 2015 at 8PM Date/Time
sp=rwl Rights Associated Read/Write/Update/List

 

It turns out that they need Read Write and List access to the package contents which make sense.

 

Thus far the query strings have been for the BlobContainers in Azure Storage, the last one is for the storage queue which is a bit different.

migration_ps_results05

 

Exploring the query string for $uploadresult.ReportingQueueUri, you’ll see a mostly the same values until it comes to the rights associated as well that the sr option is no longer included as well.

 

Query         : ?sv=2014-02-14&sig=ThFz0tBremg7%2BDYyK%2Bw%2BgIWRKA15kMeMZQ9%2FEhn8%2FCY%3D&se=2015-07-10T20%3A00%3A53Z&sp=raup

 

sv=2014-02-14 Query Service Version
sig=iYNNrcYt7GLEvomiQ6VoVuQwK7UxfcjPY%2FSCeydo6e8%3D The Secured has signature
se=2015-07-10T20 Request Expiration July 10th, 2015 at 8PM Date/Time
sp=raup Rights Associated (Query) Read/Add/Update/Process

 

 

 

So in conclusion that not only do we need to create pointers to our URI’s for the storage environment, we also need to grant access via a Shared Access Signature to the containers & queue for the tool to process correctly.

 

 

URI Necessary Permissions
FileContainerUri Read/List
FileContainerUploadUri Read/Write
PackageContainerUri Read/Write/List
ReportingQueueUri Read/Add/Update/Process

 

My next post will talk about how to generate these Uris manually if for whatever reason you toss these values in the middle of a migration like I did.

 

Leave a Reply

Your email address will not be published. Required fields are marked *