Finally moving your Enterprise Public Folders to the cloud? Understand protocols and options (spoiler alert! some are no more than wishful thinking)

If your first thought when you read this blog title, was “but do people still use Public Folders?”, the answer is YES!

Not only corporations still use Public Folders, but also they want to move them to the cloud and keep using them.

For the past year or two, working for a company that owns an outstanding migration product, MigrationWiz, I’ve seen a trend of large organizations worldwide getting to their final stages of the transition to the cloud. Usually, what that means in practical terms, is that they are addressing the more complex and harder to move or coexist workloads, which also translates to Public Folder migrations, amongst other things.

For many years Microsoft made it easy for Microsoft 365 users to access Public Folders on premises, and not that long ago they enabled on premises users to access Microsoft 365 Public Folders.

What Microsoft never supported, although it was technically possible, was two source of authorities for a Public Folder infrastructure, within a Hybrid Deployment. But all this flexibility pushed Public Folder migrations to the back of the “moving to the cloud” workload queue.

So now that we have a little bit of context on Public Folder migrations, lets address the options, when you decide to finally make the move.

How much data do you have to move?

From my experience, there are fundamental differences between two main types of migrations, you might be faced with. My first exercise, when trying to help a customer or a partner, plan their Public folder migration, is to determine if it’s a small or a large migration. Let me share with you where do a draw the line between both:

  • Small migrations: Migrations of up to 50GB of data, 1000 folders and 100k items
  • Large migrations: Anything above that

The main differences between a large and a small migration

Depending on the volume of data, or migration project can be simplified, or very complex. Here’s some bullet points on why:

  • Small migrations can easily be done with lift and shift protocols, like OA (Outlook Anywhere) or MRS (Mailbox Replication Service), however if you are looking at data transformation – this topic justifies a dedicated blog post, so won’t get into much detail on it here, but you can characterize migrating from Public Folders to Shared Mailboxes as an example of data transformation – and/or filtering or mapping the data differently from the source, you should use an EWS based migration product.
  • Small migrations do not require pre migration split work, to balance data between multiple destination mailboxes. In fact the lift and shit protocols do not require that.
  • Remember the wishful thinking mentioned on this blog title? Well trying to execute large migrations with lift and shift protocols, is exactly that. If you think you can migrate 2TB of Public folders with MRS, there’s no better way of saying this so I’ll just go for it: “YOU’RE WRONG”.
  • In addition to the above, large migrations also require pre migration work, that will basically focus on splitting the data into smaller chunks and pointing it to multiple target mailboxes, just so we never rely in the Microsoft auto splitting process for Public Folders.

Available protocols

Now that we outlined some of the biggest differences between large and small migrations, lets talk about the available protocols to migrate:

Outlook Anywhere

Outlook Anywhere is an old legacy protocol, that amongst other things, can be used to migrate Public Folders from Exchange 2010 to Exchange Online. But what are the main problems with Outlook Anywhere?

  • as stated above, the protocol is legacy and Microsoft actually stopped supporting it, in Exchange Online, back in 2017.
  • OA migrations are lift and shift and not feasible for large volumes of data
  • Setting up and/or troubleshooting OA can become complex really fast, in an Exchange version that is EOS since October 2020
  • Previous patching of the Exchange Server can be needed, before proceeding
  • Obviously it goes without saying but, OA does not support EXO (Exchange Online) as source

Mailbox Replication Service

MRS is a well established “migration-ish” protocol, that is very well know for it’s use in Hybrid migrations. For Exchange 2013+ that is the method used. Once again, where can things go wrong here?

  • With MRS, just like with OA, you’ll follow a lift and shift migration and face all the challenges that come with it, for large volumes of data
  • Being a lift and shift doesn’t only make it nearly impossible for some scenarios, it also makes it a non suitable option for mergers, acquisitions, hosted exchange and any scenario where you either have multi tenancy or you don’t want to target the entire Organization, in source or destination
  • The permissions the MRS requires can also be a road block, for the scenarios described in the bullet point above

Exchange Web Services

