I'm working with support on this with case #02088063, but I wanted to post here as I want the product team to be aware of this issue.
I have an Azure account, using my Microsoft account. It is associated with an existing "production" Azure directory, on which I am a co-administrator. I also have a (default) directory associated with the account, to which I have attached my MSDN Premium subscription. I am trying to test out VEEAM Direct Restore to Azure using this subscription.
I've been following the instructions for adding my Azure account to VEEAM, and kept running into errors. After working with support, it seems that when you are calling the Powershell cmdlet to log me in, it defaults to the "production" subscription for which I am an administrator but not service administrator (there can only be 1 per subscription, and that is assigned to another account). As a result, it blocks me from adding my account to VEEAM.
This seems like a bug/flaw in the implementation; it is assuming I want to create whatever AD application in whatever subscription comes up by default from calling Login-AzureRmAccount, when instead I want it created in a different subscription. I haven't been able to figure out how to switch the subscription on the server end so it just works, but other folks have offered ways of adjusting the powershell commands to do that (see: http://stackoverflow.com/questions/4263 ... ermaccount
The "solutions" provided by support are not really feasible; since there is only one service administrator per subscription I can't necessarily just change that. And the other solution was to remove myself as an administrator from the other subscription, which might be OK for testing but is not a long term viable option.
For the record, I did temporarily remove myself from the "production" subscription, and I was able to add my Azure account just fine -- so that seems to confirm my suspicions on the issue.
Hope this is clear, and happy to chat more about it.