Applications, applications, applications – how to ensure you are compliant

Compliance, it doesn’t have to just be about ensuring your license count is correct and working how much you owe vendors in true-ups. I’ve been working with a customer who wanted to use AppClarity for a slightly different purpose, to keep their new Windows 7 estate clean. ‘Clean’ doesn’t just mean removing any dodgy programs that users have installed, but to also ensure that the software currently installed is at the correct version, across the entire estate.
 
So let’s start with the dodgy programs. The customer reviewed the list of installed applications and compared it to their own authorized list. If AppClarity listed an application that a lot of people had installed then they would put this forward to getting this version officially packaged, licensed and supported through the business.
 
However, most detected applications were ones that they didn’t want installed on their new estate.
This is where AppClarity’s ‘Prohibited’ policy comes into effect: This policy removes the application regardless of usage across the estate without the user being made aware.
 


For one of the prohibited applications the customer did want users to be made aware of its removal (as there was a non-prohibited replacement for the product) and we used a script method through AppClarity to inform users of the software’s removal. I won’t go further into scripting methods here as they have already been discussed further in other blogs. But they add a powerful ability to AppClarity to provide bespoke uninstall solutions for different product reclaims.
 
If a user did notice that the prohibited application has been uninstalled and reinstalled it, then AppClarity would soon detect this and uninstall it again.
 
The second part of cleanliness is ensuring that end users are all on the approved version of the software and that old versions are removed. As all major versions of software are linked to the main application, you need to split the versions first to create an extra Authorised version of the product.
 
In this example I want to ensure the latest Nomad 4.0 release is Authorized, but any other version is prohibited.
 


Initially, all versions are just grouped under Nomad.
Therefore, I selected to relink the specific version I want to be Authorized and then edit the product name to include the tag ‘(Authorized)’
 
 

Now this will give me two products which I can set two different policies up against.



This Nomad Application can be set to ‘Prohibited’ whereas the Nomad (Authorised) can be set to ‘Business Critical’ or any of the other polices.
 
Both these methods of using AppClarity can ensure that the estate stays clean and lead to less issues being raised due to unsupported software on the users machines.
 
Obviously this methodology can be used along standard usage policies of AppClarity to ensure everything is truly compliant.

Rob Nichols | Escalation Engineer

To connect with 1E, why join our LinkedIn forum, 1E INSIDEV1EW, follow us on Twitter @1E_Global, or email us at info@1e.com?

If you found this article interesting, please take a moment to share it with your contacts using the social media buttons to the left. Thank you.


Press Esc to close

Leave a Reply

Your email address will not be published. Required fields are marked *

Enter the below captcha

Please type the characters of this captcha image in the input box

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>