CRAPapp Series: Using Microsoft Application Compatibility Administrator

Summary

In the first installment of my CRAPapp (Crappy Apps) Series I will be detailing how to use the application compatibility toolkit to make a crappy app (in this case an insurance rating application called "AbbyRater") work in Citrix as a non-privileged user.

Many times as a Citrix Engineer/Admin you just get an application or applications dumped on your lap and are told "make this work in Citrix".  Many times those apps weren't designed to be used on a server operating system or in a multi-user system.  This is the story of one of those apps and how I got it to work.

The Problem

So with this application, the issue arises when the application vendor releases an update.  This isnt always an application update per se, but sometimes its just updates to the ratings engine.  The problem with this in a Citrix environment is that the application does a check to see if the user is an administrator on the machine and refuses to update if that check fails. Secondly, if it can't update, the application will close not allowing the user to use the app until its updated.  In a company like the one I work for, it is not acceptable to have to wait until the following day for the app to be updated across all of our Citrix servers.  The first thing I did to troubleshoot, was to fire up procmon and do a trace while the app initiated the update check as a non-privileged user and another trace while as ad administrator to try and see if if there was a permissions issue somewhere.  I couldn't find any evidence of this.  Just as a troubleshooting step, I went ahead and modifed the NTFS permissions on the application's folder in program files so that my non-privileged user had R/W. That didn't work either.  So At this point, I was fairly certain that the app was just doing some type of basic check to see if the user was a member of the "administrators" group on the server.  

Research

To verify this theory, I used a tool called LUA BugLight.  LUA Buglight has to be opened as a user that is a member of the built-in "Administrators" account and UAC has to be turned on.  If you receive a message like the following, make sure you are not using the built-in administrator account and verify you have UAC enabled and not disabled completely.

Once you have LUA Buglight launched, browse to the application's main executable.

Click "Start". You will get a prompt for elevation that you need to allow.  Similar to procmon, the LUA Buglight application is tracing what the app is doing.  You will need to re-produce in the app where the elevation check is happening. for this app it happens immediately at startup.  Once this happens, you can bring LUA Buglight back up and select "Stop Logging".  LUA Buglight will now bring up a reporter window for you to review.  There are two tabs in this case that were of particular interest to me.  First, the "Group Checks" tab.  As we can see the crap app is doing a check to see if the user is a member of the builtin administrators group.

Next, the privileges tab is of interest as well.  This indicates that the app "may require admin-equivalent" permissions. We shall see...  

At this point we are done with LUA Buglight.  It has validated our theory that its doing some kind of permissions check.  Next is how do we fix/trick it?
The FixFirst, we need to download and install the Windows Assessment and Deployment Kit (ADK) for the OS version you are using (in this case...sigh...Server 2012R2). 
During installation, you only need install the Application Compatibility Toolkit ACT option.

Once the program is installed, launch the Compatibility Administrator 32-bit (or 64-bit if it’s a 64 bit app).
What we are going to do now, is create a custom "database" to store our modifications in.  How you choose to organize this is up to you.  If you are going to a lot of apps that you may need to work with ACT to make work then you may want to create a common directory somewhere these are stored.  For now, this is the only app I have and hopefully it remains that way. 

Now that you have the application (ACT) open Click the "Fix" button.

The Create application fix dialog will now be displayed.  You can give it any name you want. Browse to the main executable of the application.

The next page is the compatibility modes you may want to set. It my case, none of these apply for this app but yours might.  In this scenario we are just going to click Next without making a selection.

The next page is where we can select our compatibility fixes.  This is where we want to do our work for our troublesome app.  The particular fix we are looking for is "ForceAdminAccess"

Click Next. We are now at the last page for this fix.  We now have to select matching "rules" so the OS knows when to apply these fixes. Now this is important: The default rules are likely too restrictive.  For instance, you will notice that by default, "PRODUCT_VERSION" is checked.  If you leave this checked, and the version number changes in the future (for instance when the app is updated) then the fix will no longer be applied.
My suggestion would be to "unselect all" and select "ORIGINAL_FILENAME".

Select Finish.
So now you have a new fix set up but in an unsaved database.  You will need to save the database somewhere.  I've chosen to save mine at the root of the application's installation directory.

Click on the "Save" button and give the database a name.

Select a save location and a filename.

The last step is to now install the fix.  Go to File, then select Install.

That's it!  You can now test the app as a normal user.  In my case, I still needed to give the user's rights to the installation directory for the application that way the files could be updated but now the user could update the app when an update was released.