With Exchange Web Services the approach to migrate the data will be completely different. EWS will target each item in the source and create it in the destination (obviously this is done in batches of items). What that gives you is a whole bunch of options, such us:

  • When to migrate which data (folders, items) and to where (i.e PF to Shared mailboxes)
  • Split the source data to optimize speeds
  • Resume the migration from where it failed, when it does (believe me, at some point if your structure is huge, it will fail)
  • Migrate Terabytes of data
  • Scope source and destination permissions as needed
  • Target Public Folders in Hosted Exchange, per tenant
  • Migrate from Exchange Online

The bottom line

I hope that now that you read this, if you’re thinking about moving your decades old Public Folders into M365, at least you know the options you have.

There are pros to MRS (not so much to OA, to be honest), and if you have 5GB of PFs to migrate, an up to date Exchange with hybrid in place, then you can use it, but this blog post is focused in Enterprise customers, with hundreds of GBs or even TBs of data to move, and being very pragmatic, from my knowledge, that’s just not possible to do, with MRS.

Do let me know if you have any questions. Thank you for reading!

How to share the same email domain between two Exchange Online tenants for long term mail flow tenant to tenant coexistence [Part 1]

Note: Let me start with a quick note. This blog post was initially drafted to include multiple mail flow coexistence scenarios, between two Office 365 tenants. While I was writing the first scenario, I realized that it was so extensive that it didn’t make sense to put more scenarios in the same post. So stay tuned for more posts, each with its different scenario and some more focused on tenant to tenant enterprise migrations and mail flow during a coexistence period. Enjoy!

Some context

Microsoft tenant to tenant email migrations are very common in our days, and if some are small in terms of users, and the option is to just move them all at the same time, some are too big to have that approach.

Would you consider moving 50 thousand user mailboxes, in one single cut over batch, from one Exchange Online tenant to another? Probably not.

And there’s several reasons not to consider it, most, if not all of them having the user experience in mind. It’s not just about how many terabytes you can move per day, it’s also about re configuring Outlook profiles, re doing the Exchange partnership connection in your phone, all other Office 365 workloads, etc.

So when a cut over is not being considered, the coexistence between tenants comes into play. The biggest question is, can I leverage the same email domain in two tenants? And technically the answer is yes you can, but you’ll need an address rewriting service help you do it.

In a context of a migration, address rewriting is not all you need to have mail flow coexistence, but it’s the key component.

There are other components for you to consider, when doing tenant to tenant with coexistence, but this blog posts series will be focused on mail flow.

What do you need and why should you do it versus hosting it?

Lets address the requirements first. Assuming of course you have 2 tenants, the source and destination or in some cases just two tenants from which you want to send and receive email from, using a single SMTP domain, what you need next is something to do address rewriting (outbound email) and conditional forwarding or address rewriting (inbound email).

I will use the Microsoft Exchange Edge server. It’s a reliable service, that can be designed and implemented as high available and redundant, and it has a very easy to configure bidirectional address rewriting agent.

Note: before reading the rest of this blog post, I highly recommend that you click on the link above and read all details about how the Exchange Address Rewriting works.

Now lets address why should you do it yourself vs hosting it. In fact I think the decision is up to you, but there’s two things you should strongly consider:

  1. Do you want to pay a per user fee to host a service to either a migration software company or an email relay company, when you can do it yourself at much less cost?
  2. More importantly, will you allow a third party company into a crucial part of your email flow pipeline?

Those two questions are relevant, specially the second one. It involves SLAs and other super important things to consider, specially in the Enterprise space.

But if the answer to both questions above is yes, then you’re covered. If not, continue reading.

What will this blog post cover

This blog post will address a first scenario detailing mail flow simple coexistence with two tenants using one single email domain. I am labeling it as scenario 1, because this is the first blog post of a series that will cover other scenarios.

Scenario 1: Share a same email domain between two Exchange Online tenants

Scenario1-V1.0

What are the requirements?

To set the scenario above you need the following:

  • Two Exchange Online tenants (of course!)
  • One unique vanity domain per Office 365 tenant, which in my cases is:
    • Tenant1.myexchlab.com
    • Tenant2.myexchlab.com
  • One vanity domain to be shared by the two tenants, which in my case is myexchlab.com
  • At least one Microsoft Exchange Edge Server
  • An SSL certificate to encrypt mail flow between both Exchange Online tenants and the Microsoft Exchange Edge

