Exchange Online Migration Batches–How Long Do They Exist For

Posted on 3 CommentsPosted in exchange, exchange online, Exchange Server, hybrid, microsoft, migration, Office 365

When you create a migration batch in Exchange Online, the default setting for a migration is to start the batch immediately and complete manually. So how long can you leave this batch before you need to complete it?

As you can see from the below screenshot, the migration batch here was created on Feb 19th, which was only yesterday as I write this blog.

image

The batch was created on the morning of the 19th Feb, and set to manual start (rather than the default of automatic start, as did not want to migrate lots of data during the business day) and then it was started close to 5:30pm that evening. By 11:25pm the batch had completed its initial sync of all 28 mailboxes and there were no failures. There were other batches syncing at the same time, so this is not indicative of any expected or determined migration performance speeds.

So what happens next. In the background a new mailbox move request was created for each mailbox in the batch, and each individual mailbox was synced to Exchange Online and associated with the synced Mail User object created in the cloud by the AADSync process. When each move reached 95% complete, the move was suspended. It will be resumed around 24 hours later, so that each mailbox is kept up to date once a day automatically.

If you leave the migration running but not completed you will see from the migration batch status above that the batch will complete in 7,981 years (on the 31st Dec 9999 and one second before the next millennium bug hits). In the meantime the migration batch sync will stop doing its daily updates after two months.

After two months of syncing to the cloud and not being completed, Exchange Online assumes you are still no closer to migrating and they stop keeping the mailbox on-premise and the mailbox in the cloud in sync. You can restart this process by interacting with the migration batch before this time, or if it does stop by just clicking the Resume icon, and this will restart it for a further period of time.

Office 365 Retention Policies and Hybrid Public Folders

Posted on Leave a commentPosted in exchange online, Exchange Server, hybrid, Office 365, Public Folders, retention, retention policies

If you create an Office 365 Retention Policy (in the Security and Compliance Center) that applies to all Exchange Online content then you might find that after the retention policy has been deployed (a day or so later usually) that the policy is in error and there is a message at the top of the retention policy pane that shows “1 distribution result(s) found”.

image

The “Notify support” link does nothing but help you call support, and a post on the Microsoft Tech Community implies that that does not help.

The place to look for the answer is in a Security and Compliance Remote PowerShell session. Here you can run Get-RetentionCompliancePolicy -DistributionDetail | fl Name,Distribution* to return the name of each of your retention policies along with the DistributionStatus (which will be “Error”) and DistributionResults.

In my example I found I had a DistributionResults message of “{[Exchange]AllPublicFolderUnderRoot:Recipient not found: }”.

image

In the example that I was trying to resolve this issue for, the Exchange Online organization was utilizing on-premises Public Folders for Exchange Online mailboxes. That is, in Exchange Online, the PublicFoldersEnabled property of Get-OrganizationConfig was set to remote and we had a few RemotePublicFolderMailboxes (aka mailboxes that proxy the online mailboxes connection to the on-premises organization).

image

Therefore there seems to be an error in Office 365 Retention Policies where the retention policy distribution fails when you set it to archive public folders, but your public folder infrastructure is still on-premises.

So what can you do – either you ignore the error, after all it is telling you that your retention does not include objects that do not yet exist – but when you do have public folders in Exchange Online, the retention policy should take effect without you doing anything else.

The other thing you could do is to to remove public folders as a retention source, not forgetting to enable it again when you have moved your public folders to the cloud.

image

Journal Rule Testing In Exchange Online

Posted on Leave a commentPosted in EOP, exchange online, Exchange Online Protection, Exchange Server, journal, journaling, Office 365, smtp

I came across two interesting oddities in journaling in Exchange Online in the last few weeks that I noticed where not really mentioned anyway (or anywhere I could find that is). The first involces routing of journal reports and the second the selection of the journal target.

The journal report, that is the message that is sent to the journal target mailbox when an email is sent or received from the mailbox(es) under the control of the Journal Rule. This journal report is a system message, that is Exchange Online marks it as such so that it is treated and considered differently within the Office 365 service. This though means that Conditional Routing does not apply to journal reports. Conditional routing is where you have a mail flow (or transport) rule, that routes the emails based on passing the conditions in the rule. Journal messages are never subject to rules, and this includes conditional routing as well.

