In an earlier entry I discussed the mitigation feature of Standard User Analyzer. This is useful for testing the fixes to see if they work for you, but if they do, what happens next? Typically, you want to deploy those fixes across an organization once you have discovered something that you can fix.

First, let's discuss specifically what the mitigation feature does. As we discussed in an earlier article, it can recommend loosening ACLs. This is something you want to think long and hard about doing, as it destroys the very notion of the standard user. (A standard user can hork their session and their files, but they can't hork other people's sessions and files, nor can they hork the machine itself.) If you have decided that this is something you want to do, repeat the thinking step again, just to make sure - security decisions like this aren't to be taken likely. If you still want to do it, then your deployment option is to just script it out and deploy that script, modify the installer to set the ACLs at install time, or use a shim to loosen the directory ACLs on the installer (if you don't have an MSI to transform and you don't want to repackage). That's not what we'll be discussing here.

SUA can also recommend some shims to address issues running as a standard user, and that's what we'll talk about deploying. Shims sit between an application and Windows. Consequently, a shim can't do anything that the application itself can't do if you were to change the source code, and it doesn't fundamentally change the security of the application. If you can shim it, you have a more secure approach.

So, let's assume that you have run SUA against your application, you have detected issues, and you have brought up the list of available mitigations. If it recommends Loosen ACLs, you have unchecked this because you haven't had time to think yet. If you now click apply, SUA will create a custom shim database and install it on the local computer. You can actually find that database in %windir%\apppatch\custom (its name will simply be a GUID). You may be thinking to yourself, self, I can just take that shim database and use it, right? Well, not so fast.

First, let's talk about how custom shim databases work. You can add as many as you want. You can call sdbinst.exe on as many sdbs as you would like, and we'll go ahead and look at all of them. If you only have one or two applications that require shims, then perhaps that's not so bad. However, it starts to get bad if you have more. To understand why, you can just use any old database to try something out. Compare the speed of opening up a single database and running a query on 1000 rows to opening up 1000 databases and running a query on 1 row. Which do you think will be faster? Next think about long-term management of your shim data. Will it be easier for you to open up a single file and poke around, or 1000 files? So, we probably don't want to take these things one at a time.

Given that, how can we add this valuable information to a managed, organization-wide SDB file? Well, for this, let's pop open Compatibility Administrator. When you do, you'll see, in the left hand pane, an entry for Installed Databases. If you expand this tree node, you'll see "SUA Mitigations for xxx.exe -- x/x/2007 12:00:00 am" for your application - this is the custom shim database that SUA created for you. If you expand this in the tree, you'll see an Applications node, and beneath this, you'll see "xxx.exe -- Anonymous Application modified by the Standard User Analyzer", and when you select this you'll see the list of shims applied in the right hand pane. Now you may be thinking to yourself, self, I don't want to just grab the SDB as a whole, but couldn't I just cut and paste the application into my own central custom shim database?

That's right - Compatibility Administrator supports cut and paste. From the left hand pane, right click on the application, and select cut. Then, you can go to another SDB, right click, and select paste. Why not do that, then? To discover why, just look at the right hand pane. You'll see the list of matching files. here, you have the name of the .exe you were testing. And that's it. No version information, size information, publisher information - anything. We're going to match purely on the name of the exe, regardless of version. So, never versions will get shimmed up as well - probably not something you want. And, if the name of the .exe isn't particularly distinctive, you'll also end up shimming every other application with the same name.

So, the net result is that you'll use the .sdb that SUA generated for local testing, but you're going to want to build up your own in order to deploy the sdb. Fortunately, it's fairly easy to do, so we'll do that now.

The application I was testing triggered 3 mitigations - ForceAdminAccess, LocalMappedObject, and ElevateCreateProcess. If you have already started a new shim database, then open this existing database up. If not, then Compatibility Administrator automatically gives you a blank one when you start it up. Select the New Database (1) [Untitled_1], then click the Fix toolbar button. Provide details on the application (name, vendor, and path - we don't put the path in the SDB, but we use it to look at the exe and discover what matching information is available for us to use). Click next. We don't want an OS mode, so change this from Windows 95 to None. Click next. Now, you can add these shims. With the list of shims highlighted, you can just start typing the name - we'll scroll there in the list automatically (much quicker than using the scrollbar). I added these three shims. Click next, and now you get to specify the matching information above and beyond the name. You can match on just that .exe, or on other files that will always be found in directories relative to that directory, and if you have a version number then you'll also see UPTO_BIN_PRODUCT_VERSION (and the same for file). This is helpful if all of your earlier versions have the same issue, and you don't want to have to create three separate fixes (but the shims will stop being applied when you release the next version). Once you have provided enough information to uniquely identify the application (without going crazy - the more comparisons we have, the longer it takes), click on Finish. Now, click on the Save toolbar button. If you are working with a new database, you'll be asked first to name the SDB, and second to provide a file name and path. If you are working with an existing one, it will just save.

Now, you have an SDB that includes these mitigations, as recommended by SUA. Deploying is fairly straightforward. It takes a single line of script: sdbinst.exe mycustomshims.sdb (with an optional -q). Since this is machine-wide, you have to run the script elevated, so a machine startup script is an option for doing this. You can also use SMS/SCCM to run the script. Or you could package up the SDB and a quick script into an MSI and distribute it that way. Or, any other way you can call sdbinst on the target machine with elevated privileges and point it to the SDB (which can either be pushed local as well or sitting on a network location somewhere).

This week, I am at TechEd 2007 in Orlando, and we have many resources here to help you out with application compatibility issues on Windows Vista. Here are some highlights:

CLI210R - Windows Vista Application Compatibility and Application Compatibility Toolkit 5.0

Peg and Suma are giving a repeat of the talk they gave today on ACT 5.0 on Friday at 10:45 am. Suma is a PM on the ACT team, so this is a great opportunity to hear all about the product from someone directly involved in its creation. If you want to get up to speed on the toolkit, I recommend this session.

Application Compatibility Booth

In the booth area, yellow section, we have an application compatibility station set up which is manned the entire time by people from various Windows teams, from several disciplines. If you have a few minutes to chat, and want to ask a few questions, stop by and meet with the folks in the booth!

Bring Your Own Apps Lab

If you have an application that isn't working on Windows Vista, we have room S329 set aside to help out. You can register for a time slot on commnet, and schedule an hour to chat about your application. Whether you need help debugging the application to understand what is going on, or are looking for approaches to resolve the issue, we have the lab staffed with a number of extremely talented engineers and program managers to assist.

Windows Vista Application Compatibility Lab

This one is my baby. I've put together a two-part session (90 minutes each) where we walk through a number of compatibility issues with existing applications on Windows Vista, and then discuss mitigations for these issues - aligning a fix directly with the problem. In my experience, this is one of the major stumbling blocks for an organization looking to resolve a compatibility issue where they either no longer have access to the source code, or where the new version is going to be released after the projected deployment date. In these cases, the Windows Application Compatibility Infrastructure (shims) can help keep the application working on Windows Vista. But this infrastructure is big and complex, so here we try to demystify it a bit, showing the underlying power of shims and showcasing how to use them effectively. We're running the labs in room S331-C every day, in the following time slots (there is a 1/2 hour break in the middle of each):

Wednesday 6/6 - 2:00 - 5:30 pm

Thursday 6/7 - 8:00 - 11:30 am

Friday 6/8 - 8:00 - 11:30 am

I hope to see some of you at TechEd!