Mark Minasi's Windows Networking Tech Page
Issue #85 September 2010

Document copyright 2010 Mark Minasi; please see below for info on subscribing, unsubscribing or copying portions of this text.

What's Inside

  • News
    • Attend a Seminar or Listen to my Audio Recordings
  • Tech Section
    •  Hating IE8 Just a Little Less
    • Why You Sometimes Map a Drive in Windows 7... But Explorer Can't See It (It's UAC's Fault)
  • Conferences
  • To Subscribe, Unsubscribe, Read Old Newsletters or Change Your Email Address


Hi all —

This month, I've got a couple of short items to pass along, including a User Account Control-related tip that I've gotten three questions on just this month, so I felt that it's time to pass it along in a newsletter, as well as the result of some research that I did while trying to de-annoy-ify IE8 a bit.  I hope you find them useful, and let's get to them... but first, a word from our sponsor:

Hating IE8 Just a Little Less

I have to confess something that I fear may make me seem a bit lame in the eyes of some readers.  Ready?  Here it is, admitted, albeit reluctantly:  I just don't care about which browser I use.  Yes, I know that Firefox has some nifty looking add-ons (the DNSSEC one has me a bit envious, I admit) and Chrome's got some neat stuff, but the truth is that I work with and, more importantly, test so many different systems that I prefer not to have to do too much configuring on my desktops -- I just want to fire 'em up and get some work done without a lot of fiddling.

Ah, but then IE8 arrived.  You, know, IE 8 may just convince me to make a Firefox/Opera/Chrome/whatever browser install part of my "vanilla" setup routines, as I am beyond weary of starting up IE8 on a new system and having to answer a bunch of truly stupid questions before being able to use the blasted thing.  So here are two ways that I've seen how to keep a freshly-installed system's IE8 from shoving its "first time run" wizard in my face.

First, there's a group policy.  Prior to XP SP2, I think there were a sum total of about 8 group policy settings that had any effect at all on Internet Explorer.  As of Windows 7, however, I think there might be about 10,835 -- okay, I'm exaggerating, it's probably only 8,741 -- so it took a bit of poking around to find this one.  It's in Computer Configuration / Administrative Templates / Windows Components / Internet Explorer -- yes, it's right up in the root "Internet Explorer" folder, not one of the ten sub-folders in "Internet Explorer" -- and the setting's name is "Prevent performance of First Run Customize settings."

You've got to do more than just enable it, however; once you click "Enabled," you get a drop-down single-selection list box requiring you to either choose "Go directly to 'Welcome to IE' page," or "Go directly to home page."  Choose the latter, and at this point IE8 becomes, happily, no more annoying than IE7 is on its first run.

By the way, if you'd like to just punch the value straight into the Registry, you can go to HKLM\ SOFTWARE\ Policies\ Microsoft and create a key "Internet Explorer" if it's not already in there, and another key named "Main" inside that.  Then create a new REG_DWORD entry "DisableFirstRunCustomize" with value "1."  You'll need to reboot to see the change take effect.

The other approach involves using an autounattend.xml answer file to create your Windows 7 image in the first place, a tool that you can read about back in Newsletter #60.  While in Windows System Image Manager (which, you may recall, is the tool that builds autounattend.xml files), navigate over to amd64_ Microsoft-Windows- IE-InternetExplorer_8.0.7600.16385_neutral, or x86_ Microsoft-Windows- IE-InternetExplorer_8.0.7600.16385_neutral if you're running 32-bit Windows.  Add that section to Pass 4 of your answer file.  Within those settings, find the "DisableFirstRunWizard" setting.  It takes "true" or false," but you'll want "true."  If that setting's in your autounattend.xml, then your users will never see IE8's opening wizard.

Why You Sometimes Map a Drive in Windows 7... But Then Can't See It

I've gotten this question literally three times in the past month, so it must be time to put it in a newsletter.

Here's the scenario.  It will appear on any Vista, Server 2008, Windows 7 or Server 2008 R2 system with User Account Control enabled.  (Remember UAC's on by default.)  You've opened an elevated command prompt -- one wherein you didn't just double-click the "Command Prompt" icon, you right-clicked the icon and chose "Run as administrator" -- and you map a drive with the NET USE command, mapping it to, say, drive G:.  Then you pop out to Explorer... and whaddya know, no drive G:!  Maybe an F5 to refresh will... no, no change.  Perhaps a reboot, assuming you mapped it persistently?  No on that score either.

What's going on here?  Well, as you know if you've read my Vista security book or heard me talk about User Account Control, then you'll know that when you log onto your system, UAC causes Windows to create not one but two security tokens.  One of those tokens contains all of your privileges and group memberships (the "administrative token"), and Windows builds the other -- the "standard user token" -- by copying your administrative token and then removing from that token any of four particular powerful group memberships and removing any of nine particularly powerful privileges that appear in the administrative token.

But there's more to it than simply having two tokens.  Two tokens, you see, mean two logon sessions... and those sessions don't really talk all that much.  Thus, drives that you've mapped from the "high power session" (the one with the administrative token) aren't visible in the "low power session," the one with the standard user token.  It's also true the other way around, although folks don't seem to run into it much -- map a token from the lower power token and it's invisible to sessions for the high power token.  To see this, try this simple test, which requires a Vista or Windows 7 system and a server with more than one share.

Let's call the file server \\server1 and let's say that you've got shares named \\server1\share1 and \\server1\share2.  Let's also say that you have the right to access these shares because you're a member of some group other than the four that UAC would yank out of your token -- Power Users, Administrators, Backup Operators or Network Configuration Operators.  Log on and do the following.

  1. Open an elevated command prompt window.
  2. In that window, type net use t: \\server1\share1 and press Enter.
  3. Open a second command prompt window, but this time, don't elevate the command prompt, just double-click on the icon.  You'll have two separate command prompt windows open now, and the elevated one will have "Administrator:" in its title.
  4. In the second, non-elevated command prompt window, type net use v: \\server1\share2 and press Enter.
  5. Next, while still in the non-elevated command prompt window, type net use and press Enter.  You will see V: listed but you will not see T: listed.
  6. Finally, pop back over to the elevated command prompt window and, again, type net use and press Enter.  This time, you'll see T: listed but not V:.

Again, this has nothing to do with any kind of refreshing.  If you like, close both command prompt windows, open two new ones up in the same way and do the "net use" command in each, and you'll still see only T: in the elevated window and V: in the non-elevated one.

So what's the fix?  As KB 937624 explains, you can hack the Registry with a "EnableLinkedConnections" setting:

  1. In Regedit, navigate to HKLM\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\ System
  2. Create a new entry named "EnableLinkedConnections" of type REG_DWORD.
  3. Set its value to 1.

Reboot and you'll see the change take effect.  I hope this helps someone!


To Subscribe/Unsubscribe, Read Old Newsletters or Change Your Email Address

To subscribe, visit To change e-mail or other info, link to  To unsubscribe, link to Visit the Archives at Please do not reply to this mail; for comments, please link to

All contents copyright 2010 Mark Minasi.  I encourage you to quote this material, SO LONG as you include this entire document; thanks.