This means that journal rules leaving Exchange Online will always route via the default connector or a standard connector for the SMTP namespace of the journal report target. If Centralized Mail Flow is enabled in hybrid mode, the standard connector for the SMTP namespace is ignored, as all mail routes via the * connector apart from that that is already affected by mail flow rules. As journal reports cannot be routed via conditional routes due to not being processed by the mail flow rules, this means in a scenario where Centralized Mail Flow is enabled, journal reports will only follow the routing to *.

In a multi-organization hybrid deployment, this means that your journal reports from the cloud may end up in the wrong on-premises organization and you will need to route them appropriately.

The second issue I came across is more for a journal test scenario. It is against the terms of service in Exchange Online to store journal reports in a mailbox in Exchange Online, but its only in the last few days I have noticed that you now (and not sure for how long) you have been unable to enter a target mailbox that is in Exchange Online.

For example, I created a new journal rule and entered a target mailbox in a different Office 356 tenant. I was not allowed to use that mailbox. The error message was not clear though, and it took some time to work this out. The error message you get is “The JournalEmailAddress can only be a mail user, a mail contact or an external address”

image

Of course where the journal target address is external to your tenant (an external address), then this error makes no sense. Also if you create a mail user or mail contact that points towards the target it will not be accepted whilst that mailbox exists elsewhere in Office 365. You can enter an address for a domain that is hosted in Office 365, as long as that mailbox is not hosted in Office 365. It is just where the address is currently in Office 365 you cannot make a journal rule to send email to it.

You cannot also work around this limitation anymore either – if you enter a journal target address that is not in Exchange Online so that the Journal Rule setup completes, then go and add that target address to your other tenant, you will see that the journal report messages never arrive. Change it for an on-premises mailbox and it will work straight away.

Therefore it is now no longer possible to even test journaling unless you have an external mailbox. Shame the error is not clearer – would have saved a bit of time!

Duplicate Exchange Online and Exchange Server Mailboxes

Posted on 4 CommentsPosted in duplicate, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, mailbox, MX, Office 365

With a hybrid Exchange Online deployment, where you have Exchange Server on-premises and Exchange Online configured in the cloud, and utilising AADConnect to synchronize the directory, you should never find that a synced user object is configured as both a mailbox in the cloud and a mailbox on-premises.

When Active Directory is synced to Azure Active Directory, the ExchangeGUID attribute for the on-premises user is synced to the cloud (assuming that you have not do a limited attribute sync and not synced the Exchange attributes – as that is required for Exchange Online hybrid). The Exchange Online directory takes a sync of information relating to Exchange from Azure Active Directory (Azure AD), which is known as forward sync. This ensures that the ExchangeGUID attribute from the on-premises mailbox is synced into your Exchange Online directory.

When a user is given an Exchange Online licence, it becomes the job of Exchange Online to provision a mailbox for this user. When Exchange Online needs to provision a new mailbox, it will not do so where the ExchangeGUID attribute already exists. The existence of this attribute tells the provisioning process that the mailbox already exists on-premises and will be migrated here later and so not to create a conflicting mailbox. A cloud user who does not have an ExchangeGUID attribute synced from on-premises will get a mailbox created by the Exchange Online provisioning process upon a licence being assigned, and on-premises users that do not have a mailbox on-premises (who also have no ExchangeGUID attribute) will also find that granting them an Exchange Online licence will trigger the creation of a mailbox for them.

This is all well and good, and the above is what happens in most cases. But there is an edge case where an on-premises user with a mailbox (and therefore has the ExchangeGUID attribute populated) will also get a mailbox in Exchange Online. This happens where the organization manually created cloud mailboxes before enabling AADConnect to sync the directories, and these cloud users match the on-premises user by UserPrincipalName and they are given an Exchange Online licence.

In this above case, because they are cloud users with an Exchange Online licence they get a mailbox. Deleting the cloud user and then enabling sync will cause the original mailbox to be restored to the user account as the UserPrincipalName matches.

For example, the below shows a user being created in the cloud called “twomailboxes@domain.com”:

image

The user is granted a full Office 365 E3 licence, so this means the user has an Exchange Online mailbox. There is no AADConnect sync in place, but the UPN matches a user on-premises who has a mailbox.

In Exchange Online PowerShell, once the mailbox is provisioned we can see the following:

image

