Windows 7, Microsoft Security Essentials, and Proxy Servers

On the recommendation of a number of Twitter users, I decided to install Microsoft Security Essentials (MSE) on a couple of laptops running 64-bit Windows 7. These laptops are used by my kids for their school work (they are home-schooled), and I just wanted to make sure that the laptops don’t get infected with some nasty bug. More than a few Twitter users recommended MSE, so I figured it couldn’t be all bad, right?

The install was quick and painless. And that’s where the fun started. MSE wanted to do an update immediately; OK, that’s fine. The problem is, it won’t connect. I use a Squid proxy server to control outbound web access, so I figured that somewhere was a setting that told MSE to use a proxy server. There’s nothing within MSE itself. Could it be that I had forgotten to configure Internet Explorer? I did make Firefox the default browser, after all. Nope, a quick check shows that the Internet Explorer settings are configured for the right outbound proxy as well. Both Internet Explorer and Firefox are working fine, so I know it’s not the network, the proxy, or the firewall. It must be MSE itself.

Google turns up the first part of the puzzle; even though your proxy support might be configured correctly for Internet Explorer (and thus most of the rest of Windows), MSE won’t take those settings. Instead, you have to use netsh, like this:

netsh winhttp import proxy source=ie

Unfortunately, in its efforts to be “helpful,” Windows 7 won’t allow you to run that command without elevated privileges. All you get when you try is a nondescript error message that vaguely implies that you don’t have permission. However, instead of being able to elevate that one command (a la sudo in the UNIX/Linux/BSD world), you have to run the entire command prompt with administrative privileges, like explained here (and probably countless other places on the ‘Net).

Once you get a command prompt running with administrative credentials, then you can run the netsh command and it will successfully import the IE proxy configuration. Once the IE proxy configuration is successfully imported, then MSE will fetch updates from the Internet and function properly. Wasn’t that fun?

This little episode brings up a couple questions/thoughts:

  1. Why in the world wouldn’t MSE use IE’s proxy configuration? Most of the rest of Windows does.
  2. Even if Microsoft wanted MSE to have its own proxy settings, why force users down a rathole of command prompts and administrative privileges? Why not put it in the GUI?
  3. Windows 7 has made great strides in making Windows more secure, but does this enhanced security posture come at the price of decreased flexibility for the power user?
  4. If so, does Microsoft even care? After all, the default settings are probably fine for most users.

Anyway, there you have it. If you use a proxy server on your network and you also want to use MSE, you’ll need to use netsh (with administrative privileges) to configure your proxy settings properly.

