Hurrah! If you have not yet heard: Exchange Server 2019 Public preview was announced earlier, and it is the first version of Exchange that you can install on Server Core!

Now, while that’s great news, if you haven’t worked on Server Core, there may be bit of a learning curve. The purpose of this post is to help you install the Exchange Server 2019 on Server Core in your lab.

We are going to assume that you have:

1. Installed an Active Directory global catalog domain controller. Exchange Server 2019 will work with writable DCs running Windows 2012 R2 and above. Here’s a link to get you going with Active Directory, in case you have not installed it yet.
2. Installed Windows Server 2019 (or Windows Server 2016) Server Core operating system.

(In case you need help with Server Core deployment, please follow this link).

Getting started

Once you have installed Server Core and booted it up, you may find yourself staring at this strange, unfamiliar login prompt:

From here on, this command line interface is your friend!

Once you’re logged in, you will get the basic Command prompt window. From here, you can use the start command to launch processes into a new window. For instance, if you type start powershell, PowerShell will be launched into a new window. You can also type start cmd to launch an additional instance of the command interpreter. You can use exit to close any process. Typing taskmgr will launch the graphical based TaskMgr application.

Example:

If you close all command prompt windows and want to open a new one, you can do that from the Task Manager. To launch Task Manager try the CTRL+ESC shortcut, or if you’re logged in via Remote Desktop you may need to use CTRL+ALT+DELETE, click Start Task Manager. Then, , click More Details > File > Run, and then type cmd.exe. (Or Powershell.exe to open a PowerShell command window.) Alternatively, you can sign out and then sign back in.

Prepare the OS for Exchange installation

The following are preliminary tasks you will need to perform to configure the OS for Exchange installation. You can use Sconfig to configure the IP Address, install Windows Updates, enable remote desktop and join the server to AD domain. Alternatively, you can use PowerShell commands to perform each of these tasks, which is useful for scripted installations as well.

Configure IP Address:

Use the Get-NetIPAddress PowerShell command and identify interface index you want to configure the static IP on. Mostly, this should be the one that has Interface Alias Ethernet and AIPA auto assigned DHCP Address.

Sample Get-NetIPAddress output:

Then use the following command to assign a static IP:

New-NetIPAddress -InterfaceIndex 6 -IPAddress 192.168.12.123 -PrefixLength 24 -DefaultGateway 192.168.12.100

If you are going to use a DHCP assigned IP Address, inspect the IP configuration provided.

Configure a DNS Server

Set-DNSClientServerAddress -InterfaceIndex 6 -ServerAddress "192.168.12.121"

Enable Remote Desktop:

cscript C:\Windows\System32\Scregedit.wsf /ar 0

Windows features

Use the following PowerShell command to install the OS component required for Microsoft UCMA 4.0 and the OS component required for Active Directory Preparation.

Install-WindowsFeature Server-Media-Foundation, RSAT-ADDS

Download necessary software

From an admin workstation, download the following software and copy it over to the Server Core we are preparing for the Exchange installation (let’s say you copy the files into a C:\Software folder):

• Exchange Server 2019 Public Preview
• Visual C++ Redistributable Packages for Visual Studio 2013 (vcredist_x64.exe)
• .Net 4.7.1 offline installer (required only for Windows Server 2016)

Then login to Server Core and do the following:

Install VC++ 2013 Redistributable

Install UCMA (Microsoft Unified Communications Managed API 4.0)

The UCMA installable is present on the Exchange Server 2019 media itself. Use the following PowerShell command to mount the Exchange Server media:

Mount-DiskImage c:\<FolderPath>\ExchangeServer2019-x64.iso

The UCMA installable is located under the “UCMARedist” folder on the Exchange Server 2019 .ISO. Start the UCMA installation:

.Net 4.7.1

Check the .Net version installed by following this link

If you are not on .Net version 4.7.1 already, use the following command to install the .Net 4.7.1 (not required on Windows Server 2019 Server Core):

C:\<FolderPath>\NDP471-KB4033342-x86-x64-AllOS-ENU.exe /q /log c:\temp\ndp.log

The .Net installation will continue in quiet mode, i.e. no progress bar will be displayed. At the end of successful installation, you will be asked to restart the computer. You can also take a look at the log file to check progress of the installation.

Start Notepad c:\temp\ndp.log

Do not reboot the server just yet; join the computer to an AD domain and then reboot it.

Joining the computer to AD domain

The following command will:

• Rename the computer to E19Core1
• Add the computer to domain corp.contoso.com

Add-Computer -DomainName corp.contoso.com -NewName E19Core1 -DomainCredential contoso\administrator

Restart the server

Use the following PowerShell command to restart the computer:

Restart-Computer -Force

Exchange installation

After rebooting the server mount the Exchange .ISO image again using Mount-DiskImage as you did before.

Use the following command to start Exchange Server installation. The PowerShell command will also install the required OS components for Exchange:

.\Setup.exe /m:install /roles:m /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents

Notepad is available on Server Core, in case you want to open the Exchange Setup log just for review or to troubleshoot any exchange setup issues. Launch it as follows:

start notepad c:\ExchangeSetupLogs\ExchangeSetup.log

Once Exchange is installed, you can launch the Exchange Management Shell using LaunchEMS command from the command line.

Alternatively, you can also use web browser from an admin workstation to access Exchange Admin Center.

Summary

We hope this article will help you to get started with your Exchange Server 2019 deployment on Server Core and help you perform various Exchange admin tasks once you are done!

Here are some more links that you can use to learn more!

Getting started with Server Core

Use the following information to install, configure, and manage the Server Core installation option of Windows Server.

Server Core installation:

• Roles, Role Services, and Features included in Server Core
• Roles, Role Services, and Features not in Server Core
• Install the Server Core installation option
• Configure Server Core with the SConfig tool

Using Server Core:

• Basic Server Core administration tasks using Windows PowerShell or the command line
• Manage Server Core
• Patching Server Core
• Configure memory dump files
• Windows Admin Center

Bhalchandra Atre

Unless you’ve been living under an IT rock, you’ll know that Microsoft Ignite is happening soon. September 24^th to 28^th to be exact, in Orlando Florida.

If you didn’t buy a ticket already then I’m sorry to break to you that you are too late. It’s sold out! But it’s not all bad news; far from it. We have some great sessions planned and you’ll be able to watch them LIVE.

Yes, we’re streaming many sessions at the same time as they are delivered to the attendees live. Make sure you go back to the Microsoft Ignite 2018 site on the 24^th and watch them there, or get links to breakout sessions.

The Session Catalog went live this week and you can use it to find the sessions you want to see right away. There are a few sessions I wanted to shout out to make sure you knew about them.

• We have a session with more details on Exchange Server 2019. That’s BRK2176 - Welcome to Exchange Server 2019! And it’s on Monday, September 24, 4:00 PM - 5:15 PM.
• We’re going to wheel Scott Schnoll back out for the 873^rd edition of Scott Schnoll’s Exchange and Office 365 tips and tricks – that’s BRK3147 and is planned for Friday, September 28 12:30 PM - 1:45 PM
• Jeff Kizner is going to update you all on the latest happenings in all things Hybrid and more. If you missed Jeff’s session last year you missed one of the most informational sessions at Ignite. Watch it this year - BRK3143 - Hybrid Exchange: Making it easier and faster to move to the cloud - Wednesday, September 26 - 10:45 AM - 12:00 PM
• Brandon Koeller is going to demo the most common attacks against Exchange Online and explore what you can do to prevent, detect, investigate, and remediate those attacks. Don’t miss that - BRK3148 - Securing Exchange Online from modern threats - Tuesday, September 25 10:45 AM - 12:00 PM
• Ross Smith IV will of course be there too, and he’s going to explain how to securely deploy Microsoft Outlook for iOS and Android - BRK3145 - Deploying Outlook mobile securely in the enterprise - Thursday, September 27 10:45 AM - 12:00 PM
• One of the highest rated sessions at Ignite last year was delivered by Julia Foran. So make sure you see her (and Jennifer Lu too this year, and those two are quite a double act I promise you.) They will tell you What's amazing and new in calendaring in Outlook! In BRK3146 - Thursday, September 27, 9:00 AM - 10:15 AM

There are many more sessions, breakout and theaters. And many of the sessions are being delivered by the awesome MVP’s we have, but I can’t list them all here. So go take a look at the catalog and start figuring out what you want to go and see, or tune in to, LIVE.

For those of you actually in Orlando we have a special treat. We are sponsoring the Scheduled Maintenance party this year. If you have heard of that party (hosted by a Gold Partner - ENow Software) you’ll know it’s the hottest party of the week – and this year it’s being sponsored by Exchange and Outlook. So, if you want a chance to come and socialize with the engineering team, MVP’s and speakers, go and sign up. We know it will be over-subscribed and not everyone who wants to be there will be able to, but you can’t join if you don’t sign up and we would love to see as many of you there as we can.

See you in Orlando (or LIVE streaming)!

Greg Taylor
Director of Product Marketing
Exchange Server and Online

What just happened?

During a rousing presentation that was marked by wild cheers and standing ovations, we announced a few features designed to simplify hybrid Exchange deployments and speed onboarding to Exchange Online (EXO).

The features we discussed focused on two key problems, hybrid administration and configuration as customers prepare to move to the cloud and the complexities and security blockers some customers face when publishing their on-premises environments.

Let’s review.

Administration and Configuration

Back in June, we launched Organization Configuration Transfer (OCT). The idea is to take the configurations made in Exchange Server on-premises and transfer them to Exchange Online to reduce the burden of re-configuring all your settings before onboarding. Today we announced OCTv2, due out October 2018.

What does OCTv2 do?

First and foremost, seven additional objects have been added to OCT as part of v2.

But the real difference in v2 is how we deal with object conflicts.

In OCTv1, we run a bunch of new-* commands and when we find an object on-prem that matches and object with the same name in the cloud, we simple skip over it. As part of v2, if an object with the same name already exists both on-premises and online, you can now choose to either overwrite the values of the objects in EXO or keep them as is. And, just in case you overwrite the cloud settings and didn’t mean to, we’ve provided a rollback script to undo those changes.

What are the Exchange Server Versions supported?

OCT supports Exchange Server 2016, 2013 and 2010. OCT requires the latest cumulative update or update roll-up available for the version of Exchange you have installed in the on-premises organization. But if that’s really too much of a burden, the immediate previous release is also supported. You want to run any other CUs or RUs, you’re out of luck.

