Been on-site with a new client the last few days and as I was trying to get to grips with how their environment is configured, the importance of descriptions hit me (again!) It’s something I try to get through to everyone I work with, and it is by no means restricted to things in AppSense. Whether it’s an AD group, a Group Policy Object, a Citrix policy, even an OU – putting a good description in helps people follow your work, and avoids them reinventing the wheel, and causing unnecessary disruption to users.
The problem that raised this point into my head was an issue some users complained of, that they couldn’t type into the address bar in IE. Straight away that sounded like an Environment Manager lockdown object to me, and sure enough, digging into the EM policies revealed an object similar to this:-
Now straight away the class name suggests to me that this is the problem, but that’s not the full story. Why was this lockdown configured originally? Maybe there was something it was intended to do and it has been accidentally misconfigured. If I was simply to remove it, I might receive a further support call describing a restriction intended for users that has now been removed, and that needs to be redeployed ASAP. However, when looking at the General tab for any notes or pointers, all I see is this:-
The fact of the matter is that taking the time to provide a good description in the General tab of the Lockdown item would have allowed me to assess what this lockdown item was intended to do, and if it has accidentally exceeded its scope. Without this, all I could do was disable (rather than delete) the item, and if this caused an issue with allowing users to do something they shouldn’t, I could then re-enable it and alter the scope as necessary. This trial-and-error method always takes time, and time is usually something us IT bods don’t have the luxury of a lot of.
Some things in EM are fairly self-explanatory, like drive mappings, printer mappings and shortcut deployment, but Lockdown items, self-healing items, scripts and custom executions in particular, benefit greatly from a good description detailing exactly the scope and scale of the issue you are trying to rectify/avoid/initiate. As I said earlier, this sort of good practice is by no means confined to one piece of software. In any situation where you are configuring things that others may have to follow in future for troubleshooting purposes, no-one can ever accuse you of overdoing things in the Description fields provided.
My time with this client is providing some interesting challenges for the AppSense suite, so hopefully we should have some good material coming up in the next week or so – hope that the software is up to the job!
Share
