Troubleshooting Outlook connectivity issues with Office 365 is tricky. Administrators can use two valuable tools provided by Microsoft to identify and even fix client related connectivity issues.
Start with the Outlook account problems test page in the Office 365 portal. You need to log on as the Office 365 user having issues.
The site tests for the following:
If no issues are identified after you've logged on to Office 365, move to the next step.
The Microsoft Support and Recovery Assistant (SARA) for Office 365 is click to run tool that is installed and executed locally.
These two tools fix most of the Outlook connectivity issues you are facing as an Office 365 administrator.
Enjoy Office 365
The latest downloadable build of Exchange Server 2016 Cumulative Update 9 disclosed an information that was previously shown accidently to the public by Greg T. during his breakout session BRK3249 - Modern Authentication for Exchange Server On-Premises at Microsoft Ignite 2017.
As part of the global harmonization of the product name space of the well established Outlook brand the next release of Exchange Server will be named Outlook Server 2019.
This name change was mentioned originally on this slide:
Give it a thought and you'll realize that this change makes absolute sense as different product names for the same software function distract customers and users.
Another reason for renaming Exchange Server is a new functionality for integrating personal mailbox files (PST). It was and still is a tedious task for administrators to get hold of all those PST files in use by end users. Instead of implementing a complex and data protection safe process to import PST files to the primary users mailbox the new Outlook Server 2019 offers synchronized PST folders. A functionality we've waited for for years.
Two new functions are introduced as part the new modern Outlook Server 2019
How does it work?
The following diagram illustrates the new functionality in a simple Outlook Server 2019 setup:
The following screenshot illustrates the new PSTSync folder and some sample PST file for a user with SAMAccountName JohnDoe
It's good the see that there is a future for a email server product like Exchange Server and that after so many years of cloud only an on-premises only feature got added.
Enjoy the day and Happy Easter!
Using this script you can test the domain availability in Office 365 and Azure AD. As there are different closed Office 365 and Azure AD regions you need to test per dedicated closed Office 365 region.
Regions currently implemented:
The script queries the login uri for the selected Office 365 region.
The response contains metadata about the domain queried. If the domain already exists in the specified region the metadata contains information if the domain is verified and/or federated.
Load function into your current PowerShell session:
. .\Test-DomainAvailability.ps1
# EXAMPLE # Test domain availability in the default region - Office 365 Global Test-DomainAvailability -DomainName example.com # EXAMPLE # Test domain availability in Office 365 China Test-DomainAvailability -DomainName example.com -LookupRegion China
Original source: https://blogs.technet.microsoft.com/tip_of_the_day/2017/02/16/cloud-tip-of-the-day-use-powershell-to-check-domain-availability-for-office-365-and-azure/
When you use the Office 365 Portal to move an on-premise mailbox to Office 365 (aka Office 365 Onboarding) you can either move
There is no option to move only the primary mailbox, if the mailbox already uses a cloud based archive mailbox.
The required option -PrimaryOnly can only be applied when using Remote PowerShell to Exchange Online.
The following lines describe how to move the primary mailbox that does have an enabled cloud archive to Office 365:
# UPN of user to migrate to Exchange Online $User = "UserToMigrate@mcsmemail.de" # FQDN of configured migration endpoint $RemoteHost = "MigrationEndpoint.mcsmemail.de" # EOL target delivery domain aka tenant domain $TargetDelivery = "tenant.onmicrosoft.com" # Onpremise credentials to access the source mailbox $OnPremCred = Get-Credential # New onboarding move request New-MoveRequest -Identity $User -Remote -RemoteHostName $RemoteHost -RemoteCredential $OnPremCred -TargetDeliveryDomain $TargetDelivery -SuspendWhenReadyToComplete:$false -PrimaryOnly
Your scripts can go from here.
Enjoy.
You need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid? You are interested in what Exchange Server 2016 has to offer for your environment?
Contact me at thomas@mcsmemail.de Follow at https://twitter.com/stensitzki
Sometimes you have the need to download the Offline Addressbook (OAB) for the Outlook email client manually.
When initiating a manual OAB download you might encounter a 0x80200051 error. A common mitigation scenario is to switch between Outlook Online-Mode and Outlook Cached-Mode multiple times. This mitigation scenario does not solve the issue.
When you active Outlook Cached-Mode it is required to perform a full OAB download. The OAB download dialogue provides an option to download OAB changes only. This option ist selected by default. To start a full OAB download you must deselect the checkbox.
Using this download setting you will not encounter the mentioned error and the Offline Addressbook is downloaded by your Outlook email client sucessfully.
Enjoy Outlook!
During DEV/IT Connection the new release of Office 365 for Exchange Professionals has been published.
Personally I recommend this book to every Exchange professional who wants to implement Exchange Hybrid setups or needs to migrate to Office 365. If you want to be successful, read this book and use it as a reference.
The information provided reflects the experience of the authors who contribute to the Exchange community regularly. This has been written without any Office 365 marketing stuff in mind. (As one of the authrors is Tony Redmond).
The chapters provide an overview of the various technologies as well as detailed informations for the day to day work of an Exchange administrator. Notes from the field help to understand the complex (or not so complex at all) requirements of Exchange hybrid configurations.
Due to the nature of "The Service", an Exchange administrators needs to keep up with the changes deployed constantly. This book covers the most recent changes and evolvement to "The Service" like Groups or Delve.
I will kep it short:
Buy It. Read It. Enjoy It.
Not joking...
Buy the Book
This blog post focusses on an issue where your Exchange Online users are not able to send emails to other Exchange Online recipients outside of your organization when using a 3rd Party Centralized Email Flow Setup. The term 3rd Party Centralized Email Flow Setup describes a solution where you not follow the preferred hybrid architecture proposed by the Exchange product group, but use a 3rd party software as a centralized email gateway.
You have followed the recommendation to secure the Exchange Online inbound connector for your on-premises email servers by using a certificate name or the remote IP address of your on-premises email gateway.
The on-premises email security gateway utilizes a self-signed certificate to secure TLS connections. The gateway is configured to use two different send connector setups:
In this case Exchange Online Protection (EOP) will not be able to differentiate between tenant internal inbound mail flow and mail flow targeted to other tenants. Therefore, email messages sent from your Exchange Online users to recipients located in other Exchange Online tenants will be discarded.
Interestingly enough, this will happen silently. Your gateway solution will log a successful delivery to Exchange Online Protection. The tenant administrator of the recipient domain will not find an any information in the Exchange Online message tracking logs.
The following diagram illustrates the setup.
The solution for this problem is pretty simple. Just use dedicated certificates for each connector targetting Exchange Online.
Change the Internet Connector to fully trusted 3rd party certificate. In this case you are not required to modify the existing Exchange Online inbound connector setup.
The new connector configurations are:
The following diagram illustrates the new setup:
Enjoy!