Exchange Server 2019 will be supported once it reaches GA.

Hybrid Publishing

To establish a hybrid Exchange environment, customers must publish their on-premises environments. This includes, but is not limited to, adding external DNS entries, updating certificates, and allowing inbound network connections through your firewall. Over time, we’ve learned of two consistent problems here, (1) this is hard for some customers. The number of support cases asking for help in these areas tells us that. And (2) some customers, really their security wonks, do not want to publish their on-premises environments to the internet.

The Microsoft Hybrid Agent

Today, we introduced the world to the Hybrid Agent. Put simply, the goal of the Hybrid Agent is to fix those customer problems. Now, when running the Hybrid Configuration Wizard (HCW) you are presented with the option to use Exchange Modern Hybrid

This will install an agent, built on the same technology as Azure Application Proxy, this will publish your Exchange on-premises environment to EXO without requiring any of the changes customers have struggled with.

V1 of the Hybrid Agent will support the core scenarios of mailbox moves and free/busy for your hybrid deployment and is in private preview now. We’re focused on getting to public preview and GA as quickly as possible. In the meantime, we’re also working on additional scenarios we can support with the Hybrid Agent.

What’s next?

Well, if you missed the session at Ignite, go back and watch the replay (when available). Then come back here and stay tuned for updates.

Kavya Chandra, Georgia Huggins

In the security advisories released on 10/09/2018, CVE-2010-3190 was updated to apply to Exchange Server. This bulletin now applies to all versions and cumulative updates for Exchange Server released prior to October 2018.

The Exchange team is aware that the installation program for Exchange Server is applying an unpatched version of a Visual Studio released binary which was updated in the package to address CVE-2010-3190.

The Exchange team encourages customers to apply the KB2565063 update described in MS11-025 to all Exchange servers.

This action is necessary to ensure servers are protected against the vulnerability outlined in the advisory.  Windows Update and Microsoft Update will not automatically apply this update to an Exchange Server.  The installation of a cumulative update released prior to October 2018 will overwrite the affected binary even if MS11-025 was previously applied to the server.  The advisory lists the MS11-025 update as important indicating there is low to medium risk associated with the vulnerability.  Microsoft is not aware of any instances where the exploit has been used against an Exchange Server.

Applying this update does not require a reboot of the server or stopping any Exchange services.

The Exchange team considers ensuring the security of your servers and data our top priority.  We have examined the Exchange installation process to identify any additional similar scenarios where dependent binaries are not being properly updated when Exchange is installed.  We have modified Exchange installation so that all cumulative updates released after September 2018 will no longer install dependent Visual Studio binaries.  We have added pre-requisite rules to ensure that the correct version of the Visual C++ and Microsoft Foundation Class (MFC) libraries are installed via their native redistribution package before Exchange installation will proceed.  The steps taken will ensure that the correct versions of system and shared binaries are installed and that Windows Update and Microsoft Update are able to detect the need for any future updates to these dependent binaries.

The Exchange Team

The latest cumulative update for Exchange Server 2016 is now available on the download center. There is no release for Exchange Server 2013 or Exchange Server 2010 as these products are both in the extended support phase of lifecycle. The cumulative update released today includes fixes to customer reported issues, all previously reported security/quality issues and updated functionality.

Updated Pre-requisite requirements

.NET Framework 4.7.2 Support

.NET Framework 4.7.2 is now supported with Exchange Server 2016 Cumulative Update 11. .NET Framework 4.7.2 will be required on Exchange Server 2016 with the Cumulative Update released in June, 2019.

We have validated .NET Framework 4.7.2 on the previously released Exchange Server 2013 Cumulative Update 21 and are announcing .NET Framework support with Exchange Server 2013 Cumulative Update 21 as well.

.NET Framework 4.7.2 will be required on the forthcoming Exchange Server 2019. Windows Server 2019, which is also required for Exchange Server 2019, installs .NET Framework 4.7.2 by default.

Changes to Visual C++ Version Dependencies

With today’s release we are updating the Visual C++ runtime version dependencies on Exchange Server 2016. Effective with Cumulative Update 11, all Exchange Server 2016 roles (Management Tools, Mailbox, Edge) will require installation of Visual C++ 2012 runtime. This is a change from Cumulative Update 10 where Visual C++ 2013 was incorrectly listed as being required on all roles. Visual C++ 2013 runtime, in addition to Visual C++ 2012, is required on the Mailbox role only.

Versions of Exchange setup before Cumulative Update 11 silently installed Visual C++ 2010 and 2012 components. Exchange setup has been changed in Cumulative Update 11 and later to enforce the Visual C++ runtime requirements using setup pre-requisite rules. When installing Cumulative Update 11 or later for the first time on an existing server, setup will detect the presence of the previously installed instances of Visual C++ placed there by Exchange setup and will not indicate that the Visual C++ 2012 runtime needs to be installed.

However, when setup performs the first upgrade of a server to Cumulative Update 11 or later, it will remove the versions of the Visual C++ binaries placed there by Exchange setup previously. This removal is necessary to change setup behavior, correct the condition which caused us to issue an advisory to install MS11-025 and ensure that future Visual C++ updates are applied by Windows Update and Microsoft Update.

Important: To avoid a setup failure, it is necessary to install the Visual C++ 2012 runtime before installing Cumulative Update 11 or later for the first time on an existing server. The setup pre-requisite rule works as expected when using Cumulative Update 11 or later to install a new server using the Cumulative Update 11 or later package.

Note: Exchange Server 2019, when released, will include the Visual C++ pre-requisite rules enforced by setup.

Release Details

KB articles that describe the fixes in each release are available as follows:

• Exchange Server 2016 Cumulative Update 11 (KB4134118), Download, UM Lang Packs

The updates released today do not include new updates to Active Directory Schema. If upgrading from an older Exchange version or installing a new server, Active Directory updates may still be required. These updates will apply automatically during setup if the logged on user has the required permissions. If the Exchange Administrator lacks permissions to update Active Directory Schema, a Schema Admin must execute SETUP /PrepareSchema prior to the first Exchange Server installation or upgrade.

Cumulative Update 11 does require an Administrator to execute SETUP /PrepareAD to ensure RBAC roles are current before applying the cumulative update released today.

Adjustment to Cumulative Update Release Schedule

Due to the delay associated with Cumulative Update 11, there will not be a cumulative update released in December 2018. Our next planned set of quarterly updates will occur in March 2019 and will include Exchange Server 2016 Cumulative Update 12 and Exchange Server 2019 Cumulative Update 1.

Additional Information

Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate TechNet documentation.

Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.

Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the currently supported cumulative update for the product version in use, e.g., 2013 Cumulative Update 21, 2016 Cumulative Update 10 or 9.

For the latest information on Exchange Server and product announcements please see What's New in Exchange Server 2016 and Exchange Server 2016 Release Notes. You can also find updated information on Exchange Server 2013 in What’s New in Exchange Server 2013, Release Notes and product documentation available on TechNet.

Note: Documentation may not be fully available at the time this post is published.

The Exchange Team

Several months ago we added a feature to the Microsoft 365 Roadmap which generated a lot of interest. The feature was named Disable Basic Authentication in Exchange Online using Authentication Policies and as the roadmap items stated - it provided the capability for an Admin to define protocols which should allow Basic Authentication.

Why was that so interesting? Well as you probably know, Basic authentication in Exchange Online accepts a username and a password for client access requests and blocking Basic authentication can help protect your Exchange Online organization from brute force or password spray attacks. Lately there has been an increase in the occurrence of these types of attacks, and so we are accelerating our release of this feature as it helps prevent them.

If your organization has no legacy email clients or doesn’t want to allow legacy email clients, you can use these new authentication policies in Exchange Online to disable Basic authentication requests. This forces all client access requests to use modern authentication, which will stop these attacks from impacting your organization.

We are still working on some aspects of this feature, and we’ll highlight those for you here, but in response to the increase of attacks we are seeing, we want to make authentication policies available to you now, and are therefore rolling this out worldwide immediately.

There is already an excellent article describing how this feature works and we strongly suggest you read, understand and follow the article before enabling this feature.

There are three important caveats to this feature:

• There is a lack of telemetry for tenant admins allowing them to report on which users are using Basic Auth (and with which protocol) and once a block is enabled, whether such traffic was blocked. In other words, we can’t really tell you how well the block is working.
• A policy change can take up to 24 hours to take effect, unless the admin calls a cmdlet (such as Set-User) to ‘tickle’ each user. (Note that ‘tickling’ is a technical term, first used here). So the block might not kick in right away, and you might have to take some action if you want it to happen faster.
• If a user’s identity has not been replicated to Azure AD/Exchange Online, they will not be blocked and so any request received by Exchange Online will be routed to the authoritative Security Token Service (STS) where it is likely to fail. This same behavior also means that any authentication requests for unknown users in a tenant (such as might happen during a password spray attack) will also be forwarded to the authoritative STS for the domain.

We had been holding back on moving from private to public preview primarily due the first two of these - a tenant admin could misconfigure something and not realize until it’s too late due to the lack of reporting and the delayed effect of policy change.

However, given the increasing frequency of these types of attacks we would rather give you access to the capability, knowing you will all carefully read the documentation before configuring. We’ll continue to work on improving the feature set, but you don’t need to wait for us.

We acknowledge that for large customers, tickling every user using Exchange Online PowerShell (which can be unreliable for long running scripts) is challenging, but again we feel the benefit outweighs the negatives at this stage.

It’s in all our interests to prevent these types of attacks from compromising our data and users, and we hope you find these tools useful and helpful. Use them wisely!

The Exchange Team

Up to now, Administrators did not have control over which users would see public folders in their Outlook clients. If public folders were created within the organization or if an Exchange Online organization is configured to access on-premises public folders, all clients would make a connection to and show the “Public folders” object in Outlook. From there, one could control access to individual public folders (controlled through folder permissions). However, it was difficult to have only some of Outlook clients connect to public folders.

We are now introducing the ability to show the public folder object in Outlook to only a set of users who might need them. To get started, this will be available for Outlook for Windows users only.

To do this, administrators can use two parameters:

• PublicFolderClientAccess is an optional parameter on the user object. By default, its value is set to ‘false’. Setting this to ‘true’ on a specific user designates this user as one of users who will see public folders in Outlook.
• PublicFolderShowClientControl parameter on the organization config. By default, the value of this parameter is also ‘false’ and once it is set to ‘true’, the controlled access of public folders is enabled.

