locked
WSUS updates for external users RRS feed

  • Question

  • We have users that work from home on laptops and may or may not connect through a VPN back to our office. We use an internal WSUS server that stores updates and deploys them once a month to internal PCs. There are 2 scenarios we are considering for external users and I'm wondering which would be best/possible.

    1. Set up an internet facing WSUS server in the DMZ which would service external and internal clients.
           - Would it be possible to store updates locally and have internal clients download updates from WSUS and external download from Microsoft?

    2. Set up and internal WSUS which stores updates and is used for internal clients. Set up an internet facing WSUS server for external users which is a replica of the inside one.
           - If a policy was set so the laptop users connected to the external WSUS server to download updates, would they have to be connected through a VPN to download the updates or can they download them anytime they're on the internet? I would not store updates locally so they would have to get them from Microsoft.

    Thanks,
    Scott

    Thursday, April 29, 2010 1:56 PM

Answers

  • Greetings Scott.

    The solution that is appropriate for your scenario is option #2, an internal server for corporate clients with a full content store, and an Internet-facing (more typically VPN-accessible) replica server that does not maintain a content store. In this fashion, your VPN clients will obtain content direct from microsoft.com across their full Internet pipeline, rather than using the encrypted VPN channel for file transfers.

    You can configure the "Internet-facing" server to not require VPN connectivity; however, strictly speaking the EULA for WSUS requires that only corporate-licensed systems are updated from a corporate-licensed WSUS server, which implies a requirement to be able to verify that compliance. Since the connection to a WSUS server is entirely anonymous, identity of the clients become an issue in a non-VPN-secured site, not to mention the potential security implications of having your WSUS server (and approvals status) published on an open Internet-accessible server.

    At a minimum you'd need to use some form of reverse-proxy with authentication, or client-side SSL certificates -- the WUAgent in combination wiht WinHTTP does support authenticated proxy connectivity. The SSL certs scenario is a theoretical solution, I've not actually heard of anybody who has successfully implemented client-side SSL certificates in a WSUS environment.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    • Marked as answer by scottyp55 Tuesday, May 4, 2010 5:02 PM
    Thursday, April 29, 2010 6:12 PM