Some important notes about the requirements:

  • my tenant vanity domains are sub domains of the shared vanity domain, but that is not a requirement. You can use different domains (i.e abc.com and xyz.com) in your configuration.
  • In this scenario all outbound and inbound mail flow goes via the Edge server. It is highly recommended that, for production purposes, you set up a high available and redundant multiple Edge server infrastructure.
  • My Edge Server is hosted in Azure, because it’s convenient for me to quickly set it up. You can host yours anywhere you want.
  • The SSL certificate and using TLS between the Exchange Online tenants and the Edge Server, is optional but recommended.

Outbound email from Office 365

In this scenario both tenants send all email via the Edge server. Optionally you can configure Conditional Mail Routing in Exchange Online, if you want just a group of users to route their email via the Edge. I am not going to detail that here, but please reach out if you need to elaborate more on that option.

Create the send connector in Exchange Online

First lets check how the connector in Office 365 is created. If you need any basic help on how to set up Exchange Online connectors, read this.

  • In the select mail flow scenario, select the source as “Office 365” and the destination as “Partner Organization”

Connector01

  • Name the connector and turn it on

Connector02

  • Select the destination email domains. I have selected * which means this connector applies to all external email domains

Connector03

Note: Again here you can be more creative and configure a scenario where address rewriting (and more specifically here outbound email flow going via the Edge) only applies to specific destination domains – i.e you can rewrite addresses for your users but only when they email a specific partner company with a specific vanity domain

  • Enter the Public IP address of your Edge Server or load balancer in front of it.

Connector04

  • Configure the connector to always use TLS when communicating to the Edge Server. Enter the subject name or the SAN of the certificate you will use (more on how to configure the certificate later)

Connector05

And that’s it, your outbound connector is configured in your Exchange Online tenant. If you’re configuring this in a production environment, make sure you scope it for one test user first, until you’re 100% sure the Edge Server is configured properly and mail flow doesn’t have any issues.

Don’t forget to create the connector in both tenants.

Receive and Send connectors in the Edge Server(s)

Now that we addressed the Exchange Online connectors, lets look at the next hop in the mail flow pipeline, the Edge Server.

For this scenario to work properly, three things need to be created in the Edge Server:

  • Receive connector(s): This is key to accept email coming from EOP/Exchange Online
  • Address Rewrite Rule(s): To be applied by the inbound and outbound transport agents and rewrite addresses
  • Send connector(s): To send email outbound or inbound after the agent does its work

Lets address first the connectors.

Receive connector

There are multiple ways and scenarios to configure the receive connector, but ultimately here’s what you need to consider:

  • You should create a dedicated connector that accepts connections from EOP (Exchange Online Protection) only, by using the “remoteipranges” parameter when creating the connector
  • You should secure communications by adding TLS as an AuthMecanism and setting the “RequireTLS” flag to $true. You will also need to add the “TLSDomainCapabilities” and “TLSCertificateName” tags
  • If in your scenario, just like in mine, the Edge Servers are stand alone, you need to make the connector ‘ExternalAuthoritative’. This is key, because for address rewriting to be executed properly, the outbound emails should be considered internal email by the Edge Server. See more on how address rewriting works in this excellent article
  • Finally you need to make sure the connector accepts anonymous relay

Note: It is very important that you lock the connector down to a specific IP range and secure the communications with a certificate and TLS, since that connector will accept anonymous relay. Alternatively, if you have or can install an Edge Server in your existing Hybrid organization (and not stand alone like in this scenario), that will allow internal authenticated email, then you should opt for doing that.

Additional Note: I’ve added an additional method to protect your Edge and mail flow infrastructure from malicious relay from other Office 365 tenants. See the “Protect your Edge from malicious email relay by creating transport rules” section below.

Lets now start by creating the receive connector:

New-ReceiveConnector -Name “From EOP” -RemoteIPRanges [EOP remote Ranges] -Usage custom -AuthMechanism Tls -PermissionGroups AnonymousUsers, ExchangeUsers, ExchangeServers, Partners -Bindings 0.0.0.0:25

In the command above you should:

  • Change the name of the connector as per your naming convention
  • Add all EOP remote ranges that you can find here
  • Define specific bindings if relevant to your scenario

