Skip to main content

SCCM with WSUS in DMZ serving Internet Facing clients

By

SCCM with WSUS in DMZ serving Internet Facing clients

Overview:

This Blog will document at a high level my experience of implementing a 'Software Update Point' on a site server in our DMZ to serve SCCM clients (including Workgroup servers) on the Internet.
It will explain the implementation process as well as expected behaviour by diving into the log files on both the site server and client.

Please ask questions in the comments field; and I will update the main narrative in response.

Architectural design overview

  • One Primary site server on Internal network
  • One Site system Server within DMZ
    • Ports opened on firewall to allow servers to communicate.
    • Configured with the following System roles:
      • Management point
      • Distribution point
      • Software update point
  • Work group servers within the DMZ/Internet facing clients only

The Site system Server within DMZ had the WSUS role installed through 'Server Manager' console. Within IIS a webserver certificate was added to the binding port 8531

On the Primary site server the Software Update Point role was added the Site system Server within DMZ. The connection type set to 'Internet only client connections'.
Even though we set the webserver certificate within the binding we do not need to click 'Require SSL communications...' as the workgroup systems require PKI certificates and all communication is set to the SSL.


Within the Monitoring Workspace> System Status>Site Status the new SUP role will be displayed. Right click and Show all Messages. Review messages and ensure the role installed and started.

Within the Software Library Workspace> Software updates> All Software Updates right click and select 'Synchronize Software Updates'.
Go back the Monitoring Workspace> 'Software Update Point Synchronization Status' ensure there is the new SUP server and that it is a down stream server from the Primary site. The initial sync will take upwards of 30 minutes and progress can be reviewed wsyncmgr.log on the Primary server.


The SCCM environment is now aware of the additional SUP server and as it is Internet facing and configured to respond to Internet-only clients it will become the preferred choice for theWorkgroup servers within the DMZ/Internet facing clients.
When these clients 'Software Updates Scan Cycle' occurs they will assess the SCCM environment and the locationservces.log will update the WSUS path with the new SUP server. 


This WSUS path is updated within LocalPolicy and the WindowsUpdate registry value is updated.


Now that the role is installed and client is pointing at the correct SUP server. It will check in for policy and review available Software update packages. Internet clients will always download the content from the Internet first and if this fail then attempt to download from a DP.


Content is downloaded and installed as a normal deployment as seen within Software Center.







Labels:

Comments

  1. UnknownDecember 6, 2018 at 2:22 AM

    Thank you for the valuable information. this really helps

    ReplyDelete

Post a Comment

Popular posts from this blog

SCCM Unknown computer not able to see Task Sequences after installing Current Branch 1702

By
Soon after installing SCCM CB 1702 we were unable to see Task Sequences deployed to the unknown collection. This issue was identified as a random system taking the GUID of the 'x64 Unknown Computer (x64 Unknown Computer)' record. As a result it was now a known GUID; as we were only deploying Task Sequences to the Unknown collection none were made available. 'x64 Unknown Computer (x64 Unknown Computer)' record 'x86 Unknown Computer (x86 Unknown Computer)' record To get the GUID of your unknown systems open SQL management studio and run the following command: --Sql Command to list the name and GUID for UnknownSystems record data select ItemKey, Name0,SMS_Unique_Identifier0 from UnknownSystem_DISC Using the returned GUID (SMS_Unique_Identifier0) we can find the hostname that has been assigned the 'x64 Unknown Computer (x64 Unknown Computer)' GUID by running the query below. --x64 Unknown Computers select Name0,SMS_Unique_Identifier0,Decommissioned0 from Sys...
161 comments
Read more

Windows 7 Offline files will not go Online when connected to network

By
Issue Several laptop users move between networks, domain, home, etc and when they attempt to access DFS shares explorer status is working offline.  The issue only resolves it self after a reboot. Connecting directly to the share works and i am able to ping network resources.  This behavior occurs for VPN users as well. Possible Causes "slow-link mode". In win7 (with default settings) a client will enter slow-link mode if the latency to the server is above 80ms. In slow-link mode all writes are made to the local cache and a background sync only happens every 6 hours.  Depending on your connection the default slow link detection speed is 64,000 bps On client computers running Windows 7 or Windows Server 2008 R2, a shared folder automatically transitions to the slow-link mode if the round-trip latency of the network is greater than 80 milliseconds, or as configured by the "Configure slow-link mode" policy. After transitioning a folder to the slow-link mode, Offline Fil...
151 comments
Read more

SCCM Software Update - Job error 0x80004005 Failed to Add Update Source for WUAgent

By
SCCM Software Updates - Failed to Add Update Source for WUAgent  Today I have been looking at a range of servers (Server 2008 /R2 2012 /R2) that were failing to communicate with the Software Update Point (SUP) in SCCM and retrieve deployment policy. The UpdateDeployment.log was reporting the Job error 0x80004005 Job error (0x80004005) received for assignment ({af7a48e6-d550-4070-dd9b-ecc234567584}) action UpdatesDeploymentAgent 12/6/2017 10:32:27 AM 2096 (0x0830) The WUAHandler.log  was reporting "Unable to read existing WUA Group Policy object" and "Failed to Add Update Source for WUAgent " Unable to read existing WUA Group Policy object. Error = 0x80004005. WUAHandler 12/6/2017 3:41:00 AM 2828 (0x0B0C) Failed to Add Update Source for WUAgent of type (2) and id ({3AAB6A76-CE2D-4E8A-9F11-123AE69612A1}). Error = 0x80004005. WUAHandler 12/6/2017 11:03:31 AM 2276 (0x08E4) Until the agent can report back to the SUP, SCCM will not be able to summarize Software Update sta...
4 comments
Read more