DMARC Quarantine Issues

Posted on Leave a commentPosted in dkim, dmarc, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, spf, spoof

I saw the following error with a client the other day when sending emails from the client to any of the Virgin Media owned consumer ISP email addresses (,, etc.) gave this error:
vLkg1v00o2hp5bc01Lkg9w DMARC validation failed with result 3.00:quarantine

In the above, the server name (… might change as will the value before the error, but either DMARC validation failed with result 3.00:quarantine or 4.00:reject is the end of the error message.

We resolved this error by shorting the DMARC record of the sending organization. Before we made the change we had a DMARC record of 204 characters. We cannot find a reference online to the maximum length of a DMARC record, though we could successfully add a record of this length to Route 53 DNS provided by AWS, though a record of 277 characters was not allowed in AWS. Other references online to domain character length seem to imply that 255 characters is the max, but not specifically for DMARC.

So, shortening the DMARC record to remove two of the three email addresses in each of the RUA and RUF values was the fix that we needed. This change was done for two reasons, first the above error occurred only with emails to Virgin Media and sometimes an NDR would be received and other times the NDR would fail, but the original email never made it through and secondly the two removed email addresses where not actively being checked for DMARC status messages anyway and so there is no harm in the removal of them from the DMARC record anyway!

The original DMARC record we had this issue with looked like this (xxx.xxxxx representing the client domain):

v=DMARC1; p=quarantine; fo=1;rua=mailto:admin@xxx.xxxxx,,mailto:dmarc@xxx.xxxxx;ruf=mailto:admin@xxx.xxxxx,,mailto:dmarc@xxx.xxxxx;

Then we changed the record to the following to resolve it:

v=DMARC1; p=quarantine; fo=1;;;

Reducing the length of the record resulted in DMARC analytics and forensic email not going to mailboxes at the client (one of whom those mailboxes did not exist anyway) and only going to the UK government DMARC policy checking service, but most importantly for a client that has a requirement to respond to citizen’s emails (and whom could easily be using Virgin Media email addresses) we resolved the issue.

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 in it. The link will be rewritten. Some common links are never rewritten (I think 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, if the connectors to the cloud are set up correctly then internal email from on-premises to cloud should not rewrite links or process attachments. 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 processes, as Exchange Online knows it is external!
  • 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 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 1 CommentPosted 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:




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.


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.

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!

Forcing Transport Level Secure Email With Exchange Online

Posted on Leave a commentPosted in EOP, exchange online, Exchange Online Protection, Exchange Server, Office 365, security, starttls, TLS

In Exchange Online there are a few different options for forcing email to require an encrypted connection. These depend upon the level of licence you have, and some of them are user based (Office 365 Message Encryption for example), but there are two ways to force TLS (transport layer security) for the email between when the message leaves Office 365 and arrives with the recipient email system.

The first of these is a Mail Flow rule, and the second of these is a Conditional Connector. Only the second of these works!

The first, just for clarity, appears to work but it is not 100% reliable and will end up with stuck emails unless you configure the rule 100% correct. The second option is the recommended option ongoing.

For completion, we will also look at forcing TLS inbound to Exchange Online

Force TLS with Mail Flow Rules

This option relies on a Transport Rule (or mail flow rule) setting called “Require TLS”. This below example shows a UK Government requirement that states that emails to certain government departments (by domain name) should enforce the use of TLS:


This rule uses the condition “if the recipient address includes” and the list of UK Government domains that should be secured. This list is found at and for test purposes I have added my own domains to the list. The action for this rule is “to require TLS encryption”.

As mentioned above, this rule is not 100% reliable, and the the issue is when you have a Hybrid Exchange Online environment back to on-premises Exchange, though that connector back to on-premises uses TLS, the rule to force TLS conflicts and the email stays in Exchange Online in a pending state and is never delivered.
To avoid this issue, an exception is required to the rule to exempt it for your on-premises domains.

Force TLS with Conditional Connectors

This is the recommended route for forcing TLS. It requires two settings created. The first is a Conditional Connector as shown:


You must select “Only when I have a transport rule set up that redirects messages to this connector” on the connector use page.


MX delivery is the most likely option, and then either any digital certificate or issued by a trusted third party depending upon your requirements.


If you have more than one domain to force TLS to, then do not enter the end certificate info here, as it will be different for each domain.

Now that you have the connector in place, which will only be used is rules route the emails to that connector, you can create the rule.


We have purposely excluded the domains we had an issue with when using “Require TLS”, but Microsoft say that workaround should not be needed – I will update this post once I know that for sure! Also, as the rule shown in the screenshots adds a disclaimer so that we can check that the rule is being executed.

Inbound Required TLS with Connectors

To force inbound TLS requirements, so that email from given domains are rejected if they do not open a TLS session with your organization to send an email you create a Partner to Office 365 connector. This connector will force TLS or reject the email inbound if that cannot happen:




And then choosing “Reject email messages if they aren’t sent over TLS” as part of the connector conditions:



XOORG, Edge and Exchange 2010 Hybrid

Posted on Leave a commentPosted in 2010, Edge, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, Office 365

So you have found yourself in the position of moving to Exchange Online from a legacy version of Exchange Server, namely Exchange 2010. You are planning to move everyone, or mostly everyone to Exchange Online and directory synchronization plays a major part (can it play a minor part?) in your plans. So you have made the option to go hybrid mode when you discover that there are manual steps to making Exchange 2010 mail flow to Exchange Online work if you have Exchange Edge Servers in use.

So, what do you do. You look online and find a number of references to setting up XOORG, but nothing about what that is and nothing about what you really need to do. And this you found this article!

So, how do you configure Exchange Server 2010 with Edge Servers, so that you can have hybrid mode to Exchange Online.

Why You Need These Steps

So you ran the hybrid wizard, and it completed (eventually if you have a large number of users) and you start your testing only to find that emails never arrive in Office 365 whilst your MX record is still pointing on-premises. After a while you start to get NDR’s for your test emails saying “#554 5.4.6 Hop count exceeded – possible mail loop” and when you look at the diagnostic information for administrators at the bottom of the NDR you see that your email goes between the hub transport servers and the edge servers and back to the hub transport servers etc. and about three or so hours after sending it, with the various timeouts involved, the email NDR arrives and the message is not sent.

The problem is that the Edge Server sees the recipient as internal, and not in the cloud, as the email has been forwarded to the, and Exchange 2010 is authoritative for this namespace. You are missing a configuration that tells the Edge that some emails with certain properties are not internal, but really external and others (those coming back from the cloud) are the only ones to send internal to the on-premises servers.

So what do you do?


Before you run the hybrid wizard you need to do the following. If you have already run the wizard that is fine, you will do these steps and run it again.

  1. Install a digital certificate on all your Edge Servers that is issued by a trusted third party (i.e. GoDaddy, Digicert and others). The private key for this certificate needs to be on each server as well, but you do not need to allow the key to be exported again.
  2. Enable the certificate for SMTP, but ensure you do not set it as the default certificate. You do this by using Exchange Management Shell to Get-ExchangeCertificate to key the key’s thumbprint value and then running Enable-ExchangeCertificate –Thumbrint <thumbprintvalue> –Services SMTP. At this point you are prompted if you want to set this certificate as the default certificate. The answer is always No!
  3. If you answer yes, then run the Enable-ExchangeCertificate cmdlet again, but this time for the certificate thumbprint that was the default and set the default back again. If you change the default you will break EdgeSync and internal mail flow for everyone. And you must use the self-signed certificate for EdgeSync and this third party issued certificate for cloud mail flow, as you cannot use the same certificate for both internal and external traffic.
  4. The certificate needs to be the same across all your Edge Servers.
  5. If you are doing multi-forest hybrid, then the certificate is only the same across all the Edge Servers in one Exchange Organization. The next organization in your multi-forest hybrid needs to use a different certificate for all its Edge Servers.
  6. Then take this same certificate and install it on a single Hub Transport server on-premises. The hybrid wizard cannot see what certificates you have on the Edge Servers, so you need to help the wizard along a bit. Again, this certificate needs enabling for SMTP, but not setting as the default certificate.

Running The Hybrid Wizard

Now you can run the hybrid wizard. The important answers you need to include here are that the hub transport server that you pick must be the one that you placed the certificate on, as you cannot pick the Edge Servers that you will use for mail flow in the wizard. But you will need to enter the IP addresses that your Edge Servers are published on the internet as, and you will need to enter the FQDN of the Edge Servers as well.

Complete the wizard and then time for some manual changes.

Manual Changes

The hybrid wizard will have made a send connector on-premises called “Outbound to Office 365”. You need to change this connector to use the Edge Servers as the source servers. Note that if you run the hybrid wizard again, you might need to reset this value back to the Edge Servers. So once all these required changes are made, remember that running the wizard again could constitute an unexpected change and so should be run with care or out of hours.

Use Set-SendConnector “Outbound to Office 365” -SourceTransportServers <EDGE1>,<EDGE2> and this will cause the send connector settings to replicate to the Edge Server.

Next get a copy of the FQDN value from the receive connector that the hybrid wizard created on the hub transport server. This receive connector will be called “Inbound from Office 365” and will be tied to the public IP ranged of Exchange Online Protection. As your Edge Servers receive the inbound emails from EOP, this receive connector will serve no purposes apart from the fact that its settings are the template for your receive connector on the Edge Servers that the wizard cannot modify. The same receive connector will also have a setting called TlsDomainCapabilities and the value of this setting will be AcceptOorgProtocol is the XOORG value that you see referenced on the internet, but it is really called AcceptOorgProtocol and this is the value that allows the Edge Server to distinguish between inbound and outbound mail for your Office 365 tenant.

So on each Edge Server run the following cmdlet in Exchange Management Shell to modify the default receive connector: Set-ReceiveConnector *def* -TlsDomainCapabilities -Fqdn <fqdnFromTheInboundReceiveConnectorOnTheHubTransportServer>.

This needs repeating on each Edge Server. The FQDN value ensures that the correct certificate is selected and the TlsDomainCapabilities setting ensures you do not loop email to Office 365 back on-premises again. Other emails using the Default Receive Connector are not affected by this change, apart from now being able to offer the public certificate as well to their inbound partners.

You can now continue with your testing knowing that mail flow is working, so now onto AutoDiscover, clients, free/busy, public folders etc. etc. etc.

Cloud Admins, AADConnect and Privilege Increase Issues

Posted on Leave a commentPosted in AADConnect, AADSync, AdminSDHolder, Office 365, server administrator

Microsoft recommends that you stay on top of version updates to AADConnect.

In version 1.1.553.0, which became available in June 2017, there is a reference to a gain in admin privileges that could be possible with password writeback (part of Azure AD Premium and EMS licences) that hints at a security issue. The following is what I think the issue is, and therefore why you should be running 1.1.553.0 or later.

Global admins can change the password of AD admins using Azure Portal. This is an issue if you consider the following scenario – if the GA was just a delegated admin to an OU or not an admin to AD at all (i.e. cloud only admin) they would not be able to reset privileged accounts in AD, but with password writeback prior to v 1.1.553.0 they are able to do this and gain an on-premise privilege they did not have.

Or, of course, malicious actor takes over GA account and now have access to all on-premises admin accounts.

Following version 1.1.553.0 and later, only the owner of a privileged account can change it via password writeback.

So, if you have cloud admins that are not on-premises admins, or are just delegated admins on-premises, upgrade to 1.1.553.0 now.

This issue only affects customers who have enabled the Password writeback feature on Azure AD Connect. To determine if the feature is enabled:

  1. Login to your Azure AD Connect server.
  2. Start Azure AD Connect wizard (START → Azure AD Connect).
  3. On the Welcome screen, click Configure.
  4. On the Tasks screen, select View current configuration and click Next.
  5. Under Synchronization Settings, check if Password Writeback is enabled.


For information on how to upgrade Azure AD Connect, refer to Azure AD Connect: Learn how to upgrade from a previous version to the latest.

The latest version of Azure AD Connect addresses this issue by blocking Password writeback request for on-premises AD privileged accounts unless the requesting Azure AD Administrator is the owner of the on-premises AD account. More specifically, when Azure AD Connect receives a Password writeback request from Azure AD:

  • It checks if the target on-premises AD account is a privileged account by validating the AD adminCount attribute. If the value is null or 0, Azure AD Connect concludes this is not a privileged account and permits the Password writeback request.
  • If the value is not null or 0, Azure AD Connect concludes this is a privileged account. Next, it then validates whether the requesting user is the owner of the target on-premises AD account. It does so by checking the relationship between the target on-premises AD account and the Azure AD account of the requesting user in its Metaverse. If the requesting user is indeed the owner, Azure AD Connect permits the Password writeback request. Otherwise, the request is rejected.

Malware Filter Policy Updates in Office 365

Posted on 3 CommentsPosted in EOP, exchange online, Exchange Online Protection, malware, Office 365

In March I wrote a blog post that showed how to take the attachment filter list from Edge Server and add those attachment block types to EOP, as EOP had a very small list of attachments.

Today on one of my client tenants I noticed this precanned list of attachment extension types is now at 96 items, which is a considerable change from the list back in March 2017. The list in March was ace, ani, app, docm, exe, jar, reg, scr, vbe, vbs and still is for some tenants at the time of writing.

But while Microsoft has added new attachment types to the picker UI, there was no notification to the end client administrators that they might want to update their MalwareFilterPolicy to take account of these new attachment types that Microsoft have considered worthy of being blocked.

Therefore, now is the time to check your existing MalwareFilterPolicy to include the new extension types (listed below).

For reference, the new attachment filter types that have been added since March 2017 are


But notice that some of these are initial capital versions of entries that are already there (i.e. hta was in the list or on Edge server a few months ago, but now Hta is on the list as well).

I am assuming attachment blocking is not case sensitive and so the following extensions are if added from the attachment list picker will be duplicates – Hta, Inf, Ins, Jse, Ksh if you imported a matching, but lower case, list from your Edge servers.

OWA and Conditional Access: Inconsistent Error Reports

Posted on 1 CommentPosted in AzureAD, conditional access, EM+S, enterprise mobility + security, exchange, exchange online, Exchange Online Protection, IAmMEC, Outlook

Here is a good error message. Its good, because I could not find any references to it on Google and the fault was nothing to do with the error message:


The error says “something went wrong” and “Ref A: a long string of Hex Ref B: AMSEDGE0319 Ref C: Date Time”. The server name in Ref B will change as well. It also says “more details” and if you click that there are no more details, but that text changes to “fewer details”. As far as I have seen, this only appears on Outlook Web Access (OWA).

The error appears under these conditions:

  1. You are enabled for Enterprise Mobility + Security licences in Azure AD
  2. Conditional Access rules are enabled
  3. The device you are on, or the location you are at etc (see the specifics of the conditional access rule) mean that you are outside the conditions allowed to access Outlook Web Access
  4. You browsed directly to or

What you see in the error message is OWA’s way of telling you that you cannot get to that site from where you are. That you have failed the conditional access tests.

On the other hand, if you visit the Office 365 portal or MyApps ( or and click the Mail icon in your Office 365 menu or on the portal homepage then you get a page that says (in the language of your browser):

image or in Welsh, image

This says “you can’t get there from here” and the reasons why you have failed conditional access.

If you were on a device or location that allowed you to connect (such as a device managed by Intune and compliant with Intune rules) then going to OWA directly will work, as will going via the menu.

So how can you avoid this odd error message for your users. For this, you need to replace with your own custom URL. For OWA you can create a DNS CNAME in your domain for (lets say) webmail that points to (for this it will not work if you point the CNAME to Your users can now go to This will redirect the user via Azure AD for login and token generation, and as you are redirected via Azure AD you will always see the proper, language relevant, conditional access page.

Administrators, AADConnect and AdminSDHolder Issues (or why are some accounts having permission-issue)

Posted on 1 CommentPosted in AADConnect, AADSync, active directory, AdminSDHolder, dirsync, exchange, exchange online, hybrid, Office 365

AdminSDHolder is something I come across a lot, but find a lot of admins are unaware of it. In brief it is any user that is a member of a protected group (i.e. Domain Admins) will find that their AD permission inheritance and access control lists on their AD object will be reset every hour. Michael B. Smith did a nice write-up on this subject here.

AdminSDHolder is an AD object that determines what the permissions for all protected group members need to be. Why this matters with AADConnect and your sync to Azure Active Directory (i.e. the directory used by Office 365) is that any object that the AADConnect service cannot read cannot be synced, and any object that the AADConnect service cannot write to can be targeted by writeback permissions. This blog post was last updated 18th June 2017 in advance of the release of AADConnect version 1.1.553.0.

For the read permissions this is less of an issue, as the default read permissions by every object is part of a standard Active Directory deployment and so you will find that AdminSDHolder contains this permission and therefore protected objects can be read by AADConnect. This happens in reality becase Authenticated Users have read permissions to lots of attributes on the AdminSDHolder object under the hidden System containing in the domain. Unless your AD permissions are very locked down or AdminSDHolder permissions have been changed to remove Authenticated Users you should have no issue in syncing admin accounts, who of course might have dependencies on mailboxes and SharePoint sites etc. and so need to be synced to the cloud.

Writeback though is a different ball game. Unless you have done AADConnect with Express settings you will find that protected accounts fail during the last stage of AADConnect sync process. You often see errors in the Export profile for your Active Directory that list your admin accounts. Ofter the easiest way to fix this is to enable the Inheritance permission check box on the user account and sync again. The changes are now successfully written but within the hour this inheritance checkbox will be removed and the default permissions as set on AdminSDHolder reapplied to these user accounts. Later changes that need written back from the cloud will result in a failure to writeback again, and again permission issues will be to blame.

To fix this we just need to ensure that the AdminSDHolder object has the correct permissions needed. This is nothing more than doing what the AADConnect Express wizard will do for you anyway, but if you don’t do the Express wizard I don’t think I have seen what you should do documented anywhere – so this is the first (maybe).

Often if you don’t run Express settings you are interested in the principal of least privilege and so the rest of this blog post will outline what you will see in your Active Directory and what to do to ensure protected accounts will always sync and writeback in the Azure Active Directory sync engine. I covered the permissions to enable various types of writeback permissions in a different blog post, but the scripts in this post never added the correct write permissions to AdminSDHolder, so this post will cover what to do for your protected accounts.

First, take a look at any protected account (i.e. one that is a member of Domain Admins):

You will see in the Advanced permissions dialog that their is an “Enable Inheritance” button (or a check box is unchecked in older versions of Active Directory. You will also notice that all the permissions under the “Inherited From” column read “None” – that is there are no permissions inherited. You will also see, as shown in the above dialog, that if Express settings have been run for your AADConnect sync service that a access control entry for the AADConnect service account will be listed – here this is MSOL_924f68d9ff1f (yours will be different if it exists) and has read/write for everything. This is not least privilege! If you have run the sync engine previously on different servers and later removed them (as the sync engine can only run on one server to one AAD tenant, excluding staging servers) then you might see more than one MSOL account. The description field of the account will show what server it was created on for your information.

If you compare your above admin account to a non-protected account you will see inheritance can be disabled and that the Inherited From column lists the source of the permission inheritance.

Compare the access control entries (ACE) to the list of ACE’s on the AdminSDHolder object. AdminSDHolder can be found at CN=AdminSDHolder,CN=System,DC=domain,DC=local. You should find that the protected accounts match those of the AdminSDHolder, or at least will within the hour as someone could have just changed something.

Add a permission ACE to AdminSDHolder and it will appear on each protected account within an hour, remove an ACE and it will go within the hour as well. So you could for example remove the MSOL_ account(s) from older ADSync deployments and tidy up your permissions as well.

This is what my Advanced permissions for AdminSDHolder looks like on my domain


If I add the relevant ACE’s here for the writeback permissions then within the hour, and then for syncs that happen after that time, the errors for writeback in the sync management console will go away. Note though that AdminSDHolder is per domain, so if you are syncing more than one domain you need to set these permissions on each domain.

To script these permissions, run the following in PowerShell to update AD permissions regarding to the different hybrid writebacks scenarios that you are interested in implementing.

Finding All Your AdminSDHolder Affected Users

The following PowerShell will let you know all the users in your domain who have an AdminCount set to 1 (>0 in reality), which means they are impacted by AdminSDHolder restrictions. The changes below directly on the AdminSDHolder will impact these users as their permissions will get updated to allow writeback from Azure AD.

get-aduser -Filter {admincount -gt 0} -Properties adminCount -ResultSetSize $null | FT DistinguishedName,Enabled,SamAccountName

SourceAnchor Writeback

This setting is needed for all installations since version 1.1.553.0.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number or MSOL_number].
$AdminSDHolder = "CN=AdminSDHolder,CN=System,DC=contoso,DC=com"

$cmd = "dsacls.exe '$AdminSDHolder' /G '`"$accountName`":WP;ms-ds-consistencyGuid'"
Invoke-Expression $cmd | Out-Null

Password Writeback

The following PowerShell will modify the permissions on the AdminSDHolder object so that protected accounts can have Self Service Password Reset (SSPR) function against the accounts. Note you need to change the DC values in the script for it to function against your domain(s).

Note that if you implement this, I recommend that you use version 1.1.553 or later, as that version restricts rogue Azure AD admins from resetting other Active Directory admins passwords and then taking ownership of the Active Directory account. Often Azure AD admins have admin rights in AD, and so this was always possible independent of AADConnect, but versions of AADConnect prior to 1.1.553 would allow an Azure AD admin to reset a restricted AD account that they did not own.

To determine the account name that permissions must be granted to, open the Synchronization Service Manager on the sync server, click Connectors and double click the connector to the domain you are updating. Under the Connect to Active Directory Forest item you will see the Forest Name and User Name. The User Name is the name of the account you need in the script. An example is shown below:


$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number or MSOL_number].
$AdminSDHolder = "CN=AdminSDHolder,CN=System,DC=contoso,DC=com"

$cmd = "dsacls.exe '$AdminSDHolder' /G '`"$accountName`":CA;`"Reset Password`"'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls.exe '$AdminSDHolder' /G '`"$accountName`":CA;`"Change Password`"'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls.exe '$AdminSDHolder' /G '`"$accountName`":WP;lockoutTime'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls.exe '$AdminSDHolder' /G '`"$accountName`":WP;pwdLastSet'"
Invoke-Expression $cmd | Out-Null

Exchange Hybrid Mode Writeback

The below script will set the permissions required for the service account that AADSync uses. Note that if Express mode has been used, then an account called MSOL_AD_Sync_RichCoexistence will exist that has these permissions rather than being assigned directly to the sync account. Therefore you could change the below permissions to utilise MSOL_AD_Sync_RichCoexistence rather than AAD_ or MSOL_ and achieve the same results, but knowing that future changes to the MSOL_ or AAD_ account will be saved as it was done via a group.

The final permission in the set is for msDS-ExternalDirectoryObjectID and this is part of the Exchange Server 2016 (and maybe Exchange Server 2013 later CU’s) schema updates. Newer documentation on AAD Connect synchronized attributes already has this attribute listed, for example in Azure AD Connect sync: Attributes synchronized to Azure Active Directory

$accountName = "domain\aad_account"
$AdminSDHolder = "CN=AdminSDHolder,CN=System,DC=contoso,DC=com"

$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;proxyAddresses'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchUCVoiceMailSettings'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchUserHoldPolicies'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchArchiveStatus'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchSafeSendersHash'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchBlockedSendersHash'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchSafeRecipientsHash'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;publicDelegates'"
Invoke-Expression $cmd | Out-Null

Once these two scripts are run against AdminSDHolder object and you wait an hour, the permissions will be applied to your protected accounts, then within 30 minutes (based on the default sync time) any admin account that is failing to get cloud settings written back to Active Directory due to permission-issue errors will automatically get resolved.

Bypassing Focused Inbox and Clutter Folders

Posted on Leave a commentPosted in Clutter, Focused Inbox, IAmMEC, Office 365, Outlook

For the last few years Exchange Online mailboxes have been processed by a service call Clutter, which moved the less important emails, or indeed the clutter, to a dedicated folder. This is now in the processes of being replaced by the Focused Inbox, which is client version dependant and is all based on views on the mailbox and not different folders.

The way to ensure mail is not marked as clutter, or shown in the Other view when your mailbox is processed by the Focused Inbox, is to mark the item as such, or to actively engage with the item. That is if you reply or read the emails from these recipients they do not go into Clutter/Other, but if you ignore them or delete them before they are read then this makes them candidates for future processing by the Focused Inbox or Clutter engine.

There are though times when occasional emails need to be in your Inbox and not the Other view or the Clutter folder. The best two ways to do this are as follows:

Management Hierarchy

The processing engine for Clutter/Focused Inbox will not place items from your Direct Reports or management chain in the Other view/Clutter folder nor will it place any emails from yourself into the low priority location. The Direct Reports and your management chain is known to the processing engine as it is part of Active Directory. So as long as your manager (and everyone else’s manager) attribute is populated in Active Directory and synced to Azure Active Directory then this configuration can be honoured.

Transport Rules

The other way to ensure certain messages always go to the Inbox is to have the message processed by a transport rule. Transport rules, like the management chain above are only available in Office 365 Business and not The two Transport Rule placeholders below add the Clutter and Focused Inbox rules (there are two different rules, so if you added the Clutter one in the past a new one is needed for Focused Inbox). They add the rule with a arbitary placeholder, so that the rule never fires (unless you really happen to enter the demo text!). So once you add these rules change them to suit the conditions of your environment. For example if you have a “company wide communications” email sender then you could set the rule to be when that sender sends emails. The two rule placeholders you need in remote PowerShell to Exchange Online are:

   1: New-TransportRule -Name "Bypass Focused Inbox" -SubjectContainsWords "This is a placeholder rule that does nothing, change this action to suit the requirements of the client" -SetHeaderName "X-MS-Exchange-Organization-BypassFocusedInbox" -SetHeaderValue "true" -Comments "<date> - <name> - Any mail that meets the conditions of this rule will go into the Inbox or Focused Inbox and not the Clutter or Other folder in Exchange Online"

   2: New-TransportRule -Name "Bypass Clutter" -SubjectContainsWords "This is a placeholder rule that does nothing, change this action to suit the requirements of the client" -SetHeaderName "X-MS-Exchange-Organization-BypassClutter" -SetHeaderValue "true" -Comments "<date> - <name> - Any mail that meets the conditions of this rule will go into the Inbox or Focused Inbox and not the Other view in Exchange Online"

Change these rules to suit your requirements