WSUS – Force immediate update installation on clients February 10, 2013 Leave a comment I've seen heaps of guides about this topic, but all seem to miss a key point which makes the client download and install update immediately without any intervention on the client. WSUS (Windows Server Update Services) is a fundamental, free add-on program and network service developed by Microsoft which assists IT administrators in the effective management of the download and distribution of updates, patches and hot-fixes released for Microsoft software products to Windows Server operating systems in their network through the use of automation and continuous analyses.
We were having some issues with upgrading clients to the Windows 10 1809 build. They would recognize that the update was available but would stick at 0% in the download process then fail. I checked all different things on the server as recommended from TechNet but nothing seemed to work. After digging a little deeper I noticed that the files are packaged as an .esd file. Looking at the MIME types in IIS I didn't see an entry for .esd. Below are some quick and easy steps that corrected our issue with how IIS handles the .esd file.
7 Steps total
Step 1: Open IIS Manager on WSUS server
Step 2: Expand Sites node and select WSUS Administration
Step 3: Select MIME Types on WSUS Administration Home screen
Step 4: On the right Actions pane click Add
Step 5: Enter the File extension and MIME type
File name extension will be .esd and the MIME type will be application/octet-stream
Step 6: Reset IIS or restart the WSUS server
Step 7: Retry the update on the client machine
This quick fixed saved us a lot of headache. After changing the way IIS handles the .esd all updates have worked without a hitch. Hopefully if you're having the same issue this will fix it for you.
0 Comments
Download Free Force Wsus Client Check Updates Download
We're using WSUS 3.0 to update our environment with the latest Windows Updates. Overall usage is fairly simple… however…
I found that sometimes when a lot of updates had to be installed on a server, not all approved updates were downloaded to the server. The majority was downloaded and after rebooting the server when these updates were installed, windows update failed to detect and download the rest of the required updates within a reasonable amount of time. Restarting Windows update services didn't help, and neither did the command ‘wuauclt /detectnow'.
When using WSUS there are a few thing you need to take into account. Consider the process:
- A computer reports it's status to the WSUS server
- WSUS checks this status against the updates available since the last synchronization (once a day)
- Required updates are marked as ‘needed‘ in the WSUS console
- Needed updates are approved and downloaded(*) to the WSUS server
- The computer checks for updates and downloads them as needed
- Updates are installed
There is a difference between ‘reporting status‘ and ‘detection‘ of new updates.
In the first step the computer reports it's status to the WSUS server. By default this is being done every 22 hours unless you change the setting in group policy. After reporting status to the WSUS-server the computer stores the information in a cookie and will not report it's status untill these 22 hours have passed. This means that if your server has reported status and detected 13 updates that it can install in a first run, while you have approved 22 updates for this server in WSUS, the server will download and install these first 13 updates and probably ask you to reboot afterward.
When you check the logfile (C:WindowsWindowsUpdate.log) after the reboot you will find that the other 9 updates are not detected after the reboot. Furthermore, when you open a command prompt and execute the command ‘wuauclt /detectnow' you will probably find the log to state ‘0 updates detected'. The reason for this is that the server has not reported status back to the WSUS-server(as mentioned in step 1 above) between detection and installation of the first 13 updates (step 6) and the last detection after the reboot and since this is the case, the WSUS server will think these 13 updates have not been installed yet and will not offer the last 9 updates. The server will not report status untill 22 hours later unless the cached cookie is deleted and the server is forced to report status to the WSUS-server…
Very, very annoying…
So can we do this?… Yes we can…
Open up a command prompt and execute the following command:
- wuauclt /detectnow /resetauthorization
The commandline option resetauthorization tells windows update to get rid of the cached cookie. The log will still tell you ‘0 updates detected' because this command does not tell windows update to report status.
After having performed this command open up services.msc and restart Windows Update Service.
We were having some issues with upgrading clients to the Windows 10 1809 build. They would recognize that the update was available but would stick at 0% in the download process then fail. I checked all different things on the server as recommended from TechNet but nothing seemed to work. After digging a little deeper I noticed that the files are packaged as an .esd file. Looking at the MIME types in IIS I didn't see an entry for .esd. Below are some quick and easy steps that corrected our issue with how IIS handles the .esd file.
7 Steps total
Step 1: Open IIS Manager on WSUS server
Step 2: Expand Sites node and select WSUS Administration
Step 3: Select MIME Types on WSUS Administration Home screen
Step 4: On the right Actions pane click Add
Step 5: Enter the File extension and MIME type
File name extension will be .esd and the MIME type will be application/octet-stream
Step 6: Reset IIS or restart the WSUS server
Step 7: Retry the update on the client machine
This quick fixed saved us a lot of headache. After changing the way IIS handles the .esd all updates have worked without a hitch. Hopefully if you're having the same issue this will fix it for you.
0 Comments
Download Free Force Wsus Client Check Updates Download
We're using WSUS 3.0 to update our environment with the latest Windows Updates. Overall usage is fairly simple… however…
I found that sometimes when a lot of updates had to be installed on a server, not all approved updates were downloaded to the server. The majority was downloaded and after rebooting the server when these updates were installed, windows update failed to detect and download the rest of the required updates within a reasonable amount of time. Restarting Windows update services didn't help, and neither did the command ‘wuauclt /detectnow'.
When using WSUS there are a few thing you need to take into account. Consider the process:
- A computer reports it's status to the WSUS server
- WSUS checks this status against the updates available since the last synchronization (once a day)
- Required updates are marked as ‘needed‘ in the WSUS console
- Needed updates are approved and downloaded(*) to the WSUS server
- The computer checks for updates and downloads them as needed
- Updates are installed
There is a difference between ‘reporting status‘ and ‘detection‘ of new updates.
In the first step the computer reports it's status to the WSUS server. By default this is being done every 22 hours unless you change the setting in group policy. After reporting status to the WSUS-server the computer stores the information in a cookie and will not report it's status untill these 22 hours have passed. This means that if your server has reported status and detected 13 updates that it can install in a first run, while you have approved 22 updates for this server in WSUS, the server will download and install these first 13 updates and probably ask you to reboot afterward.
When you check the logfile (C:WindowsWindowsUpdate.log) after the reboot you will find that the other 9 updates are not detected after the reboot. Furthermore, when you open a command prompt and execute the command ‘wuauclt /detectnow' you will probably find the log to state ‘0 updates detected'. The reason for this is that the server has not reported status back to the WSUS-server(as mentioned in step 1 above) between detection and installation of the first 13 updates (step 6) and the last detection after the reboot and since this is the case, the WSUS server will think these 13 updates have not been installed yet and will not offer the last 9 updates. The server will not report status untill 22 hours later unless the cached cookie is deleted and the server is forced to report status to the WSUS-server…
Very, very annoying…
So can we do this?… Yes we can…
Open up a command prompt and execute the following command:
- wuauclt /detectnow /resetauthorization
The commandline option resetauthorization tells windows update to get rid of the cached cookie. The log will still tell you ‘0 updates detected' because this command does not tell windows update to report status.
After having performed this command open up services.msc and restart Windows Update Service.
Micro sd card amazon. After restarting the service open up C:WindowsWindowsUpdate.log and wait untill you see something like this in the log:
2009-10-28 11:05:50:358 820 13b8 Report Uploading 2 events using cached cookie, reporting URL = http://wsus.server.fqdn/ReportingWebService/ReportingWebService.asmx
Download gdc calculator for macshedprogram. Ad&d players dmg pdf. 2009-10-28 11:05:50:358 820 13b8 Report Reporter successfully uploaded 2 events.
Force Wsus Client To Download Updates And Install
This means the server has contacted WSUS and reported its status back. It can take up to 10-15 minutes for the server to report these entries in the log and unfortunately does not always succeed. If after 10 -15 minutes these entries are not logged, repeat these steps one more time.
Share this