PS> get-mailbox twomailboxes | fl name,userprincipalname,exchangeguid



Name              : twomailboxes
UserPrincipalName : twomailboxes@domain.com
ExchangeGuid      : d893372b-bfe0-4833-9905-eb497bb81de4

Repeating the same on-premises will show a separate user (remember, no AD sync in place at this time) with the same UPN and a different ExchangeGUID.

image

[PS] >get-mailbox twomailboxes | fl name,userprincipalname,exchangeguid



Name              : Two Mailboxes
UserPrincipalName : twomailboxes@cwh.org.uk
ExchangeGuid      : 625d70aa-82ed-47a2-afa2-d3c091d149aa

Note that the on-premises object ExchangeGUID is not the same as the cloud ExchangeGUID. This is because there are two seperate mailboxes.

Get-User in the cloud will also report something useful. It will show the “PreviousRecipientTypeDetails” value, which is not modifiable by the administrator, in this case shows there was not a previous mailbox for the user but this can show that a previous mailbox did exist. For completion we also show the licence state:

image

PS > get-user twomailboxes | fl name,recipienttype,previousrecipienttypedetails,*sku*



Name                         : twomailboxes
RecipientType                : UserMailbox
PreviousRecipientTypeDetails : None
SKUAssigned                  : True

Now in preparation for the sync of the Active Directory to Azure Active Directory, the user accounts in the cloud are either left in place (and so sync will do a soft-match for those users) or they are deleted and the on-premises user account syncs to the cloud. In the first case, the clash on the sync will result in the cloud mailbox being merged into the settings from the on-premises mailbox. In the second case, there is no user account to merge into, but there is a mailbox to restore against this user. And even though the newly synced user has an ExchangeGUID attribute on-premises that is synced to the cloud, and they have a valid licence, Exchange Online reattaches the old mailbox associated with a different GUID.

The impact of this is minor to massive. In the scenario where MX points to on-premises and you have not yet moved any mailboxes to the cloud, this cloud mailbox will only get email from other cloud mailboxes in your tenant (there are none in this scenario) or internal alerts in Office 365 (and these are reducing over time, as they start to follow correct routing). It can be a major issue though if you use MX to Exchange Online Protection. As there is now a mailbox in the cloud for a user on-premises, inbound internet sourced email for your on-premises user will get delivered to the cloud mailbox and not appear on-premises. Where the invalid mailbox has no email, recovery is not required. Finally, where there is a duplicate mailbox, move requests for those users for onboarding to Exchange Online will fail:

image

This reads “a subscription for the migration user <email> couldn’t be loaded”. This occurs where the user was not licenced and so there was not a duplicate mailbox in the cloud, but the user was later licenced before the migration completed.

Where the invalid duplicate mailbox exists in the cloud and is getting valid emails delivered to it, the recovery work described below additionally will involve exporting email from this invalid mailbox and then removing the mailbox as part of the fix. Extraction of email from the duplicate mailbox needs to happen before the licence is removed.

To remove the cloud mailbox and to stop it being recreated, you need to ensure that the synced user does not have an Exchange Online licence. You can grant them other licences in Office 365, but not Exchange Online. I have noticed that if you do licencing via Azure AD group based licencing rules then this will also fail (these are still in preview at time of writing) and that you need to ensure that the user is assigned the licence directly in the Office 365 portal and that they do not get the Exchange Online licence. After licence reconciliation in the cloud occurs (a few minutes typically) the duplicate mailbox is removed (though I have seen this take a few hours). The Get-User cmdlet above will show the RecipientType being a MailUser and not Mailbox.

You are now in a position where your duplicate cloud mailbox is gone (which is why if that mailbox had been a target to valid emails before now, you would need to have extracted the data via discovery and search processes first).

Running the above Get-User and Get-Mailbox (and now Get-MailUser) cmdlets in the cloud will show you that the ExchangeGUID on the cloud object now matches the on-premises object and the duplication is gone. You can now migrate that mailbox to the cloud successfully.

We can take a look at what we see in remote PowerShell here:

Recall from above that there were two different ExchangeGUIDs, one in the cloud and one on-premises. These in my example where:

Cloud duplicate ExchangeGuid      : d893372b-bfe0-4833-9905-eb497bb81de4

On-premises mailbox ExchangeGuid  : 625d70aa-82ed-47a2-afa2-d3c091d149aa

