Designing Azure AD can be complex if we’re leaving local AD. We need to make sure we have naming conventions in order. What about our devices like printers, where will they go? Here we will go through the designing phase of our series.
Designing Azure AD
From Part 1: Our companies are going to use the same tenant, and they all have their own IT environments. In other words, they all have their separate IT environments.
As of now, Azure AD has a flat OU structure. This gives rise to support and naming conflicts. Which is also the reason Azure AD Connect is so picky when it comes to conflicts…it just can’t handle them when exporting to Azure AD. In our scenario we need to be aware of this problem when designing Azure AD. We need naming conventions that work for all our companies.
We need to develop a naming convention for all companies being migrated into this one tenant.
- Office 365, Distribution and Security Groups
Some companies like to use domain\e251301 – Which doesn’t make much sense to the user, but some legacy system requires it to work at all.
With Azure AD we won’t have that problem, and Microsoft encourages you to use UPN = Mail = SIP.
We will also use this for our migration. Every user should be changed to: First.Last@contoso.com
What attributes should we add? In this scenario, the more the merrier. We need to have a fleshed out Azure AD so that we can easily see which Country/Company/Department/Etc the user is located at.
First the basics, what is the bare minimum that Office 365 can use to create users?
||User Display Name|
That’s it. That’s all you need to create a user.
Let’s add more information though:
|FirstName||User First Name|
|LastName||User Last Name|
|UsageLocation||Office365 needsto know this. So that it can assign the closest datacenter to you. Uses CountryCodes E.g: US.|
|LicenseAssignment||Assign a license on the user – Use Get-MsolAccountSKU to get all licenses|
|ProxyAddresses||Set by Exchange Online (Same as UserPrincipalName)|
We are dealing with several companies located in several countries.
Having the “Keep it simple”-mantra in mind, I’m recommending a simple Country.Company.Usebase
For instance, all users in a company based in France (Contoso France) will be: FR.CON.All
Management-group for a company based in Norway (Adatum Norway) would then be: NO.ADA.Management
Having a good naming system will also ease the work of the sysadmins. They can just search on Country.Company and they will find all relevant, and can create a new group if desired. This is what designing Azure AD is all about.
The same applies to Distribution groups.
We need to keep it as simple as possible and as functional as possible.