How to access BIOS on a Dell Venue 8 Pro

Turn the Tablet off.
Press the power button once and then hold the Volume down button for a few seconds.  Let go a couple of seconds after the Dell logo appears.
And now you're in BIOS.

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.

Migrating from on-premise BES on Exchange 2010 to Blackberry cloud services on office 365

I'd been waiting a very long time to finally be rid of my on-premise blackberry enterprise server and the blackberry cloud services (at the compelling price of free) was a light at the end of the tunnel for the office 365 upgrade.  But as you know, with Blackberry there are many things that can go wrong and most roads lead to phone wipes - which wasn't an option for me.

The initial activation was a piece of cake.  I just went into the office 365 admin portal and activated it under Service Settings -> Mobile.  Then waited 20 minutes as recommended on this guide:  http://www.proexchange.be/blogs/office365/archive/2012/03/08/migrate-from-on-premise-blackberry-enterprise-server-to-blackberry-business-cloud-services-in-office-365.aspx

Before proceeding I had all my blackberry users check to make sure they had the Enterprise Activation App installed.  

Then I added my first user and sent them the invite and migrated their mailbox to office 365.  At which point I found out that the user had never verified their blackberry ID so they couldn't download the app.  Oh, and they were on their last password attempt before it would wipe on them.   After having fixed that, we then tried the activation and it balked and told us to wipe the device because there was already another account on it.  Now wiping this particular employee's device was really just not an option.  So after digging around, I found a page that told us we could initiate an organization data only wipe from the BES console.

http://docs.blackberry.com/en/admin/deliverables/27983/How_device_deletes_work_data_1303191_11.jsp

"In the Device activation list, click Delete only the organization data and remove device. "

That worked properly and then we were able to get a little further along into the enterprise activation where it decided to get stuck forever while contacting the server.  To fix that, we just yanked out the battery for 30 seconds, then plugged it back in and tried again.  And voila - a fully functional blackberry on blackberry cloud services connected to an office 365 account.

remote move request not an accepted domain for your organization

So you've got your fancy Hybrid configuration all set up between your on-premise Exch 2010 SP3 server(s) and the office 365 cloud and you only get this error on some mailboxes.  Your dirsync is working fine, and your ADFS is even working for once.  Depending on your situation you may even have noticed that it's mostly older user mailboxes that are giving you grief.  In my case we used to have other domain names in use and when those were decommissioned, the extra Email addresses were never removed from the mailboxes.  For the Remote move to work, the only email address domains that can be attached to that mailbox have to be listed under the Domains tab in the office 365 admin page.  Once you remove the extras, then wait a while, then force a Dirsync, then wait a while and try again it'll go through.

Example:

UserA has these email addresses:
usera@contoso.com
usera@contoso.mail.onmicrosoft.com

UserB has these email addresses:
userb@contoso.com
userb@contoso.mail.onmicrosoft.com
userb@notcontoso.net

If the domains tab in office 365 only has contoso.com and contoso.mail.onmicrosoft.com, then UserA will move but UserB will fail.