Get-User before licences removed in the cloud, showing a mailbox and that it was previously a mailbox as well:

image

PS > get-user twomailboxes | fl name,recipienttype,previousrecipienttypedetails,*sku*



Name                         : Two Mailboxes
RecipientType                : UserMailbox
PreviousRecipientTypeDetails : UserMailbox
SKUAssigned                  : True

Get-Mailbox in the cloud showing the GUID was different from on-premises:

image

PS > get-mailbox twomailboxes | fl name,userprincipalname,exchangeguid



Name              : Two Mailboxes
UserPrincipalName :
twomailboxes@domain.com

ExchangeGuid      : d893372b-bfe0-4833-9905-eb497bb81de4

Once the licence is removed in Office 365 for Exchange Online and licence reconciliation completes (SKUAssigned is False) you will see that Get-User shows it is not a mailbox anymore:

image

PS > get-user twomailboxes | fl name,recipienttype,previousrecipienttypedetails,*sku*



Name                         : Two Mailboxes
RecipientType                : MailUser
PreviousRecipientTypeDetails : UserMailbox
SKUAssigned                  : False

And finally Get-MailUser (not Get-Mailbox now) shows the ExchangeGUID matches the on-premises, synced, ExchangeGUID value:

image

PS > get-mailuser twomailboxes | fl name,userprincipalname,exchangeguid



Name              : Two Mailboxes
UserPrincipalName : twomailboxes@domain.com
ExchangeGuid      : 625d70aa-82ed-47a2-afa2-d3c091d149aa

Note that giving these users back their Exchange Online licence will revert all of the above and restore their old mailbox. As these users cannot have an Exchange Online licence assigned in the cloud, for risk of their old mailbox returning you need to ensure that within 30 days of their on-premises mailbox being migrated to the cloud you do give then an Exchange Online mailbox. Giving them a licence after migration of their on-premises mailbox to the cloud will ensure their single, migrated, mailbox remains in Exchange Online. But giving their user a licence before migration will restore their old cloud mailbox.

For users that never had a matching UPN in the cloud and a cloud mailbox, you can licence them before you migrate their mailbox as they will work correctly within the provisioning system in Exchange Online.

Enable Report Message Add-In For Office 365

Posted on Leave a commentPosted in add-in, EOP, exchange online, Exchange Online Protection, Office, Office 365, Office 365 ProPlus, phish, phishing, spam

There is a new add-in available for Outlook and OWA in Office 365 that can simplify spam and phishing reporting to Microsoft for content in your mailbox. I recommend rolling this add-in out to everyone in your Office 365 tenant and for Office 365 consultants to add this as part of the default steps in deploying a new tenant.

This can be done with the following steps:

In the Exchange Control Panel at https://outlook.office365.com/ecp/ go to the Organization > Add-Ins section

image

Click the + icon and choose “Add From Office Store”.

In the new tab that appears, search for “Report Message” via the search bar top right:

I’ve noticed that a set of search results appear, then the website notices I am logged in, logs me in and presents a second smaller list of results. It is in this small list that you should see Report Message by Microsoft Corporation

image

I’ve noticed that clicking “Get it now” does not seem to work all the time (the popup has a Continue button that does nothing)! So if that happens, cancel the popup, click the card for the app and install the add from the Get it now button rather than the get it now link on the card. The Report Message app page is shown below with a “Get It Now” button to the left:

image

Either the link or the button should work, and you should get this popup:

image

Click Continue. You are taken to Office 365 to continue. This is the step I eluded to above that sometimes does not work

image

You are asked to confirm the installation of the App into Office 365

image

Click Yes and wait a while. I’ve noticed also that sometimes you need to refresh this page manually for the process to continue, though waiting (with no indication that anything is happening for one or two minutes is usually enough as well)

image

The message above says that the add-in is now visible in the gray bar above your messages. For this add-in this is not correct as this add-in extends the menu in Outlook (2013 and later, as add-ins are not supported in Outlook 2010) and also the app is disabled by default.

Close this tab in your browser and return to the add-in page in Exchange Control Panel that is open in a previous tab.

Refresh the list of apps to see the new app:

image

From here you can enable the app, select a pilot audience, though this app is quite silent in the users view of Outlook and OWA so a pilot is not needed for determining impact to users, but can be useful for putting together quick documentation or informing the help desk of changes.

