"Someone's knocking at the door, somebody's ringing the bell" ... As a traveling consultant, much like a traveling salesperson, I am often knocking on doors, introducing myself and offering up my services to customers. In the course of doing any GroupWise project, I have to get to know the GroupWise system I am working on - personally. I don't just kick the tires, I crawl up under the hood, squeeze in tight places and take a look-see. I have to take the whole-sum approach - top down design to last-stop server NIC's - all the layers in the OSI 7 layer cake ... er, model. Once I have done this, then I feel I can work with a customer's GroupWise system from a position of knowledge. To do any less would be negligent to say the least.
One of my checks along this GroupWise review process stops in the ConsoleOne| Tools| GroupWise System Operations| eDirectory User Synchronization Configuration. I am looking to see if eDirectory user synchronization is properly configured, and sometimes to see if it's configured at all. It seems obvious what eDirectory user sync does - it synchronizes user information from the eDirectory object to the GroupWise object. Look at what Help says about it:
Figure 1: eDirectory User Synchronization Configuration Help
History and Experience
GroupWise, just like eDirectory, is a database system. GroupWise has its own directory, if you will - GDS. Each GroupWise object is in the GDS and has its own set of attributes, such as Given Name, Last Name, and phone number. But to manage GroupWise, it has to be linked to eDirectory. This means that objects created in GroupWise will have like objects in eDirectory. Basically, they share an object, and GroupWise gets its own 'tab' within that object called 'GroupWise'. It does go a bit deeper - but let's just agree that attributes in eDirectory are used by GroupWise and vice versa.
Enter the GroupWise Address book.
Have you ever changed an attribute on an eDirectory user - such as phone number, and then gone to the GroupWise Novell System Address Book and found the change was updated? That's where ConsoleOne with GroupWise snap-ins comes in. But I am sure you have done the same process, and from time to time the change did not show up. So you ran back to ConsoleOne, did a right-click on the user object, selected GroupWise Utilities and Synchronize. Then the change appears. It's like magic!
As a nightly routine, it is considered Best Practice to have eDirectory user sync run at least one time every 24 hours in order to keep GroupWise and eDirectory in sync with each other. Some organizations prefer it run more often by using an 'interval' setting for the MTA Scheduled Event. Their reason might be Identity Management driven. As Identity Manager (IDM) runs, it updates eDirectory objects and that may require updating GroupWise as well. Unfortunately, that 'interval' feature is no longer working in the current snap-ins, nor is it available. Therefore we are stuck with once every 24 hours. This is my recommendation.
Anyway, in nearly all of my customer visits I have found any or all of the following eDirectory user sync situations:
So, I thought it was time I wrote about it. Here we go!
Configuring the MTA
First off, you need to have an MTA that can access eDirectory in order for eDirectory user sync to work. I vote for the Primary MTA. Why? Simple - it's the authoritative database and domain for the entire GroupWise system. What better MTA is there to sync GroupWise/eDirectory? Also, I prefer the Primary MTA to handle all eDirectory user sync and push down the updates to all other domains. There are a few reasons for this:
In order for an MTA to access eDirectory one of two things is needed. Either the MTA must reside on a server that has an eDirectory partition - preferably [root] or the one that has all the users in it - or it must have the ability to log into eDirectory. This last one requires you to do more work. But often times administrators do not want eDirectory replicas running on GroupWise servers. Why? Two reasons: 1) Clustered servers (nodes) have no need for replicas, and if the node goes "belly up" the last thing you want to do is deal with eDirectory; and 2) Others want their GroupWise servers to do GroupWise and eDirectory servers to do eDirectory.
This article would be very short if I just said, "Place the Primary domain and its MTA on an eDirectory replica server, and you are good." I will assume you have not done so and need some additional help.
1. Create a new eDirectory user and give him some rights to your tree. I like to call the user "MTALOGIN", and I like to create the user in my eDirectory GroupWise container where I hold all my other GroupWise-related objects.
2. Don't forget to give the user a password.
Once you have created the MTALOGIN user, then you need to assign rights.
3. Right-click on the [root] Tree object and select Trustees of this Object.
4. Add the MTALOGIN user as a Trustee of [root].
5. Assign [All Attributes Rights] and [Entry Rights]. See the two figures below for the correct rights.
Figure 2: Compare, Read with Inheritable [All Attribute Rights]
Figure 3: Browse with Inheritable [Entry Rights]
Now that you have rights, it's time to work with the MTA configuration file.
1. If you are running the MTA on NetWare, go to the Primary domain MTA screen and press F10. If you are running on Linux or Windows, go to the directory where the MTA configuration file is located and open it with a text editor.
2. Once the MTA configuration file is open, browse down to the /tracelogin- switch.
3. Un-remark it and place "2" in the value. This will activate the login trace information for the MTA. You will see this information in the logger screen on NetWare.
4. A bit further down, go to the /user- and /password- switches and un-remark them.
5. Place the user name and password in the value section. Make sure you use the fully distinguished name, as seen in the figure below.
Figure 4: Setting Trace Login and User/Password in MTA Configuration file
6. Save the MTA configuration file.
7. Unload and reload the MTA to make the changes active.
8. As the MTA is loading, switch over the the Logger screen on NetWare and you will see the MTA make its connection to eDirectory effectively giving it access.
Figure 5: Logger Screen MTA Login to eDirectory
FOR FUN - I'd like to show you what happens when an MTA tries to log in but cannot because it has no rights to eDirectory. Try this:
1. Go back to the MTA configuration file and remark out the "/user-" and "/password" but leave the "/trace-2".
2. Reload the MTA and go to Logger. You will see the MTA try to login to eDirectory and fail (assuming, of course, it is on a non-eDirectory replica-holding server).
If you made it this far, hang on because we are just about halfway through. We now have to take a trip to GroupWise System Operations.
1. Connect to the Primary domain.
2. Go to Tools > GroupWise System Operations > eDirectory User Synchronization Configuration in ConsoleOne.
Once there, you will see all your domains. You will notice that each domain MTA is assigned to do its own eDirectory user sync. We will change that. You may also notice that STATUS is ENABLED on the Primary MTA but not on the Secondary MTA's. We will work with that as well. Now your mileage may vary here. You may see the Primary domain as DISABLED, or any combination of this. No worries - we are going to set it all right.
Enabling the MTA
The next step is to ENABLE the Primary MTA so that it can do all eDirectory user sync for all domains.
1. Select Configure Agents.
2. Highlight the Primary domain MTA and on the right side select ENABLE.
3. Highlight any other domains, individually, that are ENABLED and set their status to DISABLED.
It's in this screen, by the way, you will notice the eDirectory Access is YES. If the Primary domain MTA, which we just changed is NO, then something is amiss. You may need to revisit the Trustee rights of the user we created to make sure they 'stuck'. Or you might have to sync the user, although this is rare.
4. Now that you have enabled the Primary domain MTA, click OK to return to the main screen.
Now you need to Change Assignment for all the other domains, so they are serviced by the Primary MTA.
4. Highlight a domain you wish to change.
5. Click Change Assignment.
6. Choose the Primary MTA in the Agent column and click OK.
You will see the Primary MTA has been assigned to the secondary domain under the 'Synchronized by' column.
7. For the remaining domains, 'rinse, repeat, rinse, repeat' ... in other words, just repeat the process. When you are finished, it will look something like the figure below.
Figure 6: Primary Domain MTA -DOM1- doing eDirectory User Sync for all domains
Setting a Schedule
That takes care of sync configuration for all domains. Next up, we need to set a schedule to have the process run.
1. Connect to the Primary domain and set the object selector for MTA to show the MTA of the Primary.
2. Right-click the Properties of the Primary's MTA and select the GroupWise tab and the Scheduled Events window.
3. Highlight the 'Default NDS User Synchronization Event' and click Edit.
At this point, you just need to set a time to have the Event run. 1:00am is the default and as long as that works for you, just save it.
Figure 7: MTA Scheduled Event eDirectory User Synchronization
4. The final step in setting this up is to go to each of the other domain MTA's and de-select the 'Default NDS User Synchronization Event'. Do not delete it. If you do, it deletes it system-wide. That's it - you are done!
Tips
But wait - a few tips:
Figure 8: MTALOGIN User Description Attribute
Figure 9: Rebuild Indexes for Listing to refresh the System Address Book
To summarize, by getting eDirectory User Synchronization set up in your environment you will assure timely synchronization between eDirectory and GroupWise. This will keep the GroupWise system address book up-to-date with user attribute values. And with a little luck and this article, you will be able to "Let'em in" to the organization's address book with confidence that contact information is current.
As always, I can be reached at: Gregg@HinchmanConsulting.com , if you have any comments, article ideas or just want to help a quirky consultant support his GroupWise habit.
Support
Documentation
Learning Services
Partner Programs