Tuesday, June 18, 2013

Exchange 365 hybrid Remote move request- found yet another method for getting the operation could not be performed because the GUID could not be found.

Just when you think you've got the hang of your hybrid exchange deployment (on-premise and cloud), the cloud throws another curve ball at you.   I thought I had the process nailed down but apparently I forgot the old rule of 'order is important'.

Scenario:  You need to create a new user so you go to the AD controller and create or copy them.  Then I went to my DirSync server and forced a "Start-OnlineCoexistenceSync" and then waited a few minutes for it to finish.  Now at that point what I should have done was go to the on-premise Exchange server and created the new mailbox, and then ran DirSync.  Instead since I already had the office365.com admin portal up I went ahead and assigned a license to the user since the object was already sync'd up on the cloud.  When I went to submit a Remote Move Request of the mailbox from my on-premise server to the cloud, I got the friendly "The operation couldn't be performed because object couldn't be found on  .   At this point I hadn't figured out what I'd done wrong so I forced DirSync a few more times, unassigned the license, reassigned the license, etc.  In the end, I actually wound up having to delete the new AD account I'd created and do the whole thing over again but this time I created the local mailbox BEFORE I assigned a license in the cloud.  Apparently if you assign a license to the user and they don't have an Exchange GUID in their AD attributes yet, it hoses things up.  

Order:
1. Create AD user
2. Create local mailbox
3. Force DirSync
4. Move mailbox to the cloud
5. Assign a license in the 365 admin portal

Notes:
Steps 4 and 5 are interchangeable.
We create the mailbox locally first so that we retain the ability to move it back from the cloud to on-premise later if needed.  DirSync does NOT replicate a GUID created initially from the 365 cloud back to your local AD.

1 comment:

Unknown said...

Actually, I found if you're creating a new AD user, rather than create a new on-prem mailbox just to immediately move to the cloud, just use the Enable-RemoteMailbox CMDLET, assign the license and you're done.