Select the app and click the edit button:

image

I recommend choosing “Mandatory, always enabled. Users can’t disable this add-in” and deploying to all users. Unchecking the option to make it available for all users makes it available for none. For a pilot choose “Optional, disabled by default”.

You are now done installing the add-in.

Users will now see the add-in in Outlook near the Store icon when a message is selected open:

image

Clicking the icon allows you to mark a messages as “junk”, “phishing” or “not junk” and options and help. Options gives the following:

image

Where the default is to ask before sending info to Microsoft.

Selecting Junk or Phishing will result in the message being moved to Junk Email folder in Outlook, and if in the Junk Email folder, marking a message “Not Junk” will return it to the inbox. All options will send info on the message, headers and other criteria to Microsoft to help adjust their machine learning algoriths for spam and phishing detection. This add-in replaces the need to email the message as an attachment to Microsoft.

For a pilot, users need to add the add-in themselves to Outlook. Mandatory deployment means it is rolled out to users (usually within a few days). To enable the add-in in OWA, click the options cog to the top right of the OWA interface:

image

Then click Manage Add-Ins and scroll down until you find the Report Message add-in (or search for it)

image

And turn the add-in on to view it in OWA as shown:

image

And also it will appear automatically in Outlook for iOS and Outlook for Android and Outlook (desktop, classic).

Once the app is enabled for all users, and recall the above where it takes a while to appear for all users, then your spam and phish reporting in Office 365 is very simple and easy to do and easy to remove from a helpdesk call and on to the end user directly to report and move messages.

Office 365 Advance Threat Protection Attachment Preview

Posted on Leave a commentPosted in Advanced Threat Protection, ATP, dynamic delivery, Office 365, Office 365 Advanced Threat Protection, preview

It is now possible to preview attachments that Advanced Threat Protection (ATP) is currently in the process of checking. This was enabled on my tenant recently and so will come to all tenants soon. It was mentioned at Microsoft Ignite 2017.

It looks like this. You get the email with the standard ATP attachment saying your email is being scanned. For this email you need to have Dynamic Delivery enabled for ATP, which means you need your mailbox in Office 365. If you are on-premises or not dynamic delivery then there is no preview function as you do not know that the email is on its way to you for you to preview.

Open the email whilst it is still an ATP Preview alert, and be quick at doing this, at ATP’s attachment scanning 99th percentile is under 3 minutes and the average scanning time for an ATP attachment is 1 minute. Inside the email you will see:

image

Click the preview link and the attachment opens in your browser, rendered by Office Online viewers (which do more than just Office documents)

image

Office 365 and ACDC

Posted on Leave a commentPosted in acdc, anycast, cafe, exchange online, Exchange Server, networking, Office 365

The best connectivity to Office 365 is achieved with local internet breakout and local DNS egress. This means things like each branch office should connect directly to the internet and not via the Head Office and then to the internet and that DNS lookups are done local as well. The reason for DNS lookups is to do with AnyCast and DNS resolution. Microsoft see where you make your DNS requests from and return responses to Office 365 that are near where the DNS egress point is. So if you lookup DNS from the head office in a different county, but still have local internet breakout, you might connect to the Office 365 endpoints close to the head office and not the endpoints in your country.

To test this, it used to be the case that you could ping outlook.office365.com and see what FQDN was returned and ensure that it was in the same geography to where you are. At the time of writing this is still the case some of the time, but it is changing.

Therefore, lets say you were located in Europe and you ran “ping outlook.office365.com” – it might return something in the URL that looked like EMEA-WEST. If it returned US anything then you had an issue with DNS and maybe internet egress. An example of how it always used to be was:

image

This was a great test until recently, but in the last few months this DNS lookup has changed to connect to an endpoint called ACDC. For example now it might show:

image

This is a connection to the ACDC endpoint, which is AnyCast DNS Cafe, where Cafe is the Client Access Front End service, or the Front Door service to Exchange Online. Not the data location, but a service endpoint close to you to do SSL connectivity and work out where your mailbox is and to connect to that endpoint. In the last year by changing to the ACDC endpoint technology, Microsoft have reduced latency to cloud hosted Exchange Online in the region of 100ms.

