NOTE: This is the first is a series of articles I am writing as my organization moves from using IBM Domino to Office 365.
For those who are moving from using IBM Domino as their email and directory, there are a number of things that one needs to think about for their Active Directory environment. If you have had AD and Domino in the same environment, most likely you have invested more time to make sure your Domino directory is updated with what I like to call rich contact information. This includes details such as address, telephone number, managers and work location. When you begin to move to O365, it becomes important to make sure that AD now contains this same rich information.
Directory Cleanup
One of the first aspects to look at is what information you want to store in AD. Some of the most obvious pieces of information to store is basic address information:
- Street address
- City
- State/Province
- Zip/Postal Code
- Telephone number
- Mobile number
This is basic information related to the user’s location. In addition to this information is other information related to their job:
- Employee number – This field allows us to tie an employee with our HR system.
- Employee type – We mark this field to denote what kind of employee/account this is. We use EMPLOYEE, VOLUNTEER, TEMPAGENCY, OFFICER, RETIREDOFFICER and POSTRETIREMENTSERVICE as an example.
- Manager – The manager field becomes more important as we move to O365 as there are many views in O365 that expose our relationship with our manager and others in our corporation.
- Job title – This is the job title of person.
- Officer ID – This is an additional tie we have to other external systems for a subset of our users.
Finally, there are some that are more specific to their location and where it fits in the corporation:
- Department
- Company
- Office/Location
Domino adds to this last section something that is also interesting. It is called corporate hierarchy and allows you to set the corporate hierarchy up to six levels deep and across multiple job descriptions. Because we are part of a large international organization, we have worked on setting these fields with that in mind. Here is how we have used these:
- Corporate Hierarchy 1 Level 0 – We use this to denote our Territory’s name.
- Corporate Hierarchy 1 Level 1 – We use this to denote the division or command.
- Corporate Hierarchy 1 Level 2 – This shows the area command (if a location is part of an area command).
- Corporate Hierarchy 1 Level 3 – The physical location where a user is located at.
- Corporate Hierarchy 1 Level 4 – The department or role that the user is in.
AD doesn’t have those corporate hierarchy fields, so we decided to create a custom schema to add those attributes, along with some other attributes to assist with our AD/Domino co-existence. Here are the custom fields we created in AD to match us with Domino:
- CorpHierarchy1Level0 – 6
- CorpHierarchy2Level0 – 6
- DominoAbbreviatedName
- DominoDN
- DominoMailFile
- DominoMailServer
- DominoSync
Creating the fields and having them available is one thing, but populating the data is a whole other challenge. It is also a challenge to get the data in there in a consistent manner. For example, is it “Street” or “St.”? To help us with consistency in this area, we created location groups in AD. For each location (we have over 780 different locations), we created a group in AD associated with this location. This will allow us with other initiatives to grant access to users based upon their location, as well. Tied to these groups, we also tied in the address information, as well as the ability to create the corporate hierarchy. There are a couple of ways to do this. One way would be to put the address information directly into the group (using custom fields) or have a database that is tied to all of your properties that contains the proper location information.
Once we had the location groups created, we started assigned each user to a location. I have also implemented a front-end process so that whenever a new user is created, a location (among other data) must be assigned. This now enables us (using PowerShell, of course), to stamp critical location information to each of our users based upon their group membership. Now, we can stamp our users either when they are created or later if they have been around for awhile with the correct address and corporate hierarchy information.
This helps us get some of our vital corporate information on our user accounts. Manager hierarchy is another important area, so we have worked with our HR to get an employee’s manager. The best tie we have to our HR system is the employee number. We have found this to be the best solution as we have many users who don’t go by their full legal name. Whether it is that they use a middle name as their primary name, a shortened version of their given name or even something totally unrelated to their given name, but the only way people know them, the employee number is the definitive tie.
If you already have much of this rich information populated in Domino, the quickest path will be to sync your AD and Domino environment and get that rich information over to AD. I’ll discuss later the process we use to sync our directories. As part of this process, it is also important to identify your directory of record. Is it going to be AD or Domino or will it change over time? Much of this depends upon the tools you provide for users to update their information. We have made AD our primary directory and provided tools to allow our users to update limited subsets of information about themselves.