This is part frustrated (mild) rant, part helpful hint and like the title says: part public service announcement. While I am most definitely a glass is half full kind of person, and I don’t get stressed out much or phased by pressure much, I, like anyone, do get annoyed with certain things. Let’s start with a quick vent before continuing on with the public service announcement.
Rather then just have a rant or a whinge, let me explain the situation and by doing so I’ll most likely vent some frustration.
Deploying a Hybrid Exchange environment to integrate with Exchange Online in Office 365 can be a behemoth of a task if you lack certain things. While anyone can say any number of criteria or list off important considerations, pre-requisites or requirements, I feel that there is only one thing that needs to be addressed. One thing that sticks in my mind as being the foundation of the endeavour.
Just like the old saying goes “you can’t build a strong house on weak foundations”; the same applies to that initial journey to the cloud.
I say initial journey, as for many organisations that first step after setting up a website, which can be the beginning to being a cloud-focused organisation, Office 365 is truly the first step to move infrastructure, process and systems to the cloud that I see happen the most.
Importantly though is to realise that as amazing and full of features as Office 365 is, deploying a Hybrid environment to leverage what I consider the best of both worlds, a hybrid identity, all that matters is the existing Active Directory Domain Services (ADDS) environment. That is ALL THAT MATTERS.
Step aside Active Directory Federation Services (ADFS) and Azure AD Connect (AADConnect) or even Hybrid Exchange Server 2016 itself. All those components sit on top of the foundation of the existing identity and directory services that is the ADDS environment.
ADDS is so crucial as it key link in the chain, so much so that if it has issues, the entire project can easily and quickly run into trouble and delays. Delays lead to cost. Delays lead to unhappy management. Delays lead to unhappy users. Delays lead to the people working on the project going grey.
I remember a time when I had blonde curly hair. I grew out of that and as I got older my hair darkened to a rich, chocolate (at least 70% cocoa) brown. Now, as each project gets notched on my belt, slowly, the slick chocolate locks are giving way to the odd silky, white sign that there’s not enough emphasis on a well-managed and organised ADDS.
The 7 key things to know to maintain a healthy ADDS for a smooth, thick and colourful mane
1) Folders and OUs are great, but too many leads to over organisation
I was told a long time ago that Microsoft itself kept a very simple and streamlined OU structure, even keeping every user in a single OU (not sure if that’s 100% true or not but I’ll consider it fact unless I hear otherwise). Having multiple upon multiple levels of folders for the sake of “organisation” and/or arrangement will bite you later when you need to migrate and sift through OU after OU via exported data in the form of Excel spreadsheets when a simple structure could have been implemented.
2) Naming conventions
Uniformity is not the plague of sameness in all circumstances. Naming conventions is one of, if not the most important, consideration for maintaining a healthy ADDS. Settling on conventions like “first initial.last name” for usernames or adding prefixes to different types of groups not only makes searching streamlined, but, also a streamlined administration with processes and procedures that follow these conventions are able to be reproduced quickly and efficiently.
3) Invalid characters
Further from naming conventions is choosing to use or not to use invalid characters. Ampersands (&) are convenient in certain circumstances, but, in a cloud world this character poses problems. Best to avoid any non-alphanumeric characters to open up more opportunities for future expansion of ADDS through integration with public cloud. Sidebar – Although an RFC ratified the use of “&” in email aliases, I’d still avoid them, if only to not have any potential issues with legacy mail systems.
4) Domain name
A non-routable domain name is the standard used in most cases. Nothing too difficult here and these are not a bad thing. However, flat top-level or single name domains, for example “ENTERPRISE”, rather than enterprise.local or enterprises.com, is compatible with an on-premises and enclosed ADDS. Expand that out though and there are compatibility concerns with more than just cloud platforms as some on-premises applications and systems may struggle as well.
5) Group management
Selecting the correct group type for the correct purpose is self explanatory. Mixing and matching different group types to serve duel or multiple purposes is also possible. The problem is maintaining records and knowledge of the purpose or the multiple purposes of the group. Joining up security and mail enabled groups roles into a single group can be streamlined at first, but, when there’s tens of thousands of groups, this type of management of groups means headaches for migration or transition to the cloud down the track. Separate out the different scopes to allow for quicker and more streamlined migrations.
One of the most frustrating and infuriating things is duplication. Here I’m not just talking about having multiple groups or users with the same purpose, rather, I’m talking about multiple users sharing common attributes. Setting an email alias, for example, on user A, forgetting that, and setting the same on user B. Yes, I’ve seen that many-a-time for not only users, but groups and contacts. The whole process to get these objects AADConnect sync’ed to Azure AD turns a simple exercise into a day-long needle-in-a-haystack event in order to rectify the problem(s) to allow these objects to be replicated to the cloud.
7) User management
In some organisations, user turnover is higher than others. User turnover in any case needs to be addressed quickly and swiftly as disabling users or not decommissioning correctly leads to problem 6 (duplication of attributes). It leads to AADConnect sync issues and ultimately to the burning of time that is the most finite of resources.
Italian food is by far my favourite. There are always simple ingredients cooked simply. The flavours carry over and are more intense than certain foods with many, many ingredients. The same methodology should be considered with ADDS. Less is certainly more. Structure, process and procedure and keeping the various aspects streamlined leads to a better project experience for not only customers, but, consultants and project managers undertaking the endeavour.