Here is an example of how to use these parameters; to enable access to only the user “Administrator” and turn the feature on for the organization:

Set-CASMailbox “Administrator" -PublicFolderClientAccess $true
Set-OrganizationConfig -PublicFolderShowClientControl $true

Important note: setting the organization parameter to true without setting user attributes to true first will make it so no users will see the public folder object in Outlook for Windows. In other words – if you want to implement this, we suggest that you plan ahead and populate user attributes first (PublicFolderClientAccess on users that need access set to true) and then set the organization level parameter (PublicFolderShowClientControl set to true). That way, users who need to have access will not lose access unexpectedly.

Why would you want to do this?

Tenant admins will now have more flexibility over which users connect to public folders in Outlook. This will benefit very large organizations who might have issues with connection limits to public folders and will reduce the load to that infrastructure.

This will also be helpful to organizations during mergers and acquisitions if moving to EXO. Imagine one organization having existing public folders, but after the companies merge – without this feature all of the users would unnecessarily connect to the public folder hierarchy.

Note: This feature is not intended to be replacement for public folder permissions, it is merely providing means to have more control over which clients connect to the public folder tree.

A few more questions answered that you might be interested in:

Will this work for only Outlook on Windows?

At this time, yes. We are working to bring this to additional clients (like Outlook for Mac or Outlook on the web) in the future and will talk about this later.

What about on-premises servers?

We are considering support for on-premises in a future CUs and we will provide details at the later time.

Is there a specific version of Outlook that I need to see changed behavior?

No. The feature works by removing the public folder information from the Autodiscover response to Outlook for Windows clients. Therefore, if the user is not enabled for public folder access they will simply not connect to the public folder tree no matter the version of Outlook for Windows they use.

In case of any questions, please do reach out to us via the comments section below. We are updating official documentation to add those parameters.

Public folder team

We’re pleased to announce the final build of Exchange Server 2019 is now available and can be downloaded from the Volume Licensing Service Center.

Exchange Server 2019 is designed to deliver security, performance and improved administration and management capabilities; attributes our largest on-premises customers expect from Exchange.

If you haven’t yet seen the session delivered at Microsoft Ignite 2018 we suggest you watch the video and download the slides here. During that session we talked for the first time about how the code paths between on-premises and online have separated, and the impact to on-premises customers – in short, less code churn and more stability.

Here is a selection of other key features in Exchange Server 2019:

Security: Exchange Server 2019 requires Windows Server 2019. In fact, we recommend installing Exchange Server 2019 onto Windows Server 2019 Server Core. Exchange Server 2019 installed on Windows Server 2019 Core provides the most secure platform for Exchange. You also have the option of installing Exchange 2019 onto Windows Server 2019 with Desktop Experience, but we have worked hard to make sure running Exchange on Server Core is the best choice for our code.

We’re aware all media for Windows Server 2019 and Windows Server, version 1809 has been temporarily removed and Microsoft will provide an update when refreshed media is available. Exchange Server 2019 will be fully compatible with version 1809, and the refreshed version.

We also built Exchange Server 2019 to only use TLS 1.2 out of the box, and to remove legacy ciphers and hashing algorithms. To understand how this affects coexistence with earlier versions, please reference our previous series of posts on TLS.

Performance: We’ve done significant work to allow Exchange Server to take advantage of larger core and memory packed systems available in market today. With our improvements, Exchange Server can use up to 48 processor cores and 256GB of RAM.

We’ve re-engineered search using Bing technology to make it even faster and provide better results, and in doing so have made database failovers much faster, and administration easier.

We’re adding dual storage read/write capabilities to Exchange Server 2019 using Solid State Drive (SSD) technology to provide a super-fast cache of key data for improving end user experience. We also talked about this in our Email Search in a Flash! Accelerating Exchange 2019 with SSDs session at Ignite.

We also changed the way database caching works to allocate more memory to active database copies, again improving the end user experience. You can learn more about Dynamic Database Cache from Welcome to Exchange Server 2019! video and slides.

The improvements we have made to Exchange Server 2019 will enable you to scale to a larger number of users per server than ever before, use much larger disks, and see the latency of many client operations being cut in half.

End user experience: We all rely on Exchange for calendaring, and we know large enterprises are heavy calendar users. We are bringing a few key features such as restricting the forwarding of meeting requests and better control over OOF settings to Exchange Server 2019. Administrators get some new calendaring features too, as we’re adding the ability to manage events on user’s calendars and assign delegate permissions more easily.

We are also adding support for routing mail to and from EAI/IDN recipients and hope to add additional capabilities in this area in the future.

The session recording also goes into some of the other features we have plans for, so make sure you watch it to the very end.

As we mentioned in the Preview post in July, the Unified Messaging role will not be available in Exchange Server 2019. Customers who currently connect either a 3rd party PBX or Skype for Business Server to Exchange Server won’t be able to do so with Exchange Server 2019 mailboxes. Those customers considering an upgrade to Exchange Server 2019 should consider migrating to Skype for Business Server 2019 and using Cloud Voicemail, or migrating to Office 365 with Cloud Voicemail.

Our official product documentation is now live, and we’ll be publishing the updated Preferred Architecture documentation soon.

We’re also pleased to also announce there are even more Office Server products releasing today! You can read more about those releases here.

We look forward to your feedback and thank you for your continued support and love of Exchange.

The Exchange Team

Microsoft Ignite 2018 ended a few weeks ago, and what a great event it was. It was great to see so many of our customers, partners and friends there – thank you for coming to our sessions, thank you for coming to the booth, thank you for hanging out with us whenever the opportunity arose and thank you for giving us great feedback on what we’re doing. We’re still recovering but we heard you and are focused on doing a better job because of it.

All of the sessions were recorded this year, and so here’s a handy reference to all the sessions in the Exchange and Outlook track, and some others we think you’ll find interesting, so you can refer back here whenever you want to find one.

You will need an account in Tech Community to access them, but that’s something you should have anyway.

So here’s a long list of sessions, in no particular order but grouped by technology as much as possible.

Exchange

• Welcome to Exchange 2019!
• Panel discussion: Microsoft Exchange/Calendar/OWA
• Hybrid Exchange – Making it easier and faster to move to the cloud
• Scott Schnoll's Exchange and Office 365 Tips & Tricks
• Securing Exchange Online from Modern Threats
• So long and thanks for all the (email) phish
• Email Search in a Flash! Accelerating Exchange 2019 with SSDs
• Turbo charge your Exchange on-premises and Hybrid environment – Notes from the field
• How to add MFA to your Exchange On-Prem/Online mailboxes in 20 minutes or less
• Preparing to Move (or remove) Those Public Folders to the Cloud
• Why do we need to keep an Exchange Server on-premises when we move to the cloud?
• Making the best of the cloud: How Exchange Online is different from Exchange on-premises
• Azure Information Protection and Exchange Online - better together
• Securing your Office 365 environment from advanced phishing campaigns with Office 365 Advanced Threat Protection

Outlook

• Deep dive into what’s new and coming soon to Outlook for Windows and Mac
• Outlook mobile in the Enterprise
• Deploying Outlook mobile securely in the enterprise
• What's Amazing and New in Calendaring in Outlook!
• Outlook on the web - What's new and why you should care!
• The Best (Outlook driven) Day of Your Life
• Success through people with LinkedIn and Microsoft 365
• What's New in groups in Outlook
• Panel discussion: Microsoft Outlook (Windows, Mac, and Mobile)
• Let the intelligence built into Outlook help you to make time for what really matters
• Simple room booking in Outlook using new built-in Intelligence
• The Power of People in Outlook
• Security made real with Outlook mobile in-app experiences
• Outlook on the web: Don’t block your users, restrict them with conditional access/limited access!
• Adaptive Cards in Teams, Windows, Outlook and your own applications
• Create engaging, powerful new business processes in Microsoft Outlook with Adaptive Cards

Office 365

• Notes from the field: how we moved a large global bank to Office 365
• Office 365 – Marriages, Divorces and Adoptions
• Getting stuff done: Solving Office 365 problems with PowerShell
• How to be an author and write about Office 365
• Real-world best practices for managing Office 365 groups
• Embrace Office 365 Groups: What's new and how to get started
• Office 365 Groups automation inside-out
• Delivering Office 365 as an evergreen service: What to do, and more importantly, what not to do
• Understanding how Microsoft Information Protection capabilities work together to protect sensitive information across devices, apps, and services
• Secure enterprise productivity with Office 365 threat protection services including EOP, ATP, and Threat Intelligence
• Strategies for building effective, optimal and future proof connectivity to Office 365 that will delight your users
• Implementing a modern network architecture to get the most out of Office 365
• Addressing global data residency needs with Multi-Geo in Office 365

Podcasts/Broadcasts

• Ross Smith IV & Greg Taylor on theCUBE
• Scott Schnoll & Jeff Mealiffe on theCUBE
• Ross Smith IV on Channel 9 talking about Outlook mobile
• Greg Taylor on Channel 9 talking about Exchange Server 2019
• Greg Taylor, Tony Redmond and Paul Robichaux – Office 365 Exposed talking about random stuff

It’s possible we missed a session you think we should have included (there were 750 or more after all), if so, add it to the comments section so people can find it. Thanks!

Happy watching!

And see you next year for more of the same. Microsoft Ignite 2019 here we come!

Greg Taylor
Director of Product Marketing
Exchange Server and Online

In an earlier post, we announced we were increasing the maximum number of public folders that could be migrated from Exchange Server 2010 to Exchange Online to 250K. We also highlighted in that post that the migration of public folders on Exchange Server 2013 and 2016 were limited to 100K.

We’ve been working hard to remove this limitation and we are very pleased to announce today that we now support migrating up to 250K public folders from Exchange On-Premises 2013/2016/2019 to Exchange Online.

What does all this mean to you?

• Any Exchange On-Premises customer running Exchange 2010/2013/2016/2019 with up to 250K public folders can now migrate them directly to Exchange Online.

Please do check this link for planning migration of public folders to Exchange Online. The current Exchange Online limits can be viewed here.

We’ve love to hear your feedback and please feel free to ask any questions via the comments section below.

Public folder team

We are happy to announce Organization Configuration Transfer (OCT) - V2, which includes updates to OCT-Phase 1 that was launched earlier this year. OCT-V2 further reduces the manual work that admins are required to do once the hybrid setup is complete. OCT-V2 is now available as part of the Hybrid Configuration Wizard (HCW).

What does OCT-V2 include?

