Onboarding - Best Practice AD

Taen keren 

My number one recommendation to customers for preparing for AAD Connect is to look at your AD data like a SQL database owner.  Don't let there be any junk, make sure all your attributes are programmatically verified (i.e., if there is a rule affecting an attribute, ensure all object conform to that rule.  Ex: all users must have a Department set and normalized to one of the allowed values), and of course get rid of any conditions which must use OU filtering and replace them with attribute filtering.  Example.  Don't put all contractors in an OU, Azure doesn't have OUs, instead set an attribute on a user to define them as internal, external, contractor, seasonal, intern, etc. so you can tell who people are when they are all synchronized to Azure into the same OU.  And of course, fix all IDFIX errors ahead of time.

I have used the following.

1.  Reserve three extension attributes, they don't have to be the same as mine.

- ExtensionAttribute1: 

    - Enter 'NoSync' if the user does not sync to Azure.  Configure this in AAD Connect to not sync these object that meet this filter.

    - Enter 'DoesNotMigrate' if the mailbox does not move to O365.  Use this filtering when looking for mailboxes that are left on-premises.  An example would be service accounts that have to be on-premises because they send too much email for throttling policies.

    - Enter 'Postpone: <date>' if the mailbox cannot migrate until a future date

- ExtensionAttribute2:

    - Use for licensing.  This can be a single entry, string of characters, or a bitwise number.  Whatever you need for your environment.  You can then set up AAD Connect transforms to put people in O365 licensing groups based on this information.  Example: 'O365E5;TeamsConferencing;Visio;Project;NoYammer'

- ExtensionAttribute3:

    - Similar to Attribute2 but used for Admin group memberships

    - Example:  'Azure:GlobalAdministrator', 'O365:HelpDesk,Compliance'.  Etc, you get to define the names and associate those with scripts to put people in the proper role groups effectively controlling the membership of cloud groups with on-premises attributes.

I hope these ideas have helped.