Experience Exchange Sever

June 28, 2017

X-Microsoft-Exchange-Diagnostics-untrusted header – (NDR) Message header is too large – (Resolved)

Filed under: Uncategorized — vijayarelangovan @ 2:53 pm

Note : This issue has been fixed by Microsoft.  This article is just for an information

If your office 365 is setup to amend signatures to your email that are going out to external domains or attaching disclaimers to the email, then

There is existing issue.

The size of the message header grows drastically if you have this setup.  If you look at the messaging header, the content might be filled up like below,

X-Microsoft-Exchange-Diagnostics-untrusted: 1;VI1PR0602MB3232;7:eitiAZyhSkfzWdu2wx4WYDDsg97GybOhP52ygjEEopTGZOnqE44bl

T5+vSwWgBBvRj4qc7ypijFZ7jvebh9TbjvpifW3j5Y/nw90VgykX/xC1Wp7BKFQs7xdUpgBX7

hxaJGOvxvPEbUZ+6xcywCDxKwVE9jfPFxGtMA5ZL3IKUdcHKzrW4GoPKGimLIt94zJLY+IT

uqSBZdW+LAueVC2CDXSIcXefNpnoTDROP9yWvgCWbGNHLxD29iYcORDCkszvpXo+/hg9

Z/voAf75jxKb6Ph5lMVqUEjH1SKRHDImsVuQgT/1YqjDTr3JQ5ohxXspfMAxQIhd3Ghw8z9B

i+V7ltOGrdKKz7gTFWErJ/86NccrRyWFb37nFoAReh3IinALxOPsxPAy/woWk2xKcOqU1SJK

kHb9mYbCrHmue2jdZyeCzjcK3qYgMDaBGX1D2XnR42WYVNN6rxdWhC0vgrpaXEKOQOE

ixv+aTkODMoPWEFKeI/+6M5hsVNhoA+InBxBYWseFpTn9cUFctZ83g+1f+tP9uzOZapm+YC

4dk5TuqJ9JYvyNY1vc2AMfNMNVLRL8548dd+zcEakaMtpK3Syq3+ayIIZOHzZA1phacjTCB

S9oRbQzjkVUOP1TjPayPtmc05YtcQePNRdmSd3m5rIJHDpuFUr26x+4BALgo4yktxugimWB

XSx9zlXmkCv0AGEH/eR5D4JwM5pL5vf2Ui22z2aDUwnKj1azlIv+AKINbQZfXQJq+LuzHljj7

s7thi8O4Yo0PZoyp6ifNJK8YXc60zVw0axOMV1PMrlO7cv3G0=

 

Because of the large size of the message header, the recipient domain may reject your email saying it is not complaint or message header size is too large.

To fix the problem,

You can remove the X-Microsoft-Exchange-Diagnostics-untrusted header using transport rule,

messageheader

Or Simply wait until Microsoft fix it.

VJ

Advertisements

June 17, 2017

ADConnect Sync Issue – Resource/Active forest topology

Filed under: Office 365 — vijayarelangovan @ 7:21 pm

Recently i’ve encountered an issue with the AD connect. I thought it is worth sharing with others.

Infrastructure

There are 2 forest

1. Forest A and Forest B
2. Exchange is installed on Forest A
4. Forest B users mailbox are on Exchange server which is in the same forest
3. Forest A users mailboxes are on Exchange server which is in the forest B

The typical setup of the organization is below

1665.image_57B62B1E

 

For office 365 migration, AD Connect has 3 connectors

Connector for Forest B – Syncs the user attributes of forest A
Connector for Forest A – Sycns the AD object attributes of Forest A
Connector for Office 365 – Projects the object and their attributes to Azure AD

Forest B users mailboxes are migrated to office 365, Forest A users mailboxes are still on prem.

The reason for projecting the forest A object to AD Azure is to make use of sharepoint online and eventually migrate them to office 365.

Issue:

Ok, the issue here is that, one of user from forest A is assigned with share point but unable to login to it.

Diagnosis:

Sequence of steps that i tried to fix this eventually helped me understand

How AD Connect works.

1. Sharepoint license assinged correctly, and the sites are ok (with the help of sharepoint support i confirmed it is setup correctly comparing with the rest of them)
2. Searched the Forest A connector to see if the user AD attributes are projected – yes it does
3. Searched the Forest B connector to see if the mailbox attributes are projected – yes it does
4. The immutableID of the user object from AD Azure matches the base64 objectGuid of the AD object matches the Forest A (this proves that source anchor is from Forest A)

The catch is, Both the connectors are projecting assuming both are different object

How this supposed to work

1. the attributes of the user from Forest B called msExchMasterAccountSid is matched with the objectGuid attribute of the user in Forest A
2. The AD object on Forest A must be disabled
3. The metaverse should combine the AD attributes from Forest A and Exchange attributes from Forest B and project it to AD Azure

Solutions:

1. Move the user object to non-sync OU on both the forest A & B
2. force the Delta synchronization on all 3 connectors
3. Move the user object in Forest A to syncing OU
4. Run the full synchronization on Connect for forest A, Connector for Office 365
5. Move the user object n Forest B to Syncing OU
6. Run the full synchronization on Connect for forest B

This resolved the problem

But what difference does it make?

Lesson learnt is,

When we create the connector it automatically takes the first priority, so Forest B was project disable object. The second connector created was Forest A, it took the second priority.
For some reason the metaverse cannot combine the disabled Forest B (Exchange attributes) and Forest A ( AD Attributes).
By manually syncing one after the other, the issue was resolved.

But wait, should i do it everytime when new user is created – NO

You can change the priority by yourself using “Rule Editor” which gets installed along with the AD Connect. Keep the priority of the the active forest at the top and the resource forest first to the bottom.

Hope this was useful

Blog at WordPress.com.