Problem:

When you are trying to delete a verified domain name in Office 365, an error pops up saying that some users or Office365 services are still attached to the domain.

Root Cause:

Just like what the error said, some of the Office 365 services or users are still attached/assigned to the domain name that you are trying to remove.

Solution:

Things to check:

1. Ensure that no users are associated with the domain that you are trying to delete. You can verify this by going into Users And Groups, and Edit a user. Ensure that the domain you are trying to delete, eg, abc.com, is not listed there.
2. Ensure that no security groups/distribution groups have the accounts attached to abc.com. Security groups/distribution groups can be access by logging into Office 365, click on Users And Groups, and click on Security Groups.
3. If you have just deleted the users, or changed the domain for each individual users, you will need to wait for a while (1 min?) as it will need to sync the changes to the different Office365 service settings.
4. If the accounts are uploaded to Dirsync, you will need to stop the Dirsync synchronization to change the accounts to a Cloud Only account. Then, you will need to do step 1-3 above to delete the Security groups; and/or manually modify the e-mail addresses fields in Office 365, Exchange Online.

Lately, I had an issue with Office 365’s MIISClient.exe

Problem:

MIISClient.exe shows that a bunch of user accounts failed to sync with the error “Insufficient Permission”.

Solution:

Certain permissions needed by MSOL Service Account went missing (for whatever reason!). All we had to do is to recheck back the permissions.

Step 1: Run the Azure Active Directory Sync tool Configuration Wizard

Make sure that the latest version of the Directory Sync tool is installed and that you run the Azure Active Directory Sync tool Configuration Wizard. When you run the wizard, one screen prompts you to enable rich coexistence. Complete the wizard, and then start directory synchronization.

Alternatively, you can run the Enable-MSOnlineRichCoexistence cmdlet after the Directory Sync tool is installed to enable the write-back feature. This cmdlet must be run by using enterprise credentials or should be run by the enterprise admin.

Step 2: Confirm MSOL_AD_Sync_RichCoexistence permissions

If step 1 doesn’t resolve the issue, check that the MSOL_AD_Sync user belongs to the MSOL_AD_Sync_RichCoexistence group and that the group has Allow permissions to the user who is experiencing the issue, where write-back is not working for the following attributes:

• msExchSafeSendersHash
• msExchBlockedSendersHash
• msExchSafeRecipientHash
• msExchArchiveStatus
• msExchUCVoiceMailSettings
• ProxyAddresses

To do this, follow these steps:

1. In Active Directory, make sure that the MSOL_AD_Sync_RichCoexistence group exists and that the MSOL_AD_Sync user is a member of the group.
2. In the on-premises environment, use Active Directory Users and Computers to open the user properties for the user who is experiencing the issue.
3. On the Security tab, click Advanced.
   
   Note You must enable advanced features to complete step 3.
4. Make sure that the MSOL_AD_Sync_RichCoexistence group is listed. If it’s not listed, add the group, and then make sure that the group is granted Allow permissions to write to the attributes that are listed previously.

Note Step 2 may be required if the object does not inherit permissions from the parent. This issue may be resolved by making sure that the object inherits permissions from the parent object.

Source: Microsoft KB 2406830

Hope this helps!

Statement:

You have purchased some Office 365 E3 plans and have assigned the Office 365 E3 licenses to the users.

You would like to activate Legal Hold for these users in bulk, using PowerShell.

Script to Activate:

1. # First you need to be connected to the Exchange PowerShell.
3. $pagesize = 100; # The number of mailboxes per loop
4. $inc = 0; # Start increment value
6. # Continue until all mailboxes are litigation hold enabled
7. do {
8.     Write-Output “Getting mailboxes”
9.     # Get UserMailboxes that does not have litigation hold enabled
10.     $mailboxes = Get–Mailbox –Filter {LitigationHoldEnabled -eq $false -andRecipientTypeDetails -eq “UserMailbox”} –ResultSize $pagesize –WarningAction SilentlyContinue
11.     if($mailboxes) { Write-Output (“Current mailbox count: {0}” -f ($inc += $mailboxes.Count))}
12.     # Enable litigation hold
13.     $mailboxes | Set–Mailbox –LitigationHoldEnabled $true –WarningAction SilentlyContinue
14. } while($mailboxes);

Source: Goodworkaround.com

In a Hybrid deployment, lately I had experienced that:

1. On-premise users can see cloud users’ free/busy

2. Cloud users cant see on-premise users free/busy

Note: the below may not solve your problem, but it should lead you to the right way to brute force your way to solve the problem lol

Resolution:

1. Try out the Hybrid Free/Busy Troubleshooting Tool.

2. Check out: User can’t view free/busy information for a remote user in a hybrid deployment of on-premises Exchange Server and Exchange Online in Office 365

3. Did an IISRESET as recommended: http://jesperstahle.azurewebsites.net/?p=242

4. Update/Refresh the Federation Metadata. See this blog for more information.

•  Connect to Exchange Online in PoweShell
• Execute:
• Get-FederationTrust | Set-FederationTrust -RefreshMetadata

5. Execute the free/busy test from Microsoft Remote Analyzer

6. Ensure that in all Exchange Servers (including the inactive ones located in the DR sites), the Get-WebServicesVirtualDirectory has the correct ExternalURL: https://mail.contoso.com/ews/exchange.asmx (and is routable from the internet)

Get-WebServicesVirtualDirectory -Identity “ServerName\EWS (Default Web Site)”

Leave a comment if it’s still not working. No promise that I can help you fix, but I’ll try