Run Profiles

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:

  1. Delta Import (Staging)
  2. 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.

Delta Synchronization

Sync changed objects to the metaverse.

Full Synchronization

Sync all objects to the metaverse.

Export

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.

Logs

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.

About: Carol

I've been doing IT for 30 years, and IdM for 15. I live in Australia and build IdM solutions based on Microsoft Identity Manager. I also play the violin, but that doesn't help much with the IdM solutions.


11 thoughts on “Run Profiles”

  1. Could you please explain the difference between using “Delta Import and Delta Synchronization” as compared to using “Delta Import (Staging)” and “Delta Synchronization” together, with the help of an example?

    Like, if out a total 10 obects in CDS ony 5 objects actually changed (hence the delta table containing only 5 records), how would the two approaches have different affects at the end?

    btw, i loved your posts ever since you gave me the link on technet i have been reading them all day! as a newbie i couldn’t have found an easier blog to understand MIIS/ILM !!!! thank you so much!

  2. In a DIDS only the objects imported as part of the delta import are actually sync’d.

    If you run the delta sync as a seperate operation MIIS will sync *all* objects in the connector space that have changed. In reality this may give you exactly the same result, however it will be slower as it has to check the whole connector space. Normally it is preferebale to do a DIDS as a single step.

    Glad the blog is helping!

  3. got it, thanks! one more question…. you mentioned…

    “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.”

    i wasn’t able to understand why an Import has to follow an export. Doesn’t the ILM already have all the objects since it is the ILM which is “exporting” it to CDS? also, what kind of “import” is required: full or delta? what difference would it make?

    thanks again!

  4. The export is not considered confirmed until a subsequent import has proved the change really was applied out in the connected directory. ILM knows what it sent out there, but you get all sorts of situations where the change does not actually get applied due to reasons outside ILM’s control – group policies, database triggers etc etc. ILM will then report this situation with an “expoorted-change-not-reimported” error.

    As for the confirming import – it can be either delta or full. Delta is always preferable for performance, though it is always good to do a Full Import at least once a day if you can, just to make absultely sure ILM still has a full and correct picture of the outside world.

  5. for the sake of understanding, can the “export” profile be considered as inherently of “Delta Export” type exporting only the “pending changes” like pending adds, updates & deletes only? since as a result of the very first export run, all objects in target CS would be pending “adds”, the delta would actually be the whole set of objects in CS. for consecutive runs though, the delta would typically be smaller in size containing pending adds/updates/deletes.

    If this is true, can’t we simulate a “full export” by manually deleting all objects from both the destination CS as well as its CDS?

  6. Yes an export is always a delta export unless, as you say, you delete everything from the CDS.

    To understand exactly what is going in an out of the CS use the log file options of the run profiles to create a full log of all exported/imported objects.

  7. If the MA doesn’t support it natively then no. Mostly when working with SAP I have passed the data through a SQL database, allowing me to generate my own delta table.

  8. So if I use BAPI from SAP through ERP MA then it will be impossible for me to do DI, is that correct?

Comments are closed.