OCT-V2 not only copies the organization policy objects from on-premises to Exchange Online (EXO), but also updates the values in EXO with the values from on-premises. Seven additional objects have been added to OCT as part of V2. The list of objects considered in OCT so far are:

OCT (available since June 2018)

• Active Sync Mailbox Policy
• Mobile Device Mailbox Policy
• OWA Mailbox Policy
• Retention Policy
• Retention Policy Tag

OCT-V2 (available now)

• Active Sync Device Access Rule
• Active Sync Organization Settings
• Address List
• DLP Policy
• Malware Filter Policy
• Organization Config
• Policy Tip Config

If object values are updated on-premises after they are moved to EXO, admins can re-run OCT to copy over the updated values from on-premises to EXO. Admins will continue to control the process of keeping the objects in sync but with reduced effort by using OCT.

How is V2 different from the initial version of OCT that was launched in June 2018?

Phase 1 of OCT dealt only with copying objects from on-premises to EXO. However, it did not edit/update the parameters in EXO. As part of V2, if an object with the same name already exists in both on-premises and EXO, admins can now choose to either overwrite the values of the objects in EXO or keep them as is. A rollback script with values of the objects prior to the update in EXO will be available to admins in the log folder.

What are the Exchange Server Versions supported?

The supported versions are Exchange Server 2019, 2016, 2013 and 2010. OCT-V2 requires the latest cumulative update or update roll-up available for the version of Exchange you have installed in the on-premises organization. If you cannot install the latest cumulative update or update roll-up, the immediate previous release is also supported. Older cumulative updates or update roll-ups are not supported.

Kavya Chandra

We have been working hard behind the scenes to improve the public folder migration experience and are very glad to announce even more improvements. These improvements will help you in faster onboarding of public folders to Exchange Online.

Speed improvements

Mailbox Replication Service (MRS) performs certain clean-up tasks during the finalization phase of the migration. If a clean-up task fails, it is retried for up to 4 hours. Ultimately it will delay the finalization of the migration request. And the delay will be even more if there are a greater number of migration jobs in the batch.

We have made improvements to the clean-up tasks that take place during finalization of the public folder migration. After these improvements we have observed large public folder migrations, which historically could have taken 3-4 days, are completed in only 15-20 hours.

Reliability improvements

Previously, if a migration batch encountered a non-fatal warning, a warning which could be ignored, it would still be marked as Failed. In such scenarios, a tenant admin would have to re-submit the migration batch, potentially causing significant delays in migration.

We have made improvements in this area. If the migration batch completes with those same non-fatal warnings, the batch is treated as completed successfully. This allows for faster completion of public folder migrations, without compromising the data integrity.

These improvements are being rolled out to Exchange Online and should be available to your tenant soon.

We’ve love to hear your feedback and please feel free to ask any questions via the comments section below.

Public Folder Team

Working in support at Microsoft, you get to deal with a lot of organizations who are migrating to Exchange Online. This type of migration dramatically changes how web traffic flows in the organization as the traffic moves away from Exchange on the Local Area Network to servers hosted by Microsoft in a Microsoft Data Center, essentially a remote internet location.

We spend plenty of time troubleshooting Outlook when a customer has difficulties connecting to their Office 365 mailbox. We troubleshoot other connectivity issues too of course, and we continually use tools such as The Support and Recovery Assistant (SARA), (top support tip: particularly useful to detect client based issues is the Collect Information about my Outlook configuration option in SARA) Outlook ETL files (which can only be viewed by Microsoft support), and Fiddler traces to see the conversation between the Outlook client and the service – whether that’s Exchange Online, some other Office 365 service, or an Authentication or Federation provider.

Since we spent so much time working with Fiddler, we wanted to put together an extension which brings our knowledge of the issues we see on a daily basis directly into Fiddler to assist with troubleshooting Outlook and Exchange Online. Whether you are in contact with Microsoft support or otherwise, we’re putting it out there so you can use it too!

What does the extension do, or add?

• It colourizes sessions in the session list according to any known error condition.
• It adds additional columns added to highlight particularly useful information:
  • Session total Elapsed time.
  • Type of Response server that responded to the session request.
  • Exchange type a calculated field based on session characteristics.
  • Authentication giving you information about the session Authentication.
  • Host IP address of the server which responded to the session request.
• It adds an Exchange Online inspector tab.
• It adds an Office365 Auth inspector tab.
• It adds a menu to control extension features.
  • Don’t want to see one or more of the columns? Simply turn them off and restart Fiddler to see the changes.
• We added an update checking feature. Making sure anyone using the extension gets any available extension updates as we update the session logic rule set.

What kind of scenarios can the extension help me troubleshoot?

• Authentication
  • See if the Outlook client is Basic or Modern Authentication capable.
  • See if Exchange Online Basic or Modern Authentication is enabled.
  • SAML response parser to validate UserPrincipalName, ImmutableID and signing certificate used for Authentication in an Outlook session.
• Autodiscover
  • See if Exchange on your network redirects to Exchange Online.
  • See any Autodiscover responses from a server not running IIS; Apache, for example.
• Network Connectivity
  • Web proxy or other device blocking Outlook traffic from reaching the internet and Office 365 / Exchange Online.
  • Outlook cannot connect to an Exchange Online mailbox.
  • Outlook cannot communicate with an Exchange server - either on your network or in Exchange Online.
• Performance information
  • Check the length of time sessions take to complete.
  • Check the length of time the Exchange Online server took to service the request; 'Server Think Time'.
  • Check the length of time it took to send the response back to Fiddler and for Fiddler to relay the response back to the client app (Outlook).
• Other
  • OWA cannot connect to an Exchange Online mailbox.
  • Outlook or OWA cannot perform a specific function with the mailbox.
  • Exchange Free/Busy and other EWS calls.

What does it look like?

Here’s an example of the session coloring:

Exchange Online inspector tab:

Exchange Online inspector tab with a HTTP 503 Federation service unavailable scenario:

Office 365 Auth tab with authentication summary:

Office 365 Authentication tab with SAML response parser:

Extension menu to control features:

Where to get it and how to provide feedback?

Want to try this out for yourself? If so, you can download the extension from https://aka.ms/EXOFiddlerExtension

To install it the following pre-requisites need to be met:

• Fiddler must first be installed. See https://aka.ms/FiddlerDownload
• .NetFramework 4.6 or newer See this.
• Start the Fiddler application at least once before installing any extension to initialize Fiddler properly.

If you have any issues, feedback or questions with the extension please raise them at https://aka.ms/EXOFiddlerExtensionIssues - we’re listening and want to help if we can.

For additional information on the extension see the extension wiki at https://aka.ms/EXOFiddlerExtensionWiki.

Thanks for using the extension and let us know how it works for you. We’d love to hear if it helps you solve any particularly difficult problems. All the best.

Jeremy Knight

Overview

The Exchange audit log is an important tool in the defender toolbox to understand the activity of users (or attackers masquerading as users) in an organization. Defenders can manually browse through their audit logs for user activity that indicates malicious activity. These audit logs feed many first-party and third-party protect, detect, and investigate capabilities in Security Information and Event Managers (SIEMs). This data can be consumed via both the Security and Compliance Center (SCC) and Microsoft Cloud App Security (MCAS) for their detections.

Today, we are offering session context in the exchange audit logs to empower defenders to better understand account activity and better distinguish malicious attackers from regular employees. Session ID will be audited as a part of mailbox audit logs and admin audit logs. Session ID is a guid identifier encoded in the Azure AD token. The session ID is preserved over token refreshes and can group all actions a user has taken in a single logon session (a user has to re-enter credentials in order for the session ID to change). A few of the ways that this contextualization becomes useful:

• In the case of compromise coming through a corporate VLAN where the IP address of the attacker matches that of the user, you can still distinguish attacker activity from that of a user via the session ID.
• In the case that attackers use a third-party VPN with hundreds of IPs and compromise credentials for an account, you can track the actions through the user session even across varying IP addresses.
• You can build a profile of what actions users typically take during a session and compare each new session for signs of anomalous behavior that may be indicative of a compromise.
• You can understand how many individual sessions are occurring at one time on a user’s account.

The case where session ID can no longer help is when the attacker manages to steal the token. Since they are using the exact same token as the user, you would no longer be able to distinguish between attacker and the user actions. Token theft usually requires the attacker to control the user endpoint, however, which has other implications for the severity of the breach.

Session ID

The session ID is encoded in the claims of the token; since the tokens can only be created by Azure AD, they offer protection against falsifying session information. For every action audited by Exchange, we are including the session ID in the audit logs. You can see an example of the audit log below:

In the case that a user’s credentials get compromised and the attacker logs to execute malicious user activity, exchange auditing will log the actions with session IDs below: red (12bce…) denotes attacker with green (bdcea…) denoting the user. As shown in the table below, you can distinguish between two kinds of user activity simply based on the session ID below.

Set up your organization to use Session ID

Turn on Auditing for your Organization

Turning on auditing is an important all-up security measure for your organization. Audit data is important to understand not only what actions were taken in the organization but in what context did the actions take place (IP address, user, session ID, etc.) To get the full range of audit data in Exchange, you need to make sure mailbox auditing is turned on. Starting from the 2019 calendar year, auditing will be enabled by default but you should check if your organization has auditing enabled from this blogpost.

You should also turn on Office 365 Unified Auditing to record audit data from workloads besides Exchange as well as enable Microsoft 365 detection capabilities and scalable consumption of audit data across your organization. You can find instructions to turn on Unified Auditing in this documentation.

Block Basic Authentication

One caveat to using the Session ID is that it is an AAD construct which does not exist in the case of legacy authentication; it can only be tracked when the logon occurs through modern authentication. Since the session ID is not present unless a user is authenticating via modern authentication through Azure AD, you need to disable legacy authentication throughout your organization. The benefits of blocking basic authentication cannot be overstated; they enable a host of protection capabilities. You can find more information about how to block legacy authentication and the benefits in this blogpost.

Investigating Attacker Activities using Session ID

When investigating an incident, defenders use pivots through with which they can identify attackers to link together actions and understand the full attack chain. Examples of pivots used are properties such as user account, IP address, target mailbox, activity pattern, resource/asset, etc.

Scenario: Correlate attacker action when they use third-party VPNs