Unfortunately this means a simple test for local internet egress has stopped working and you need to investigate further the route taken to reach the Microsoft network. A suggestion simple test for this is tracert. For this you need to run “tracert outlook.office365.com”. This has the risk of being blocked at the firewall, as ICMP is often restricted even though it is used to help modulate TCP window size and other useful network packet adjustments, but an idea can be got from running tracert to the same location as the ping.

For example, ping outlook.office365.com for me was returning an RTT (round trip time) of 17ms. Tracert showed similar:

image

In my case I was getting the following:

Tracing route to outlook.ms-acdc.office.com [40.101.72.194]
over a maximum of 30 hops:

  1     1 ms    <1 ms     2 ms  192.168.0.1
   2     1 ms     2 ms     1 ms  192.168.5.1
   3     *        *        *     Request timed out.
   4     9 ms     9 ms     9 ms  oxfd-core-2a-xe-003-0.network.virginmedia.net [62.254.128.161]
   5     *        *        *     Request timed out.
   6     *        *        *     Request timed out.
   7    12 ms    11 ms    13 ms  tcma-ic-2-ae9-0.network.virginmedia.net [62.253.174.178]
   8    12 ms    12 ms    12 ms  213.104.85.230
   9    20 ms    20 ms    19 ms  be-71-0.ibr02.dbb.ntwk.msn.net [104.44.9.180]
  10    19 ms    18 ms    18 ms  104.44.10.150
  11     *        *        *     Request timed out.
  12     *        *        *     Request timed out.
  13     *        *        *     Request timed out.
  14     *        *        *     Request timed out.
  15    22 ms    17 ms    18 ms  40.101.72.194


Trace complete.

From this we can see 18ms to the first hop on Microsoft’s network. Full RTT and latency for Outlook can be found on the Connection Status dialog, as this includes the processor time in Exchange Server/Exchange Online and the network RTT to the server that contains the data and not just the Microsoft Front Door CAFE service.

Azure AD SSO and Disabled Computer Accounts

Posted on 5 CommentsPosted in Authentication, Azure Active Directory, Azure AD, Office, Office 365, SSO

When you set up Azure AD SSO, the Azure AD Connect application creates a computer account called AZUREADSSOACC. Do not disable this account, or SSO stops working.

I’ve had a few clients in the past week disable this when generally disabling all the computer accounts that have not logged in for X days.

Therefore if you have Azure AD SSO enabled, I suggest updating your documentation on disabling computer accounts – ‘cause not all computer accounts actually login as computers (I’m thinking Cluster services here as well) and consider actually whether or not disabling accounts for computers that are not logging in any more is necessary.

Then also take the AZUREADSSOACC account and set a description on it saying do not disable!

image

How To Run an Advanced Threat Protection Proof of Concept

Posted on Leave a commentPosted in Advanced Threat Protection, ATP, malware, Office, Office 365, Office 365 ProPlus, Proof Of Concept, Safe Attachments, Safe Links

I put the following post together as I was asked this question from Microsoft themselves! This post covers what you need to put in place, and how you can test some of it (as testing the blocking of malware involves sending malware first!)

First, lets take a look at the Advanced Threat Protection steps for a proof of concept (PoC), and then later we will look at the new Office Smart Links feature.