All replies

  • Greetings Scott.

    The solution that is appropriate for your scenario is option #2, an internal server for corporate clients with a full content store, and an Internet-facing (more typically VPN-accessible) replica server that does not maintain a content store. In this fashion, your VPN clients will obtain content direct from microsoft.com across their full Internet pipeline, rather than using the encrypted VPN channel for file transfers.

    You can configure the "Internet-facing" server to not require VPN connectivity; however, strictly speaking the EULA for WSUS requires that only corporate-licensed systems are updated from a corporate-licensed WSUS server, which implies a requirement to be able to verify that compliance. Since the connection to a WSUS server is entirely anonymous, identity of the clients become an issue in a non-VPN-secured site, not to mention the potential security implications of having your WSUS server (and approvals status) published on an open Internet-accessible server.

    At a minimum you'd need to use some form of reverse-proxy with authentication, or client-side SSL certificates -- the WUAgent in combination wiht WinHTTP does support authenticated proxy connectivity. The SSL certs scenario is a theoretical solution, I've not actually heard of anybody who has successfully implemented client-side SSL certificates in a WSUS environment.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    • Marked as answer by scottyp55 Tuesday, May 4, 2010 5:02 PM
    Thursday, April 29, 2010 6:12 PM
  • Thanks for your response.

    If the laptops users were VPN'd in, would I still need to use the reverse-proxy or SSL certs?

    How do your require or not require clients to come through a VPN? I can't find this option on our WSUS server?

    At the time the client connects and gets approval for the updates, is that when it goes back out to Microsoft for the updates? Does the VPN tunnel need to be open to get the updates or can they get them anytime once they've been approved?

    Thanks,
    Scott

    Thursday, April 29, 2010 6:44 PM
  • "scottyp55" wrote in message news:3d0d1138-addc-4fee-b22e-b3d37e2c4d78...

    Thanks for your response.

    If the laptops users were VPN'd in, would I still need to use the reverse-proxy or SSL certs?

    How do your require or not require clients to come through a VPN? I can't find this option on our WSUS server?

    At the time the client connects and gets approval for the updates, is that when it goes back out to Microsoft for the updates? Does the VPN tunnel need to be open to get the updates or can they get them anytime once they've been approved?

    Thanks,
    Scott


    If the laptop users are using a VPN connection, it would not be necessary to implement reverse-proxy or SSL certs, as the VPN serves the purpose of authoritatively identifying the clients as authorized users.
     
    WSUS does not provide the functionality to require a VPN, that's implemented by simply not publishing the WSUS server to the Internet, and requiring VPN access to get on the LAN segment hosting the WSUS server.
     
    The download of the update content is queued immediately upon discovery of an update APPROVED for installation. The VPN tunnel would need to be open to execute the detection and recognize the approval, but not to initiate, maintain, or resume the download of the binaries.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, April 29, 2010 9:04 PM
  • Thanks again for your response.

    I think a lot of our users may not always be using their VPN, so we probably will have to set up an internet-facing WSUS server. Can we use our internal MS Cert Authority for SSL certs or would we need to purchase public certs? Or is their any documentation on setting up a reverse proxy?

    One of our biggest problems is trying to determine what time to set our GPO for download and install for laptops. Is there a recommendation for this since most laptops aren't online or even powered on at the same time?

    Thanks a lot,
    Scott

    Friday, April 30, 2010 2:49 PM
  • Can we use our internal MS Cert Authority for SSL certs or would we need to purchase public certs?

    Or is their any documentation on setting up a reverse proxy?

    One of our biggest problems is trying to determine what time to set our GPO for download and install for laptops. Is there a recommendation for this since most laptops aren't online or even powered on at the same time?

    1. You can use any certification authority. The point is to simply ensure that you can verify that only your clients have access to the Internet-facing server so as to be in compliance with the published EULA.

    2. Documentation on setting up a reverse-proxy generally comes with the software providing that service. One tool that can be used for this purpose is ISA Server (or Forefront TMG, as it's been renamed). There are also several less expensive non-Microsoft solutions that could be implemented as well, the key here is that the product needs to be able to support NTLM authentication, as that's what the WinHTTP client will need to use to authenticate with the proxy server.

    3. Recognize that the GPO only sets the *installation* time for the updates, it does not control the *download* time. For roaming clients, using AUOption '4' and setting an installation time is pretty much an exercise in futility, since you cannot be assured that the remote machines (home-based desktop systems or mobile laptop/notebook systems are actually powered on at the scheduled time). Furthermore, since those systems are typically powered off at normal "installation times", they have a high probability for being trapped into installing updates at power-up -- which can be especially annoying for a roaming business user trying to do actual work at that moment.

    The better solution to use for roaming systems is a nominal level of trust in the users to implement "Install Updates and Shutdown" or interactively install updates (using AUOption '3'), combined with deadlines which will impose the installation of an update if it's delayed too long. They'll learn fairly quickly to take care of updating at a time/place appropriate to their schedule so as to not be inconvenienced if they wait too long. Combining this functionality with an email notification of updates being distributed and an email notification of a pending deadline (perhaps 48-72 hours in advance of the deadline) can be a very useful tool for ensuring compliance with roaming users.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, April 30, 2010 4:47 PM
  • Thank you again for your detailed response. I believe what we'll do is just use our MS certificate authority to verify access for external users. Are you aware of any documentation on how to setup/generate certs for server and clients? I'm not having much luck finding anything.

    Thanks,

    Scott

    Monday, May 3, 2010 4:59 PM
  • "scottyp55" wrote in message news:dfd8a5e5-d5c2-4513-981c-23c31dde5f87...

    Are you aware of any documentation on how to setup/generate certs for server and clients?

    Everything you need to configure the use of SSL for a WSUS Server is documented in the WSUS Deployment Guide.
     
     

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Monday, May 3, 2010 9:13 PM
  • This is perfect. Thanks a lot.
    Tuesday, May 4, 2010 5:02 PM
  • The #2 solution is an i deal solution that seems doable but how can you add a remote computer to the internet facing WSUS server especially the one's that do not belong to the domain?

    Thanks!

    Thursday, April 20, 2017 12:28 PM