Experience Exchange Sever

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

April 8, 2017

Case study for Office 365 migration – Part 1

Filed under: Office 365 — vijayarelangovan @ 8:27 pm

Recently i worked on Exchange 2010 to Office 365 migration.  It is a complex environment, i had to customize too many things to be able to make this successful.  This post is to explain the challenges that i have faced and how i was able to get around the situation.  I’m not covering technical details of the migration process, but it is just a case study.

First let me tell you the existing architecture,

  • Parent company – ABC.COM
  • Child Company – XYZ.COM
  • Child domain of the child company is – UK.XYZ.COM (this is domain were Exchange environment is present)

The oragnization decision is to bring all the employees under one roof.  Atleast for now, to bring email systems to parent domain.

Existing setup is

architecture copy

  • Each users from UK.XYZ.COM have a separate AD account to access the ABC.COM resources.
  • Each users from UK.XYZ.COM are mapped to the corresponding AD account on ABC.COM
  • The password of UK.XYZ.COM users account and their corresponding AD account on the ABC.COM are sycned using Dell password sync.
  • Each users from ABC.COM have a mailbox on UK.XYZ.COM, and the email are forwarded to ABC.COM mailbox if any emails are sent.
  • If there is any email for UK.XYZ.COM coming in ABC.COM, it will be routed through the AD accounts created on ABC.COM

So, the environment is so complicated, and the job is to bring everyone under one roof when migrated to office 365.

I’m not going to explain technical details, rather I’m going to explain the challenges and how we overcome all that.

For any given architecture i feel that following should be the prime focus of an Architect,

  • Defining a Model like
    • Type of licensing
    • Identity management
  • Active Directory consideration
    • UPN identification
    • Domain trust consideration
    • attribute consideration and remediaton
    • Identification of OU to be synched
  • Exchange server consideration
    • Mailflow
    • Email domains
    • Autodicover & Exchange web services
    • Exchange certificate
    • Active sync solution/MDM
    • Message limits
    • Mailbox sizing
    • Public folder
    • Archiving and Journaling
    • SMTP relay setup
    • Third party integration
  • Network Consideration
    • Bandwidth & Utilization
    • DNS requirement
    • Internet proxies
    • Firewall ports consideration
  • End-user desktop considerations, like windows version, outlook version, anti-virus
  • Future expansion consideration

Out of the above said considerations, the challenges that needs to be addressed or discussed

Mailflow – Right now, there are 2 incoming gateway.  one for ABC.COM and one for XYZ.COM.  When we implement office 365, how this is going to affect.  How many hops an email had to travel?, How to address the email loop? and so on

Dirsync – Right the password is synced from XYZ.COM to ABC.COM DC’s through Dell password sync.  After Office 365 who is will be the authority for syching the password.  Is is ABC.COM only or Both ABC.COM and XYZ.COM? if it is single authority, then which domain should own it?

Domain name – Fortunately, both domain has a common name, @domain.com.  Can we use the same name for the user to authenticate themselves to Office 365? if they use the same @domain name, if so, how this can be federated for 2 domains?

Domain Trust – There is one way trust between XYZ.COM to ABC.COM.  Though the trust between 2 root domains are transitive, does that going to impact UPN?,

Auto-discover – Since both the domain have the same common name, after migration, how the users from each domain will reach Office365 mailbox from inside the network? External URL needs changes? or Outlook on the client machine needs to be upgraded (User have office 2010)

MDM – Users in both the domain users same MDM solution (mobile iron) but different infrastructure.  Does that need to be changed? or both the infrastructure should be integrated or redefine a new solution?

In my Part 2 post ill explain how to overcome this challenge and the resulting architecture

VJ

Blog at WordPress.com.