android Apple ATP Defender email EOP exchange exchange online Exchange Online Protection EXO iOS iPhone Office 365 Advanced Threat Protection phish phishing spam

Exchange Online Warning On Receipt Of New Email Sender

Released recently to no fanfare at all, Microsoft now has a SafetyTip that appears if you receive email from a first time recipient.

Most often phish emails will come from an address you have never received email from before, and sometimes this email will try to impersonate people you communicate with or are internal to your organization. Warning for attempted spoofed domains or users is part of Microsoft Defender for Office 365 (previously known as Advanced Threat Protection for Office 365) and the functionality to warn based on similar sender is also part of this product if you enable the “mailbox intelligence” option. But the option to warning for a new sender is available for all Exchange Online users without ATP licences.

The user sees the SafetyTip above the email body as shown below once this new feature is enabled:

New Sender Safety Tip

To turn on this option you enable a custom message header in a transport rule and then within 30 minutes or so, every new sender under the scope of the rule is warned when they receive email from a new sender. This also includes senders that have not send a lot of message to you, as I see that this Safety Tip appear on subsequent messages from the same sender. Not sure yet when this stops appearing for slightly less new senders!

To enable this feature create the following transport rule, restricting the scope of the rule to some users only to start with and then when happy with the functionality changing the rule to apply to all users.

First Contact Safety Tip Transport Rule

Open Exchange Online Control Panel (at the time of writing this is in the old UX for this, so these screenshots represent the classic view – this will change at some point in the future) and select Mail Flow > Rules

Click the + icon > Modify Messages and fill in the name “Enable First Contact Safety Tip”

Select under Apply this rule if… The sender is located > Outside the organization

Select under Do the following… Set the message header to this value and click the first option for Enter text and copy and paste the following string X-MS-Exchange-EnableFirstContactSafetyTip

Click the second option for Enter text and enter any value you like. I have had reports that only “enable” works but that is not my experience and I had this working with the value AnythingYouLike!

I turn off the audit option and then save the rule as shown:

New Transport Rule for First Contact Safety Tip

To set the rule for a pilot program, click More options and then the newly displayed add condition button and then select that the rule should only apply if the recipient is and select a few names from your global address list.

Pilot Program for First Contact Safety Tip

Within 30 minutes and then the next new sender and Outlook, Outlook Web Access and Outlook Mobile will display the new safety tip

android Apple AutoPilot Deployment Endpoint Manager Graph Intune iOS

What Is The Value of enrollmentProfileName

In Microsoft EndPoint Manager there are a few different device registration scenarios that make use of a property called device.enrollmentProfileName. To find and apply other settings (apps, config, etc) to these devices later on you need to have a Dynamic Device Group based on this property. The problem is the value of the property is not available to view in PowerShell or the Endpoint Manager portal.

This value is used by AutoPilot, Apple Business Manager devices (aka DEP) and Android Fully Managed device profiles.

So how can I see what a devices value is so I can create a group to contain that device. I need to use the Graph Explorer.

In the Graph Explorer, using the Beta endpoint, I can get data for my device using the query{objectId}

This gets BETA endpoint graph data, which includes enrollmentProfileName. The version 1.0 endpoint does not return enrollmentProfileName in the response.

If you have never used the Graph Explorer before, here are the steps to get this info:

Open the Graph Explorer from

Click Sign In button to the left, and once signed in, select Beta (highlighted) and paste in the query replacing /me with /devices/{objectID}

Graph Explorer to look for a device properties (beta endpoint)

You may not have permissions (consent) to view the data you need, so you might need to click on Modify Permissions tab (also highlighted above) to request and approve consent to access the data. This consent may need administrator approval depending upon your security settings in Azure AD.

Click Run Query button and view the results in the Response Preview section below:

Response to a Device query in the Graph

The value of enrollmentProfileName will be the profile the device was enrolled under, at the time of enrollment. Its possible that the profile was renamed or deleted since the device was enrolled, or that you have many profiles, and so actually working out which profile the device is under can be tricky.

Also a top tip – don’t name your profiles all starting with “Test”. In the tenant where the above screenshots where taken from we found DEP profiles called “Test…” and AutoPilot profiles called “Test…”, so creating dynamic device groups where the device.enrollmentProfileName -contains “Test” was returning too many devices!

activesync android email exchange exchange online Exchange Server iPad iPhone

Too Many Folders To Successfully Migrate To Exchange Online

