Test Connectivity Website and TLS 1.2

Posted on Leave a commentPosted in certificates, exchange online, Exchange Server, Kemp, SSL

An excellent resource for Microsoft Exchange Server and Exchange Online administrators and consultants is the Remote Test Connectivity website at http://exrca.com or https://testconnectivity.microsoft.com/.

Here I am going to document an error that indicated that the Exchange Server (in this case) was not working, but we could see that the phone was connecting fine to the server. The error we say was:

“The certificate couldn’t be validated because SSL negotiation wasn’t successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.”

and also

“The Microsoft Connectivity Analyzer wasn’t able to obtain the remote SSL certificate”

The error looked like the following:

exrca tls 10 support[96033]

This error occurs when TLS 1.0 is disabled either on the end server or on a load balancer in front of the server. In my case this as the case with the Kemp load balancer we were using – TLS 1.0 was disabled under SSL Properties. Once we restored TLS 1.0 the Remote Connectivity Test tool, the tool worked instantly:

TLS Kemp setting[96034]

Public Folder Sync–Duplicate Name Error

Posted on Leave a commentPosted in AADConnect, exchange, exchange online, Exchange Server, migration, Office 365, Public Folders

I came across this error with a client today and did not find it documented anywhere – so here it is!

When running the Public Folder sync script Sync-ModernMailPublicFolders.ps1 which is part of the process of preparing your Exchange Online environment for a public folder migration, you see the following error message:

UpdateMailEnabledPublicFolder : Active Directory operation failed on O365SERVERNAME.)365DATACENTER.PROD.OUTLOOK.COM. The
object ‘CN=PublicFolderName,OU=tenant.onmicrosoft.com,OU=Microsoft Exchange Hosted
Organizations,DC=)365DATACENTER,DC=PROD,DC=OUTLOOK,DC=COM’ already exists.
At C:\ExchangeScripts\pfToO365\Sync-ModernMailPublicFolders.ps1:746 char:9
+         UpdateMailEnabledPublicFolder $folderPair.Local $folderPair.Remote;
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
     + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,UpdateMailEnabledPublicFolder

This is caused because you have a user or other object in Active Directory that has the same name as the mail enabled public folder object.