In order to hide their tracks, attackers use VPNs or TOR to hide their IP addresses to avoid law enforcement retaliation. These networks regularly have thousands of servers with different IP addresses that attackers can constantly switch between; defenders cannot depend on simply filtering on a single IP address to get the full story of actions that the attacker took. Filtering on the user agent on the other hand would result in activities bleeding into the search query from the day-to-day benign operations (from the organization itself) on that account which could be incredibly noisy. However, since a single AAD session can persist for as long as 180 days, filtering on the session ID will allow defenders to quickly and accurately filter and understand what the attacker had done during that session.

Scenario: Distinguish attacker actions when they have compromised the corporate VPN

A common attack vector is the compromise of a corporate VPN. This compromise helps attackers get around a host of protections and detections that corporations set up against access from an external network. Furthermore, investigating these breaches can be challenging because the IP address cannot be used to distinguish between corporate and external traffic since it would be the IP address of the VPN service. In this case, defenders can distinguish between separate logon sessions by filtering on the session ID; this will allow defenders to remove the noise of the day-to-day organization activity and focus on the session during which the attacker operated.

In the example below, there is a chronological list of audit records from a service account in exchange. One of the actions, AddInboxRules, would be an action of interest though not representative by a breach by itself.

Let’s imagine that while investigating a breach a defender finds it odd that at some point that service account would create an inbox rule, especially over mail protocols rather than PowerShell. In this case the defender might be inclined to filter the mailbox audit records for all actions in that session and find the following list of actions.

At this point, the defender might be very suspicious that they see so many AddInboxRules and AddFolderPermissions activities over mail protocols in a single session when they don’t have any automation to do this. Digging deeper into this session, the defender would reach out to the user responsible for all these actions through another medium (ie. phone) and find out that the user had no recollection of taking these actions. The defender might also look into the specific inbox rules being created and notice that they are forwarding mails to an external entity with the keyword “invoice”.

During this investigation, the defender moved from seeing something that is a little odd, to quickly understanding everything that occurred during that session, to recognizing that the session belongs to an attacker who has malicious motives. Now that the defender was able to quickly identify the session as malicious, they could close access to the account and move to study which accounts has the attacker compromised, scope the extent of the compromise and remediate by removing the inbox rules/folder permissions.

Additional Resources

• Ignite presentation on investments in Exchange auditing and other Exchange security features
• TechNet article on Exchange mailbox auditing
• Blogpost on default enablement of Exchange mailbox auditing
• TechNet article on auditing across Office 365 services

We hope this post has helped you understand more about how to use your audit data effectively to protect your organization. Leave us a comment below with feedback!

Jeff Sun

In April 2018 we blogged about the coming End of Support date for Exchange Server 2010. It’s time for another reminder, but today’s post is extra special. Why?

One year from today Exchange Server 2010 will no longer be supported.

What does ‘end of support’ mean?

Exchange Server, like almost all Microsoft products, has a support lifecycle during which we provide new features, bug fixes, security fixes, and so on. This lifecycle typically lasts for 10 years from the date of the product's initial release, and the end of this lifecycle is known as the product's end of support. When Exchange 2010 reaches its end of support on January 14, 2020, Microsoft will no longer provide:

• Technical support for problems that may occur
• Bug fixes for issues that are discovered and that may impact the stability and usability of the server
• Security fixes for vulnerabilities that are discovered and that may make the server vulnerable to security breaches
• Time zone updates

Your installation of Exchange 2010 will continue to run after this date. However, due to the changes and risks listed above, we strongly recommend that you migrate from Exchange 2010 as soon as possible.

What are my options?

