I had an interesting chat with an ILM collegue the other day, and one of the topics that came up was whether you should ever, under any circumstances, call external processes from extension code.
The prohibition on calling external processes from provisioning (MVExtension) code is clear and well accepted (see the Calling External Processes section on this technet page), so what we were actually talking about was extensible MAs.
The way it came up was this: I was showing him my Techdays presentation, part of which includes a demo where I create personal websites in IIS as a way of saying “Look! It’s not just about user accounts!”. I do this pretty simply by running the iisVDir.vbs script which comes with IIS 6, using the /query option as part of my Import routine, and the /create and /delete options as part of the Export. (MVExtension code, CSExtension code)
Now my collegue said that he would never use ILM to run any kind of external process, because it slows down the system too much. He would just provision lines into a SQL table and then configure something external to ILM to pick up the rest of the work.
So in my IIS example here we’d just have ILM writing lines into a table, and then perhaps a scheduled task checking the table periodically, running iisVDir.vbs for anything new, and then updating the status once the code had succesfully completed. ILM would then import the “done” status back in and everything’s happy.
The advantages of this method are clear:
- Speed and efficiency in ILM – it’s very, very good at creating simple objects like lines in SQL tables, and will whip through these without a moment’s hesitation,
- Simple to set up – no need to delve into extensible MAs, just a simple SQL MA and a vbscript to run the external bits,
- Efficiency again – you can offload the external part of the process to another server to share the workload.
I have, in fact, used this method before – like when I used Exmerge to archive mailboxes, as it would have slowed the whole sync cycle down unacceptably if I’d had to wait for Exmerge to finish every time I ran an Export. I also used the same method for sending “account x created” emails – writing a line into a SQL table once an account creation was confirmed, and leaving the emailing part up to another server.
But I’ve also written XMAs where I do call external processes. As well as the IIS example above, I made an XMA to create and then archive Netware home folders. Folder creation, zipping and deletion was all done straight from the CSExtension code (with the help of an archive library and some command line stuff for setting the ACLs). The create side was pretty fast, and the archiving wasn’t too bad either – except on the occassions when a couple of hundred folders were going at once (this was a university) and then you started to see a big impact on the rest of the syncs.
So what are the advantages of calling these external process directly from the CSExtension code?
- Imports are closer to the source – I like the idea that the import step should be going and discovering what is really in the data source, and not just reporting on the contents of a SQL table.
- As long as the code in the export step is not adding too much of a delay, you should have linked objects created more closely together – for instanace a user account and its home folder.
- If there’s a problem with the external process, and it’s stopping your other sync activity, you’re going to pick it up very quickly. Note this can also count as a Bad Thing!
I guess my conclusion is that my collegue is almost cerainly right for large installations, where there are a lot of objects, or MAs, or both, and sync times are an issue. But for a smaller installation, or for external processes which are quick and light to run, I see no problem in calling them directly from CSExtension code. After all, that is what XMAs are supposed to be for!