Once the connector is created, we need to add the necessary AD permissions:

Get-ReceiveConnector "From EOP" | Add-ADPermission -User 'NT AUTHORITY\Anonymous Logon' -ExtendedRights MS-Exch-SMTP-Accept-Any-Recipient

Before you add TLS to the connector, you need the certificate name:

$cert = Get-ExchangeCertificate -Thumbprint [Thumbprint of your third party Exchange certificate assigned to the SMTP service]
$tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)"

Note: Make sure that you obtain, import and assign a proper third party certificate to your Exchange Server Edge, before you configure the receive connector

Now lets set all the necessary TLS properties in the connector:

Get-ReceiveConnector "From EOP" | Set-ReceiveConnector -AuthMechanism ExternalAuthoritative, Tls -RequireTls:$true -TlsDomainCapabilities mail.protection.outlook.com:AcceptOorgProtocol -TlsCertificateName $tlscertificatename -fqdn mail.yourdomain.com

Make sure that the FQDN of the connector matches the certificate name.

Receive01

Above a snapshot of the most relevant properties of the receive connector.

Send connector

Again here, for the send connector, you can have multiple scenarios. For mine, my Edge Server just has a simple send connector, not scoped to any transport rule or address space, that sends outbound email for all domains. Since this send connector is to send email to the Internet, no special TLS settings are configured.

The command I used was:

New-SendConnector -Internet -Name "To Internet" -AddressSpaces *

See here how to create a send connector and create your own.

Exchange Edge Address rewrite rules

Before I explain what rules you should create, I strongly encourage you to read this Address Rewriting on Microsoft Edge Servers article.

Address rewriting rules can be done per domain or per user. When you plan yours, think about if a domain type rule is enough or not, i.e do you want to translate John@abc.com to John@xyz.com, or do you want to translate John.Smith@abc.com to JSmith@xyz.com, meaning is the prefix changing or not? If the answer is yes the prefix will change, then you need one rule per user.

Lets now check what we need to do for this specific scenario:

  • John.Smith@tenant1.myexchlab.com is on the first tenant and we need to translate his address to John.Smith@myexchlab.com
  • Mary.Smith@tenant2.myexchlab.com is on the second tenant and we need to translate her address to Mary.Smith@myexchlab.com

Now the rules:

New-AddressRewriteEntry -Name "John tenant1.myexchlab.com to myexchlab.com" -InternalAddress John.Smith@tenant1.myexchlab.com -ExternalAddress John.Smith@myexchlab.com
New-AddressRewriteEntry -Name "Mary tenant2.myexchlab.com to myexchlab.com" -InternalAddress Mary.Smith@tenant2.myexchlab.com -ExternalAddress Mary.Smith@myexchlab.com

The rules I created in this scenario are bi-directional.

Again you should consider per domain rules when applicable. You can also import the rules via CSV, to make sure you can create all rules with minimum effort.

Protect your Edge from malicious email relay by creating transport rules

When you set up the connectors for inbound and outbound relay of email, although the connections require TLS and only accept emails from Exchange Online, you have no control on what other Exchange Online tenants will try to do, and if they try to use your Edge to relay email.

To be able to control that, you need to create multiple transport rules in all of your Edge servers. Creating a transport rule in an Edge server is not as linear and doesn’t have the same available options that a CAS server has, but here’s what you need to do:

First exclude the recipient domains by creating one transport rule for each (or consolidating all in one) that basically stops transport rule processing if it finds a match:

New-TransportRule -Name "Emails from Outside to myexchlab.com Inside" -FromScope NotInOrganization -AnyOfRecipientAddressContains "myexchlab.com" -StopRuleProcessing $true
New-TransportRule -Name "Emails from Outside to tenant1.myexchlab.com Inside" -FromScope NotInOrganization -AnyOfRecipientAddressContains "tenant1.myexchlab.com" -StopRuleProcessing $true
New-TransportRule -Name "Emails from Outside to tenant2.myexchlab.com Inside" -FromScope NotInOrganization -AnyOfRecipientAddressContains "tenant2.myexchlab.com" -StopRuleProcessing $true

And finally the rule with less priority that will drop the email if it’s from outside of the Organization:

New-TransportRule -Name "Drop email if Outside of Organization" -FromScope NotInOrganization -DeleteMessage $true

The rules above must be in the right priority, meaning priority 0 to 2 should be to the rules that stop processing more rules, if an internal domain is detected.

Then, if there’s no internal domain detected in any of the recipients of the message, the Edge should drop the message. This is to allow that inbound email still works and outbound doesn’t allow malicious connections for relay.

Basically what you are saying in the last rule is that if the sender is not internal to your organization, have the Edge server just drop the email, if that rule ends up being processed. I strongly advise you to test the rule right after you implement it, and make sure it allows all the domains you need.

Lets show the rule in action:

email14

As you can see above the email sent from a non accepted domain gets dropped by the Edge server. Also remember that the rules was processed because no other rule found a domain match in all recipients.

Consider the transport rules, although unfortunately very limited when applied in Edge Servers, when it comes to available actions and predicates, as an additional and important layer of security that you can apply to your infrastructure.

Accepted domains in the Edge Server

One of the important things I mentioned before, is that the Edge Server considers the outbound and inbound emails, sent to and from the domains you are translating to and from, as internal emails.

In my scenario all I had to begin with was a stand alone Edge Server, with no accepted domains, which might not be the case for you if you use an Edge in an existing Hybrid infrastructure, but if it is, here’s what you need to know about accepted domains:

  • Add the vanity domain from source and destination tenants, that you are translating from (outbound) and to (inbound)
  • Add the vanity domain both tenants are sharing

AcceptedDomains

Here’s the snapshot of mine, just so you understand better what I needed for my scenario.

DNS Records

Now let me describe how my email related DNS records should be configured. Remember this is specific for my scenario. Also I am only covering the MX and SPF DNS records. Make sure that you apply the industry recommendations for email when configuring your email domains (i.e DKIM).

The MX records

Here’s how the MX records for all 3 domains are configured, in my scenario:

  • tenant1.myexchlab.com: MX record points to EOP in the Office 365 tenant where the domain is valid
  • tenant2.myexchlab.com: MX record points to EOP in the Office 365 tenant where the domain is valid
  • myexchlab.com: MX points to the pool of Edge Servers

The explanation for the above is simple, you need to make sure that any email outside of the address rewriting can go to the correct recipient. For example, if someone external emails Peter@tenant1.myexchlab.com, there’s no reason for the email to go via the address rewriting process or the Edge pool. And this applies to any external communication going to source and destination going directly to those domains.

As for the myexchlab.com, the opposite happens, meaning if someone emails Jack@myexchlab.com, the email must go to the Edge just so the inbound transport agent can translate that address to Jack@tenantX.myexchlab.com. For that reason and because the Edge is the source of authority for the myexchlab.com domain, that effectively is not an SMTP address in any recipient in my scenario, the MX for that domain needs to point there.

The SPF records

Here I opted for the safest approach and configured all SPF records the same way, for all 3 domains, to include senders from:

  • MX record
  • Exchange Online protection
  • The Edge server

Lets break this down:

  • tenant1.myexchlab.com and tenant2.myexchlab.com: for this domains, hosted in Office 365, allowing the MX and EOP is redundant but it does no harm, and I allowed the Edge server for one simple reason, if the address translation fails for some reason, the email can still go from the Edge server outbound and the source address would be on of these domains, so for those unexpected scenarios you should add the Edge to the SPF.
  • myexchlab.com: for this domain, adding EOP is in fact not needed in my scenario, since there’s no point in time where the domain is expected to be moved to Office 365, but in most scenarios, specially migration scenarios, EOP should be in the allowed senders, so I added it. The Edge and the MX are again redundant, but you should have at least one of them.

Here’s how the SPF would look:

v=spf1 mx ip4:[Edge IPV4 Public address] include:spf.protection.outlook.com ~all

How everything works

It’s time to test the scenario now. Here’s what I will do:

  • Send an outbound email from both tenants
  • Reply to the outbound emails
  • Send an inbound email to both tenants

The results we will analyze are:

  • Verify source and destination “from” and “to” addresses, looking at the email in the destination
  • Verify that TLS is being used
  • See the transport agents in action

