Updating the Remote Loader:

Novell Identity Manager is a complicated product, and it has fingers in many pies. (Always use food analogies, when possible, it makes people more interested!) An Identity Manager driver not only affects the eDirectory tree it is installed in, (The Identity Vault perhaps) it also directly affects the connected system to which it is synchronizing data.

To complicate things even more, an event in the Identity Vault (the center of the Identity Manager model) can cause events in many drivers at once. Even more complex is the case where one connected system, such as the Human Resources application (Like PeopleSoft or SAP), makes a change to a user, which progates to the Identity Vault, then each driver that has the attribute in the filter will generate an event to be processed to the connected systems. Tracing this can be a lot of fun!

There are two common ways to make the actual connection to the remote application, direct and remote.

• Direct, is where the shim (whether it is Java or native (DLL based) runs as part of the Identity Manager process (which is part of the eDirectory process).

• Remote, is where there is a remote loader running somewhere, and the engine makes a connection to that server. The Remote Loader on that server loads the driver shim (Java or Native) and connects to the application itself.

There are several benefits to running with a remote loader. The Remote Loader has fairly low overhead, and is easier to troubleshoot on its own, than when part of the Identity Manager engine server. It takes load off the Identity Manager engine server, which can be a good thing. It also allows more options for handling machine security to the application. For example, it may be that only a machine on a specific network or VLAN can connect to the application for security reasons, and it makes no sense to place an engine server on that network or VLAN.

Communication between the Remote Loader and the engine can be SSL encrypted (or not) to provide transport security.

One major benefit of the Remote Loader model, is that when updates to the shim are needed, it is just the Remote Loader process that needs to be restarted. Whereas in Direct mode, if it is a Java based shim, then to get Identity Manager to read the new JAR file provided by the update, you would need to restart eDirectory, which can have serious impacts on the production environment.

The Identity Manager instance runs inside the eDirectory application, in the eDirectory memory space, the Identity Manager application reads all the various classes in the path and does not look at them again, until it starts the next time. The eXtend Composer tool set is a great example of one type of driver where you have to run it Direct (a JAR file on the Identity Manager engine server) and doing development is a royal pain, since every time you fix something in the JAR file during development, you need to redeploy the file, and restart eDirectory. In fact it becomes easier to stand up a new replica of eDirectory just for this one instance than pretty much anything else.

Thus running Remote can be very powerful, when it is an option.

It turns out there are actually several kinds of Remote Loaders available for Novell's Identity Manager product. You should probably read this article, http://www.novell.com/communities/node/2994/many-faces-remote-loaders-idm about the many faces of the Remote Loaders, to get a better understanding of what the options are.

For the sake of simplicity, we will discuss two basic kinds here, the Windows based Remote loader (imagine the Active Directory driver) and a Unix like operating system (Linux, Solaris, AIX, HP-UX, whatever) based remote, say the JDBC driver. The Bidirectional drivers, (Midrange, Mainframe, Linux/Unix, Scripting drivers), use a more monolithic design for the Remote Loader, and basically just reinstall is your only real option. Well maybe not for the Linux/Unix driver, since you probably need to modify some of the scripts that do the work. But that is an entire topic for another article. We will focus on the more common examples of a Windows based Remote Loader and a Unix platform based Remote Loader instance.

There are three major parts to a RL update.

1. The Remote Loader application itself. This is mostly a series of Java classes and some native libraries. On Windows this includes the GUI you see, which is really just an interface to control the Remote Loader instances. There is more underneath, but this helps identify the widget.

• The driver shim itself (mostly addriver.dll in the AD driver case, but often some Java classes as well)

• In the case of the AD driver specifically, the Password Sync Applet.

Running the installer on the server running the Remote Loader will update all three components, and for a new release of the product (say when Identity Manager 3.6 is released sometime this coming quarter) this is probably your best bet.

Patches usually update one piece of either component. I.e. Maybe a new addriver.dll or a new rl_console.exe. There have been several patches for Identity Manager 3.01 and 3.5 so far for each of these cases. Some patches consist of a new Java class, like JDBCShim.jar for example. There was a patch to fix a state file issue, and it turned out it was a third party class that was leveraged, so while the core driver class did not change, it required an updated support file to be deployed. One thing to watch out for is that some driver shims expect certain parameters in the driver configuration, deployed in the rule set. If that is the case, you would catch this by trying it in the test lab first (you have a test lab, right? Of course you do! If you don't, start working on one so you can test things like this in it!!!) and the dead giveaway would be once you have updated the module on the Remote Loader server, and restarted the Remote Loader service, then trying to restart the driver from iManager. If there is a missing attribute in the driver config, usually the driver trace will show a fatal error with the detail of the missing attribute.

The last one, #3, the Password Sync applet pretty much requires running the install. (Though Lothar Haeger has an INF for applying the update on the other DC's by itself, which is easier than running the installer on each DC, that you can find on Cool Solutions in the Cool Tools section.). One of the issues with the Password Sync service is that the Remote Loader server has a Control Panel applet (.cpl) installed that can make RPC calls to the various other domain controllers in the AD domain and push the file and registry setting, and finally, if desired, reboot the remote domain controller. There seemed like an issue with the release of Identity Manager 3.5 that the updated Password filter DLL was not properly being sent out. Thus the need for a separate installer on each remote domain controller.

The other major downside is that each domain controller in the Active Directory domain will require a reboot to start using the new DLL file.

In the case of a patch that just includes a new DLL, JAR, or rl_console.exe you can usually just copy the file to the correct location and restart the Remote Loader. Nice and easy.

Some of the patches for the Unixlike operating systems will come as an RPM that needs to be installed.

So when time comes to upgrade your engine to a new revision, a common question is, do I have to update my remote loaders at the same time?

In general the Remote Loader Java classes have not changed all that much between versions of Identity Manager, so an update the remote loader Java classes is not usually that big a deal.

In general the Remote Loader application for Windows has not changed all that much either, as it is really just a GUI shell around the Java classes.

The actual driver module (DLL or JAR based) is what does much of the actual work in the remote loader. Within versions of Identity Manager, the module can usually just be replaced and the Remote Loader restarted. The major point to watch out for is that the Activation credential used for Identity Manager is based on the version number that the driver shim (Remote or Direct) returns. When you load the IDM 3.0 or 3.5 addriver.dll and it connects to the engine, you need a matching activation credential to properly activate it. While you should never do this in production, if you ran a addriver.dll that returned a version string for 3.51 on a 3.01 engine, with the activation credential for Identity Manager 3.0 including the Active Directory driver, you would still get only 90 days before the driver would shut itself off.

The Remote Loader patches for Unix like operating system can come as JAR files (obviously not as DLL's, that is a Win32 format only) that need to be patched in basically the same way. (Copy the JAR to the correct directory, and restart the Remote Loader, (usually "/etc/init.d/rdxml restart" or the like command)) Some patches have come as RPM's for the entire Remote Loader that need to be installed as a package.

Overall the key point is that the remote loaders are pretty easy to update, and aside from special cases like the Active Directory Password Sync filters it is pretty simple and low impact to do the updates.