Run profiles are one of the more straight-forward aspects of ILM configuration, however, like everything else, there are aspects that are not immediately obvious, and others which only become apparent through experience.
MAs have no run profiles initially – you have to create them all. You can call them what you like, and they can have multiple steps. I’ll look at the steps first.
Run Profile Steps
Delta Import (Staging)
Imports changes from the connected data source (CDS) into the connector space (CS), and no further.
The CDS must support delta imports:
- AD does this natively,
- SunONE LDAP will if you enable the retro changelogs,
- eDirectory will not support deltas,
- SQL, and other DB MAs, can if you create a delta table,
- I can’t comment on the others.
Full Import (Staging)
Import all objects and attributes, that the MA has been configured to see, into the connector space.
You must run a Full Import before you try and provision anything into the CS. In particular, if you are trying to provision into an LDAP-style CDS, the parent OUs must be present in the CS so that ILM can form the DN.
Delta Import and Delta Synchronization
Import changed objects from the CDS and then sync them to the metaverse.
Note that this differs in a subtle, but significant way, from creating a run profile with the two steps seperated:
- Delta Import (Staging)
- Delta Synchronization
In the combined steps, all imported objects are sychronized.
When the steps are seperated, only objects that have actually changed in the CS will be sync’d to the metaverse.
This becomes important if you want to implement something to force the re-sync of individual objects. If you seperate the steps, and the imported objects actually haven’t changed, then the sync will not occur.
Full Import and Delta Synchronization
Import everything from the CDS, then only sync changed objects to the metaverse.
Full Import and Full Synchronization
Import everything from the CDS and sync all objects to the metaverse.
Sync changed objects to the metaverse.
Sync all objects to the metaverse.
Export pending Adds, Deletes and Modifies to the CDS.
Note that there is no way to force an export of all objects – ILM will only export what is pending.
An Export must always be immediately followed by an Import, either delta or full. ILM does not consider the object properly exported until it has been confirmed by a subsequent import. Some people like to configure their Export run profiles to include both an export and an import step.
Run Profile Configuration Options
Create a new profile. Give it a meaningful name and click next. Choose the desired step. So far so easy.
The log file allows you to dump an xml file showing exactly what has been imported or exported. You have several options:
- Create a log file – I suggest you always create a log file on import and export steps. I have some complaints about the way they are overwritten each time, but see my post about keeping a timestamped history of the logs.
- Create a log file and stop the run – this is extremely useful when testing, particularly for exports. Rather than exporting to the actual CDS you can dump the export into the log file. By importing into Excel, and then mucking about with prettification, you can produce a picture of what will happen when ILM is allowed to proceed, to then be used in calming the nerves of any doom sayers who happen to be dogging your footsteps.
- Resume run from existing log file – finish the job of the previous option: pick up from the log file, and resume importing or exporting. This can be useful in test environments – you can actually tinker with the data before resuming, perhaps to simulate a particular scenario on your test server.
Note that passwords are not written to log files.
Number of Objects
You have the option of limiting the run profile to a certain number of objects.
Again this is mostly useful in test scenarios. One thing I like to do, when cautiously moving a new MA or bit of code into the production environment, is to create a run profile called “Export One”, which only exports a single object. (Although there is, unfortunately, no way to choose which object.)
Number of Deletions
A good safety net. ILM will stop the run profile if more than x deletions are queued. Rather than exporting up to x deletions and then stopping, it actually blocks the entire export (including any adds or modifications).
On sensitive MAs I will have a regular Export run profile which stops at, say, 10 deletions. Then I’ll have another one called “Export All”. If the deletes are expected, someone needs to manually kick off the “Export All” run profile.
I do think it is a pity that a similar block cannot be applied to particular changes. For instance, I would like the export to be stopped if more than a certain number of accounts are to be disabled. If you want to do something like that you need to find other ways using vbscript.
Management Agent Configuration
Initially you would just leave any settings on this page as default. You may find you need to increase the timeout if you are seeing connectivity problems to a domain controller or similar.
Run Profile Naming
Just a final point to make, on naming: Be consistent!
I don’t really care if you use “Full Import and Full Synchronization”, “FIFS”, or anything else you like – just as long as you keep it consistent between your MAs. It will save you a lot of trouble when you use MASequencer or vbscripts to automate ILMs tasks.