We’ve created a page (https://aka.ms/Exchange2010EndOfSupport) where we outline options, but in order to stay supported you essentially can;

• Migrate all mailboxes to Office 365 and remove all Exchange 2010 servers by Jan 2020, making sure any on-premises servers used for administration purposes are on a supported version.
• Go Hybrid with Office 365, remove all Exchange 2010 servers by Jan 2020 and make sure any on-premises servers are on a supported version.
• Stay On-Premises and upgrade to a newer version of Exchange Server.

Clearly, we think moving to Exchange Online and Office 365 is a good idea. We really do believe that’s where you’ll get access to the most secure and productive software with the lowest TCO. But over and above all of that, and in relation to the subject of this post – it gets you out of the upgrade business. If you migrate fully to Office 365 you really don’t need to worry about these big bang version migrations any more. You just have to make sure you keep a much smaller number of on-prem servers up to date, and you’re good.

If you do want to stay on-premises don’t forget that you cannot upgrade directly from Exchange 2010 on-premises to Exchange Server 2019. You can upgrade to Exchange 2013 or 2016 directly from Exchange 2010 and we recommend you upgrade to Exchange 2016 if you have the choice. It will give you a longer support lifecycle and more features. Given how similar 2013 and 2016 are from a migration standpoint, it’s also just as easy to go to 2016 as it is 2013. So, upgrade to Exchange 2016, and then you have the option to go to 2019 if you want to.

What if I need help?

If you have a complex deployment, or if you just don’t have the time or skills you might need some help. That’s fine, there are plenty of ways to get help.

If you're migrating to Office 365, you might be eligible to use our Microsoft FastTrack service. FastTrack provides best practices, tools, and resources to make your migration to Office 365 as seamless as possible. Best of all, you'll have a real support engineer that will walk you through your migration, from planning and design all the way to migrating your last mailbox. If you want to know more about FastTrack, take a look at Microsoft FastTrack.

If you run into any problems during your migration to Office 365 and you aren't using FastTrack, or you are migrating to a newer version of Exchange Server, we're still here to help. Here are some resources you can use:

• Technical community
• Customer support

You might choose to engage a partner to help too. We have a great number of partners with deep skills in Exchange, and we’re sure one of them will be able to help you. Start your search here.

So what now?

What now? You need to get started if you haven’t already. Time really does fly and Jan 14^th 2020 is only a year away.

(Tick, tock….)

The Exchange Team

During my day to day work as a part of support organization, I work with and help troubleshoot mailbox migrations very often. One type of migrations that we see quite often is IMAP migrations. I wanted to put together an overview of IMAP migration good practices as well as troubleshooting tips related to IMAP migrations. Hopefully, you find this useful! I realize that the second part of the post is a bit dry and might not be relevant unless you actively need to troubleshoot.

A few things to get out of the way first:

• We support migrations from IMAP servers to Office 365 Exchange Online using IMAP4 protocol.
• We don’t support IMAP migrations between two Office 365 tenants. Our documentation for this scenario can be found here.
• We also don’t support offboarding back to an IMAP server from Exchange Online using IMAP. Offboarding is only possible using Mailbox Replication Service (MRS) migrations using an MRSProxy endpoint.
• We don’t recommend IMAP migrations from Exchange on-premises servers. In such scenarios, we recommend using a native migration method (Cutover or Minimal / Express Hybrid). We also don’t recommend Staged migration from Exchange 2007 or Exchange 2003 servers if you intend to keep directory synchronization in place after mailbox migration to Office 365. The recommended migration method when migrating from these old Exchange Servers when Directory Synchronization is required for your organization is Minimal Hybrid Configuration; this requires inserting an Exchange 2010 (for Exchange 2003 servers) or Exchange 2013 (for Exchange 2007 servers) and running Minimal HCW. This will give you a free Hybrid license and will allow you to perform an MRS migration (this means there is no need to recreate Outlook profiles). The Minimal HCW will also allow you to be in a supported scenario when you have Exchange Online Mailboxes and the AD users synced to Azure AD and you will need to manage your Office 365 Mailboxes using on-premises Exchange 2010 / Exchange 2013 Management tools (Exchange Admin Center and Exchange Management Shell). This is due to directory synchronization which requires administration of Exchange Online Mail Attributes from on-premises Exchange for your synced users. Managing Exchange Online Mailboxes from Exchange 2007 or Exchange 2003 servers after mailbox migration is not supported. More about Minimal and Express Migrations can be found here.

Here are some considerations that you need to take into the account when you perform an IMAP Migration:

• Only items in a user's inbox or other mail folders can be migrated. You can't migrate contacts, calendar items, or tasks. (Note that we are working on a richer migration experience for G Suite to Exchange Online migrations, as mentioned here.)
• By default, the maximum message size that can be migrated is 35 MB. This can be increased up to 150 MB.

There are 2 ways to perform an IMAP migration to Office 365:

1. Using a graphical user interface: either Exchange Admin Center or Office 365 Admin Center
2. Using PowerShell

Either method you choose, the IMAP migration needs an IMAP Migration Endpoint created first.

Here are some screenshots from Office 365 Exchange Admin Center that show where to locate and create Migration Endpoints:

And this is a PowerShell view of an IMAP Endpoint (from get-migrationendpoint) established with remote IMAP server on port 993 and using SSL:

If you have issues with creating the IMAP Endpoint, you can use Test-MigrationServerAvailability command while connected to Exchange Online PowerShell to test IMAP connectivity:

Test-MigrationServerAvailability -Imap -RemoteServer <Your IMAP server> -Port 993
Test-MigrationServerAvailability -Imap -RemoteServer <Your IMAP server> -Port 143

When you create the migration batch and specify the Office 365 user mailboxes where you will migrate content via IMAP, the migration service will create Migration Users and corresponding Sync Requests for each user you specified in the CSV File.

Similarly, for Hybrid Remote Moves (Full or Minimal Hybrid Configurations), you would have Move Requests created for the users.

This is how you would create the Migration Batch via Exchange Admin Center based on a CSV File where you specify the mailboxes you would migrate to:

You can optionally exclude folders in the IMAP Migration Batch if you don’t want to migrate specific folders, or if you find yourself in scenarios where we have a corrupted IMAP folder.

When troubleshooting failed IMAP migrations, Microsoft support will need at least one of the following XML reports from you:

Get-MigrationBatch -IncludeReport -DiagnosticInfo "showtimeslots, showtimeline, verbose" | Export-Clixml C:\temp\EXO_All_Batches.xml
Get-MigrationBatch <Specific Migration Batch Name> -IncludeReport -DiagnosticInfo "showtimeslots, showtimeline, verbose" | Export-Clixml C:\temp\EXO_Batch_X.xml
Get-MigrationUserStatistics <affected user SMTP> -IncludeSkippedItems -IncludeReport -DiagnosticInfo "showtimeslots, showtimeline, verbose" | Export-Clixml C:\temp\EXO_MigUserStats1.xml
Get-SyncRequest -Mailbox <affected user SMTP> | Get-SyncRequestStatistics -IncludeReport -DiagnosticInfo "showtimeslots, showtimeline, verbose" | Export-Clixml C:\temp\EXO_SyncReq.xml

However, depending on when (in which stage) things have failed, we might not always have a Sync Request for the user or even have a Migration Batch.

In that case, you would run commands similar to these:

Get-MigrationEndpoint |FL
Test-MigrationServerAvailability -Endpoint <Identity of the IMAP endpoint from above>
Test-MigrationServerAvailability -Imap -RemoteServer <IMAP server> -Port 993
Test-MigrationServerAvailability -Imap -RemoteServer <IMAP server> -Port 143
Get-MigrationBatch
Get-MigrationUser
Get-SyncRequest -Mailbox <affected user>

If you do have a Sync Request created for the user that failed migration, then you should run Get-SyncRequestStatistics command, as described above, to export the XML report in order to retrieve more information on the cause of the issue.

If you don’t have a Sync Request created, but you have a Migration User, you would run Get-MigrationUserStatistics command, as described above.

Usually, when customers open support cases with support, for any migration to Office 365, this is because of 2 main reasons:

• Migration failed, and they are unable to migrate one or more users to Office 365. Errors break down in two categories:
  • Permanent – the error that actually made the migration fail
  • Transient – errors which might slow down the migration to the point where it might fail at the end
• Migration is slow or stalled due to Office 365 Resource Throttling or IMAP Server performance issues. These depend on many factors like source server performance and network related configurations, capabilities or issues. More info here. It can also happen that Office 365 will stall the migrations to protect Office 365 Servers health and also because migrations have a lower priority assigned than things like mail-flow tasks or client connectivity. More info on that can be found here.

Errors are our friends – how to troubleshoot in practice

Based on the failure you got in the Sync Request Statistics or Migration User Statistics, you can find out what is causing the issue and get more details on the migration error.

When troubleshooting an IMAP Migration, find out if you have a Sync Request created for the user. If there is one, you would retrieve the Sync Request Statistics for it and store it in a variable or directly export it in an XML report to look at it into detail.

To see if the sync request is created for the user, run the following command in Exchange Online PowerShell:

Get-SyncRequest -Mailbox <Affected User SMTP>

Check the STATUS of the Sync Request, is it Failed / Synced / Syncing?

Supposing it is Failed, you would then store the Sync Request Statistics into a variable, I used $syncstats in my example below.

$syncstats = Get-SyncRequestStatistics crystal@contoso.com -IncludeReport -DiagnosticInfo "showtimeslots, showtimeline, verbose"

We would then look at the failures. Here are some examples of commands to check various failures:

• Retrieve Last Failure: $syncstats.Report.Failures[-1]
• Retrieve the Last 2 Failures: $syncstats.Report.Failures | select -Last 2
• Retrieve First Failure: $syncstats.Report.Failures[0]
• Count all failures and group them by failure type: $syncstats.Report.Failures | group failuretype | ft -autosize
• List all the failures with their details: $syncstats.Report.Failures

Similarly, if you don’t have a Sync Request but do have a Migration User created and we failed to create a Sync Request, we would need to gather the Migration User Statistics for that user in order to get more details.

If you run Get-MigrationUser, you would list all migration users: their Identity, Name of the Migration Batch user is part of, Status and Last Synced time.

Example (Get-MigrationUser):

We would then store the Migration User Statistics into a variable or export to XML.

# Store into a variable:
$ustats = Get-MigrationUserStatistics crystal@contoso.com -IncludeSkippedItems -IncludeReport -DiagnosticInfo "showtimeslots, showtimeline, verbose"
# Export to an .xml file:
Get-MigrationUserStatistics crystal@contoso.com -IncludeSkippedItems -IncludeReport -DiagnosticInfo "showtimeslots, showtimeline, verbose" | Export-Clixml C:\temp\EXO_MigUserStats1.xml

Next, we would use similar commands as we did to retrieve failures and internal failures from Sync Request Statistics.

For example, to retrieve Last Failure from a Migration User Statistics, you would run a command similar to this: $ustats.Report.Failures[-1]

Note that for troubleshooting IMAP failures, we prefer Sync Request Statistics instead of Migration User Statistics (if we have a Sync Request in place for the user).

Next up, I have gathered some of more common (that we see in support) IMAP Migration Errors / Failures and what you can do to fix them.

1. Error: Imap server sent NO response to SelectCommand

Message : Imap server sent NO response to SelectCommand. Response code: '', message: 'Invalid mailbox name: Junk/'.
Message : Imap server sent NO response to SelectCommand. Response code: '', message: 'Invalid mailbox name: Sent/'.

This can be because we have invalid folder names with Forward Slash Characters. Reference here. If you don’t need to migrate these folders, you can exclude the folders from migration also.

2. Error: Mailbox folder hierarchy contains multiple roots: FolderHierarchyContainsMultipleRootsTransientException

Error: Mailbox folder hierarchy contains multiple roots: [Folder1: EntryID: [len=54, data=563D313B503D494D41503B46503D37393145423136314534463244383234433438443433413634463936393641354444333942383235], ParentID: [len=54, data=563D313B503D494D41503B46503D33304134424342304331383135314645423643353933414244423837374630393933413432393135], Type: Generic], [Folder2: EntryID: [len=54,

The "duplicate root" parent folder is the "SomeHiddenFolder" that is not returned by IMAP LIST command. So, when MRS runs LIST to enumerate folder hierarchy, it gets something like this:

Inbox
SentItems
TopLevelFolder
TopLevelFolder/NormalSubfolder
SomeHiddenFolder/ Folder1
SomeHiddenFolder/ Folder2

Note that SomeHiddenFolder is *not* returned as a separate entry in the LIST command output.

You would look in report.Failures to see the Folder Names impacted. In this example, it is Folder1 and Folder2. You would check the Folder Hierarchy of the affected user by this error, paying attention to folder names and their parent folder. Problem can also be duplicated folder names or parent folder to be a Public / Shared Folder (for those raising eyebrows right about now – access to public folders through IMAP was a thing in legacy versions of Exchange, for example Exchange 2003).

You can also run the following script to LIST IMAP Folders for that mailbox: Get-ImapFolders.ps1 from GitHub and send us the output to see the IMAP Folders List together with the Sync Request Statistics XML.

Another thing you can do is run Remote Connectivity Analyzer for IMAP test and select Exchange Server Tab (even if source IMAP server is not an Exchange server) and then IMAP Email under INTERNET Email Tests, fill in the affected user settings and then SAVE report as HTML and send us the file in order to see the IMAP Folders list.

Ultimately, our support can’t do much for you in this situation other than identifying problematic folders. It is up to you to make the Folder "SomeHiddenFolder” a SELECTABLE folder and if needed, discuss with your vendor where original data is located.

You could also try to create a new folder, selectable in IMAP and move the content from "SomeHiddenFolder” to this New Folder, including its subfolders, example Folder1 and Folder2.

3. Error TooManyLargeItemsPermanentException has occurred

As per our current documentation, the message size limit that we can move to Office 365 Exchange Online during an IMAP Migration is maximum 35MB.

However, for IMAP migrations, where we need to have mailboxes created in Office 365 before we can migrate with IMAP, we can increase the message size limit up to 150MB on the target mailbox and this will allow email messages up to 150 MB size to be moved to Office 365 during IMAP Migrations.

Set-Mailbox -Identity alias@domain.com -MaxReceiveSize 150MB

This setting will also allow the user to receive larger email messages via transport (if the sender is capable). We don’t recommend lowering this limit back to 35 MB if you already migrated emails larger than 35MB.

The Error "Fatal Error TooManyLargeItemsPermanentException has occurred." suggests that we reached the Large Item limit set on migration batch. Usually large item limit is set to 0 and if we encountered at least 1 email message in the source mailbox bigger than 35MB (default MaxReceieveSize on the Office 365 Mailbox), the limit would have been reached and migration is failed for that user.

So you need to either Increase MaxReceiveSize (maximum 150MB) on the affected O365 User Mailbox to be able to migrate email messages larger than 35MB or increase the LargeItemLimit on the migration batch from GUI or from PowerShell with set-migrationbatch -LargeItemLimit XX or on the Sync Request (Set-SyncRequest -LargeItemLimit XX) so that we can skip migration of these large items and migration won’t fail because of this.

4. Error: Imap server sent NO response to LoginCommand. Response code: '', message: 'LOGIN failed.'.

MigrationPermanentException: Unable to log into account. --> Unable to log into account. --> The username or password for this account is incorrect, or IMAP access is disabled. --> Imap server sent NO response to LoginCommand. Response code: '', message: 'LOGIN failed.'.

This error suggests bad login (wrong username or password) or that IMAP protocol is disabled. If more or all users are affected, there might be issues with IMAP server certificate.

Suggestions for this issue:

1) Check if you are able to configure IMAP profile in Outlook Desktop for the user

2) Check if you are able to connect to the IMAP Source Mailbox and List folders with one of these 2 methods:

• Run Get-ImapFolders.ps1 Script from GitHub
• Go to Remote Connectivity Analyzer for IMAP test and select Exchange Server Tab (even if source IMAP server is not an Exchange server) and then IMAP Email under INTERNET Email Tests, fill in the affected user settings as mentioned in the CSV file you used for Migration Batch and see if you are able to connect

3) Test-MigrationServerAvailability command in EXO PowerShell

Test-MigrationServerAvailability -Imap -RemoteServer <IMAP server> -Port 993
Test-MigrationServerAvailability -Imap -RemoteServer <IMAP server> -Port 143

4) If you use a Super User / Admin password, make sure the CSV file is created properly. See this and this.

5) If the source server is Gmail, this error message might happen because 2 step verification process/ app password which is required when migrating from it.

5. Errors that suggest RFC non-compliant source IMAP Servers.

For example, we might get a Permanent Failure after these transient failures which would make migration to fail for a specific user or more.

MigrationMRSPermanentException: Error: The job encountered too many transient failures ‎(61)‎ and is quitting. The most common failure is ImapCouldNotParseResponseException/ImapUnexpectedTokenFormatException with the hit count 57. --> Imap server sent a response that we could not understand. Command: ‎'WIR01992 UID FETCH 16967 ‎(INTERNALDATE UID BODY.PEEK[])‎ ‎'. Response: ‎'‎' >>‎'‎'. --> Unexpected response format - expected ‎')‎‎', actual ‎' ‎'.

This error suggests that the IMAP server returned a bad response format, it was expected a parenthesis after Date / Time of the messages received.

In this situation, you would need to discuss with vendor where at the mailbox source to help you fix this issue.