You need to put the following in place:

  • Exchange Online Protection managed tenant. That is MX to EOP is required for simple PoC
  • Hybrid with MX on-premises and then mail flow to cloud is possible for an advanced PoC, but here it depends upon what the customer has in-front of on-premises. If this is the case, then a simple PoC with a new email namespace and MX to EOP is recommended before transitioning to protecting their actual mailbox.
  • Create ATP rules in wizard in Exchange Control Panel for both Safe Attachments and Safe Links. PowerShell is pointless for this, as there is not a lot to do, and there are more steps if do it via PowerShell!
    • Enable ATP for a selected mailbox(es) and not an entire domain. Mailboxes can be cloud or on-premises.
    • Enable Smart Links for same mailboxes. Mailboxes can be cloud or on-premises.
    • Do not enable Smart Links for Office documents (as this is a global setting) (see later)
  • Check if org has rules to block .exe attachments. If they do then exe’s will be blocked by this rule and not processed by ATP.
  • Test. I have sent the .NET Framework installer .exe in email before to test this. But at any given day or time the rules could change as to what is blocked or not. I used to have a “fake macro virus” document (see below), but OneDrive’s built in AV started detecting it and now I do not have the file anymore! The doc I used to test with had an autorun macro that set a regkey that included the words “I download stuff and drop files” or something like that! It might be possible to create your own document, but watch out for AV software and the like blocking it and/or deleting it, or it being filtered out before it arrives at the target mailbox. I did say above this PoC is quite hard to do when trying to send malware for detection!
  • For SafeLinks, send an email from external that contains a URL with www.spamlink.contoso.com in it. The link will be rewritten. Some common links are never rewritten (I think www.google.com falls into this category) and you can whitelist URLs as well company wide. So if you whitelist a URL, send an email from the internet containing that link. That is a useful addition to the PoC as well.
  • ATP now quarantines (or at least its coming soon) the failed attachments, so include that on a demo. I have found that forwarding failed attachments to another mailbox (like a shared mailbox) is a bit temperamental – hasn’t for at least a year in one of my tenants but does in another tenant.
  • If users are on-premises (EOP before an on-premises mailbox) then do not enable dynamic delivery. If PoC mailboxes are both on-premises and cloud then create two ATP rule sets, one rule for each type of mailbox, and enable dynamic delivery for cloud mailboxes only.
    • Dynamic delivery sends the message without attachment to the cloud mailbox and later writes the attachment into the message body. This works in the cloud as Microsoft manage ATP and Mailbox. It cannot work on-premises as Office 365 cannot write the modified message into Exchange Server at a later time.
    • Dynamic delivers the body but not the attachment instantly. Attachment, if safe, follows later (7 or so minutes I tend to find). I understand an option to view the content of the attachment in a web browser but not the attachment is coming, but I have not seen that yet) – suspect the link to this will be inside the “pending attachment notification” in the dynamic email, but am guessing at this.
    • Do not dynamic deliver to on-premises mailboxes.
  • Demo that internal emails do not SafeLink rewrite and attachments are not processed. That is, send an email between two internal mailboxes and show that it is not processed.
  • In hybrid mode, if the connectors to the cloud are set up correctly then internal email from on-premises to cloud should not rewrite links. External emails are marked as such when they arrive on the first Exchange Server and so an external email to on-premises and then via the hybrid connectors to Exchange Online should be processed, as Exchange Online knows it is external!
  • Attachments are always scanned when sent between senders, even in hybrid mode (on-premises to cloud) or within two mailboxes the cloud.
  • Enable ATP for direct attachment links (i.e. link directly to an exe, pdf etc.). Then email and click that link. ATP with a yellow background will popup saying the file needs to be scanned. After a while (7 minute or so) click the link again and you will get to the file directly.
  • Safelink URLs are geo based. So EMEA tenant (or UK tenant) will get emea01.safelinks.protection.outlook.com rewritten URLs. UK tenants have EOP in EMEA, so the links for UK tenants are the same as EMEA tenants (at this time, not sure if this is changing).
  • Send emails that are both HTML based and Text based, and use the range of clients that the end customer users to see experiences. Rewriting text formatted emails appears different than html formatted emails.

SafeLinks for Office

  • Once you/client is happy enable SafeLinks for Office option. This is a global setting. Though this only works if you have Office Click-to-Run June 2017 Current Branch and later in use. For this create a new document that was never emailed:
    • On a Win10 AAD joined machine, save the file anywhere or just create a new Word doc and do not save it
    • On a Win10 not AAD or legacy Windows client then save the file to OneDrive for Business sync folders or SharePoint sync folders. It needs to be saved to these folders to know that it is a cloud document.
    • Get a demo machine that syncs to multiple tenants and later save a copy of the file OneDrive sync folders for the unprotected tenant. In this scenario you will see a protected document become unprotected (or visa versa) as you change the folder where it is saved to.
  • Once you have the file start creating content in it (typing “=Rand(20)” without quotes is a good way to do this in Word) and then start adding some links to the document. Use the above mentioned test link as well.
  • Click each link.
    • If it is safe, then the webpage will open
    • If it is not, then the alert page will open, or a dialog will popup saying its not safe (I have seen both behaviours)
  • Note that links are not rewritten (unlike in the email client, where you cannot be sure what client is in use, so the link needs rewriting). In Office documents the link is checked at time of click, and only if the document is saved to a cloud location (sync folders included)

