Tidbits: life under a Limited User Account (LUA)

  • Article

I'm about to wipe my main work machine and install Vista RTM x64.  Wish me luck.  Sure, people @ MS wipe their boxen all the time, but I'm not one of them: this install of Win2k3 has lasted me since 6/29/2005.  (For reference, I was hired in April '05 and received this machine in early June.  So other than a couple months with the noisy old Athlon MP that our office hands from incoming sucker to sucker, and a couple weeks testing the x64 waters when this shiny machine arrived, this install has spanned my entire career.) 

Furthermore, I probably have the least Vista experience in the whole company.  Despite endless exhortations, I only installed it on my test box after RTM.  Adoption drivers, if you're reading: blame the lack of upgrade path from Win2k3 + the fact our Raleigh boot server is not WDS capable.  For home dogfooding, meanwhile, blame IHVs: can't upgrade any of those machines until the Emu 1212M, nVidia DualTV, and 3ware 7000 series are onboard, respectively.  Much as I cling to long-running software installs (the opposite of every other PC enthusiast, it seems), I swear it wasn't fear: I absorbed Office 2007 releases as early & often as possible and never looked back.*

Sure I saw several Beta1+ Vistas during major Whidbey test passes -- QA uses scores of lab machines to exercise configuration combos.  Conclusion: Vista's impact on my scenarios was far lower than most other variables in the support matrix.  Whatever people say about the Vista interface, it's way easier for a newbie to navigate than Arabic WinXP or Japanese TFS are.  But that phase of my career ended several months ago, just as Vista was really coming to life.  Owning SourceSafe is a much bigger responsibility, yet it's also been an escape from the usual DevDiv overhead.  So come fall '06, still no quality time with Vista.

*with one exception I'll blog about some other time

----

This post was supposed to detail a few LUA issues I debugged in my first few days of living with a Vista test box, plus complete the final "draft" article sitting in Live Writer so it wouldn't be lost in the main box's wipe.  So far I've done neither.  Onward!

  1. UAC prompts weren't pre-filling the admin account's username.  When you're first setting up a box, you inevitably hit UAC a lot; typing "machineName\adminName" each time was getting old quickly.  (No, logging in as the local admin wouldn't help; that would have me typing my domain credentials instead, just as frequently.)  My previous experiences with UAC were brief, but I knew it wasn't that annoying.  I searched & searched for an answer...my complaint to the UAC talk alias was nearly composed when I finally found this post.  Thank you, Daniel!
  2. I type things like "{pushd | start | dir} \\someMachine\d$\<tab complete...>" a LOT.  Always will, at least until James gets me fully hooked on PowerShell.  You probably see where this is going: when your main network account isn't an administrator on someMachine, admin shares stop working.  It's not hard to add some trivially named shares and lose the '$', but it adds conscious thought to commands that used to be rote.  Oh well.
  3. Soon as I set up FolderShare, it was stymied.  I didn't save the exact error message but it was along the lines of "FolderShare could not write to c:\program files\sync\foo\foo.exe.  Retry | Close"  First of all, how annoying is it that the only workaround is to close FolderShare?  Can't you just disable that library?  So begins the only true debugging challenge.
    1. We all know non-admins can't write to Program Files, so step 1 was to grant Modify permission to the Users group on Program Files\Sync.**  Click Retry.  No dice.
    2. I notice my account is not actually a member of Users, but of Remote Desktop Users.  I try manually adding myself to Users as well.  (if that fixed it, i.e. RD Users didn't inherit User permissions, I would have to yell at someone!)  Somewhere in here I also discover the new Effective Permissions tab in the shell.  Very nice...and confirms that this is not the problem.  Retry fails again.
    3. Time for Process Monitor.  Since FolderShare hasn't been able to drop my toolset into place yet, I manually download it to Program Files\Sync\SysInternals\procmon.exe.  Before I can fire it up, though, I notice that accevent32.exe, accexplorer32.exe, etc. are starting to appear in the folder I just created!  I manually create another folder under Sync, and sure enough files (but no subfolders) start being pushed there too.
    4. Armed with the theory that I've somehow granted a set of ACLs that allows new files but not new folders, I head back to my elevated shell and give my user Full Control + ownership.  Doesn't help.
    5. So, I need ProcMon after all.  Filtering on foldershare.exe and the Sync dir, I see that among a sea of successful Querys that CreateFile attempts on Sync's subfolders come back as REPARSE, but there are no actual failures in sight.  Mysterious.  I know all about NTFS reparse points, but that sequence of calls & return values tells me nothing.  Luckily ProcMon has an awesome feature that displays the full stack of each filesystem call.  This quickly tells me that foldershare is actually calling RenameFile(), not CreateFile().  Thus, the piece of activity I'm looking at is actually the behavior of an internal Windows function.  Furthermore, it's now obvious what's happening (or failing to happen): FolderShare must download to a temp location and then move completed items into place.  Still, why would moving from A to B require any more permissions than creating something at B?
    6. Regardless, I know I must remove my path filter.  It's ugly -- as I knew from past experience, an unfiltered FolderShare loves to fill up ProcMon logs with hundreds of thousands of entries.  But I know what I'm looking for: some sort of anomaly around creating + moving temp files.  I soon find it when I spot activity not only under the expected c:\foldersharetemp, but under c:\Users\me\AppData\Local\VirtualStore.  Hooray for the vastly simplified name of these directories!  But what is VirtualStore?  Quick Google tells me it's the root for filesystem redirection: something I'd experienced firsthand in my testing around WOW64, and that I'd read would be used for lots of shimming in Vista, but had not really put 2 & 2 together.  I'm also quickly reminded that shimming can be turned off by providing a manifest for your binaries.
    7. So, what does a manifest for a native app look like anyway?  Web searches lead me to tons of pages telling me how to add manifests to the Visual Studio build process, a few pages describing the schema for manifests on managed code, but precious little on native code.  Surely the format whose root XML node is "assembly" is for managed code only, right?  Sadly, the web offers no alternatives, so I copy/paste a sample anyway & restart Foldershare. 
    8. Won't load.  Syntax error or wrong schema entirely?  The event log won't tell me, so all I can do is optimistically eyeball the syntax and try again.  Before long Foldershare loads and happily starts writing to Program Files\Sync.  Success!  So yes, fair web travelers: those manifest samples full of tags like <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="Sample" type="win32" /> really do apply to native code.

**this is where I store apps that don't require installation, making them perfect for FolderSharing.  Command line tools, sysinternals, dozens of A/V applets, and lots of misc cool stuff.  This category of apps also tends to be freeware or open source, which lead to frequent updates.  Finally, a lot of them write user data to their containing folder, either because they're cross-platform or simply amateurish.  Thus ends my justification for breaking the principle of least privilege.

Wow.  This became a heckuva long post, especially for the offtopic category.  Despite my earlier self-deprecation the fact is I'm not ignorant of MS tech trends, especially relative to the huge non-Softie world out there.  I knew upfront my first few days under LUA would present trials, yet more than once I found myself wishing the causes & solutions were easier to find.  I do know our published info & general transparency is better than it's ever been, and will continue to improve.  Novel length or not, I sincerely hope blogging my experiences adds to that momentum in some small way.

Soon as I publish, my next move will literally be Start -> Shut Down, rebooting onto a DVD and into a brave new world.  Farewell, dear c:\.  See ya on the other side.