Incorrect Hyper-V Virtual LAN Configuration causes Network disruption

Windows Hyper-V Virtual LAN Configuration Issues

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.

Note: The Hyper-V networking wizard usually produces correct configurations and it is advisable to use this wizard to correct re-do settings. Make a note of any desired IP settings before making any changes. Using the wizard or changing any settings will result in momentary disconnection from the network of any guest operating systems.

Correct Physical and Virtual NIC Configuration

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:

Note: Always make notes or backups of your existing configuration information before making changes.

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:

How to Fix a Domain Controller's slow Hard Drive performance on entry-level Server Systems


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.

Hard Drive Caching Features Disabled by Design

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.

Note: This issue exists as Windows is operating in the way designed by Microsoft, so we cannot recommend that you work-around this issue. Hard drive caching features are disabled so as to guarantee the consistency of the Active Directory (AD) database, especially in the event of an unexpected power outage. We have provided a work-around below for customers that specifically require this, but recommend instead that customers use seperate domain controller and file/print physical servers. Use of the work-around is the customer's responsibility.

Re-Enabling Hard Drive caching Features

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.


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


Reminder: It is recommended to use seperate physical hardware for Domain Controller and File and Print services to work-around this issue, unless using a virtualised environment. This work-around is provided for customers that need to resolve this issue and is provided without warranty. Customers must always ensure that servers are protected by a UPS and that they have tested system backups which include the System State / Active Directory database.

Applies to:

Windows 2008R2 Server Hyper-V wont start - System recently recovered or repaired

Hyper-V Is Not Working after System Recovery



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.

Verifying that the Settings have been installed

Type in BCDEDIT from an Administrative command prompt and check that the nx and hypervisorlaunchtype settings appear as per the example below.

Note: If CPU Virtualisation features were disabled in the BIOS, and then enabled, the system will need to be physically turned off and then started for the setting to take effect.


Applies to:

Additional Steps Required After Renewing your Office 365 SSO / Federated Domain Certificate


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.

Sample Notification of Certificate Renewal Being Required

Additional Steps

If you complete the Microsoft steps and the new certificate is not working, see the attached guide to complete the installation of the certificate.

More Information

For more information, see here.

Tip: For help with generating a certificate signing request without IIS being present, see here.


Applies to:

Why do my Deployed Network Printers No Longer Work? Why am I prompted for Administrator Credentials?



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:

  1. Replace your printer drivers on the print server with new, digitally signed "packaged" versions.
  2. Uninstall KB3170455 from your print server, and then reboot it. Ensure that this update is not automatically reinstalled.
  3. Install the Microsoft Mitigation Update, here - see "Oct 2016 Update: Mitigation for known issues".
  4. Use the work-around below. This is most useful when you cannot obtain updated printer drivers, perhaps for an older device, and does not require changes to the client PCs.

​Work Around

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.



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:

Windows Server Update Services (WSUS) Not Working After May 2016 Windows Update






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:


                  These 4 endpoint bindings are required for supporting both http and https
                <endpoint address=""
                        contract="Microsoft.UpdateServices.Internal.IClientWebService" />
                <endpoint address="secured"
                        contract="Microsoft.UpdateServices.Internal.IClientWebService" />

Additional Recommended Steps Over the Microsoft Instructions

Note: You may still encounter a problem after the above steps with the Wsus Content folder. If you get a Windows Update error 80244017, ensure that <servername>\Users are given Read Permissions on the Content folder, usually c:\wsus\wsuscontent or d:\wsus\wsuscontent

Finally, also ensure that NETWORK SERVICE has Full Control permissions on the same folder.

How to Test that the Issue is Resolved

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/ 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:

Windows Server Update Services (WSUS) Reports Error: Connection Error when trying to Perform Cleanup






Try each resolution in order to resolve the issue.

Initial Steps

Get-WsusServer | Invoke-WsusServerCleanup –CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates


Get-WsusServer | Invoke-WsusServerCleanup -CleanupUnneededContentFiles

Resolution 1

Remove the Wsus Application Pool memory limit

Resolution 2

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

Resolution 3

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();

Resolution 4

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


Get-WsusServer | Invoke-WsusServerCleanup -CleanupUnneededContentFiles


Applies to:

Windows Server Settings App Says that "Windows Cannot Access the Specified Device, Path or File"


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


Applies to:

Third Party Products -> Windows Server -> Troubleshooting