One of the simplest use cases for the AppSense EM Self-Healing feature is to restore desktop icons. Now, if you wanted your users to not make any changes at all to their desktops, you could always create a fully locked-down desktop as detailed here. However, for most enterprises, that level of lockdown is inappropriate for their needs and would possibly create bad feeling amongst the user base. But there’s still the problem of users inadvertently deleting icons for applications from their desktops or Start Menus. Sometimes they’ll have to put a call in to the helpdesk to get them back, and that can be time-consuming, or perhaps even not possible dependent on the user’s location or current disposition. But how can you let them create and remove their own folders and shortcuts, yet still be protected from accidental deletion of application icons?
Self-Healing is the answer, by monitoring specific files for changes and disallowing them, but it’s not just limited to monitoring files and folders. You can also self-heal processes and Registry data. First, we need to decide where to place our Self-Healing Action. If we were monitoring for changes to a Registry key that referred to a specific application, we could save processing time by putting the Self-Healing Action inside a Process Started trigger. However, as we are going to be dealing with a desktop icon specific to a user, the appropriate trigger to use is User | Logon. First we’ll create a node within here called, imaginatively, Self-Healing.
Next, as usual, we’ll create a condition to ensure this Action doesn’t run for anyone but the users we want it to. As this is a simple example we are putting together, we’ll exclude local Administrators from the Action by using a Condition of Administrator = False
Next we add our Self-Healing action into the Condition, choosing Actions | Self-Heal | Self-Heal File. Note that you can’t yet Self-Heal files on a network share, only on the local machine. Perhaps the ability to self-heal remote files on network drives might make it into a future release of EM?
We will demonstrate this using a shortcut to Internet Explorer, but you can obviously put any file you want into the Action. You can select whether the file is always present (which is the option we want), or never present. When selecting always present, you also have an option to prevent the file from being changed, which we have also selected here.
Next we simply need to save and deploy our new configuration, and wait for it to propagate to our test server (or, if you’re impatient like me, just use the Poll Now function in the Management Console, or restart the AppSense User Virtualization Service on the test server)
Now, we log on to the published desktop using our test user, and try to delete the Internet Explorer 8 shortcut that we see there
And there you go, once you confirm the delete (if you’ve configured this properly), you will see a very short delay, and then as if by magic, your self-healed file is back! If you want to further test the functionality, simply try to alter the properties of the shortcut by switching it to Read-Only or Hidden. Again, the Self-Healing Action will discard the changes as it has been configured to prevent any changes to the file.
So there it is – a very simple example of how you can use Self-Healing Actions to cut down on unnecessary support calls, without unduly restricting your users in what they can do on their own desktops.
Share
