Quest Migration Manager (MAGE) Microsoft.Exchange.WebServices.Data.ServiceResponseException: Access is denied. Check credentials and try again.

Issue
During a Mailbox or Calendar sync job, you may receive an error similar to the below on a particular mailbox (s).

"Microsoft.Exchange.WebServices.Data.ServiceResponseException: Access is denied. Check credentials and try again. "

All permissions are set correctly and you can connect via EWSEditor , All AD permissions look correct (inheritance, Full Access)

Problem
Time for spot the difference.  For some reason the "Self" permission was not showing in Exchange Management Shell. (Even though was showing in AD!!)

Missing Self Permission

Added Self Permission

Solution
Re-Add the self permission via EMC and re-synchronize the mailbox. Viola !!!

AutoDiscover fails with 0x80040413 Hybrid Office / 365

Scenario

During a recent Office 365 Hybrid Deployment, we utilized an existing set of Exchange 2010 CAS Servers (Clue) to preform the required Federation, MRS Proxy and AutoDiscover functions. All configuration tasks where completed without error. The Microsoft RCA (Remote Connectivity Analyzer) passed and test mailbox moves worked fine.

The Issue
However.! During the testing of AutoDiscover with setting up Outlook over the web (no SCP)
we discovered this would fail. Upon checking the Outlook "Test E-Mail AutoConfiguration" we were presented with the failure "0x80040413" Failed

Fig 1. AutoDiscover error

The Cause
So, as I mentioned above, The RCA gave us the "all clear", However it did carry a "warning". This is normally to do with some certificate warning on old windows mobile devices. However I decided to drill down through the RCA to find a warning I have "never" seen before. it was the test for "Checking the IIS configuration for client certificate authentication"
There was a warning something like (sorry, did not screen shot) "Client certificate authentication was detected" And a statement around setting to ignore. Upon checking the IIS Virtual Directory for AutoDiscover, Indeed this setting was set to "Accept"

Fig 2. This is what caused the issue.

The Solution
Pretty obvious now, and so it seems from the (Clue) I find myself victim of inheriting a configuration that had been "tampered" with.  So simply set the SSL settings client certificate to Ignore.  All good !

Fig 3. Set back to Ignore. The resolution

Outlook 2010 Office 365 Direct Access Forced Tunnell Disconnected

Scenario
Windows 7 / Outlook 2010 SP2 + Patches Clients using Direct Access and configured for Forced Tunneling. Clients connect via a webproxy via DA Policy. User mailbox is migrated to Office 365 / Exchange online.  

Problem
When on WAN / LAN normal Wi-Fi, there are no issues. But when client connects over Direct Access, Outlook will not connect to Office 365 and says disconnected.  Windows 7 / Outlook 2010 is fully patched.  (this may be where the problem lies). Access to webmail, normal internet is fine.

Solution / Workaround
At the time of writing there is no official word on Microsoft on this issue. (Although we have a pending case, in which I will update accordingly).

But after trial and error, I stumbled across this KB.  (Not directly related but started the cogs turning.)
So I reversed this setting to Disable MAPI/HTTP (MS new way of connecting to Exchange) by adding the below Key.

Key: HKEY_CURRENT_USER\Software\Microsoft\Exchange
DWORD: MapiHttpDisabled
Value: 1

Note: The setting takes a few minutes to kick in, after it updates via AutoDiscover.

So how do you know when this is kicked in ?

 OK,  so where you would normally see the “connection” tab in account settings, when MAPI/HTTP is enabled,  This disappears..:) Once this is disabled.  It reappears..,

 

Once this became active. Outlook connected Via Direct Access !!!!   Thanks MS. Await the Official KB / Hotfix.... 

Office 365 Hybrid oauth issue - Event ID 3002 - IIS 401

Issue
Free busy requests fail from Office 365 users to on-premise users after oauth is enabled on an Exchange 2013 Hybrid server. 

you may see in the Event log:

event ID 3002
Protocol /EWS failed to process request from identity NT AUTHORITY\SYSTEM. Exception: Microsoft.Exchange.Security.OAuth.InvalidOAuthTokenException: The user specified by the user-context in the token does not exist.

You also may see in the exchange hybrid IIS logs something similar to the below. (where 401 is an authentication fail)

443 - 192.168.1.110 ASProxy/CrossForest/EmailDomain//15.01.0427.019 - 401 0 0 15

Resolution
If after applying the latest Exchange 2013 CU Updates this issue still persists, you can disable the oAuth connector in Exchange online to resolve this issue.

1. Open Exchange online Powershell and connect to your tenant.
2. Get-IntraOrganizationConnector MyHybridConnector | Set-IntraOrganizationConnector -Enabled $false

The change may take 30 minutes to fully update within Office 365, so please be patient.

This issue relates to KB https://support.microsoft.com/en-us/kb/3001281 but its is not clear on what the issue is or how it should be fixed other than disabling the connector. Assume CU would correct, but my lab was Running SP1 CU 11 and I had this issue.

Office 365 / Exchange Online - Outlook 2010 / 2013 /2016 Hangs on entering credentials.... (Not Responding)

Problem

Upon moving to Exchange online. You attempt to open Outlook (Either as en existing Profile (Mailbox Move) or new Profile.) When you are prompted to enter your credentials you are unable to do so and get "Not responding" and are unable to continue.

Cause

This issue is caused by "HP Client Security" Hi-Jacking the logon screen.

Resolution.

• Option 1
• Uninstall HP Client Security

Option 2

• Follow the steps below to disable the Logon Screen interaction.

.