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.

Monday, October 31, 2016

Expand a VHD/VHDX with Powershell

In the spirit of the "GUI-less" future that Microsoft and other vendors are pushing, I recently removed the GUI from all of our Hyper-V hosts. Now, I know I'm a bit late to the party on this one. I've been cleaning up a lot of things left over from past generations of IT guys, and removing the GUI from our Hyper-V and SOFS hosts just happened to be one of those things.

Last night we received an alert from OpsMan about one of our VMM servers running low on drive space. I figured, "no problem, I'll just pop into Hyper-V Manager and expand the disk". To my dismay, I quickly remembered that I had removed the GUI. "How the heck am I going to expand that disk???", I quietly said to myself.

In comes Powershell...

Using Powershell I was able to expand the disk within seconds! The cmdlet is simple, you just need to know the path to the VHD/VHDX.

Example:

Resize-VHD -Path \\SOFS01\virtualHardDisk.vhdx -SizeBytes 80GB

Then boot the server, open Disk Management, and extend the volume.

Expand a VHD/VHDX with Powershell

In the spirit of the "GUI-less" future that Microsoft and other vendors are pushing, I recently removed the GUI from all of our Hyper-V hosts. Now, I know I'm a bit late to the party on this one. I've been cleaning up a lot of things left over from past generations of IT guys, and removing the GUI from our Hyper-V and SOFS hosts just happened to be one of those things.

Last night we received an alert from OpsMan about one of our VMM servers running low on drive space. I figured, "no problem, I'll just pop into Hyper-V Manager and expand the disk". To my dismay, I quickly remembered that I had removed the GUI. "How the heck am I going to expand that disk???", I quietly said to myself.

In comes Powershell...

Using Powershell I was able to expand the disk within seconds! The cmdlet is simple, you just need to know the path to the VHD/VHDX.

Example:
Resize-VHD -Path \SOFS01virtualHardDisk.vhdx -SizeBytes 80GB

Then boot the server, open Disk Management, and extend the volume.

Wednesday, October 5, 2016

New Script - Moves All Disabled AD Objects to a Specified OU


The title says it all. This script will move all disabled AD objects to a specified OU. This script accepts parameters that will allow you to specify whether you want to move Users or Computers and the destination OU. It also accepts a "test mode" parameter that will run the script and output the results, without actually modifying Active Directory.

This is revision 1 of the script. There are still several improvements I would like to make, including better error handling and recovery.

If you have any suggestions or requests, please leave a comment.

Download Here

Monday, October 3, 2016

Exchange 2013: Error 0x80070070 While Adding DAG Member



Error: A server-side database availability group administrative operation failed. Error Failed to add or remove the Failover-Clustering feature. Error: The request to add or remove features on the specified server failed. A DISM session could not be opened. An error occurred accessing the temporary folder C:\Windows\TEMP\57ACE2DE-4CD2-4F5F-B7A0-93D867A89A12. Ensure that the path to the temporary folder exists and that you have Read/Write permissions on the folder. Error: 0x80070070



Solution: I was attempting to remotely add the DAG member from the ECP on my workstation. I logged into the server and found that the system drive was nearly full (<100MB free). Luckily this mailbox server was a virtual machine, and I was able to quickly expand the drive using VMM. After doing this I was able to successfully add the mailbox server to the DAG. 

Exchange 2013: Error 0x80070070 While Adding DAG Member

Error: A server-side database availability group administrative operation failed. Error Failed to add or remove the Failover-Clustering feature. Error: The request to add or remove features on the specified server failed. A DISM session could not be opened. An error occurred accessing the temporary folder C:WindowsTEMP57ACE2DE-4CD2-4F5F-B7A0-93D867A89A12. Ensure that the path to the temporary folder exists and that you have Read/Write permissions on the folder. Error: 0x80070070



Solution: I was attempting to remotely add the DAG member from the ECP on my workstation. I logged into the server and found that the system drive was nearly full (<100MB free). Luckily this mailbox server was a virtual machine, and I was able to quickly expand the drive using VMM. After doing this I was able to successfully add the mailbox server to the DAG.

Sunday, April 10, 2016

Script for Setting Max Send/Receive Size for Exchange Online Mailboxes

BulkSet-MessageSize.ps1

Script for Setting the License for Multiple Office 365 User Accounts

A script for setting the Office 365 license for multiple users. Requires a CSV file named users.csv. This file must in the same directory as the script. The CSV file must contain three columns. The title of the columns should be UPN, UsageLocation, and SKU.

BulkSet-MsolUserLicense.ps1

Monday, February 15, 2016

Azure AD Sync - Unable to Update this Object - Values Associated with Another Object

ERROR MESSAGE:
User@contoso.com<mailto:user@contoso.com>
Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [UserPrincipalName user@contoso.com<user@contoso.com>;]. Correct or remove the duplicate values in your local directory. Please refer to http://support.microsoft.com/kb/2647098 for more information on identifying objects with duplicate attribute values

When implementing SMTP soft-matching after a cutover migration, you may see this error if objects in the on-premises AD were not properly prepared to sync.
To fix this, you need access the object in ADUC and set the “E-mail:” attribute to the primary SMTP email address of the user in Office 365. This is how SMTP soft-matching works.



This run another sync and the on-premises AD account should sync up with the Office 365 account. For help with forcing a sync, please see this article:


Follow by Email

Search This Blog