In Exchange Online PowerShell if you run Get-User PublicFolderName you should not get anything back, as its a Public Folder and not a user, but where you see the above error you do get a response to Get-User (or maybe Get-Contact or any other object that is not a Public Folder. This class of object name (common name or cn) means the script can create the public folder in the cloud, but not update it on subsequent runs of the script.

The easiest fix is to rename the common name of the public folder object in Active Directory for all clashing public folders, unless you know you do not need the other object that clashes – as renaming that and letting AADConnect sync process the change is another way to resolve this.

To rename the mail public folder, in Exchange Server management shell run Set-MailPublicFolder PublicFolderName –Name NewPublicFolderName

I have changed my names to start with pf, so PublicFolderName becomes pfPublicFolderName and then the script runs without issue.

CannotEnterFinalizationTransientException On Exchange Move Request

Posted on Leave a commentPosted in error, exchange, exchange online, Exchange Server, migration, move

Did not find a lot on the internet on this particular error, so I guess it does not happen very often, but in my case it delayed to move of the mailbox in question by a week or so until I could resolve it.

When a mailbox is moving to a different Exchange organization (cross-forest or to/from Exchange Online) the move process copies the mailbox data to the target database and then right at the end of the move updates Active Directory in both the source and target forest. In the source it changes the object type from mailbox to mailuser (or remotemailbox if Exchange Online is in play, though this is really a special form of mailuser) and in the target, updates the mailuser to become a mailbox.

This particular error occurs at this stage. The Get-MoveRequest cmdlet reports Failed as the status, and Get-MoveRequestStatistics reports FailedOther as the status. If you get the move logs (Get-MoveRequestStatistics <name> -IncludeReport | FL | Out-File <filename.txt>) then in the logs you will see CannotEnterFinalizationTransientException as the error repeated many times until the move fails.

The fix for this issue is as follows:

1. Check that the Exchange System account has permission to the Active Directory object in question. In Active Directory Users and Computers choose View > Advanced to enable the Security tab and then view the security tab on the object in question. Edit > Advanced and then check or click “Enable Inheritance” option or button (depending upon version of AD tools). If inheritance is already set to enabled there is probably no harm in disabling inheritance, copying permissions and then enabling inheritance again.

2. Move the mailbox to a different database in the source Exchange Organization (New-MoveRequest <name>) and waiting for that to complete.

3. Removing and restarting the move in the target forest. If you do not remove and restart the move in the target you will see both MailboxIsNotInExpectedMDBPermanentException and SourceMailboxAlreadyBeingMovedTransientException. The first of these is because the mailbox is not where the target move expects it to be, and the second of these is becuase the source is currently being moved and so cannot be moved to the correct target forest at the same time.

This should resolve your ultimate move request – it did for me! 

Exchange Server Object ID Error With Windows Server 2016 Domain Controllers

Posted on Leave a commentPosted in 2010, 2013, 2016, active directory, ADDS, error, Exchange Server

Saw this error the other day:

image

When you open Exchange Control Panel and view the Mailbox Delegation tab of any user account you get the following:

The object <name> has been corrupted, and it’s in an inconsistent state. The following validation errors happened: The access control entry defines the ObjectType ‘9b026da6-0d3c-465c-8bee-5199d7165cba’ that can’t be resolved..

You do not see this error on any mailboxes that you have moved to Office 365 in hybrid mode, that is you do not see it on any RemoteMailbox objects.

The issue is because ObjectType ‘9b026da6-0d3c-465c-8bee-5199d7165cba’ is the GUID of the DS-Validated-Write-Computer Control Access Right introduced in WS2016 AD DS which is new to your Active Directory upon installing your first 2016 domain controller. Exchange Server reads this access control list when you open the Mailbox Delegation tab in Exchange Control Panel or when you run Get-ADPermission on the mailbox. This error is cosmetic, but to remove it you just need to reboot all your Exchange Servers in turn (relying on your database availability groups and load balancers to maintain service). Once you have rebooted each server, the error goes away when you are connected to that server for administrative functions. There is no impact on user connectivity whilst this error is in place, though it may impact you ability to assign permissions without error.

Therefore recommend that you reboot one server as soon as you can and then use that server as your target for administration until you can reboot the remaining servers.

Copy Links and Backlinks Between Users and Shared Mailboxes (automapping)

Posted on 1 CommentPosted in cross-forest, Exchange Server, mailbox, migration, msExchDelegateListBL, msExchDelegateListLink, shared mailbox

Automap for shared mailboxes does not work across forests when moving mailboxes.

When the user is granted permission to a shared mailbox, the default behaviour of automapping means that the shared mailbox has msExchDelegateListLink set to the DN of the user, and the backlink (hidden in AD by default) on the user is populated with the DN of the shared mailbox. Whenever the link attribute is updated, the backlink is automatically updated as well. For more on back links see https://neroblanco.co.uk/2015/07/links-and-backlinks-in-active-directory-for-exchange/

That is, is UserMailbox is granted full access to SharedMailbox you will see the following in Active Directory (Advanced View) > Attribute Editor > msExchDelegateListLink = “CN=UserMailbox,OU=etc” (on the SharedMailbox). And for the UserMailbox in Active Directory (Advanced View) > Attribute Editor > msExchDelegateListBL = “CN=SharedMailbox,OU=etc”.

When you migrate mailboxes across forests you make use of Prepare-MoveRequest.ps1 to copy all the attributes. The msExchDelegateListLink is not part of this attribute set and the msExchDelegateListBL is auto populated so we can ignore it for now – if msExchDelegateListLink was copied and updated to the new forest name, then msExchDelegateListBL would be filled in automatically.

So how do we copy the msExchDelegateListLink value for each user and then write it to the mail user object in the target forest before the mailbox is migrated (or if you have already done your migration and found this property missing and so automapping of shared mailboxes having failed (though the permissions have been copied fine), how can you grab the data from the old source forest and apply it to the mailboxes in the target?

Using PowerShell and the ActiveDirectory module is how.

First you need to export a list of all the automapped shared mailboxes each user has (this is the msExchDelegateListBL values for the user mailboxes you have migrated). There are two cmdlets to run here, the first does the entire source directory and the second filters the output to an OU and its child OU’s (so you can export a subset of data) using SearchBase. Only one of these two cmdlets is needed.

This code is PowerShell and needs to be run from any domain joined computer.

Import-Module ActiveDirectory
Get-ADUser -Properties msExchDelegateListBL,msExchDelegateListLink -LDAPFilter "(msExchDelegateListBL=*)" | Select name,DistinguishedName,@{Name='SharedMailbox';Expression={$_.msExchDelegateListBL -Join ";"}} | Export-csv automap-userlist.csv -NoTypeInformation -NoClobber -Encoding UTF8
Get-ADUser -Properties msExchDelegateListBL,msExchDelegateListLink -LDAPFilter "(msExchDelegateListBL=*)" -SearchBase 'OU=Sales,DC=domain,DC=local' | Select name,DistinguishedName,@{Name='SharedMailbox';Expression={$_.msExchDelegateListBL -Join ";"}} | Export-CSV automap-userlist.csv -NoTypeInformation -NoClobber -Encoding UTF8

These cmdlets return a CSV file listing each mailbox that has an automapping to a shared mailbox and what that shared mailbox is.

The CSV file then needs copying to the target AD forest, and as the target forest is very unlikely to contain the same OU structure and domain names, the DN of each object in the CSV file needs updating. This can be done with Find/Replace in Excel or Notepad quite easily.

For example, in a CSV I might see:

“name”,”Distinguishedname”,”SharedMailbox”

“First User”,”CN=First User,OU=Sales,DC=domain,DC=local”,”CN=SharedMailbox,CN=Users,DC=domain,DC=local CN=AnotherSharedMailbox,OU=Shared Mailboxes,OU=Exchange,DC=domain,DC=local”

“Second User”,”CN=Second User,CN=Users,DC=domain,DC=local”,”CN=Sales,OU=Shared Mailboxes,OU=Exchange,DC=domain,DC=local”

In this I have the DN of the mailbox and the DN of the shared mailbox in the source forest. Use Find and Replace to change all the source DN’s (or the OU/DC bits) to suit the location of the matching object in the target forest. For example, my above “second user” was as shown, but after updating the DN might be “CN=Second User,OU=Migrated,DC=target,DC=forest”. So in that case I find/replace “CN=Users,DC=domain,DC=local” for “OU=Migrated,DC=target,DC=forest”.

For my examples that follow on from here, I have saved the edited CSV file as automap-userlist-target-dn-updated.csv

Once I have the CSV file updated for the values in the target forest, I need to split each row where a user has more than one shared mailbox listed into multiple rows. This is simple with PowerShell:

Import-Csv -Path automap-userlist-target-dn-updated.csv |
% {$row = $_; $_.SharedMailbox.split(";")} |
% {$row.SharedMailbox=$_; $row} |
Export-Csv automap-userlist-target-dn-updated-split.csv -NoClobber -NoTypeInformation -Encoding UTF8

Now that I have a row in the CSV for each Shared Mailbox to User Mailbox mapping, I can set the msExchDelegateListLink value on each shared mailbox for the DN of the user that has access to it. This will update the msExchDelegateListBL on the user object automatically.

Import-Module ActiveDirectory
Import-CSV "automap-userlist-target-dn-updated-split.csv" | % {
Write-Host Add $_.DistinguishedName to $_.SharedMailbox
Get-ADUser -identity $_.SharedMailbox | Set-ADUser -Add @{msExchDelegateListlink=$_.DistinguishedName} 
}

In terms of errors in the above, if you get “get-aduser : Directory object not found” then the DN value for the Shared Mailbox is wrong, and if you see “set-aduser : The name reference is invalid” then the DN value for the user who has access to the shared mailbox is wrong (the DistinguishedName column in the CSV). The script can be run multiple times, so you are safe to fix the CSV file and import the entire list again. It will only add a given DN once in total per shared mailbox.

If your target (or source) forest has more than one domain, run the script from a server in the correct domain or use “-Server DC-name” in both the Get-ADUser and the Set-ADUser cmdlets.

Anonymous Emails Between On-Premises and Exchange Online

Posted on 1 CommentPosted in Authentication, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, hybrid, smtp, spam

When you set up Exchange Hybrid, it should configure your Exchange organizations (both on-premises and cloud) to support the fact that an email from a person in one of the organizations should appear as internal to a recipient in the other organization. In Outlook that means you will see “Display Name” at the top of the message and not “Display Name” <email address>. An email from the internet is rightly treated as anonymous and so should appear as “Display Name” <email address> but when it comes from your on-premises environment or your cloud tenant it should be authenticated.

In the email headers you should see a header called AuthAs that reads internal. The SCL (Spam Confidence Level) should always be –1 and you should not have a header called X-CrossPremisesHeadersFilteredBySendConnector visible on internal emails.

Your hybrid setup can be incorrectly configured and cause this, and depending upon what Exchange Server version you are running and when you last ran the hybrid wizard you can end up with different results.

Lets take a quick view to some of the settings you should see:

  1. Exchange Server 2010 (with or without Edge Server 2010)
    1. Hybrid wizard will use Remote Domains to control internal vs external and authentication state. You should have a Remote Domain for tenant.mail.onmicrosoft.com that shows TNEFEnabled, TrustedMailOutboundEnabled, TargetDeliverDomain, and IsInternal all set to True on-premises
    2. TrustedMailnboundEnabled attribute is set to True on Get-RemoteDomain domain.com in the cloud
    3. The AllowedOOFType, which controls Out Of Office is set to InternalLegacy
  2. Exchange Server 2013 and later
    1. Your “Outbound to Office 365” send connector on-premises should have CloudServicesMailEnabled set to True
    2. The Remote Domains matter for Out of Office and moderated emails/voting buttons, but not for authentication as mentioned in #1 above
    3. The Inbound Connector for “Inbound from GUID” should have CloudServicesMailEnabled set to True
  3. Exchange Server 2010 with Exchange Server 2013 or later Edge (no 2013 on-premises, only Edge)
    1. The setting CloudServicesMailEnabled needs to be True, but 2010 does not support this setting, so you need to edit the directory using ADSIEdit and change the msExchSmtpSendFlags on the send connector from 64 to 131136. All this does is tell the 2013 or later Edge to enable CloudServicesMailEnabled
    2. See https://support.microsoft.com/en-us/help/3212872/email-sent-from-an-on-premises-exchange-2013-edge-transport-server-to for the steps to do this
  4. As #3 but with 2010 and 2013 on-premises – run the cmdlets and hybrid wizard from the 2013 server and not connected to the 2010 server!

Send-On-Behalf Permissions in Exchange Online

Posted on 2 CommentsPosted in exchange, exchange online, Exchange Server, hybrid, permissions, send-on-behalf

This document is up to date as of November 2018 and is therefore unlike many earlier documents on this issue as this feature set is in the process of changing.

First, Send-On-Behalf is changing so that it is supported across a hybrid Exchange Server to Exchange Online connection. At the time of writing this is in the process of being rolled out, so it might well be in your tenant by the time you read this.

But even if the config for this is enabled in the cloud, there is config that is needed on-premises. In Exchange Server 2013 you need to be on the latest CU and then run Set-OrganizationConfig  -ACLableSyncedObjectEnabled $True (as mentioned in https://docs.microsoft.com/en-gb/exchange/hybrid-deployment/set-up-delegated-mailbox-permissions). For Exchange 2010, this is not an option (and the ACL sync needs to be done manually) and for Exchange 2016 it is documented that this cmdlet is already enabled. But this is not true; Exchange Server 2016 needs treating in the same way as Exchange Server 2013 regardless of what the Microsoft article says at the time of writing.

[Note: Update Nov 2018 – if you are using Exchange Server 2016 and you set the OrganizationConfig setting to true this does not make all mailboxes moved to the cloud after this date ACLable. I have recently discovered that about 1/10 to 1/3 of my mailboxes do not get converted to the correct recipient type property on migration. This means I need to treat Exchange Server 2016 like I treat Exchange Server 2010, I need to run the script to update the recipient type after each migration]

So what does -ACLableSyncedObjectEnabled $True do – well it changes Exchange Server so that all MoveRequests completed after the change leave behind a RemoteMailbox object where msExchRecipientDisplayType is -1073741818. For reference before the change to the OrganizationConfig this value on a RemoteMailbox was -2147483642.

msExchRecipientDisplayType Value
SyncedMailboxUser

-2147483642

ACLableSyncedMailboxUser

-1073741818

An ACLableSyncedMailboxUser is one that can have Send-On-Behalf permissions set or maintained across on-premise and the cloud – that is once your tenant is  updated as well.

This though leaves a few issues – the main one is that the RemoteMailbox left behind by the MoveRequest is only set to -1073741818 where the RemoteMailbox is made by a MoveRequest. If once you have moved all your users you start provisioning users directly in the cloud, then New-RemoteMailbox or Enable-RemoteMailbox will not set msExchRecipientDisplayType to -1073741818.

Therefore provisioning of users directly into the cloud with –RemoteMailbox will need the addition of Set-ADUser to update the msExchRecipientDisplayType after the RemoteMailbox is created. The cmdlet for this is the same cmdlet that you need to run if you are using Exchange 2010. This cmdlet is Get-AdUser <Identity> | Set-AdObject -Replace @{msExchRecipientDisplayType=-1073741818}

This  cmdlet would need to be added to your provisioning scripts, and if you don’t have scripts to provision users in AD and have a mailbox in the cloud, then now is the time to look at this as the number of moving parts is growing.

If you do not do the msExchRecipientDisplayType change then some of your remote mailboxes in Exchange Online will be able to be granted permissions for Send-On-Behalf and other permissions as they are added to the cloud, as they are ACLable (as in we can set them in Access Control Lists, ACLable!), and others users will not be. To make these changes you need to change the msExchRecipientDisplayType on-premises to -1073741818 and wait for this to sync to Azure AD and then wait for that to sync from Azure AD in the Forward Sync process to your Exchange Online directory.

420 4.2.0 RESOLVER.ADR.Ambiguous; ambiguous address

Posted on Leave a commentPosted in active directory, exchange, exchange online, Exchange Server, migration, smtp

This error can turn up in Exchange Server when Exchange Server is trying to resolve the object that it should deliver a message to. Exchange queries Active Directory and expect that if the object exists in the directory, that the object exists only once. If the object exists more than once, this is the error – as Exchange does not know who to deliver the email to.

The error is visible when running Get-Queue in Exchange Management Shell, and seeing that there are lots of emails in the Submission Queue. If you run Get-Message –Queue servername\Submission | FT Identity,FromAddress you can pick one to look at, and for that one run Get-Message server\submission\ID | FL where server\submission\ID is the Identity value from Get-Message cmdlet. Here you will see LastError and Recipients showing the ambiguous address error.

There are a number of articles on the internet covering this issue, but I came across a unique one today.

The easy way to search for the issue is to find the address that is in duplicate. This will be listed in Event Viewer under MSExchangeTransport as the source and Event ID 9217. The Task Category will be Categorizer, as the job of working out who is going to get the message is the role of the Categorizer.

image

An example of this error is shown.

So the fix. Often suggested is to do a custom AD query for “proxyaddress=smtp:name@domain.com” where name@domain.com is the email address shown in the event log error. If this returns two or more recipients, and this will be across all the domains in the forest, then you need to decide which is the primary one and carefully delete the rest.

By carefully I mean that you want to leave either one contact, or one mail user or one mailbox etc. If the duplicate is two contacts, then find the one with the most correct information on it and carefully delete the other. If you find two mailboxes, work out which the user is actually logging into and has email in it – and carefully delete the other etc.

And by carefully, here I also mean that on the object you are going to delete, copy the legacyExchangeDN value and then delete the object. Then find the real correct object and add a new x500 email address to the proxyAddresses attribute of the correct user. The value of the x500 address will be the legacyExchangeDN that you copied from the deleted contact.

This will ensure that users who have previously emailed the now deleted contact before, will still be able to email the remaining object.

But what is unique about that? At the customer I am working on at the moment the issue was that doing the proxyaddresses=smtp:name@domain.com search only returned one object across the entire forest – what is duplicate about that? Well in my case, the user had user@domain.com added to their proxyaddresses twice – they were the duplicate object to themselves.

image

Opening this user via the search results as shown above, and with Advanced Features enabled from the View menu, you can see the Object tab:

image

Opening the object value directly, redacted in the picture above, I can change to the Attribute Editor tab and open proxyAddresses attribute. Here i saw the following:

name@domain.com

name@mail.domain.com (used as a target for forwarding emails from another system)

smtp:name@old-company.com

SMTP:name@domain.com

x500:legacyExchangeDN from Exchange 2007 migration

Note that the name@domain.com value, the one in error in the logs, appears twice but not starting SMTP (primary address) or smtp (secondary address) but without an address protocol at all!

Querying the user in Exchange Administration Console returned:

image

And also then opening the user in Exchange Management Console showed that the address without the smtp: value was shown with it.

Remove one of the two addresses and within ten minutes the emails queued to this user in the submission queue will be delivered. Restarting the transport service will also kick start the submission queue as you cannot use Retry-Queue against this queue.

Exchange Online Migration Batches–How Long Do They Exist For

Posted on 5 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!

Outbound Email Via Exchange Online Protection When Using Hybrid Exchange Online

Posted on 2 CommentsPosted in dmarc, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, hybrid, mailbox, spf

In a long term hybrid scenario, where you have Exchange Online and Exchange Server configured and mailboxes on both, internet bound email from your on-premises servers can route in two general ways.

The first is outbound via whatever you had in place before you moved to Office 365. You might have configured Exchange Online to also route via this as well.

The second is to route Exchange Server outbound emails via Exchange Online Protection. Your Exchange Online configuration does not need to be adjusted for this to work, as the default route for all domains to the internet (or the * address space as it is known) is via EOP as long as you create no alternative outbound connector for *.

This blog post looks at configuring Exchange Server so that your on-premises mailboxes also route out via Exchange Online Protection, and does it without changing the connectors made by the hybrid wizard. If you change the hybrid wizard connectors and then run the wizard again, it will reset things to how it wants them to be, which will remove your configuration changes.

This configuration setup results in a single new send connector created on-premises in Exchange Server (or one connector per site is you route emails from more than one Active Directory site). This new connector is not the Outbound to Office 365 connector that the hybrid wizard creates and so changes here do not break hybrid and changes to the hybrid wizard do not impact outbound mail flow.

This blog post also assumes you already have a working route outbound for all internet emails and you are swapping over to outbound via EOP, so these steps work though ensuring that is correct and will work before changing the route for *.

Examine the hybrid send connector to Office 365

[PS] C:\ExchangeScripts\pfToO365>Get-SendConnector out* | fl

AddressSpaces:                  {smtp:domainuk.mail.onmicrosoft.com;1}
AuthenticationCredential :
CloudServicesMailEnabled :      True
Comment : ConnectedDomains :    {}
ConnectionInactivityTimeOut :   00:10:00
DNSRoutingEnabled :             True
DomainSecureEnabled :           False
Enabled :                       True
ErrorPolicies :                 Default
ForceHELO :                     False
Fqdn :                          mail.domain.uk
FrontendProxyEnabled : 	        False
HomeMTA :                       Microsoft MTA
HomeMtaServerId :               SERVER01
Identity :                      Outbound to Office 365
IgnoreSTARTTLS :                False
IsScopedConnector :             False
IsSmtpConnector :               True
MaxMessageSize :                35 MB (36,700,160 bytes)
Name :                          Outbound to Office 365
Port :                          25
ProtocolLoggingLevel :          None
RequireOorg :                   False
RequireTLS :                    True
SmartHostAuthMechanism :        None
SmartHosts :                    {}
SmartHostsString :
SmtpMaxMessagesPerConnection :  20
SourceIPAddress :               0.0.0.0
SourceRoutingGroup :            Exchange Routing Group (DWBGZMFD01QNBJR)
SourceTransportServers :        {SERVER02, SERVER01}
TlsAuthLevel :                  DomainValidation
TlsCertificateName :            <I>CN=GlobalSign Organization Validation CA - SHA256 - G2, O=GlobalSign 
                                nv-sa, C=BE;<S>CN=*.domain.uk, O=Acme Limited, L=London, S=London, C=GB
TlsDomain :                     mail.protection.outlook.com
UseExternalDNSServersEnabled :  False

The above PowerShell from the on-premises Exchange Management Shell shows you the hybrid send connector. As you can see this is set to route emails only for your hybrid address space (domainuk.mail.onmicrosoft.com in this example)

The other important attributes for EOP mail flow here are AddressSpaces, CloudServicesMailEnabled, DNSRoutingEnabled, Fqdn, RequireTLS, SmartHosts, and TLSAuthLevel. Setting these correctly on a new send connector will allow you to route other domains to EOP and then onward to the internet.

Create a new send connector

This blog is based upon information found in https://technet.microsoft.com/en-us/library/dn751020(v=exchg.150).aspx but it differs from the scenario described there within. In this scenario, as you have already run the hybrid wizard, the connector to the cloud from on-premises and from the cloud to your servers already exists. Therefore all we need to do is create an additional send connector on-premises to route all the other domains to EOP and the internet.

New-SendConnector -Name <DescriptiveName> -AddressSpaces testdomain1.com,testdomain2.com -CloudServicesMailEnabled $true -Fqdn <CertificateHostNameValue> -RequireTLS $true -DNSRoutingEnabled $false -SmartHosts <YourDomain_MX_Value> -TlsAuthLevel  CertificateValidation -Usage Internet

In the above, the connector is originally created being able to route for two test domains (written as testdomainx.com above, comma separated in the list with no spaces). This ensures that you do not break your existing mail flow but allows you to test that the connector works and then later change the connector to support * address space. The “YourDomain_MX_Prefix” is the same value as you would use in your MX to route emails to Exchange Online (tenant-prefix-com.mail.protection.outlook.com for example).

Testing the connector

In the above new send connector, testdomain1.com is a domain hosted in a different Office 365 tenant. Testdomain2.com is a domain who’s email is not hosted in Office 365 at all. You need both test scenarios, as routing to domains inside Office 365 is more likely to work if the connector is not configured properly.

So from a mailbox on-premises, send an email to a recipient at both testdomain1.com and testdomain2.com. Do not set the connector up to use gmail or Outlook.com, as that will impact other senders within your organization. Use domains that no one else is likely to want to email.

Ensure that you do not get any NDR’s and check the recipient mailboxes to ensure delivery. Note that you are possibly likely to need to update your SPF record for the sending domain to additionally include the following:

  • include:spf.protection.outlook.com
  • ipv4:w.x.y.z (where w.x.y.z is the external IP address(es) of your on-premises Exchange transport servers)

Updating the connector

Once your mail flow tests work, and you can check the route by pasting the received message headers into http://exrca.com you should see that email routes into your Office 365 tenant, then leave EOP (the word “outbound” will be in one of the FQDNs – this server is on the external edge of EOP), then routed inbound to your email provider (or back into your recipient tenant).

Once mail flow works, you can either add more recipient domains to increase the scope of the test – for example add a domain that you email occasionally, such as the partner helping you with this work and a few other domains. Once all your testing is ready change this connector to have * as the address space and not list specific domains.

As your other connector for * is still up and running you will find that 50% of your email will use the new connector and 50% the old. Then you can disable the old connector to go 100% email outbound through EOP (you need an EOP licence per sender to do this, or if you have an Exchange Online licence for each user you are already covered).

Finally when you have been routing on-premises email through EOP for a few weeks with the old connector disabled, you can delete the old connector and tidy up the configuration rather than leaving disabled connectors around.

Duplicate Exchange Online and Exchange Server Mailboxes

Posted on 6 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 directories, you should never find that a synced user object is configured as both a mailbox in Exchange Online 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 done a limited attribute sync and excluded the Exchange attributes from syncing to AAD – as syncing the attributes is required for Exchange Online hybrid). Exchange Online though does not read attributes from Azure Active Directory. Exchange Online reads its attributes from the Exchange Online Directory Service (EXODS). 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 Exchange Online for your tenant.

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 may 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. Note that this last option will create a mailbox in the cloud – but all the attribute management of this mailbox must be done on-premises, as the object syncs from on-premises and so that is the source of the object. Therefore avoid licencing synced objects that do not have a mailbox or remote-mailbox on premises (see my session on this at Microsoft Ignite 2018 “THR2145 – Why do we need to keep an Exchange Server on-premises when we move to the cloud?“)

The above is what happens in most cases – the user on-premises has a ExchangeGUID value, that is synced to the cloud, and then the user is licenced and a second mailbox is not created. 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 or primary SMTP address.

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 cloud 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 of course a different ExchangeGUID.

image

[PS] > Get-Mailbox twomailboxes | FL name,userprincipalname,exchangeguid


Name              : Two Mailboxes
UserPrincipalName : twomailboxes@domain.com
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, which 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 (on-premises values overwrite cloud values unless on-premises value is null or does not exist). In the second case, cloud object deleted before sync, 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 but same UPN/email address.

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!

The other problems are that 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) run in Exchange Online 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 before you migrate their on-premises mailbox, as that will restore the old cloud mailbox, 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 licence. 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.

Conversation Red Number in Skype For Business That Won’t Go Away

Posted on 1 CommentPosted in conversation, exchange online, Exchange Server, Outlook, Skype For Business Online, Skype for Business Server

I have had this issue for ages, but could not find any answer for it on the internet that did not involve resetting Skype for Business or other complex stuff when in fact the answer is so easy it hurts! Finding it was one of those Duh! moments.

You have this:

image

Skype for Business shows a red flag in one of the sections that will not go away. In my case it was the Conversation History pane and all the conversations in the view were read!

Then one day in Outlook I noticed the Missed Conversations view in Outlook:

image

Its a Search View and it was already active for me, but look – it also says one conversation unread. So I scrolled down the list of conversations in Outlook, found the unread one and the issue went away in Skype for Business within seconds.

image

image

This issue will probably be true for Teams as well when Outlook Conversation History functionality moves over to that product as well from Skype for Business Online!

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.

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 (virginmedia.com, ntlworld.com, blueyonder.com etc.)

mx3.mnd.ukmail.iss.as9143.net gave this error:
vLkg1v00o2hp5bc01Lkg9w DMARC validation failed with result 3.00:quarantine

In the above, the server name (…as9143.net) 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-rua@dmarc.service.gov.uk,mailto:dmarc@xxx.xxxxx;ruf=mailto:admin@xxx.xxxxx,mailto:dmarc-ruf@dmarc.service.gov.uk,mailto:dmarc@xxx.xxxxx;

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

v=DMARC1; p=quarantine; fo=1;rua=mailto:dmarc-rua@dmarc.service.gov.uk;ruf=mailto:dmarc-ruf@dmarc.service.gov.uk;

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.