6. Errors that suggest Source IMAP Server Bugs or Internal Errors

Message : Imap server reported an error during SelectCommand indicating that it encountered some bug: 'Internal error occurred. Refer to server log for more information. [2018-11-29 10:40:44] (0.002 + 0.000 + 0.001 secs).'.
DataContext : --------
Operation: ImapMailbox->GetFolderInternal<T>() for folder < >

The error message is generated at the selection of one or maybe more folders on the Source IMAP server (SELECT command) and according to the failure, the admin should check the logs that are generated on that IMAP server around the timestamp of the failure.

To retrieve the Last Failure or the previous one before last, you can use the commands below:

$syncstats = Get-SyncRequestStatistics user@domain.com -IncludeReport
$syncstats.Report.Failures[-1]
$syncstats.Report.Failures[-2]

You can use one of these 2 methods below to LIST the Source IMAP Folders for the user and see their names:

• Run Get-ImapFolders.ps1 Script from GitHub
• Go to Remote Connectivity Analyzer for IMAP test and select Exchange Server Tab (even if source IMAP server is not an Exchange server) and then IMAP Email under INTERNET Email Tests, fill in the IMAP User Details and check the LIST of folders.

If the folder referenced in the error is found in the Sync Request Failure, you can try to Exclude it from IMAP migration batch when retrying migration.

Many thanks to all that contributed to this blog post: Nino Bilic, Brad Hughes and Cristian Dimofte.

Mirela Buruiana

Introduction

As a Tenant Admin of an Office 365 Exchange Online organization, have you ever needed to monitor who, what, and where someone is connecting to your Exchange Online resources, like accessing mailboxes on mobile devices? I ran into this request a few weeks ago, from one of my customers. After hours of research, and testing I became a believer in the power of Microsoft Graph (Graph). By now you’re probably thinking, what is an Exchange engineer working with a graphing tool for? Well last month, that is exactly what I would have thought too. Surprising (to me) Graph is an extremely powerful tool that can interface with a large set of Microsoft services and technologies to pull data and perform tasks within the service/technology. Pulling sign-in data from Azure Active Directory (AAD) is a breeze with Graph. After the data is extracted, using Power BI for visualization brings your reporting capabilities to a new level! Let’s walk thru a scenario setup where as a Tenant Admin you can find out who is accessing mailboxes in your Exchange Online tenant on mobile devices, using Exchange ActiveSync protocol (which is used by default mail apps on Apple & Android devices) from anywhere in the world.

Note: For this procedure to work for you, you need to have two subscriptions: Exchange Online (like E1 or E3) and Azure Active Directory Premium (like P1 or P2).

Allowing Graph Access to AAD Audit Log Data

AAD allows application access through the App Registration feature. To allow Microsoft Graph to query audit log data from AAD you must first create a new app registration. You can do this by logging into https://portal.azure.com and going to Azure Active Directory > App registrations (you may also see one option as ‘App registrations (Preview)’, we will not use that one).

From here simply create a New app registration provide a Name and enter https://localhost as the Sign-on URL.

After you have created the app registration you can now grant the required permissions by going to Settings > API Access > Required permissions.

Now Add ‘Microsoft Graph’ (under ‘Select an API’) and grant Read all audit log data permission (under ‘Select permissions’). Click ‘Done’ to complete this step.

It will look like this after the above steps.

Next, you will need to commit the change via the Grant permissions button by clicking on Yes, as in the screenshot below.

You’ll see this confirmation message on top right hand corner in the Azure Admin Portal.

Next, we need to create the key secret. This can be done under Settings > API Access > Keys (keep in mind that your key secret will only be displayed once & you need to copy it for later use).

Under Passwords section, give the key a short description & set an expiration time, and then click on Save button, which would result in a warning message (as in the screenshot below) asking you to copy the key value, please do so to use it later in the script below.

Pulling the data with PowerShell

To connect to Graph with PowerShell you first need to obtain an OAuth token from logon.microsoft.com. For authentication, your application ID and key secret is used. This is done using the code below:

You will need the following parameters for the PS script below.

Application ID:

Key Secret: The value that you copied earlier, it would look something like this (example): 6vNGGm5rAB4Zn32rOW9RT+4zEaqcx3l92qyGwb+vT2c=

Tenant Domain: The tenant domain that’s registered for your tenant in Office 365, like contoso.com, for example (Admin Portal | Setup | Domains)

Directory Path: The path on the local machine to save the output CSV file from this script, where this PS script is being executed by you as Tenant Admin

$ClientID = "[INSERT APPLICATION ID]"
$ClientSecret = "[INSERT KEY SECRET]"
$TenantDomain = "[INSERT TENANT DOMAIN]"
$OutputDirectory = "[INSERT DIRECTORY PATH]"
$loginURL = https://login.microsoft.com
$resource = https://graph.microsoft.com
$body = @{grant_type="client_credentials";resource=$resource;client_id=$ClientID;client_secret=$ClientSecret}
$oauth = Invoke-RestMethod -Method Post -Uri $loginURL/$TenantDomain/oauth2/token?api-version=1.0 -Body $body

Once the OAuth token has been obtained, we can now request the data from Graph using a web request:

$headerParams = @{Authorization="$($oauth.token_type) $($oauth.access_token)"}
$url = https://graph.microsoft.com/beta/auditLogs/signIns
$resultSet = (Invoke-WebRequest -UseBasicParsing -Headers $headerParams -Uri $url)

We can now filter the results and export them to a CSV:

$output = @()
ForEach($event in ($resultSet.Content | ConvertFrom-Json).value) {
If($event.clientAppUsed -eq "Exchange ActiveSync")
{
$output += $event
}
}
$output | Export-CSV "$OutputDirectory\EXOClientAccessUsageReport.csv" -NoTypeInformation

Here is a full example of the PowerShell script:

<###############Disclaimer#####################################################
The sample scripts are not supported under any Microsoft standard support
program or service. The sample scripts are provided AS IS without warranty
of any kind. Microsoft further disclaims all implied warranties including,
without limitation, any implied warranties of merchantability or of fitness for
a particular purpose. The entire risk arising out of the use or performance of
the sample scripts and documentation remains with you. In no event shall
Microsoft, its authors, or anyone else involved in the creation, production, or
delivery of the scripts be liable for any damages whatsoever (including,
without limitation, damages for loss of business profits, business interruption,
loss of business information, or other pecuniary loss) arising out of the use
of or inability to use the sample scripts or documentation, even if Microsoft
has been advised of the possibility of such damages.
###############Disclaimer#####################################################>
#Declare unique instance variables
$ClientID = "[INSERT APPLICATION ID]"
$ClientSecret = "[INSERT KEY SECRET]"
$TenantDomain = "[INSERT TENANT URL]"
$OutputDirectory = "[INSERT DIRECTORY PATH]"
#Declare static variables
$loginURL = https://login.microsoft.com
$resource = https://graph.microsoft.com
#Build OAuth tequest
$body = @{grant_type="client_credentials";resource=$resource;client_id=$ClientID;client_secret=$ClientSecret}
#Request OAuth token
$oauth = Invoke-RestMethod -Method Post -Uri $loginURL/$TenantDomain/oauth2/token?api-version=1.0 -Body $body
#If OAuth was successful request data from Microsoft Graph
If($null -ne $oauth.access_token)
{
#Build Microsoft Graph web request
$headerParams = @{Authorization="$($oauth.token_type) $($oauth.access_token)"}
$url = https://graph.microsoft.com/beta/auditLogs/signIns
#Request data via web request to Microsoft Graph
$resultSet = (Invoke-WebRequest -UseBasicParsing -Headers $headerParams -Uri $url)
#Place all events related to EXO into an array
$output = @()
ForEach($event in ($resultSet.Content | ConvertFrom-Json).value) {
If($event.appDisplayName -like "*Exchange *")
{
$output += $event
}
}
#Export all EXO events to a CSV
$output | Export-CSV "$OutputDirectory\EXOAccessReport.csv" -NoTypeInformation
}
Else
{
Write-Error "Failed to authenticate to OAuth, no token obtained."
}

After running the script above, which you can do thru Windows PowerShell on any Windows machine, you’ll have a csv file in your hands, i.e. EXOAccessReport.csv, in the output directory that you provided in the above script.

Visualizing Data with Power BI

The geniuses that developed Power BI (download the Power BI desktop app from here) have made this next step so easy even I can do it! Launch Power BI desktop app and simply import the data using Get Data > Text/CSV, select your report (if you used the defaults it will be named EXOAccessReport.csv), and click Load.

Once this is complete you can now select your visualization (I recommend ArcGIS Maps, or Maps), and drag and drop the data fields to the visualization fields. Drag location to Location and Size, userDisplayName to Legend, and clientAppUsed and createdDateTime to Tooltips. Note by selecting First (Default) for clientAppUsed this will select the latest login being as the CSV generated by the script is in descending order from most recent to least recent.

Further down the settings pane, you will find Filters the add clientAppUsed, userDisplayName, location, and createdDateTime to Report level filters.

Finally you can review your report and publish it to your workspace in Power BI.

Remember that in order for Power BI to access the data from the cloud your Power BI Gateway must have access to the CSV file generated by the PowerShell script. See On-premises data gateway for information and instructions on how to setup a Power BI gateway.

Keeping it fresh

To ensure that the report is always up to date with the latest data, I recommend you configure the PowerShell script to run at an interval that meets your needs. This task could be easily accomplished by Task Scheduler, System Center Orchestrator, and many other task scheduling solutions. For the purposes of this post we will use Task Scheduler since it is readily available on most versions of Windows.

On the machine the script will be running from, launch Task Scheduler by pressing Windows + R then typing taskschd.msc and clicking OK.

Click Create Task in the Actions pane on the right hand side of the window.

Name your task, select Run whether user is logged on or not and check Run with highest privileges.

Select the Triggers tab and click New…

Check Repeat task every, select 30 minutes for the interval, and Indefinitely for the duration then click OK.

Select the Actions tab, then click New…

Type powershell.exe into Program/script and enter the full path to your script into Add arguments (optional) then click OK.
Note: If there is a space in the full path to your script you must put a “ at the beginning and end of the path.

Click OK then provide your credentials or the credentials you are running the task as into the prompt.

Reading the Report

Now that we have created an amazing Power BI visualization how do we view it? Navigate to https://app.powerbi.com/groups/me/list/reports then click on the report we just created.