Tags: , , ,


  1. Dave Crown’s avatar

    its not just MSE that has this behavior, but windows in general. Vista and later dont like unprivileged users configuring the proxy used by the OS. Windows Update’s root certificate lookups are just as finicky about using the user’s proxy

  2. Jeremy Barth’s avatar

    MSE likely doesn’t use IE’s proxy settings for the same reasons as outlined in with respect to Windows Update. IE proxy settings are user-specific whereas MSE (and Windows Update) runs as Local System, i.e. a completely separate security context.

    On a home PC this may not seem like a big deal but in an environment where multiple users can share the same PC (corporate, kiosk, etc.) you don’t want a system process that’s interacting with the internet to use the proxy settings of a random non-admin user.

  3. slowe’s avatar

    Dave, thanks for the additional information.

    Jeremy, I can understand your argument. I would counter with two points: 1) In environments with proxy servers, the proxy will generally be enabled for all users. It’s unlikely that the proxy would be turned on for some users but off for other users. 2) Even *if* you didn’t want the system processes to use user-specific proxy settings, then why not build a mechanism in the OS to set the system-side proxy settings? This is the dichotomy that I find so many times with Windows (and other operating systems as well, but espeically with Windows): Microsoft wants everything to be easy, simple, and straightforward, but then they make users run commands like netsh or proxycfg in order to do stuff that, realistically, should be in the GUI. And when these users do try to run these commands, Microsoft puts UAC in front of them to further slow them down and get in their way!

    Sorry, bit of a rant there. I understand your point, although I do not necessarily agree completely with it.

  4. Andrew’s avatar

    Would it be because MS are pushing corporate users (who are likely to use a proxy) toward the paid Forefront Client Security product?

  5. Jeremy Barth’s avatar

    Scott, I understand where you’re coming from — it shouldn’t have been hard for Microsoft to expose the systemwide proxy setting somewhere under, say, the Control Panel > “Network and Internet” GUI.

    I don’t want to get too far afield, but here’s an alternative perspective from someone who has dealt with endpoint security in a large corporate setting. My practice is to disable systemwide default proxies. IMHO a PC’s Local System account should never be talking directly to the internet. Instead, Windows Update, antivirus updates, any and all software patching should be done via internal software deployment mechanisms which are controlled, monitorable and stageable.

    A more intangible benefit is from the standpoint of corporate good citizenship: a compromised PC can no longer “phone home”, e.g. a worm or bot running as Local System won’t be able to find a way out to the internet (assuming your environment has blocked the default outbound TCP/80 in favor of a non-standard proxy port).

    Again, this is getting a bit afield of the issue you ran into but I thought I’d share some of my experiences.

  6. Nik Simpson’s avatar

    One consideration is that viruses often reconfigure the proxy server settings for IE as a way of misdirecting your attempts to access the web. If MSE is using the same proxy setting then the virus will also kill MSE’s ability to get virus updates. So keeping the A/V software walled off in this way is probably done for security reasons.

  7. slowe’s avatar

    Andrew: Probably!

    Jeremy: I get your point, certainly, and I don’t necessarily disagree with you. Microsoft already has a fabulous policy engine built into Active Directory (Group Policy), so why not just expose the functionality via the GUI and then give administrators the option to control it via policy? Of course we are veering off-course from the original discussion, but the approach of making things “easier” by removing flexibility is, IMHO, the wrong approach to take.

    Nik: Good point. I don’t disagree specifically with the fact that Microsoft has the settings “walled off”; my primary complaint is the hoops that you must jump through in order to set this value, and how Microsoft’s attempts to make things “easier” are actually making things harder in many cases (or so it seems). All things said, though, I’m glad to see that Microsoft appears to be taking security a bit more seriously. Now if Apple would only follow suit…but that’s an entirely different discussion!

  8. Dave Crown’s avatar

    I beat my head against the wall with it. best solution i found is to whip a wpad.dat (really eaasy one you get the hang of it) and push it via DHCP. once thats done. everything plays real nice with proxies

  9. @that1guynick’s avatar

    I 100% agree that proxying functionality needs to be able to be “turned on” for the power user somehow, via Control Panel maybe, as suggested. But I DO like that out-of-the-box, it is controlled by policy. It makes placing Win7 in the corporate enterprise much more streamlined and easier to manage. (i.e. you don’t have to build policy to “turn off” these functions)

    I think at the end of all of this, your veering off from the fact that for a free product that 99.999% of “home users” will use, MSE delivers. And all it requires is a genuine copy of the OS. Running squid at home is an extremely unique requirement for Microsoft to meet.

    I run it on my laptop, MCE box, and gaming machine at home, and it is extremely lightweight. I won’t know if it’s actually doing it’s job properly, because I don’t typically get a lot of viruses/spyware/malware. It updates itself, has a default scheduled scan, etc.

    Anyone have any malware-based (non-porn) sites I could visit to do some testing?

  10. slowe’s avatar

    Dave: I haven’t messed with wpad.dat; might have to give that a try and see how well it works!

    Nick: I fully understand that MSE is free and works just fine for 99% of the users out there. My comments are more directed at Microsoft’s apparent general direction where making things “easier” means less flexible. That’s not a good trend!

  11. Dave Crown’s avatar

    Nick. It is turned on for a power user per say. if you log on with admin credintials and set a proxy for your self, WinHTTP should get ypur proxy settings

  12. Anne’s avatar

    The command did not work with the company proxy server I work at.

Comments are now closed.