Exchange Online has a limit of 10,000 folders within a mailbox. If you try and migrate a mailbox with more than this number of folders then it will fail – and that would be expected. But what happens if you have a mailbox with less than this number of folders and it still fails for this same reason? This is the problem, with resolution, I outline below.

I was moving some mailboxes to Exchange Online when I came across the following error in the migration batch results:

Data migrated: 18.18 MB ‎(19,060,890 bytes)‎
Migration rate: 0 B ‎(0 bytes)‎
Error: MigrationMRSPermanentException: Error: Could not create folder 2288. –> MapiExceptionFolderHierarchyChildrenCountQuotaExceeded: Unable to create folder. ‎(hr=0x80004005, ec=1253)‎ Diagnostic context: Lid: 55847 EMSMDBPOOL.EcPoolSessionDoRpc called [length=204] Lid: 43559 EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=468][latency=1] Lid: 52176 ClientVersion: 15.20.1730.17 Lid: 50032 ServerVersion: 15.20.1730.6019 Lid: 35180 Lid: 23226 — ROP Parse Start — Lid: 27962 ROP: ropCreateFolder [28] Lid: 17082 ROP Error: 0x4E5 Lid: 25953 Lid: 21921 StoreEc: 0x4E5 Lid: 27962 ROP: ropExtendedError [250] Lid: 1494 —- Remote Context Beg —- Lid: 38698 Lid: 29818 dwParam: 0x0 Msg: f28f1e21-62aa-4999-977f-ce310efea309-61f0997f-74d5-4421-9050-64f8272e5ac2[9]-28A06 Lid: 29920 dwParam: 0xB Lid: 29828 qdwParam: 0x2711 Lid: 29832 qdwParam: 0x2710 Lid: 45884 StoreEc: 0x4E5 Lid: 29876 StoreEc: 0x4E5 Lid: 30344 StoreEc: 0x4E5 Lid: 54080 StoreEc: 0x4E5 Lid: 56384 StoreEc: 0x4E5 Lid: 38201 StoreEc: 0x4E5 Lid: 35904 Lid: 45434 Guid: f12f3e45-67aa-89012-345f-ce678efea901 Lid: 10786 dwParam: 0x0 Msg: 15.20.1730.017:VI1PR0502MB2975:145a3769-3902-4e6b-9fe4-6db564e4eb92 Lid: 1750 —- Remote Context End —- Lid: 31418 — ROP Parse Done — Lid: 22417 Lid: 30609 StoreEc: 0x4E5 Lid: 29073 Lid: 20369 StoreEc: 0x4E5 Lid: 64464 Lid: 64624 StoreEc: 0x4E5

In the above I have highlighted some of the errors I was seeing – with the “could not create folder” message, the first indicator is that I have too many folders to migrate or I have a corrupt mailbox. Running Get-MoveRequestStatistics and including a full report (with -IncludeReport) shows in part the below. This was run to get more info on the move request. This was run from Exchange Online:

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​26/03/2019 17:10:09 [VI1PR0502MB3855] ‘MigrationService (on behalf of ‘’)’ created move request.
26/03/2019 17:10:15 [DB8PR05MB6025] The Microsoft Exchange Mailbox Replication service ‘’ (15.20.1730.17 ServerCaps:01FFFFFF, ProxyCaps:07FFFFC7FD6DFDBF5FFFFFCB07EFFF, MailboxCaps:, legacyCaps:01FFFFFF) is examining the request.
26/03/2019 17:10:15 [DB8PR05MB6025] Content from the Shard mailbox (Mailbox Guid: f12f3e45-67aa-89012-345f-ce678efea901, Database: cc980daf-4402-4645-b26c-2a83760b161c) will be merged into the target mailbox.
26/03/2019 17:10:15 [DB8PR05MB6025] Connected to target mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’, database ‘EURPR05DG090-db014’, Mailbox server ‘’ Version 15.20 (Build 1730.0).
26/03/2019 17:10:20 [DB8PR05MB6025] Connected to source mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’, database ‘DB’, Mailbox server ‘’ Version 15.0 (Build 847.0), proxy server ‘’ 15.0.847.40 ServerCaps:, ProxyCaps:, MailboxCaps:, legacyCaps:1FFFCB07FFFF.
26/03/2019 17:10:21 [DB8PR05MB6025] Request processing started.
26/03/2019 17:10:21 [DB8PR05MB6025] Source mailbox information:
Regular Items: 8443, 905.4 MB (949,422,345 bytes)
Regular Deleted Items: 1149, 189.9 MB (199,115,692 bytes)
FAI Items: 4651, 11.72 MB (12,285,701 bytes)
FAI Deleted Items: 9, 19.26 KB (19,721 bytes)
26/03/2019 17:10:21 [DB8PR05MB6025] Cleared sync state for request 2c065e32-3bd5-4524-9aac-03880fa8e961 due to ‘CleanupOrphanedMailbox’.
26/03/2019 17:10:21 [DB8PR05MB6025] Mailbox signature will not be preserved for mailbox ‘\f12f3e45-67aa-89012-345f-ce678efea901 (Primary)’. Outlook clients will need to restart to access the moved mailbox.
26/03/2019 17:11:20 [DB8PR05MB6025] Stage: CreatingFolderHierarchy. Percent complete: 10.
26/03/2019 17:12:38 [DB8PR05MB6025] Initializing folder hierarchy from mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’: 29048 folders total.
26/03/2019 17:21:21 [DB8PR05MB6025] Folder creation progress: 1102 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 17:31:22 [DB8PR05MB6025] Folder creation progress: 2730 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 17:41:22 [DB8PR05MB6025] Folder creation progress: 4535 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 17:51:23 [DB8PR05MB6025] Folder creation progress: 6257 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 18:01:23 [DB8PR05MB6025] Folder creation progress: 7919 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 18:11:23 [DB8PR05MB6025] Folder creation progress: 9570 folders created in mailbox ‘\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 18:14:15 [DB8PR05MB6025] Fatal error StoragePermanentException has occurred