Once the report launches and populates with the latest data you can see all user logins plotted on the map with circles. The circle gets larger when more users login from the same location. In the report below we can see an anomaly with one users login location. By hovering over the circle we can see the location (where), display name (who), number of times the user logged in, what technology/method (what) was used to login during the most recent sign-in, and the date and time of the latest login.

If there are multiple logins from this location, there could be multiple methods used to login. To determine which methods were used we can use the Filters pane and apply a location and userDisplayName filter. Once this is complete when we expand clientAppUsed only the technology/method of login is left, in this case Exchange ActiveSync.

Conclusion

Using Microsoft Graph, PowerShell, Task Scheduler, and Power BI we created an auto updating report to track Exchange Online user logins.

With our new skills Exchange Online doesn’t mark the end of custom reporting for organizations. With Microsoft Graph and Power BI our ability to generate custom reports is stronger than ever! Happy Graphing!

Dana Garcia

It usually starts with the following question: Is there a way to release the license of an Exchange Online user that left the company, but at the same time, keep the mailbox content? To get this done, we have a feature called Inactive mailboxes, but as we have seen some of our customers being a bit confused about the sequence of steps that needs to be taken to do this correctly, I wanted to cover this scenario.

Scenario

David is a cloud-only user. David currently has an Office 365 Enterprise E5 license. David leaves the company, so as an Admin, I’ll need to remove his account, but I still need to have access to his emails.

Note: In this article, we will provide the steps that have to be taken in order to correctly move a mailbox from the Active state to the Inactive state. Details about how to access the content of an inactive mailbox can be found here.

Before you begin

You have to be connected with PowerShell to Azure Active Directory / Microsoft Online Directory Service (MSODS) and to Exchange Online in order to complete tasks mentioned on this article.

Steps to take

1. Put the mailbox on a hold (which will also place the Archive on the hold, if it is present). For this scenario I’ve used LitigationHold, but, any hold from Exchange Online, or Security and Compliance can be used:

Set-Mailbox David -LitigationHoldEnabled $True -LitigationHoldDuration Unlimited

Note: The hold setting may take up to 60 minutes to take effect.

2. Ensure the mailbox has Litigation Hold enabled:

Get-Mailbox David | fl PrimarySMTPAddress, Identity, LitigationHoldEnabled, LitigationHoldDuration, MailboxPlan, PersistedCapabilities, SKUAssigned

User properties should now show:

PrimarySmtpAddress : David@contoso.com
Identity : David
LitigationHoldEnabled : True
LitigationHoldDuration : Unlimited
MailboxPlan : ExchangeOnlineEnterprise-0527a260-bea3-46a3-9f4f-215fdd24f4d9
PersistedCapabilities : {BPOS_S_O365PAM, BPOS_S_ThreatIntelligenceAddOn, BPOS_S_EquivioAnalytics, BPOS_S_CustomerLockbox, BPOS_S_Analytics, BPOS_S_Enterprise}
SKUAssigned : True

3. Check the number of licenses you have in total/assigned:

Get-MsolAccountSku | fl AccountSkuId, ActiveUnits, ConsumedUnits

Example of what you might get:

AccountSkuId : contoso:ENTERPRISEPREMIUM
ActiveUnits : 25
ConsumedUnits : 3

ConsumedUnits represents the number of licenses that are currently assigned.

4. Remove the Azure Active Directory user, which will move the mailbox to inactive state:

Remove-MsolUser -UserPrincipalName David@contoso.com

5. Check if the mailbox was deleted and become an inactive mailbox:

Get-Mailbox David -InactiveMailboxOnly | fl PrimarySMTPAddress, Identity, LitigationHoldEnabled, LitigationHoldDuration, SKUAssigned, IsInactiveMailbox, IsSoftDeletedByRemove, WhenSoftDeleted

The results should be similar to:

PrimarySmtpAddress : David@contoso.com
Identity : Soft Deleted Objects\David
LitigationHoldEnabled : True
LitigationHoldDuration : Unlimited
SKUAssigned : False
IsInactiveMailbox : True
IsSoftDeletedByRemove : True
WhenSoftDeleted : 6/4/2018 6:42:11 AM

6. Check if the Azure Active Directory user was deleted (you should be able to see it in the list of Deleted users, or you can run a command similar to the one below):

Get-MsolUser -ReturnDeletedUsers -All | where {$_.ProxyAddresses -match "David@contoso.com"} | fl UserPrincipalName, IsLicensed, Licenses

The results should be similar to:

UserPrincipalName : David@contoso.com
IsLicensed : True
Licenses : {contoso:ENTERPRISEPREMIUM}

7. Check the number of licenses you have in total/assigned (the license for the user that is now deleted should be released):

Get-MsolAccountSku | fl AccountSkuId, ActiveUnits, ConsumedUnits

The results should be similar to:

AccountSkuId : contoso:ENTERPRISEPREMIUM
ActiveUnits : 25
ConsumedUnits : 2

Optional (if you want to remove the Azure Active Directory user for good):

8. Wait for 30 days to have the Azure Active Directory user deleted from the Deleted Users list, or run a command similar to the below in order to permanently remove the user:

Get-MsolUser –ReturnDeletedUsers -All | where {$_.ProxyAddresses -match "David@contoso.com"} | Remove-MsolUser -RemoveFromRecycleBin

9. Check if the user still exists in the Active Users, or in Deleted Users (for both commands no results should be returned and you should not see the user within Deleted users anymore):

Get-MsolUser -All | where {$_.ProxyAddresses –match “David@contoso.com”}
Get-MsolUser -ReturnDeletedUsers -All | where {$_.ProxyAddresses -match "David@contoso.com"}

10. Verify that the mailbox is still in the inactive state, and the Litigation Hold is still enabled:

Get-Mailbox David -InactiveMailboxOnly | fl PrimarySMTPAddress, LitigationHoldEnabled, LitigationHoldDuration, SKUAssigned, IsInactiveMailbox

The result should be similar to:

PrimarySmtpAddress : David@contoso.com
LitigationHoldEnabled : True
LitigationHoldDuration : Unlimited
SKUAssigned : False
IsInactiveMailbox : True

References; additional information / more details on:

• Litigation/In-Place Holds
• In-Place Archive
• Inactive Mailboxes
• How to create and manage Inactive Mailboxes in Office 365
• How to search and export contents of an Inactive Mailbox
• How to remove a hold from an Inactive Mailbox

Thanks to Mark Johnson, Nino Bilic and Murali Natarajan for their support and contribution to this blog post!

Cristian Dimofte

At Microsoft Ignite, Outlook for iOS and Android announced support for deploying managed device account setup configuration settings for Office 365 mailboxes and on-premises mailboxes leveraging hybrid modern authentication. This capability leverages either the Managed App Configuration for iOS or the Android managed configurations to enable MDM solutions to push configuration detail. This functionality was delivered to facilitate large scale deployments of the leading, secure email client which is known to be loved by users and trusted by IT.

Today, we are announcing the availability of new functionality within the Intune that enables admins to easily deploy account setup configuration to Outlook for iOS and Android for modern authentication capable accounts via App Configuration Policies.

Figure 1: App Configuration Policy for Outlook for Android on Android Enterprise devices from https://devicemanagement.microsoft.com. If you're in https://portal.azure.com, then you'll go to Intune -> Client apps -> app configuration policies and add a config policy. 

With this new policy experience, administrators can simply push Outlook account setup details to their user’s enrolled mobile devices. This updated policy experience combines the prior experience and provides administrators with a choice depending on your messaging environment:

1. If the messaging environment is on-premises and not leveraging hybrid modern authentication (basic authentication), then the authentication type needs to be set to Basic authentication. Additional details like Email Server, Username attribute, and Email address attributes are required.
2. If the messaging environment is Office 365 or an on-premises environment leveraging hybrid modern authentication, then the authentication type needs to be set to Modern authentication. The admin only needs to define the Username attribute and Email address attributes. Modern authentication capable accounts also support the ability for the admin to restrict Outlook for iOS and Android to only allow the work or school account; for more information see “Organization allowed accounts mode” in Setup with modern authentication.

Note that for Outlook for iOS and Android to apply these settings, the app needs to be installed and managed by the Company Portal.

We hope you enjoy this new policy experience available within the Intune portal  for Outlook for iOS and Android. Up next is general app configuration. That’s right, Outlook for iOS and Android will soon support managing and configuring Outlook for iOS and Android features such as Focused Inbox and contact synchronization capabilities. Stay tuned!

Ross Smith IV
Principal Program Manager
Customer Experience Engineering

Frequently asked questions:

Q: What if we are not using Intune to manage device enrollment, but instead are leveraging a third-party MDM solution?

Not to fear, we have you covered. These settings can be delivered via any MDM provider. For more information on the configuration keys you need to use, see the following articles:

• For Office 365 and on-premises mailboxes leveraging hybrid modern authentication, see Account setup with modern authentication in Exchange Online and Deploy app config settings.
• For on-premises mailboxes not leveraging hybrid modern authentication (basic authentication), see Account setup in Outlook for iOS and Android using Basic authentication.

Q: Can I deploy account setup configuration to Outlook for iOS and Android if the device is not enrolled?

No, unfortunately, that is not possible. Enrolled devices provide the identity and information necessary for configuring the app.

Q: What if I had already deployed the configuration keys manually in an App Configuration Policy; do I need to do anything?

No! The keys will be automatically consumed in the new policy experience.

Q: How do I create an App Configuration Policy for Outlook for iOS or Outlook for Android?

We’ll be updating Deploy app config settings to include the new policy experience, but you can also review Add app configuration policies for managed iOS devices and Add app configuration policies for managed Android devices.

Q: Wait – I see the setting “Block External Images” but it’s not working on the device.

Surprise, you caught us! This is unfortunately an UX bug that exposed a setting that is not yet available (configuring the setting will not have any impact in Outlook for iOS). Please stay tuned, we’ll have more to share soon.

In our continued efforts to improve the reliability, speed and administration experience of public folder migration, we are very glad to announce the availability of Remove-PublicFolderMailboxMigrationRequest cmdlet for the use of Exchange Online tenant administrators.

The cmdlet will help tenant administrator remove individual public folder mailbox migration request, which is very helpful in scenarios where the migration request may have been duplicated or orphaned. Please check this link for detailed documentation on how to use the cmdlet.

A sample script (provided here) can be used to detect duplicate or orphaned public folder mailbox migration requests and also remove them if so desired.

We’ve love to hear your feedback and please feel free to ask any questions via the comments section below.

Public Folder team