Tame BAD Applications with ProfileUnity, without users having administrative rights

What is a BAD application?

We consider bad applications those applications that store user settings in places the user does not have rights to out of the box and traditionally you would have to give the user administrative rights to tame these bad applications. But with ProfileUnity, we have a better way to not repeat the mistakes of the past when moving to VDI and strip away the administrative rights the user once had.

ProfileUnity has traditionally been a Persona Management tool and environmental management has grown more powerful over the years. ProfileUnity’s environmental management feature used to be limited to only places the user had rights to, for instance, %userprofile% (c:users%username%) or HKCU. But since the introduction of elevation about a year and a half ago ProfileUnity’s environmental management features just got very powerful to help tame those bad applications.

You don’t have do anything within the product to use elevation with ProfileUnity. The elevation service is installed out of the box and automatically elevates ProfileUnity execution at run time, most commonly during login and logoff. When our client.exe process is executed, a request for elevation is made to the elevation service.  Then, since our executables are code signed by Liquidware Labs, Inc., they are automatically approved for elevation.  What’s different here with our elevation versus windows elevation is our requesting process is run “as the user” but with local administrator rights and this only applies to the processes NOT the entire user session.

Here are some core features that can help tame those bad applications
1. Portability
2. User defined scripts
3. App launcher
4. Registry setting

Portability is ProfileUnitys ability to capture files and/or registry keys anywhere on the system. So, if your bad application is writing to for example C:winTAM*.ini for user settings, because of elevation you can create a rule that captures these files and lays them back down to this path without the user being an administrator, the same would also apply to registry keys.


User Defined Scripts lets you create a script in almost any language to have it execute with administrative rights during login. Since your script will run with administrative rights while the user is logging in the sky’s the limit to what you can do to the system.


Application Launcher can also be used to run simple scripts without the need to maintain any script files on the network. For example, if your script is cmd, you can create an application launcher rule that is %systemroot% /c copy \serversharebadapp*.ini c:wintam /y. This would copy files from a server share locally for an application to use. The cmd command would run with administrative rights and would remove the need for a .cmd on the network share.


With the Registry setting module, you can push Registry settings that an app might need where the user would not normally have rights. For example, HKLMsoftwareBadApp data=1.


I hope this helps give you some ideas for the power of ProfileUnity and how its power can be leveraged.

If you would like to browse the management interface of ProfileUnity, we have a live version on the website. Just click the link below.


This site uses Akismet to reduce spam. Learn how your comment data is processed.