The requirement to allow users to install applications is becoming more and more common. The days of providing a unified set of monolithic desktop applications to each end user are slowly being worn away. Today's users are often a little more tech-savvy, sometimes requiring access to new applications as circumstances dictate. Most of these applications will be what we classify as long-tail apps - not core business or departmental systems, but niche applications required by certain users for certain specific tasks or enablements, sometimes even things they need to run at certain times of the year.
Of course, you can't simply give your users administrative rights and then allow them to install software from anywhere. That would rapidly compromise the security and integrity of your managed environment. What would be useful is to provide a set of applications that have been pre-verified by IT - an app store of sorts, to steal a phrase from somewhere else - that users can install on demand, without having to raise a call with the IT department. It also removes the need for each and every individual application to be packaged or delivered - the IT department, once they've verified the software, can simply drop the install files into the AppStore share and let the users install them as required.
AppSense already have StrataApps which allows users to install applications into a bubble of sorts, but as yet (rather disappointingly) this isn't integrated into Application Manager. Which means that if you deploy StrataApps as the solution to UIA (user-installed apps), you are allowing your users to install pretty much anything. I am reliably informed that AppSense are working hard on the StrataApps integration with Application Manager, and this will be a very exciting development when it happens, but just for the moment, we will have to do without the advanced stuff we could have gleaned from StrataApps and try to achieve our goal through Application Manager itself.
The next dilemma you'll face when thinking about UIA is whether it is suited to server-based computing or not. Primarily this sort of thing is aimed at desktop, laptop or VDI users, simply because there won't be the constraints of disk space or performance that you may get when allowing users to install their own apps onto an SBC platform. Now you could do something like fire up AppSense DataNow and do some editing of the various application installation files to point the install location into the user's DataNow folder (which is network-based), but this raises so many possible issues of application failure and additional complexity that I am going to consider this as out-of-scope for this article. Right this minute, we will assume that you are going to deploy this UIA solution onto single AppSense-enabled endpoints - desktop computers, laptops, or VDI sessions running Windows.
So, the first thing we need to do is configure the network share we are going to use as our enterprise AppStore and populate it with a few applications. We will choose Notepad++ for our developers, mRemoteNG for our first-line support staff, and TweetDeck for some of our marketing bods. Not a particularly complicated line-up, but I'm sure you get the idea :-)
![]()
Next, because we will be using the Trusted Ownership feature of Application Manager to verify that these files can run, we need to ensure that the NFTS permissions and ownership are set correctly. Users should simply have RX (Read, eXecute) permissions to the folder and files, Administrators should have F (Full Control), and the owner should be set to the BUILTIN\Administrators group. Also ensure that the files in the folder are inheriting permissions from the parent folder.
![]()
![]()
Next, because we will be using the Trusted Ownership feature of Application Manager to verify that these files can run, we need to ensure that the NFTS permissions and ownership are set correctly. Users should simply have RX (Read, eXecute) permissions to the folder and files, Administrators should have F (Full Control), and the owner should be set to the BUILTIN\Administrators group. Also ensure that the files in the folder are inheriting permissions from the parent folder.
Next we will verify that our current users can't actually install these apps themselves. I will log onto a user session and try to install a couple of the applications we placed in our AppStore.
As you can see, the user can't install applications without having administrative rights, which is what we'd expect. In this situation a user would probably be calling the helpdesk, logging a case and facing a long wait as the call was queued and prioritized according to a company's SLA - maybe even experiencing further delays if the application needed extensive testing or packaging for delivery. However, we will now try and use AppSense Application Manager to get around all of this!
We're going to use a specific Active Directory group to make this AppStore accessible to, so we will first add a Rule Group, the process of which I should hope regular readers of this blog might already be familiar with :-)
In the Accessible Items section of our Rule Group, we will need to add a Folder item
![]()
then we will supply the required details
![]()
and ensure that the Trusted Ownership and Include Subdirectories options are selected for this particular item
![]()
Now we need to utilize the User Rights node of our Rule Group to allow us to elevate permissions of the user when they are executing content from this share. We need to add the folder we specified above to the Applications tab of the User Rights section
![]()
and then ensure that the following options are set (note - you may want to use the Substitute environment variables where possible option, the reason I didn't is because for reasons of quickness I hosted my AppStore share on a domain controller)
![]()
Once this is done, you'll need to ensure that the User Rights Policy you've selected is the Builtin Administrator Elevate as shown below
![]()
The Apply policy to child processes option needs to be selected because often installers will spawn other processes, such as installing pre-requisites
The Standard user rights on common browse dialogs optionis very important, not just for this particular scenario but any in which you make use of elevated user rights. This stops elevated administrative rights "leaking" into things like Explorer windows where users could technically use their elevated privileges for nefarious purposes, and it's one of the best features of Application Manager IMHO
Next, as most installers leverage the Windows Installer process, we need to configure the pre-defined Windows Installer node under Process. In the Accessible Items node for the Windows Installer process, we need to add *.msi to the list of allowed items
![]()
![]()
![]()
And then we will need to add the file share as a Folder to the User Rights node of the Windows Installer Process Rule
![]()
![]()
And as mentioned earlier, ensure that the User Rights Policy for this Folder is Builtin Administrator Elevate
![]()
Now, the only other option you need to check before deploying this configuration is on the General Features tab under Options. User Rights Management should be selected for this to work (it is enabled by default, but check this just in case someone has turned it off)
![]()
Once all this is set up, you will need to save the configuration and deploy it to your target endpoints. When the configuration is successfully deployed, we can now log on again as a non-admin user and put it to the test! First we will try a traditional MSI installer file...
![]()
We're going to use a specific Active Directory group to make this AppStore accessible to, so we will first add a Rule Group, the process of which I should hope regular readers of this blog might already be familiar with :-)
In the Accessible Items section of our Rule Group, we will need to add a Folder item
then we will supply the required details
and ensure that the Trusted Ownership and Include Subdirectories options are selected for this particular item
Now we need to utilize the User Rights node of our Rule Group to allow us to elevate permissions of the user when they are executing content from this share. We need to add the folder we specified above to the Applications tab of the User Rights section
and then ensure that the following options are set (note - you may want to use the Substitute environment variables where possible option, the reason I didn't is because for reasons of quickness I hosted my AppStore share on a domain controller)
Once this is done, you'll need to ensure that the User Rights Policy you've selected is the Builtin Administrator Elevate as shown below
The Apply policy to child processes option needs to be selected because often installers will spawn other processes, such as installing pre-requisites
The Standard user rights on common browse dialogs optionis very important, not just for this particular scenario but any in which you make use of elevated user rights. This stops elevated administrative rights "leaking" into things like Explorer windows where users could technically use their elevated privileges for nefarious purposes, and it's one of the best features of Application Manager IMHO
Next, as most installers leverage the Windows Installer process, we need to configure the pre-defined Windows Installer node under Process. In the Accessible Items node for the Windows Installer process, we need to add *.msi to the list of allowed items
And then we will need to add the file share as a Folder to the User Rights node of the Windows Installer Process Rule
And as mentioned earlier, ensure that the User Rights Policy for this Folder is Builtin Administrator Elevate
Now, the only other option you need to check before deploying this configuration is on the General Features tab under Options. User Rights Management should be selected for this to work (it is enabled by default, but check this just in case someone has turned it off)
Once all this is set up, you will need to save the configuration and deploy it to your target endpoints. When the configuration is successfully deployed, we can now log on again as a non-admin user and put it to the test! First we will try a traditional MSI installer file...
...and hey presto! We have a flawless install process instead of the error about policies preventing the installation.
Next we will try a non-MSI installer, a standard .exe file, using the Open command, not the Run As Administrator option...
Next we will try a non-MSI installer, a standard .exe file, using the Open command, not the Run As Administrator option...
...bingo! This one works perfectly too!
Now just to prove that we haven't inadvertently allowed everything to be installed, we will take our final example installer, the mRemoteNG one, and drag that onto the user's desktop before we try to run it...
...and now, because we have a valid Application Manager configuration running, we see that the user isn't simply restricted from running installers, they can't run anything at all that hasn't been allowed according to the configuration rules. Sweet!
This looks like a really great way to allow users to install longtail applications from a pre-approved network share, allowing IT to verify the applications are valid and relevant but freeing them from the overhead of management and deployment. There are a few things worth mentioning, though:-
1. If you want to force users to install to a non-standard location or disallow them from changing other installation options, you are going to have to customize the installation files you provide on the AppStore share. There are various ways you can do this dependent on the software in use, using Orca is one of the more popular methods.
2. The security of the AppStore share is of absolute paramount importance. If a user manages to place a non-standard or malicious installer file to this area, you're going to be in a world of hurt. Lock it down as hard as you can, and make sure you test the security!
3. Uninstalling applications delivered in this way is a little tricky, because if you allow users the rights to uninstall things they can remove anything, not just the apps you've installed through this method. This is one of the reasons why I'd sooner use StrataApps combined with Application Manager rather than just Application Manager itself, because StrataApps, amongst other useful UIA features, allows users to perform uninstallations of their self-installed apps. As soon as AppSense integrate StrataApps nicely with Application Manager, we will have to revisit this whole subject, as StrataApps is specifically designed with UIA in mind and does a whole lot more than we can achieve with Application Manager on its own. If you need self-installed apps uninstalling in the meantime, users will have to leverage the IT department to do it.
Well, here's hoping this method proves useful to some of you out there. It's certainly something I've put in place for a couple of clients to get around problems, mainly with power users like developers, but as the application needs of the general user populace grow ever more diverse, it will probably spread to other groups a lot more quickly than we anticipate.
I've also made the configuration I put together in this article available, should you wish to download it. Usual caveats apply regarding the AD group name and obviously the network share, and please also bear in mind that I unchecked the option for using environment variables because I'd hosted the file share on a domain controller - you may want to reinstate this in your own environments.