Hey, Ben Might this help? http://blogs.techrepublic.com.com/window-on-windows/?p=1546
Just came across it earlier today. -*ASB*: http://XeeSM.com/AndrewBaker Providing Competitive Advantage through Effective IT Leadership On Tue, Sep 15, 2009 at 8:23 PM, Ben Scott <[email protected]> wrote: > Does anyone know of a way to have Admin Approval Mode disabled while > keeping File and Registry Virtualization working? > > ENVIRONMENT > > Vista, SP2, Biz Edition. No domain controller or network for the > PCs I'm interested in right now, although when we migrate the main > network to Vista/Win7 this will be relevant then, too. > > BACKGROUND MATERIAL > > LUA = Limited User Account > UAC = User Account Control > AAM = Admin Approval Mode > FRV = File and registry virtualization > AIS = Application Information Service > > An LUA is a user account with no special rights, permissions, > privileges, etc. In particular, not a member of "Administrators". > AAM is the thing that gives an admin account two different access > tokens at logon -- one that acts like an LUA token, and one a full > admin token -- and only "elevates" to the admin token when needed. > FRV is the thing that intercepts attempts by LUAs to write to system > areas (C:\WINDOWS, C:\ Program Files, HKEY_LOCAL_MACHINE) and > redirects them to user areas. FRV thus allows one to run a program > which assumes permission to write to system areas without admin > rights. UAC is a term Microsoft uses for all of this stuff, although > it tends to get used to refer to AAM elevation prompts in particular. > > SCENARIO > > We've been using LUA since before Microsoft invented their term for > it. None of the accounts we use for day-to-day operations have admin > rights. Admin accounts are used only for administering the system. > > In this scenario, AAM only gets in the way. If somebody is logged > in as an admin, we're doing admin work. We don't do non-admin things > from an admin account. So we get prompted *constantly* by AAM. > Non-stop. Aside from being highly annoying and a waste of time, this > desensitizes people to confirmation prompts, thus actually making > people more likely to ignore a prompt for something important. Yuck! > > So what I wanted to do was disable AAM. That way admin accounts do > their thing, regular user accounts do their thing, never the twain > shall meet. > > But, it appears that disabling AAM also disables FRV, for no good > reason that I've been able to find. That is a problem, since we need > FRV to get a couple programs to run. > > INVESTIGATION > > If I leave AAM enabled, the programs work fine. If I check Task > Manager and right-click the process, I find "Virtualization" is > checked. Good. > > If I disable AAM but leave the FRV option at "Enabled", then the > programs fail with their LUA bugs. If I check Task Manager and > right-click the process, I find "Virtualization" is > grayed-out/disabled. > > We have the all-to-common situation where fixing/replacing the > programs isn't feasible. > > According to Microsoft[1], something called "Application Information > Service" (or "AIS") is reportedly the thing that implements FRV, and > it is "effectively turned off" when AAM is off. That seems dumb. > They're not intrinsically the same thing, and there's real benefit to > the one even without the other. > > [1] = http://technet.microsoft.com/en-us/library/cc709628%28WS.10%29.aspx > > I couldn't find anything identified as "Application Information > Service" or "AIS" verbatim. I did find the service "Appinfo", long > name "Application Information", description "Facilitates the running > of interactive applications with additional administrative > privileges...". That sounds like it. It *is* running. Setting it to > AUTO, or restarting it after login as the LUA, didn't help. So I > guess the service isn't actually stopped, it's simply programmed to > sit there and do nothing whenever AAM is turned off. Sigh. > > I see no reason why FRV should be disabled just because AAM is > turned off, so I'm wondering if there's a way to convince AIS to keep > doing its FRV job. > > I can confirm that "Virtualize file and registry write failures to > per-user locations" remains "Enabled" in the GPEDITGUI, despite "Run > all administrators in Admin Approval Mode" being "Disabled". I can > only assume AIS is ignoring the former setting when it sees the > latter. > > I won't buy the "malware defense" argument here for one single > second. As I stated, we're already doing a better job than AAM > ("admin rights with nag screens") does. The computers in question are > *very* safe. They have the Microsoft SSLF template applied. They use > Software Restriction Policies for all users -- you can't even run a > shortcut from the desktop. They are not connected to any > communications lines -- Ethernet, Internet, modem or cans-and-string. > They are protected by least a dozen more layers of physical, > personnel, and computer security beyond that. I don't need Windows > asking me if I'm sure every three seconds on top of that. And like I > said, getting in the habit of clicking "Continue" all the time is > *not* a good thing. > > I am aware of the option to set "Behavior of the elevation prompt > for administrators in Admin Approval Mode" to "Elevate without > prompting". This helps, but it's not the same. Most things still > implicitly run as LUA, causing constant permissions headaches. Having > to manually elevate so many things is still annoying. Plus, I've > found that some stuff seems to be slightly borken in this mode. And I > include Windows itself in that. For example, the "New" menu in > Windows Explorer suddenly becomes empty except for "Folder" with a > shield icon. So with "Elevate without prompting" I can't create > shortcut icons anymore. *rolls eyes* > > I'd call MS PSS but I've found that if a Microsoftie finds > documentation saying it's supposed to work a certain way they stop > thinking. "This behavior is by design" ("So say we all!"). And this > behavior *is* documented; it's just broken. The fact that it's broken > as designed doesn't make it okay. If someone knows of a magic word or > something to get them to start thinking again, I'd be willing to try > that. > > advTHANKSance for any clues, insight, suggestions, comments, > criticisms, random ideas, dumb looks, etc. > > -- Ben > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