On-Premises Public Folders, Exchange Online, And Multiple Forests

Posted on 4 CommentsPosted in exchange online, Exchange Server, Office 365, Public Folders

Here is a scenario I have come across in a few clients in just the last few weeks. This is not something that I recommend implementing lightly, as there are implications. But it does allow some very specific problems with public folder integration to be solved in the short term.

The specifics of the scenario is that with Exchange Online mailboxes and on-premises public folders, each user in Exchange Online needs a login account in the on-premises forest. That is easy for hybrid mode Exchange Server to Exchange Online, but once you move to multi-forest hybrid it is not. In multi-forest hybrid you will have users from more than one forest (of course).

When you set up integration between Exchange Online and an on-premises Exchange organization, you choose the single organization that you can proxy public folder requests to. This is done with Set-OrganizationConfiguration in Exchange Online and the value is the email address(es) of mailboxes that are located on the same servers as the public folder servers on premises – these are known as the public folder proxy mailboxes. For example this would look like Set-OrganizationConfiguration -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes pfProxy1. Once this is done, all Exchange Online users get allocated one of these email addresses as their public folder proxy address. When the user uses Outlook, the AutoDiscover response for their mailbox will include a publicFolder value that contains this email address given to the users mailbox. For example, it would look like this:

      <PublicFolderInformation>

<SmtpAddress>pfProxy1@domain.com</SmtpAddress>

</PublicFolderInformation>

Outlook will then do AutoDiscover for that mailbox (in the same way that it does AutoDiscover for shared mailboxes) and attempt to login to the public folders (Outlook 2010) or show “Public Folders” in the Outlook tree folder view and wait until the user expands to attempt to connect (Outlook 2013 and later). If the user has an account on-premises then the Public Folder hierarchy is shown and the user can open folders for which he or she has permission.

But, if the user belongs to another forest, they do not have an account in the forest that the public folders are in and so login to the public folder hierarchy fails.

image

So how do we solve this. There is one way I have tested, and another way I have yet to test. The first way turns off the public folders for the users in all the non-primary forest for public folders. They cannot access public folders at all, unless you implement a third party folder migration software and even these might not work. The steps to implement this “fix” is to begin to implement public folder migration, but actually to stop very early in the process and jump to near the end of that process. So first create a new public folder in Exchange Online. As you are using public folder proxies, you can only create public folders that are held for migration, and that is the key to this idea. So New-Mailbox pfMailbox1 -PublicFolder -HoldForMigration will create a new empty (and that is important) public folder mailbox in Exchange Online. Now near the end of published process for public folder migration there is a step where you can individually set cloud mailboxes to use the cloud public folders. You do this with Set-Mailbox name -DefaultPublicFolderMailbox pfMailbox1 and this user will now only look at the empty cloud public folders and not attempt to connect on-premises. Therefore if you do this for all mailboxes from the non-primary forest for public folders then they will stop failing to login on-premises. Sure, they loose public folder access to their original folders as well, but that was the risk that that you would have been discussing with your consultant before you started migrating.

Note that it has come to my attention that the email address of this proxy mailbox must not be the tenant.onmicrosoft.com address or tenant.mail.onmicrosoft.com, as AutoDiscover for that namespace intentionally blocks requests or is non-resolvable to its namespace as part of Exchange Online hybrid. Therefore the email address used must be a domain that resolves AutoDiscover quickly, as Outlook will query AutoDiscover for this proxy mailbox on every folder action (move folder) or where you scroll down the folder using the scroll bars.

My second, untested option, is to instead run the Set-OrganizationConfiguration option but to use proxy mailboxes from multiple forests that have previously created and synced. And rather than allowing Exchange Online to randomly distribute the proxy mailboxes across all the users, you would provision the user with the correct proxy mailbox for the organization they are in. Assume therefore that Forest1 has pfForest1Proxy and Forest2 has pfForest2Proxy1. You would run Set-OrganizationConfiguration -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes pfForest1Proxy,pfForest2Proxy and then individually ensure that Set-Mailbox <each user in Forest1> -DefaultPublicFolderMailbox pfForest1Proxy and that Set-Mailbox <each user in Forest2> -DefaultPublicFolderMailbox pfForest2Proxy. Note that this is not tested. Please let me know if this works for you in the comments if I don’t get to test it first!