First, we're going to have to login as an Administrator to the portal at: portal.microsoftonline.com

Upon successful login, you should be redirected to the Office 365 admin center where you'll want to select "users and groups" on the left-hand pane, followed by "Setup" next to "Set Multi-factor authentication requirements" in the middle pane.

Once on the multi-factor authentication page, you will select the users you want to provision for MFA and click "Enable" under "quick steps" in the right-hand pane.

 Once the users has been enabled for MFA, the next time they login they will be prompted to click "Setup now" to configure their MFA settings. Here, they can select an initial setting to authenticate with.

 Upon successful authentication, they should be redirected to their OWA page where they can go to the cog in the top-right corner and select "Office 365 settings."

Here, they can select "additional security verification" in the left-hand pane followed by "Update my phone numbers used for account security" in the middle pane.

 They will be taken to the screen below where they can change the method of multi-factor authentication to the following options:

• Call my mobile phone
• Text code to my mobile phone
• Call my office phone
• Notify me through app
• Show one-time code in app

Thanks for reading!

WARNING: The operation wasn't successful because an error was encountered. You may find more details in log file
"C:\ExchangeSetupLogs\DagTasks\dagtask_2013-03-22_21-28-43.273_add-databaseavailabiltygroupserver.log".
A server-side database availability group administrative operation failed. Error The operation failed. CreateCluster
errors may result from incorrectly configured static addresses. Error: An error occurred while attempting a cluster
operation. Error: Cluster API '"CreateCluster() failed with 0x5. Error: Access is denied"' failed.. [Server:
E2K13MR1.corp.exlab.com]

So I decided to follow the TechNet article on pre-staging the Cluster Name Object for the DAG: https://technet.microsoft.com/en-us/library/ff367878.aspx

However, I still couldn't add any nodes to the DAG. So after some further research (checking our MSSolve database), I found a recommendation to disable that CNO after you've pre-staged it. I went back and followed the suggestion I found, disabled the CNO, and VOILA!, added the DAG nodes without issue.

After troubleshooting the issue more, I found the same process against the Public Folder Hierarchies object resolved our issue. Here's how:

1.) Open ADSIEDIT.msc

2.) Navigate to Configuration > Services > Microsoft Exchange > (Your Exchange Org) > Administrative Groups > (Your Administrative Group) > Folder Hierarchies

3.) In "Folder Hierarchies" right click and open the Properties on the Public Folders Object

4.) Switch to the "Security" tab and highlight "Everyone"

5.) In the bottom pane, find "Create Public Folder" and check the "Deny" checkbox. (I know you see the "create top-level public folder", but denying just the "Create Public Folder" did the trick. Their permissions should still be intact for creating subfolders)

How I built the script, was to have them provide a list (in a text file) of each batch of user migrations, then I would find the problem users based on the size of their recoverable deleted items (the users that it was supposed to apply to shouldn't have had that much for the retention policies to effect because they already had a policy on Exchange 2007 that was working). This allowed us to find which users were truly effected, then either restore their mailbox in Exchange 2007 and migrate again or just select all the user's recoverable deleted items and restore.

I've attached the script, but if you would like just copy and paste to a text file and rename to .ps1, you can do that with the below:

#Author: Aaron Calloway
#Use this script to get the size and item count of the items in user's recoverable items
#Usage: When prompted for input file, type the full path of file location. i.e. "C:\temp\userlist.txt"
#When prompted for the output file, type in the full path of where you want the file to be located.
#i.e. "C:\temp\recoverableitemslist.txt"
#
#Note:This script APPENDS data, so it will not overwrite an existing file, it will add to it.
#
#
#
$ip_file=Read-Host "Where is the input file located?"
if (! $ip_file){
Write-host -Foregroundcolor "Red" "You must select an input file!"

$ip_file = Read-Host "Where is the input file located?"
}

$Users=(Get-Content -Path $ip_file)

$op_file = Read-Host "Which file would you like the results written to?"

if (! $op_file){
Write-Host -Foregroundcolor "Red" "You must select an output file!"

$op_file = Read-Host "Which file would you like the results written to?"
}

foreach ($user in $users) {Get-MailboxFolderStatistics $user |? {$_.FolderType -eq "RecoverableItemsDeletions"}|select identity,foldertype,folderpath,itemsinfolder,foldersize | Out-File $op_file -append}
Write-Host -Foregroundcolor "Green" $users.count "Users Completed. File is located at $op_file"

Get_RecoverDeletedItems.ps1

Warning: Failed to clean up the source mailbox after the move.

Error details:
MapiExceptionUnexpectedMailboxState: Unable to delete mailbox. (hr=0x80004005,ec=2634)

When we looked around a little bit, we found that all the mailboxes that had completed with this particular error ended up having a disconnected mailbox showing up in the Exchange Management Console.

With a little bit of research, I found that this is a bug that applies to Exchange 2010 SP2 RU3, RU4, and RU5. You can prevent this issue from happening in the future by upgrading to Exchange 2010 SP3. However, you still need to get those disconnected mailboxes out of there. To do this, you want to use the following commands in Exchange Management Shell:

1.) Run the command to find the specific mailboxes that were impacted by this bug.

Get-MailboxStatistics -Database <MAILBOXDATABASE> | Where { $_.DisconnectReason -eq "SoftDeleted" } | fl LegacyDN, DisplayName, MailboxGUID,DisconnectReason

 2.) Run this command to remove those disconnected mailboxes cleanly.

Remove-StoreMailbox –Database <MAILBOXDATABASE> –Identity <MAILBOXGUID> –MailboxState Softdeleted

After running these steps, we were able to successfully cleanup those disconnected mailboxes.