Friday, November 18, 2016

WSUS: Update Files Not Downloading (Content File Download Failed)

This article will discuss an issue regarding WSUS failing to download updates from Microsoft Update servers. You may notice that the home page of your WSUS console states that it has downloaded 0MB of updates:


You may also see this event (or similar) in the Event Log. 


This problem is caused by not specifying a valid path when assigning the WSUS content drive when first installing the role. The first time you load the WSUS console after installing the role, you will be prompted to specify the path to store Windows Update files. WSUS does not like to have its content directory be the root of a partition. For example, if I were to specify "e:\" as the path for the Windows Update content, the wizard would give you an error message stating that the path is not valid. However, it doesn't prompt you to re-enter the path if you click close. The WSUS console opens immediately after and that invalid path is where WSUS will try to store your update files. This is and has been a known bug for a while and needs to be addressed by Microsoft. Evidence of the invalid path can be found in the registry under:

HKLM\Software\Microsoft\Update Services\Server\Setup\ContentDir


If you come across this problem, you can change the ContentDir above to a valid path. Keep in mind that it cannot be the root of a partition. You need to specify a drive letter with a subfolder (eg: e:\wsus).


The other option is to reinstall the WSUS role. If you remove the role, the WID database is not removed, unless you remove that role as well (or manually delete the database). This means that when you reinstall the WSUS role, it will be able to use that same database and any clients that have contacted the WSUS server will immediately show up in the console. The same is true for update metadata. The new WSUS installation will still have the same approvals, denials, etc. as the old installation.

Regardless of what option you choose, I suggest rebooting the server after you make the changes.

WSUS: Update Files Not Downloading (Content File Download Failed)

This article will discuss an issue regarding WSUS failing to download updates from Microsoft Update servers. You may notice that the home page of your WSUS console states that it has downloaded 0MB of updates:




You may also see this event (or similar) in the Event Log.




This problem is caused by not specifying a valid path when assigning the WSUS content drive when first installing the role. The first time you load the WSUS console after installing the role, you will be prompted to specify the path to store Windows Update files. WSUS does not like to have its content directory be the root of a partition. For example, if I were to specify "e:" as the path for the Windows Update content, the wizard would give you an error message stating that the path is not valid. However, it doesn't prompt you to re-enter the path if you click close. The WSUS console opens immediately after and that invalid path is where WSUS will try to store your update files. This is and has been a known bug for a while and needs to be addressed by Microsoft. Evidence of the invalid path can be found in the registry under:

HKLMSoftwareMicrosoftUpdate ServicesServerSetupContentDir

If you come across this problem, you can change the ContentDir above to a valid path. Keep in mind that it cannot be the root of a partition. You need to specify a drive letter with a subfolder (eg: e:wsus).


The other option is to reinstall the WSUS role. If you remove the role, the WID database is not removed, unless you remove that role as well (or manually delete the database). This means that when you reinstall the WSUS role, it will be able to use that same database and any clients that have contacted the WSUS server will immediately show up in the console. The same is true for update metadata. The new WSUS installation will still have the same approvals, denials, etc. as the old installation.

Regardless of what option you choose, I suggest rebooting the server after you make the changes.

Thursday, November 10, 2016

WSUS: An error occurred trying to connect the WSUS server

Ran into this error message when configuring a new WSUS server:


Restarted the WSUS, WID, and IIS services to no avail. I even rebooted the server. The WSUS console would work for a short period of time, and then would randomly stop working.

I found that the WSUS app pool in IIS was being disabled anytime new clients connected to the server. I believe this was because the app pool was running out of usable memory. 


You can manually start the app pool in IIS, but it will continue to crash. 



The solution for me was to increase the memory limit available for the application pool:


By default it is only configured to use just under 2 GBs. I reconfigured it to use up to 4 GB and the WSUS console has not crashed since. After re configuring the memory for the application pool, run an IIS reset or reboot the server.




UPDATE: Setting the Private Memory Limit to "0" will allow the application pool to use whatever amount of memory it needs.

WSUS: An error occurred trying to connect the WSUS server

Ran into this error message when configuring a new WSUS server:




 
Restarted the WSUS, WID, and IIS services to no avail. I even rebooted the server. The WSUS console would work for a short period of time, and then would randomly stop working.


I found that the WSUS app pool in IIS was being disabled anytime new clients connected to the server. I believe this was because the app pool was running out of usable memory.



 
You can manually start the app pool in IIS, but it will continue to crash.




The solution for me was to increase the memory limit available for the application pool:



 
By default it is only configured to use just under 2 GBs. I reconfigured it to use up to 4 GB and the WSUS console has not crashed since. After re configuring the memory for the application pool, run an IIS reset or reboot the server.

 

UPDATE: Setting the Private Memory Limit to "0" will allow the application pool to use whatever amount of memory it needs.

Wednesday, November 9, 2016

WDS Service: The Service did not respond in a timely fashion...

This was a new one for me. Usually WDS is rock solid and it just works.

Anyway, I was getting ready to deploy some servers in my lab and found that I couldn't get WDS to start on my deployment server. I got this error message when trying to start the service:



I then tried to start the service from the Services console and got this error message:


"This was just working yesterday", I said to myself. What could possibly have happened since yesterday evening that could cause this? I looked in the event log and after scrolling through the Administrative Events, I found this:


The solution was so obvious it was staring me in the face, but I wanted to verify first. So I fired up a cmd prompt and ran netstat, and found this:



I had installed DHCP on this server the night before and totally forgot about it. Anyway, the solution was simple. I just needed to tell the WDS service to not listen on port 67. To do that, just open the WDS server properties and got to the "DHCP" tab. Then check the box next to "Do not listen on DHCP Ports".


I was then able to start the DHCP service.

WDS Service: The Service did not respond in a timely fashion...

This was a new one for me. Usually WDS is rock solid and it just works.

Anyway, I was getting ready to deploy some servers in my lab and found that I couldn't get WDS to start on my deployment server. I got this error message when trying to start the service:



I then tried to start the service from the Services console and got this error message:


"This was just working yesterday", I said to myself. What could possibly have happened since yesterday evening that could cause this? I looked in the event log and after scrolling through the Administrative Events, I found this:


The solution was so obvious it was staring me in the face, but I wanted to verify first. So I fired up a cmd prompt and ran netstat, and found this:



I had installed DHCP on this server the night before and totally forgot about it. Anyway, the solution was simple. I just needed to tell the WDS service to not listen on port 67. To do that, just open the WDS server properties and got to the "DHCP" tab. Then check the box next to "Do not listen on DHCP Ports".


I was then able to start the DHCP service.

Follow by Email

Search This Blog