Change Tracking is a Client-Side Feature - Implications on Deployment

Today, I'd like to go over a major Change Tracking design aspect:

Change Tracking is a client-side feature - it runs only inside the ISA COM (and management console - MMC).

That's right. Change Tracking does nothing on the ISA Server itself, and nothing on the CSS. It does its job only on the ISA MMC and other users of the ISA COM/automation interface (scripts/etc). The rationale behind this decision is that the client side knows much more about the changes, and can produce more meaningful description than the server side (CSS or ISA registry).

This has both good and bad implications:

Good: Installing any update on your production, mission-critical server is something you want to plan carefully, test before, etc. But you can use Change Tracking before that - just install a remote management console with SP1, enable Change Tracking from it, and then any changes made from that console would be tracked, and be viewable on that console! Then you can proceed to install SP1 on the server at your leisure.

Bad: If someone, somewhere, is managing your server from a pre-SP1 console, then his changes will not be tracked. There's no way to block access for such consoles - sorry.

Good: Change Tracking can log client-specific information, such as management machine name, and command-line of the application making the change. This is why you see script name and parameters in entries made by scripts.

Bad: Change Tracking log is as reliable as the management console computer. Anyone with sufficient permissions can spoof the log in a number of ways.

Such is life - every design decision is a trade-off.

-Jonathan Barner, ISA Sustained Engineering Team