I don’t want to prove my scenario with screenshots, since I don’t think that’s relevant and I’d have to grey out most of the information anyway, but below you can find some snippets of how it worked, just so we’re clear on what you should expect and also how to troubleshoot any issues.

Outbound email from both tenants

The email being sent at the source, from John:

email01

And from Mary:

email02

Now lets see what happens when the email hits the Edge server:

email03

email04

I used the message tracking log, and as you can see for the message I sent, the agent event “SETROUTE” is translating the address.

Lets look at the message in the destination:

email05

email06

… and now lets really look inside the message 🙂 (just one of them now)

The original mailfrom address:

email07

The address translated:

email09

And TLS being used:

email08

Reply to the outbound emails

For the reply I will just use one user as the example, since the behavior is the same for both.

email10

So lets see what happens in the Edge:

email11

As you can see above, there’s two messages address to Mary, one is a reply and the other a brand new message, in both cases you can see that the recipient got translated. Unlike outbound email, you won’t see an event ID associated to the transport agent, but you can check in the recipients column that it did its job.

And finally, the external email in the internal mailbox:

email13

That’s it. Enough screenshots. Hopefully you understood how everything works and how you can troubleshoot it.

The bottom line

Hopefully after reading this blog post, you can understand better how the mail flow coexistence can be done. This was in fact a simple scenario but more will come in future posts. If you want me to describe and blog about a specific scenario you have, or if you need help understanding it better, please drop me a line.

I’ve been working in the migration business for more than 5 years now, and I’ve seen a lot of partners and customers that do need mail flow coexistence between two tenants. Because it’s not simple for Microsoft to address that, and allow things like the same vanity domain in two tenants, some companies created products and services that try and fill that gap, but like I said previously in this post, handing over your mail flow pipeline is not a simple decision nor one that Enterprises are willing to take, specially when it’s not that hard for you to do it yourself and I am sure that building and maintaining a high available mail flow infrastructure (like Edge servers) is cheaper than paying a per user fee to get this functionality.

In fact, for many Enterprises, they already have what they need. This doesn’t necessarily has to be done with Edge servers. The top email appliances in the market can do this as well. I might include some of those scenarios in future posts.

Stay tuned and thank you for reading!

 

 

 

 

 

 

 

 

 

 

 

 

Exchange Auditing, Calendar Logging and @MigrationWiz mailbox migrations with @BitTitan

Before you read this post, please have a look at this Microsoft article about the Recoverable Items Folder in Exchange Online.

Two of the hidden folders you will find within the Recoverable Items, are there to log changes done to the mailbox:

  • Audits: If mailbox audit logging is enabled for a mailbox, this sub-folder contains the audit log entries. To learn more about mailbox audit logging, see Export mailbox audit logs in Exchange Online.
  • Calendar Logging: This sub-folder contains calendar changes that occur within a mailbox. This folder isn’t available to users.

Note: The folder “Versions” does keep track of multiple versions of a changed item, so in theory it also logs changes, but it’s not relevant for this post.

Dumpster01

Above you can see the structure of a mailbox and recoverable items.

So why is this important in the context of a migration?

When you leverage MigrationWiz to migrate mailboxes into a new Office 365 tenant, and because those tenants will have enabled by default both the Audit and the Calendar logging, the tool will create a lot of logs in those folders and in some extreme cases when the logs created are in a large number, it will slow down your migration.

It’s also important to state that the logs created on those folders are for the changes made by the migration tool. It logs what MigrationWiz changes in the process of the migration.

Dumpster02

The above is a warning thrown by MigrationWiz, stating that the folder “Audits”, in the recoverable deleted items, has more items than it should. Technically any folder in the recoverable deleted items can have up to 3 million items, but because MigrationWiz leverages EWS (Exchange Web Services), when the count goes over 100k items we will see and surface warning messages from Exchange.

Can you still create up to 3 million items? Yes, you should be able to, but the migration will slow down considerably.

Again, I want to stress that those items are probably in its majority the result of audit and calendar logging, and not necessarily items being migrated from the Audits source folder.

So how can we mitigate this?

Because the way to deal with Audit and Calendar logging is different, I am going to address it below, separately. Basically the solution, although applied separately and differently, is to disable Audit logging and/or disable Calendar logging, during the migration.

