none
WSUS & Remote Users

    Question

  • I know i can do this either 2 ways. But, i am not sure on how to do this.  I need to make sure my remote users are getting their updates.  

    How do i say if WSUS is not availble then go to microsoft to grab the update.  Or how do i set it up to grab the updates remotely. 

    If you need anymore information please let me know. Thanks in advance. 
    Thursday, February 19, 2009 1:04 PM

Answers

  • I'm not saying there is "No Way" to manage remote users... we've discussed remote users special needs in this forum and the newsgroup for many months and there are several options available.

    What I'm saying is that you cannot auto-fallback to using Automatic Updates when the machine is not physically connected.

    Here are some options to consider for managing remote users:

    1. If you have machines that routinely use VPN connectivity, consider setting up a VPN-only no-content WSUS Server. The remote machines obtain update approvals from the WSUS Server, but download content directly from download.microsoft.com. Combine this with scheduled installation and/or "Install Updates and Shutdown", and possibly deadlines, to ensure machines are updated in a timely manner.

    2. If you have machines that only occassionally use VPN connectivity, they might be better served by not being managed by WSUS. Alternatively, you might implement a quarterly half-day mandatory system servicing requirement. (Every other piece of equipment in an organization needs to be taken out of service from time to time for preventive maintenance -- we should treat computer equipment, including workstations, in exactly the same fashion.)

    3. For a slightly more complex scenario, you could implement a logon script that temporarily assigns the client system to a WSUS Server, executes a detection/reporting event, and then reconfigures the client back to using Automatic Updates. There's a bitflag in the WUA key of the registry, "UseWUServer", that determines whether the client system uses update.microsoft.com, or a local update services server (e.g. WSUS). By simply flipping this bit you can bounce a machine back and forth between AU and WSUS.

     

     


    Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    Thursday, February 19, 2009 4:36 PM

All replies

  • Generally speaking, there is no "fallback" capability in this regard.


    Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    Thursday, February 19, 2009 1:45 PM
  • So there is no way to manage my remote users updates? If they are not physically connected to our network,
    Thursday, February 19, 2009 3:08 PM
  • I'm not saying there is "No Way" to manage remote users... we've discussed remote users special needs in this forum and the newsgroup for many months and there are several options available.

    What I'm saying is that you cannot auto-fallback to using Automatic Updates when the machine is not physically connected.

    Here are some options to consider for managing remote users:

    1. If you have machines that routinely use VPN connectivity, consider setting up a VPN-only no-content WSUS Server. The remote machines obtain update approvals from the WSUS Server, but download content directly from download.microsoft.com. Combine this with scheduled installation and/or "Install Updates and Shutdown", and possibly deadlines, to ensure machines are updated in a timely manner.

    2. If you have machines that only occassionally use VPN connectivity, they might be better served by not being managed by WSUS. Alternatively, you might implement a quarterly half-day mandatory system servicing requirement. (Every other piece of equipment in an organization needs to be taken out of service from time to time for preventive maintenance -- we should treat computer equipment, including workstations, in exactly the same fashion.)

    3. For a slightly more complex scenario, you could implement a logon script that temporarily assigns the client system to a WSUS Server, executes a detection/reporting event, and then reconfigures the client back to using Automatic Updates. There's a bitflag in the WUA key of the registry, "UseWUServer", that determines whether the client system uses update.microsoft.com, or a local update services server (e.g. WSUS). By simply flipping this bit you can bounce a machine back and forth between AU and WSUS.

     

     


    Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    Thursday, February 19, 2009 4:36 PM
  •  

    As this thread has been quiet for a while, we assume that the issue has been resolved. At this time, we will mark it as ‘Answered’ as the previous steps should be helpful for many similar scenarios.

    If the issue still persists and you want to return to this question, please reply this post directly so we will be notified to follow it up. You can also choose to unmark the answer as you wish.

    In addition, we’d love to hear your feedback about the solution. By sharing your experience you can help other community members facing similar problems.

    Thanks!

    Thursday, February 26, 2009 9:39 AM