The move request logs show an increasing folder count, and when this exceeds 10,000 a storage error occurs.

So the next thing to do is to check what I have on-premises. I have generally two options to try and fix a mailbox I am moving to Exchange Online. One is to move the mailbox elsewhere on-premises (on the basis that I discard errors on-premises and then move a cleaner mailbox to the cloud) or run repairs on the mailbox. Note that running repairs on-premises is part of the move to the cloud anyway as Exchange Server does this as part of the move.

But this revealed nothing! The move request logs on-premises showed the same – there was over 10,000 folders (indeed some of my mailboxes had over 20,000 folders) and this was enumerated in the move request logs. A New-MailboxRepairRequest did nothing either. But interestingly, Get-MailboxFolderStatistics | Measure showed only 200 folders! Each of my failing mailboxes had between 150 and 263 folders – nothing like the +10,000 that the move request was finding!

So I opened the mailbox in Outlook having granted myself permissions to it – again nothing.

So I opened MFCMapi and had a look at the folders. Now MFCMapi shows everything in the mailbox, and not just items under the “top of the information store” folder. I went about expanding each subfolder I could find and I came across a subfolder that everytime i expanded it, MFCMapi would hang. I would close and restart MFCMapi and the same thing!


I had found my suspect folder – its a iPhone device that had created the +10,000 folders. Now that I had a good candidate for my issue, the fix was easy. I listed the active-sync devices using Get-MobileDevice -Mailbox “Richard Redmond” | FL Identity and then removed the suspect device using Remove-ActiveSyncDevice “ Redmond/ExchangeActiveSyncDevices/iPhone§A9BCDE7FG57HIJ81KL1M08NOPQ” -Confirm:$false where the device identity was returned in the Get-MobileDevice cmdlet run just before.

This Remove-ActiveSyncDevice (or Remove-MobileDevice) cleans up this mailbox and deletes the partnership with the device.

Once this was done, I moved the mailbox again and it was ~200 folders and moved to Exchange Online without further issue.

Where I tested the move to Exchange Server rather than Exchange Online, I found that looking in the move request report (I had prestaged the move and then removed the corrupt mobile device), the move report showed information like the following and all I had done was removed one mobile device from the mailbox!

26/03/2019 17:41:22 [servername] Folder hierarchy changes reported in source ‘Primary (a8c13a2f-535b-d996-908e-ff84b1484a7)’: 200 changed folders, 24080 deleted folders.

From the users perspective, if the phone is an active device and is syncing email, then removing the phone causes it to create a new partnership. If the server allows any device then this is seamless to the user. If the server requires authorization to add a new device, then the user will be told this and service desk/admin will need to approve the device again. So if Allow/Block/Quarantine (ABQ) is not enabled on the server, one wonders if deleting all active sync partnerships before migrating any mailbox is an idea worth considering – there could be mailboxes I have moved that are <10,000 folders but not far from that number and therefore storing up issues for the future!