In this recipe, we will look at some of the issues found during the update process, how to deal with them, and how the update process works.
Unfortunately, it's very common to have update issues from time to time, simply because there are a lot of components involved, from Microsoft, through the Internet, through a firewall, and often a proxy for WAN optimization. Then there might even be a Network Intrusion Detection system that analyzes all the traffic going between servers. After that, it should reach your Configuration Manager defined Windows Server Update Services (WSUS), which will fetch and download the updates requested.
A common problem is that Firewalls or proxies may interfere with the download from Microsoft. Now, you may not have any issues with this at all, and it just might work fine. But from my experience what some businesses encounter is that over time firewalls and security features may suddenly start to interfere and block this kind of network traffic.
This is caused by security being increased with good intentions, but on this occasion it's something we don't want; we need to make sure it's working.
I recommend you take steps to ensure good connectivity without interference to Microsoft's Update source, because if this service stops, your Endpoint Protection clients will not be updated with the latest definitions and all your clients will need to use the failover mechanism and fetch updates on their own over an Internet connection.
What you need to get your Network or Firewall administrator to do is to make a pass-through rule for you, allowing the WSUS server full, uncompressed access to the Microsoft Windows Update Download addresses.
The following URL contains the addresses you need to make sure the WSUS can be reached and downloaded from:
https://technet.microsoft.com/nb-no/library/bb693717.aspx
If Configuration Manager Software Update Point and WSUS have issues with downloading updates, it should now show up as red in the Consoles Site Status, as well as on the first information page when you start the Configuration Manager Console, but you can also check a log file, within Configuration Managers log files, named PatchDownloader.log.
At first, when installing and setting up Configuration Manager, the log files are located in …Microsoft Configuration ManagerLogs, as shown in the following screenshot:
PatchDownloader.log file
After you install the Configuration Manager Client on the Site Server, it will start creating the log files in another place, …SMS_CCMLogs, as shown in the following screenshot:
Second place where the PatchDownloader.log file can be found
This often leads to wasted time during troubleshooting because you open the first location where the log file is found, and you figure out that there has been no activity for quite a while. Therefore, you might start troubleshooting in the wrong places.
Another log file we might need to keep an eye on when troubleshooting is the file called wsyncmgr.log, located in the …Microsoft Configuration ManagerLogs.
This will show you what kinds of categories and updates the Server is downloading at the moment.
An example of a healthy downloader log is shown in the following screenshot:
wsyncmgr.log file that shows Software Update WSUS syncronization
Antimalware Policies configure how Definition updates for Endpoint Protection are retrieved in the given order, as shown in the following screenshot.
The updates are not pushed from the SCCM server to the clients. The clients need to fetch the updates for themselves:
Definition Update Sources view from the Endpoint Protection Policy
Now the first three options shown in the preceding screenshot will be utilizing the Windows Update agent within the Windows component:
- From Configuration Manager
- From WSUS
- From Microsoft Update
The next two sources will not depend on the Windows Update agent, as Endpoint Protection will use its own channel to fetch updates:
- From Microsoft Malware Protection Center
- From UNC shares
Remember, as mentioned in Chapter 3, Operations and Maintenance for Endpoint Protection in Configuration Manager, in the Creating and deploying Antimalware policies for Endpoint Protection in Configuration Manager. For the WSUS source to work, you need to enter the WSUS Console and set up the automatic approval of definitions for Endpoint Protection and/or Defender.
Finally, we reach the Windows Client machine, which is either a Windows Server or Windows Workstation Operating System. Troubleshooting definition update issues may be very hard because of all the different time schedules and source orders, as well as the fact that very often, client machines move around on the local LAN, WAN, or Internet. Therefore, you need to pay the most attention to the update statistics in the Configuration Manager console for Endpoint Protection or reporting, as this will give you a good indication of how most of your clients are doing, and whether things are more or less as expected, based on your defined settings.
If most of your clients have not updated in the last 24 hours, this would seem to indicate a misconfiguration and/or a fault.
In the following screenshot, you will see, in the bottom-right section of the page, Definition Status on Computers, where there is a green checkmark named Current, and a number and percentage. This should represent the majority part of your client machines. Now, of course, there can be situations where most of your client machines are laptops that travel a lot, in which case, this would be normal for your business situations. Clients will update directly via the Internet, and will not report back to the Configuration Manager unless you have Internet-Based Client Management (IBCM) configured, Direct Access, or clients working through a VPN. The last two are the easiest to set up. The IBCM requires thorough planning and consideration, as well as PKI Certificates to work. PKI is also required in Direct Access, but is easier to setup and configure, in my opinion. But if you have or are planning to setup and configure PKI Certificates to your SCCM hierarchy there is now a great new feature released in version 1610 of SCCM. It's called Cloud Management Gateway and runs in Microsoft Azure, that allows you to run a Management Point, Software Update Point and Distribution Point, in the Cloud.
The cool thing about that is that clients that travel around only need an Internet connection to talk to SCCM.
The screenshot preceding shows you the Endpoint Protection status, with focus on Definition Status.
Now, the Windows Update agent on Windows machines has issues from time to time. Fortunately, this has greatly improved with Windows 8 and later, but in Windows 7 or earlier, there were many issues where you would need to fix and repair the Windows Update agent.
When troubleshooting on the Windows client side, you would want to check a few steps.
But remember that from time to time, you would need to deploy and update the agent to maintain the clients. Otherwise, you may encounter Update scans failures and so on, causing incorrect compliance status.
The following URL will guide you in this regarding Windows 7, 8, and Server 2008:
You should pay close attention to what KB patches your WSUS Server needs, as well as the Windows Update agent on all your client computers. The Microsoft Configuration Manager Team will guide you with recommendations regarding these components.
Looking further into the Windows clients, first, there is a log file named WindowsUpdate.log located in C:Windows.
You need to check that the URL = http://…… points to the Software Update Point defined for that client and nothing else. This is the number-one check:
If the preceding screenshot looks correct according to your settings and environment, then have a look at the log file named UpdatesHandler.log located in the C:Program FilesSMS_CCMLogs.
It should indicate that it's downloading updates, as shown in the following screenshot:
UpdatesHandler.log
These are new actions you can trigger from the Configuration Manager console after updating to version 1606 or newer. You could also trigger these actions within the Configuration Manager client itself. Otherwise, you would have to wait for the client to do it based on its schedules defined in Client Settings.
If there is a fault with the Windows Update agent, it could be a number of things. Luckily, there are now several good solutions out there to fix and repair all kinds of issues.
An example that you might try on a machine encountering issues is this script from Microsoft Technet:
https://gallery.technet.microsoft.com/scriptcenter/Reset-Windows-Update-Agent-d824badc
That will stop some required dependency Services in Windows Update, and re-register the necessary .dll files.
The end result might also be that the Windows Update Agent becomes out-of-date and does not have the correct version. Thus, it stops working and receiving updates properly.
The huge increase in attacks and vulnerabilities with Windows XP and Windows 7 demanded a large number of security updates. This resulted in the Update module reaching a maximum of 200 round trips. Microsoft is constantly working to improving this, but you need to keep your WSUS and Software Update environment as tidy as possible.