Example:
Try each resolution in order to resolve the issue.
Get-WsusServer | Invoke-WsusServerCleanup –CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates
Or:
Get-WsusServer | Invoke-WsusServerCleanup -CleanupUnneededContentFiles
Remove the Wsus Application Pool memory limit
Re-Index the Database
This fix uses a Microsoft SQL Server Instance to perform scripted maintenance operations on the SUSDB, as a Windows Internal Database (WID) MDF file.
Step 1 - Determine if you are using an SQL Server for your WSUS database, or Windows Internal Database (WID):
Windows Internal Database Re-Indexing
sqlcmd -S np:\\.\pipe\MICROSOFT##WID\tsql\query -i WsusDBMaintenance.sql
SQL Server WSUS Database Re-Indexing
sqlcmd -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query -i WsusDBMaintenance.sql
Attempt to use Powershell to perform a WSUS Cleanup
Import-Module -Name UpdateServices
[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")` | out-null
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();
$cleanupScope = new-object Microsoft.UpdateServices.Administration.CleanupScope;
$cleanupScope.DeclineSupersededUpdates = $true
$cleanupScope.DeclineExpiredUpdates = $true
$cleanupScope.CleanupObsoleteUpdates = $true
$cleanupScope.CompressUpdates = $true
$cleanupScope.CleanupObsoleteComputers = $true
$cleanupScope.CleanupUnneededContentFiles = $true
$cleanupManager = $wsus.GetCleanupManager();
$cleanupManager.PerformCleanup($cleanupScope);
Manually cleanup the WSUS Database using a SQL Script
For a WID WSUS Database
sqlcmd -S np:\\.\pipe\MICROSOFT##WID\tsql\query -i WsusDBCleanup.sql
For an SQL WSUS Database
sqlcmd -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query -i WsusDBCleanup.sql
If disk space is not automatically reclaimed with these methods
Run the following command from an Administrative Powershell prompt:
Get-WsusServer | Invoke-WsusServerCleanup –CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates
Or:
Get-WsusServer | Invoke-WsusServerCleanup -CleanupUnneededContentFiles
Credits:
Applies to:
Entry-level servers that use basic Serial-ATA hard drives may experience slow disk transfers if the server is a Microsoft Windows Domain Controller (DC). Typically file transfers to the server over the network are slow (around 10MB/second or less). File transfers between hard drives or partitions on the actual server itself are also slow.
This issue is caused by the deliberate disabling of hard drive caching features on any system that is a domain controller. A Windows Domain Controller will attempt to disable hard drive caching features on every boot. Typically Windows cannot succeed in disabling caching features on systems equipped with a full hardware RAID controller, but it can succeed in disable caching features on systems equipped with single SATA hard drive.
This setting is visible in Device Manager of the affected system, however on every system boot the features will be disabled again. Both check boxes need to be ticked to restore maximum performance. (The default on any non-Domain Controller system is that at least the top check box is ticked).
To re-enable full hard drive caching features on every boot, use the attached package.
Both fixes use the same utility but with different options. They are both usable on 2008R2 and 2012R2. However the 2012R2 version has been configured to enable caching features on all disks, including SCSI disks. This is needed on modern 2012R2 servers as most IDE or SATA disks now work through AHCI controllers which often, when the right driver has been loaded, appear as SCSI disks to the system. The 2008R2 fix only configures disks that are not recognised as SCSI to the system.
Instructions
Use a Scheduled task to call FIX.BAT on every system startup with a 30 second delay.
The package includes an importable Task Scheduler XML file; however you will need to change the task privledges and use your own Administrator username and password. If you want to use this XML file, you will need to extract the contents of the package to C:\Regfix
Applies to:
When using:
...and logged in using the Domain Administrator account, you may appear to be blocked from carrying out some basic adminstration tasks, including:
You may be presented with the error message below, stating that "Windows cannot access the specified device, path or file. You may not have the appropriate permissions to access the item".
This issue appears to be caused by a missing security policy. This issue has been found to occur on fresh installs on Windows Server when an existing domain administrator account is used, or on upgrade installs of Windows Server (i.e. 2012R2 to 2016) when the same domain administrator account is used.
Edit the local computer security policy to grant
Steps
Applies to:
Scenario:
A recovered or created boot configuration database may not have the required settings to enable Hyper-V to run. To verify this, open an administrative command prompt and type in BCDEDIT. Check the boot settings for the "identifier {current}" collection of settings and verify that the settings "nx" and/or "hypervisorlaunchtype" are missing.
From an administrative command prompt, type the following:
BCDEDIT /set nx OptOut
BCDEDIT /sec hypervisorlaunchtype Auto
Reboot the system and then verify that Hyper-V guests can be started.
Type in BCDEDIT from an Administrative command prompt and check that the nx and hypervisorlaunchtype settings appear as per the example below.
Applies to:
If you use Office 365 and have a federated domain, this relies on important certificates to allow secure communications between your on premises systems, and the Microsoft Office 365 cloud.
Most certificates have an expiry date and periodically needs to be renewed. Usually, you will receive a notification from Microsoft when certificate renewal is required.
When you renew the certificate and follow the instructions, additional steps may be required to complete the process.
If you complete the Microsoft steps and the new certificate is not working, see the attached guide to complete the installation of the certificate.
For more information, see here.
Applies to:
You had a working print environment with deployed network printers which stopped working after you applied Windows Updates to your Print Server on or after 12/7/2016.
End user devices that were reimaged after this time are more prone to the issue as they are less likely to have the required Print driver installed.
Microsoft Windows Update KB3170455 has changed the security associated with Print Servers. Print Servers will now normally only automatically be able to supply printer drivers to end user devices if the printer driver has a signed print driver package, normally supplied in a .CAB file.
There are three potential resolutions to this issue:
This involves changing the PrinterDriverAttributes registry entry per driver to allow Windows to use it as before. The entry tells Windows that the driver is a signed package, even if it is not.
Instructions
What If its a Hexadecimal number?
Use the table below to guide you in changing the PrinterDriverAttributes value.
Last Digital - Old Value | Last Digit - New Value |
0 | 1 |
1 | No Change |
2 | 3 |
3 | No Change |
4 | 5 |
5 | No Change |
6 | 7 |
7 | No Change |
8 | 9 |
9 | No Change |
a | b |
b | No Change |
c | d |
d | No Change |
e | f |
f | No change |
Applies to:
Example:
Carry out the steps indicated in the Microsoft KB article, and then an additional step for configuring the memory limit on the WSUS Application pool.
Microsoft KB Steps Overview:
<services>
<service
name="Microsoft.UpdateServices.Internal.Client"
behaviorConfiguration="ClientWebServiceBehaviour">
<!--
These 4 endpoint bindings are required for supporting both http and https
-->
<endpoint address=""
binding="basicHttpBinding"
bindingConfiguration="SSL"
contract="Microsoft.UpdateServices.Internal.IClientWebService" />
<endpoint address="secured"
binding="basicHttpBinding"
bindingConfiguration="SSL"
contract="Microsoft.UpdateServices.Internal.IClientWebService" />
Additional Recommended Steps Over the Microsoft Instructions
1. Open the WSUS console and run a Synchronisation, and make sure it succeeds.
2. If you are using SCCM and WSUS together, check the Software Update point Synchronisations in SCCM.
Open the "Software Update Point Synchronization Status" under Monitoring, and check that it succeeds.
3. Run Windows Update on a client PC that is configured to get its updates from the WSUS server, and check that the process completes successfully.
4. If you are still having problems, try opening http://fully.qualified.wsusserver.hostname:8530/selfupdate/wuident.cab from a client PC and make sure you can download the CAB file. If you can't check to see if you need a proxy exception to bypass the proxy for the WSUS server.
Applies to:
The configuration of the virtual and physical LAN adapters on a Windows Hyper-V server Host is important. If the adapters are mis-configured then both the Host and Guest operating systems may experience connectivity issues including packet loss, network loops, or network hostname conflicts.
The example below shows three network adapters. One network adapter is unused (and unplugged). The 82579LM adapter is being used to connect the Host and Guest operating systems to the outside world. When the Guests operating systems were created, the Hyper-V wizard allows you to specify an adapter on the Host to be used by the Guests. The Wizard then creates a Virtual Network connection which is used to share the traffic.
The common mistake when troubleshooting any connectivity issues with this configuration is to enable TCP/IP communication for the 82579LM adapter, as you normally would in a standard configuration. Using a Hyper-V setup, the physical adapter should only be bound to the Microsoft Virtual Network Switch Protocol, as below:
The virtual adapter, on the other hand, should be bound to TCP/IP and this where the Host systems IP settings should be maintained. It is not bound to the Microsoft Virtual Network switch protocol:
The screenshot below shows the Virtual Network Manager properties of the Hyper-V server. This illustrates the relationship between the virtual network and the physical adapter. If you have multiple virtual networks, we recommend giving them a useful descriptive name which reminds you which guest operating systems and/or physical network adapter is being used.
Applies to: