question

MarkP-1195 avatar image
0 Votes"
MarkP-1195 asked joeyvldn commented

Azure Migration Appliance - issue applying key to appliance in step 2 "Register with Azure Migrate"

After creating a migration project in Azure, we went to the Discover phase to create a key for the migration appliance. We gave a name to the appliance and a key was generated. However, when we put the key in to link it back to the subscription in Azure, we get the message that "The Migrate project key entered seems to be incorrect". However we've copied/pasted it right from Azure to the appliance itself. It's almost like Azure is generating a key that's invalid.
197466-key-issue.jpg

We are the "owner" of the Azure account, so we don't think there's a permissions/RBAC issue. We tried using an Azure free account unrelated in anyway to our main account, and the key that generated worked correctly and the appliance could connect without fail. On the account with the problem, we've tried creating the projects/appliance keys in different subscriptions, in different regions all with the same result - the generated keys don't work; it doesn't appear that the appliance even tries to contact Azure, it gives the error immediately as if the key is not formatted correctly. We compared the keys from the free/working Azure account and the non-working keys, and we see differences (beyond the GUIDs that would always be different) - there's actually a URL attached to the end of the key in a way that makes us think it shouldn't be there.

The end of the "working" key from the Azure free account is:
...181585b0cdd4/resourceGroups/TempDA-rg/providers/Microsoft.Migrate/MigrateProjects/DAmigrateTest

which seems reasonable, where the resource group is called out, along with the test project name we created. However, the non-working key ends with this:
...6363c1cd0c00;https://discoverysrv-wus2.prod.migration.windowsazure.com/;westus2;false

which is a completely different format than the prior one. Is this really part of the issue or are there 'region' differences that might make the key look different?

If this looks like it is formatted correctly, what else could be causing the issue? If it doesn't appear correct, why would Azure generate a key that was useless?



azure-migrate
key-issue.jpg (96.8 KiB)
· 3
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

To add to that, we've looked at various logs with no obvious errors; we've ran the "Run Diagnostics" on the appliance and it comes up clean.

TIA for any answers on this.

0 Votes 0 ·

Same issue here!

I downloaded and installed the OVA file first. When this was up and running i started the procedure in the Azure Portal. Should i start with generating a key and then downloading the OVA file?

Or do we have issues on MS their side?

0 Votes 0 ·

Update:
Downloaded the .OVA once again, created a new VM and then it worked.. No idea what happened.

0 Votes 0 ·

1 Answer

MarkP-1195 avatar image
2 Votes"
MarkP-1195 answered MarkP-1195 published

Ok found a work around; the problem of Azure not generating a useable key still exists, but the work around does get past the problem. When a migration project is created, Azure correctly creates the ID that becomes part of the key that gets generated, but the key is not formatted correctly. However, if you use Resource Graph Explorer you can find the pieces that you need to build the key in the correct format. It really shouldn't be called a "key" but rather a connection string that the appliance uses to connect to the correct subscription and resource group.

Using Resource Graph Explorer run the following query:

  resources | where  type == "microsoft.migrat/migrateprojects"

197872-azure-project-answer.png

and look for the "id" field (download as CSV to make copy/paste easier to get the string)

You'll then have to piece together the key from the unusable key and the contents of the "id" field from the downloaded CSV.

If the appliance name was "test-migapp" and the resource group name was "rg-for-migration" and the project name is "mig-proj" then the broken/unusable key would have looked something like this (with GUIDs represented by "n")

  **test-migapp**;PROD;nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnn;nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnn;**rg-for-migration**;**mig-proj**;nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnn;nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnn;https://prod.cus.discoverysrv.windowsazure.com/;centralus;false

and the output of the Resource Graph Explorer "id" field should be similar to:
/subscriptions/nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnn/resourceGroups/rg-for-migration/providers/Microsoft.Migrate/migrateprojects/mig-proj

you'd piece the first three semicolon-delimeted sections from the broken key, and the entirety of the "id" field together to get:

  test-migapp;PROD;nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnn;/subscriptions/nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnn/resourceGroups/rg-for-migration/providers/Microsoft.Migrate/migrateprojects/mig-proj

Which would be a functional key that the appliance will accept.




5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.