Getting the mailboxes to which you have full access automatically mapped in the Outlook profile dates back to Exchange 2010. While it is a time saver in an on-premise deployment of Exchange 2010, how will things be when these mailboxes are migrated to Office 365 in a hybrid deployment?
When a federated user tried logging into Office 365 portal, the generic “We have received a bad request” error came up in the browser. The detailed information towards the bottom of the browser had a proper error.
While trying to change the configuration on a hot standby Azure AD Connect server, the “cannot change configuration” error comes up and what is interesting is that it complains about a synchronization in progress as the cause. But, how can a standby server be synchronizing?
Most of the admins are familiar with Clutter in an Office 365 mailbox these days and have mixed opinion about the feature. Machine learning is in its early stages and things can only improve.
While migrating from on-premise Exchange to Office 365, which one is a better choice – the new Migration Batch or the good old Move Request?
As part of the hybrid deployment testing at a customer site, emails that were sent from an on-premise mailbox to an Office 365 user was always failing and the NDR was very clear as well. The Exchange Online Protection was blocking emails from the customer’s outgoing public IP address.
“Unable to connect to synchronisation service after installing Azure AD Connect” error comes up if you try to launch Synchronization Services Manager straight after installing Azure AD Connect.
While working at a customer site, I was notified that the AAD Connect hasn’t synchronized in the last 24 hours. Checking out the portal confirmed that even though password sync was working.
How to fix the User realm discovery failed error while configuring Azure AD Connect.
Microsoft has released Cumulative Update 2 for Exchange Server 2016. This release adds support to .NET Framework 4.6.1, the same goes for Exchange 2013 CU13 as well.