Office 365. Grrr. 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 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.
It’s so crucial that with so many links in the chain that the entire project can easily and quickly get disjointed causing 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.
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 “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.
Uniformity is not the plague of sameness in all circumstances. When it comes to naming conventions its one of, if not the most important considerations for maintaining a healthy ADDS that’s required for a smooth transition to Office 365 and hybrid identity. Settling on conventions like first initial.last name for usernames or adding prefixes to different types of groups used 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.
Further from naming conventions is chasing 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 set of characters to open up more opportunities for future expansion of ADDS like integration with public cloud. Sidebar- Although an RFC ratified the use of “&” in email aliases, I’d still avoid them to not have any potential issues with legacy mail systems.
A non-routable domain name is the practice to use 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’s compatibility concerns with more than just the cloud but certain on-premises applications and systems as well.
Selecting the correct group type for the correct purpose is self explanatory. However, mixing and matching different group types to serve duel or multiple purposes works. Sure. 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 10s 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. Not having multiple groups or users with the same purpose, rather, 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 synchronised to Azure AD turns a simple exercise into a day long needle in a hay stack event to rectify the problem(s) so these objects are replicated in the cloud.
In some organisations user turnover is higher than others. User turnover in any case needs to be addressed quickly and swiftly. Disabling users or not decommissioning correctly leads to 6) duplication of attributes. It leads to AADConnect sync issues and ultimately time that is the most finite of resources.
Italian food is by far my favourite. There’s 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.