Before I proceed, and explain how you can do it, I have to state that both Audit and Calendar logging are security and compliance features in Exchange Online and on premises, so it’s ultimately up to you to decide if you should temporarily disable it or not. One thing that you should take into account, is if those mailboxes are being used by the end users or just for migration purposes? If it’s just migration purposes and if you are migrating mailboxes with very large item counts, then think of this as an option, since at that point there’s no end user actions to be logged.

Read more about Mailbox Audit logging in Exchange Server.

Microsoft doesn’t have a lot of official documentation on Calendar logging, but I’ll explain how you can disable it during the migration.

Mailbox Audit logs

There are several ways to disable Audit Logging in Exchange Online:

  • Disable Audit at the Organization Level
  • Disable Audit per mailbox

Read this article to understand how to Manage Mailbox auditing.

So let’s look at a mailbox without audit disabled:

AUdit1

As you can see above, the mailbox has audit enabled and is auditing all actions by admins, delegates and owner. We will not completely disable auditing in the mailbox, as it’s not needed. All we will do is disable Admin audit, since that is the only one that audits the impersonation access granted to MigrationWiz.

This is the recoverable items of the destination mailbox, before the migration:

Audit2

As you can see above, this being a brand new mailbox, the Audits folder is not even created.

And when migrating, we see the following:

Audit3

The count in the Audits folder went up to 6 items. Now lets see if that count matches what MigrationWiz migrated:

Audit4

Perfect match. So the bottom line here is that, as MigrationWiz copies the data into the destination mailbox, Exchange Online will Audit each action for each item as an Admin access to the destination mailbox. That can become a problem for mailboxes with hundreds of thousands of items, and a bigger problem when you are actually using MigrationWiz to move from recoverable items to recoverable items.

So now lets try the same migration but without Audit logging. Execute the following Exchange Management Shell cmdlet:

Set-Mailbox Peter.Smith -Auditadmin $null

Note: You might need to wait up to one hour (might take longer sometimes), after the changes are applied and before you migrate.

We will not completely disable auditing in the mailbox, as it’s not needed. All we will do is disable Admin audit, since that is the only one that audits the impersonation access granted to MigrationWiz.

Lets look at the results:

Audit9

I listed the entire mailbox just so you can see that the Inbox content was moved, but the Audits folder is still empty. Actually the Audits folder wasn’t even created because no audits were done and the mailbox is new.

Finally lets put the Auditing setting back to active. Don’t forget to re enable those settings, otherwise Admin auditing will stay disabled!

Execute the following Exchange Management Shell cmdlet:

Set-Mailbox Peter.Smith -DefaultAuditSet Delegate,Owner,Admin

To make sure the settings were applied you can run the command below:

Audit10

And that’s it regarding Audit logging. In summary, it’s up to you to run the migration with or without audit logging enabled for admin access, but in my opinion, temporarily disabling it during the migration might prevent some issues and be beneficial.

Calendar Logging

Exchange Online calendar logging will track changes of calendar items. Those changes will be stored in the recoverable deleted items, inside the “Calendar Logging” folder.

Just like with the Audits, when you are migrating data with MigrationWiz, in this specific case when you are migrating calendar items, the calendar logging folder can get a large volume of items, due to the logging feature being enabled.

The logic behind disabling it here is the exact same, and so are the reasons to consider it and decide if you want to do it or not.

Now lets look at how we disable calendar logging:

Audit5

As you can see above, there’s a property at the mailbox level named “CalendarVersionStoreDisabled“. By default that value is set to “False“. Lets see what happens when we migrate calendars with the option set like this:

Audit6

As you can see above the Calendar Logging is 7. Below you’ll see that the total number of calendar items migrated was 4. Depending on the meeting type (single, recurring, etc) the number of logged events in calendar might vary, and it’s not always 1 per event migrated.

Audit7

Again, above you can see in yellow the number of calendar events is 4. The default calendar (United States Holidays) migration does not get logged.

Now lets see how can we remove the logging. First start by running the command below:

Set-Mailbox Peter.Smith -CalendarVersionStoreDisabled $true

Note: You might need to wait up to one hour (might take longer sometimes), after the changes are applied and before you migrate.

Lets look at the destination mailbox after the migration, when logging is disabled:

Audit8

Above you’ll see that 4 calendar items got migrated but no Calendar logging was done.

Now how do you revert back the changes?

Set-Mailbox Peter.Smith -CalendarVersionStoreDisabled $false

Just set the value back to false. It’s very important to understand that those logging features should be enabled, so make sure you revert the changes done during migration.

The Calendar Logging done during migration is, just like for audits, even more problematic if you are migrating from recoverable items to recoverable items.

Bottom line

In this blog post we discussed how Auditing and Calendar logging in Exchange, might have an impact in your mailbox migration. It’s important to understand that those features are super important and should ideally be enabled, but consider the following:

  • do you really want to log 150 changes to calendar items in John’s mailbox when they were all done by a migration account in the context of a migration?
  • and how will that impact future log searches as part of a compliance process?
  • how about the 50000 audits of mailbox items being moved? do you need those, them being done in the context of a migration?
  • finally, if you’re migrating the recoverable items folder, you’re technically duplicating every audit log that exists in the source, because MigrationWiz will move the audit log entry and create a new one as part of auditing the move

The main reason for this blog post is to prepare you for some potential delays, if you are migrating large item counts with auditing enabled, but also to explain how you can disable it and, in my opinion, have a cleaner destination without a lot of logging that might not be as relevant.

Ultimately, it’s your decision to use this information as you see more fit for your organization.

 

 

 

 

 

 

Are you considering Exchange 2019 as a “hybrid” management server in Exchange Online environments with objects synced from on premises Active Directory?

If you happen to manage an Exchange Online environment where most or all users (and other objects) are synced from your local Active Directory, you know that, for your management tasks to be executed in a supported and easy way, you need two things:

  • The local Active Directory Schema extended to the latest (recommended) Exchange version
  • At least one Exchange management server, to execute the management actions from

Because you need the schema extended, to match the cloud Exchange attributes, in your management server, it’s also logic that you would try and keep your management server with the latest version possible. With that said, you should plan to update your Exchange server on premises, whenever a new version is made available.

Seems simple, right? Well it was that simple, until Exchange 2019 came out and Microsoft decided to not provide Exchange Server Hybrid keys for it.

In the past, Microsoft had a specific site where you would get the Hybrid keys from. In theory, to be compliant, for any Exchange on premises version that was used for management and/or hybrid purposes only, and that did not host any mailbox, you would be able to license it for free.

But in July 2018 in the tech community article “Hybrid Configuration Wizard and licensing of your on-premises server used for hybrid” Microsoft explains how you can now use the Hybrid Wizard to license your Exchange server for free, but also states “Please note that HCW does not provide a ‘hybrid key’ for Exchange Server 2019. If you need a hybrid key, the latest version that it is available for is Exchange Server 2016.”

I know this is not new, but managing synced organizations has been and will continue to be a hot topic, for many different reasons, so I decided to blog about it, again.

Why not extend the free licensing to Exchange 2019?

It’s public that Microsoft still has a strong focus on providing Exchange 2019 as the Exchange version for organizations that do not want to move to the cloud, and this licensing decision is for sure related to that, in my opinion.

Is the Hybrid Wizard the best option to license your server?

I think that the Microsoft move from the website to the Wizard, to obtain licenses for hybrid server versions until 2016, is a clever one because it allows the licensing process to be easier to control, however, not all Exchange on premises in this environments can be truly characterized as “Hybrid”.

Many organizations either never had Exchange on premises or don’t rely on any type of interaction with their on premises Exchange, that could truly define it as a “Hybrid server”. Mail flow is fully in the cloud, all hardware and applications on premises interact directly with Exchange Online and free/busy between the cloud and on premises is not required because no objects are hosted from on premises.

So now you not only ask those type of customers to install an Exchange Server, just so they can manage their synced objects in a supported way, but you also ask them to run the Hybrid Wizard in a technically “non-hybrid” environment.

What’s my best option to keep my management server up to date?

The answer is simple: To stay fully up to date, you should update to 2019 and pay for a Standard license.

But if you don’t want to do that, at least for now managing the objects with Exchange 2016 is also a very valid option. Keep the 2016 version for as long as it’s officially supported and tackle the upgrade when you really need to have it done to stay in that supported scenario.