Transition from LBFO to SET in Windows Server 2022 for Hyper-V Networking

Load Balancing and Failover (LBFO) refers to the traditional NIC Teaming feature in Windows Server that allows multiple physical network adapters to act as one for load distribution and redundancy. Switch Embedded Teaming (SET) is a newer technology introduced in Windows Server 2016 that integrates NIC teaming directly into the Hyper-V virtual switch​ (Link). The key difference is that LBFO is an independent teaming mechanism at the host level, whereas SET is built into the Hyper-V switch itself (hence “switch embedded”). Microsoft has shifted toward SET for Hyper-V environments because it simplifies the stack and enables advanced capabilities (like RDMA and faster VM networking) not possible with LBFO. Starting with Windows Server 2022, a Hyper-V virtual switch cannot be bound to an LBFO team – it must use a SET team​(Link). (In other words, LBFO is deprecated for Hyper-V networking.) This change was made to improve performance and support new features. For example, SET allows teaming on RDMA-capable NICs and even guest RDMA, as well as features like Dynamic Virtual Machine Queue (Dynamic VMMQ)​(Link), which were not supported with the older LBFO approach. In summary, Microsoft now recommends using SET for Hyper-V networking because it provides better integration with the hypervisor and future-proofs the environment.

Differences between LBFO and SET: LBFO (the older NIC Teaming) offered more flexibility in some ways – it could team a larger number of NICs (in Windows Server 2019/2022, up to 32 adapters could be in one LBFO team) and had no strict requirement that NICs be identical. SET, on the other hand, supports a maximum of 8 physical NICs in a team​(Link) and requires the adapters to be symmetric (same make, model, speed, and configuration) for best results​(Link). Another difference is in teaming modes: LBFO supports various teaming modes including Switch Dependent options (like LACP or static link aggregation) and Switch Independent mode. SET only supports Switch Independent mode, with the Hyper-V switch handling the distribution of traffic​(Link). This means features like LACP are not available with SET, but this simplification reduces complexity in Hyper-V scenarios. In practice, LBFO allowed teaming across mixed adapters and multiple switches, whereas SET requires a uniform set of NICs and is designed to work with the Hyper-V virtual switch exclusively. Microsoft’s decision to shift to SET for Hyper-V reflects the aim to streamline networking for virtualization and enable high-performance features (e.g. SET is the only supported teaming method for new software-defined networking scenarios and Azure Stack HCI). While LBFO was mature and stable, it will not see new improvements for Hyper-V usage (it remains supported only for non-virtualization scenarios). The move to SET ensures Hyper-V networks can leverage modern networking enhancements that the older LBFO teaming could not support.

Workload Support in Windows Server 2022

It’s important to distinguish which scenarios still support LBFO versus those that require SET in Windows Server 2022:

• Non-Hyper-V Workloads (Physical/Standalone Roles): Traditional LBFO NIC Teaming is still fully supported for non-Hyper-V scenarios in Windows Server 2022​ (Link). This means if you have a file server, SQL server, or any standalone server role that benefits from NIC teaming for higher availability or throughput (and not using a Hyper-V virtual switch), you can continue to use LBFO as before. The LBFO management UI and PowerShell (New-NetLbfoTeam, etc.) are still present for these use cases. For example, teaming NICs for a standalone cluster heartbeat network or a general active/passive failover team on a physical server is allowed with LBFO.

• Hyper-V and Virtualization Workloads: Any scenario involving a Hyper-V virtual switch (i.e. networking for virtual machines) must use Switch Embedded Teaming (SET) in Windows Server 2022. The Hyper-V virtual switch will not bind to an LBFO team interface in this release​(Link). If you attempt to create an External vSwitch on an existing LBFO NIC team, it will be blocked (the Hyper-V Manager GUI in 2022 will throw an error, as LBFO for vSwitch is deprecated). Instead, the NIC teaming for Hyper-V needs to be done via SET as part of the vSwitch creation. This applies to Hyper-V hosts and scenarios like Software Defined Networking (SDN) or Azure Stack HCI as well. (For instance, Azure Stack HCI and other SDN solutions only support SET for host teaming, not LBFO​(Link).) In summary, any workload involving virtual machine networking in WS2022 requires SET, whereas LBFO is reserved for legacy purposes outside of virtualization.

To put it simply: Use LBFO for non-virtualized roles; use SET for Hyper-V hosts. Microsoft’s support stance reflects this – the change “only applies to Hyper-V” and LBFO remains supported for other scenarios​(Link), but if you’re running Hyper-V, the recommended and supported teaming method is SET.

SET Teaming Configuration (PowerShell Steps)

Configuring a Switch Embedded Teaming team for Hyper-V in Windows Server 2022 can be done with PowerShell. Below are step-by-step instructions to set up a SET team optimized for Hyper-V, incorporating Microsoft’s recommendations for performance tuning:

1. Plan and Prepare – Identify the physical NICs on the Hyper-V host that will form the SET team. Ensure these NICs have identical link speed and capabilities (it’s best if they are the same model and firmware) because SET requires symmetric adapters for optimal performance​(Link). For example, if you plan to team two 10 GbE adapters for your virtual switch, verify both are from the same vendor/model and running at 10 Gbps. Also ensure no existing LBFO team is configured on them; the physical NICs should be standalone and enabled.

2. Create the Hyper-V Switch with Embedded Teaming – Use the New-VMSwitch cmdlet to create a new external virtual switch and specify multiple NICs for the -NetAdapterName parameter. This will automatically create a SET team as part of the switch. For example:

   New-VMSwitch -Name "HyperV-TeamSwitch" -NetAdapterName "NIC1","NIC2" -AllowManagementOS $true -EnableEmbeddedTeaming $true

   In this command:

   • "HyperV-TeamSwitch" is the name of the new virtual switch (you can choose any friendly name).
   • -NetAdapterName "NIC1","NIC2" specifies the two physical network adapters to team. Replace "NIC1","NIC2" with the actual interface names of your adapters (as shown by Get-NetAdapter). You can list up to 8 NICs here for a SET team (the limit supported by SET)​(Link).
   • -AllowManagementOS $true (optional) allows the host OS to share this NIC team for management traffic. Include this if you want the Hyper-V host itself to have an IP on the teamed interface (commonly true if this team also carries host management or cluster traffic).
   • -EnableEmbeddedTeaming $true explicitly tells Hyper-V to create an embedded team. (Note: When you provide multiple NICs, PowerShell treats it as a SET team automatically. This switch is a safeguard, especially if using one NIC now and adding others later.)

   This single command replaces the old multi-step process of creating an LBFO team then attaching a vSwitch. It creates the virtual switch and teams the NICs in one step, since the teaming is integrated into the switch with SET. After running New-VMSwitch, you should have a new vSwitch visible (e.g., in Hyper-V Manager or via Get-VMSwitch) and the physical NICs will be part of the switch’s team.

3. Optimize Load Balancing Algorithm – By default, a SET team uses the Dynamic load-balancing algorithm​(Link), which in many cases is fine. However, Microsoft documentation recommends using the Hyper-V Port algorithm for best performance on high-speed adapters (10 Gbps and above)​(Link). Depending on your workload and NIC speed, you may want to set the algorithm to HyperVPort. You can configure this using the Set-VMSwitchTeam cmdlet. For example:

   Set-VMSwitchTeam -Name "HyperV-TeamSwitch" -LoadBalancingAlgorithm HyperVPort

   This command changes the team named "HyperV-TeamSwitch" to use Hyper-V Port mode for load balancing. (The TeamingMode is implicitly SwitchIndependent for SET and cannot be changed – SET doesn’t support LACP​(Link), so no need to specify the teaming mode.) The Hyper-V Port algorithm distributes network traffic based on the virtual switch port (essentially per-VM distribution). This mode ensures each VM’s traffic is affinitized to a particular physical NIC, which can improve throughput consistency and avoid packet reordering on 10 GbE+ networks​(Link). If your host has many VMs or you are using very fast NICs, Hyper-V Port mode is often beneficial. On the other hand, Dynamic mode (the default) uses a combination of port and flow hashing to spread traffic and can yield better NIC utilization in some scenarios (it attempts to use all team members for outbound traffic). You should choose the mode based on Microsoft’s best practices: Hyper-V Port for 10 Gbps or higher NICs (and many VMs), Dynamic for general purpose or lower-speed networks​(Link)(Link). You can always adjust this setting with Set-VMSwitchTeam after initial setup.

4. (Optional) Additional Tuning – If your deployment requires features like SR-IOV or RDMA, ensure to configure those on the vSwitch at creation. For SR-IOV, include -EnableIov $true in the New-VMSwitch command (assuming your adapters support SR-IOV). For RDMA on a SET, make sure the physical NICs support RDMA and consider using Set-VMNetworkAdapter to enable Virtual RSS (vRSS) on the VM adapters for better scalability of network processing. Also verify that features like Virtual Machine Queue (VMQ) are enabled on each physical NIC. In Windows Server 2022, these are usually enabled by default when using SET, but it’s good to double-check (you can run Get-NetAdapterVmq on each team member). The goal is to follow Microsoft’s performance tuning guidance for Hyper-V networking: enable offloads and virtualization features that are compatible with SET. (SET inherently allows Dynamic VMMQ, which automatically distributes incoming VM traffic processing across multiple CPU cores, improving performance on high throughput links​(Link).)

By following the above steps, you will have created a Hyper-V switch that uses Switch Embedded Teaming under the hood, providing both redundancy and load balancing for your Hyper-V host’s networking. This configuration is fully supported in Windows Server 2022 and aligns with Microsoft’s recommended practices for Hyper-V networking.

Hyper-V Port vs. Dynamic Load Balancing Modes in SET

When using SET, there are two load balancing algorithms available for distributing traffic across the teamed NICs: Hyper-V Port and Dynamic(Link). Understanding these modes and when to use each is important for optimizing network performance on Hyper-V hosts:

• Hyper-V Port Mode: In this mode, each virtual switch port (which typically corresponds to a VM’s virtual network adapter, or the host’s management vNIC) is tied to a specific physical NIC in the team. All traffic for a given VM will egress through one team member interface (though inbound traffic to the host is automatically balanced by the Hyper-V switch across NICs based on VM port as well). This one-VM-to-one-NIC mapping ensures no single VM’s traffic is split across multiple physical NICs. The benefit is that it avoids potential issues with out-of-order packets and is easier on upstream switches (each VM’s MAC/IP consistently comes from one NIC, preventing “flapping”). Microsoft notes that Hyper-V Port is often the best choice for high-bandwidth networks – specifically, it is recommended for NICs 10 Gbps or faster to achieve optimal performance​(Link). In environments with many VMs, Hyper-V Port mode naturally spreads the VMs across the physical NICs (e.g. one VM’s traffic on NIC1, another on NIC2, etc.), achieving load distribution at a per-VM level. Use Hyper-V Port mode if you have very fast adapters or if you’ve observed better stability with it in your network. It’s particularly suited for scenarios where each VM can generate significant traffic on its own, as it guarantees that VM can use up to one NIC’s worth of bandwidth without interference from load-balancing algorithms.

• Dynamic Mode: Dynamic is a more complex algorithm that combines elements of both outbound flow-based distribution and inbound port-based distribution. In practical terms, Dynamic mode will distribute outgoing traffic across the team NICs based on flow hashing, and still use Hyper-V Port for inbound traffic to ensure stability. Microsoft set Dynamic as the default load balancing algorithm for SET teams​(Link) because it aims to utilize all NICs efficiently even if a single VM is very busy. For example, if one VM’s traffic is heavy, dynamic mode can spread different TCP streams (flows) from that VM across multiple NICs, potentially exceeding the throughput of a single NIC. This can maximize aggregate bandwidth (as seen in some cases where dynamic mode allowed using the full team bandwidth). Dynamic mode is generally recommended by Microsoft for most scenarios since it provides a good balance of load distribution. However, it can be more sensitive to switch configurations – because multiple NICs may carry traffic for the same VM or IP, your physical switch (if not in a stable configuration for independent teaming) might log MAC address moving or “IP flapping” alerts. In a properly configured Switch Independent scenario (no EtherChannel/LACP on the switch ports), dynamic mode should work well. Use Dynamic when you want the team to automatically balance traffic and you have relatively moderate NIC speeds (1 GbE or 10 GbE where each VM alone might not saturate a NIC). It’s the default for a reason: in many deployments it yields the best overall throughput distribution across a team.

Best Practice: For Windows Server 2022 Hyper-V, start with the default Dynamic mode, but consider switching to Hyper-V Port mode on hosts with 10 GbE or higher NICs, or if you encounter stability issues with dynamic. Microsoft’s official guidance suggests Hyper-V Port on >=10 Gbps networks for best performance​(Link), as mentioned. Remember that in all cases with SET, the teaming mode is always Switch Independent (the physical switch does not need special configuration)​(Link), so these algorithms operate at the host level. If you change the algorithm with Set-VMSwitchTeam, the change takes effect immediately and you can monitor performance to decide which works better for your environment. Both modes will provide fault tolerance (failover to the remaining NIC if one fails), so the choice mainly impacts load balancing behavior.

Verification Steps for SET Configuration

After setting up a SET team for Hyper-V, you should verify that the configuration is correct and optimized as intended. Use the following PowerShell commands and checks to confirm a successful deployment:

• List the Virtual Switch and Team Members: Run Get-VMSwitchTeam -Name "<SwitchName>" to retrieve information about the switch’s team. For example:

  Get-VMSwitchTeam -Name "HyperV-TeamSwitch"

  This command will display the details of the SET team associated with the switch “HyperV-TeamSwitch.” You should see output listing the Team Members (the physical NICs in the team), the TeamingMode (which will show as SwitchIndependent), and the LoadBalancingAlgorithm (Dynamic or HyperVPort, depending on what you configured)​(Link)(Link). Verify that all expected NICs are present in the team and that the load-balancing mode matches your intended setting. For instance, if you set Hyper-V Port mode for performance, ensure the output shows LoadBalancingAlgorithm : HyperVPort. If anything is incorrect, you can re-run the Set-VMSwitchTeam command to adjust settings.

• Check the Virtual Switch Properties: You can also run Get-VMSwitch -Name "<SwitchName>" | Format-List * to see detailed properties of the virtual switch. In the detailed output, confirm that AllowManagementOS is set to True (if you intended the host to have access), and look at the NetAdapterInterfaceDescription or NetAdapterName field which should list the teamed adapters. This confirms the switch is indeed bound to the multiple physical adapters (indicating a SET team). Additionally, the SwitchType should be External (for an external vSwitch). While this cmdlet doesn’t explicitly enumerate team members as clearly as Get-VMSwitchTeam, it’s useful for checking that the switch was created with the correct parameters.

• Validate NIC Status: Ensure all physical NICs in the team are up and functioning. Use Get-NetAdapter -Name "<NIC1>","<NIC2>" to check the link status and speed of each member NIC. Each should show Status: Up and the expected LinkSpeed (e.g., 10 Gbps). If a NIC is down or has a mismatched speed, the team may not perform optimally. All team members should be connected to the appropriate switch ports with identical configurations (no VLAN set on one and not the other, etc.). Remember that SET requires symmetric configuration on the NICs​(Link), so any discrepancy here should be fixed at the network or adapter level.

• Test Connectivity and Failover: Although not a PowerShell one-liner, a practical verification is to ensure that VMs and the host (if applicable) have network connectivity through the new SET switch. You can create or attach a test VM to the “HyperV-TeamSwitch” and assign it an IP to ping out. Try disconnecting one of the physical NIC cables (or disabling one NIC) and ensure traffic continues on the remaining NIC (the ping should continue without dropping more than a packet or two during failover). This tests the failover aspect of the team. For load balancing verification, you might monitor the NIC traffic counters (using Performance Monitor or Get-NetAdapterStatistics) while generating load from multiple VMs to see that both NICs in the team are carrying traffic. This is more of a manual test, but it confirms that the SET team is functioning as expected in both load balancing and redundancy.

• Review Event Logs (if needed): The Hyper-V Virtual Switch will log events if something is misconfigured. After setting up, check the System event log for any Hyper-V Networking or VMSMP warnings/errors. For example, an event about “an LBFO team may not be attached” would indicate an attempt to use LBFO where not supported (which our configuration avoids by using SET). No such errors should be present if the SET team is correctly configured for the vSwitch.

By performing the above verification steps, you can be confident that the transition to SET was successful. The Get-VMSwitchTeam output is the clearest confirmation – it shows that your Hyper-V switch is indeed using SET with the intended NICs​(Link). You should see SwitchTeam information indicating SwitchIndependent mode and either Dynamic or HyperVPort load balancing (with all members listed). This confirms you’re using the supported configuration on Windows Server 2022 (since an LBFO team would not appear here – instead, Get-NetLbfoTeam would list it if one existed, but in our case we bypass LBFO). Once verified, your Hyper-V host’s networking is now running on Switch Embedded Teaming, which is the Microsoft-endorsed solution moving forward. This ensures you can take advantage of the latest Hyper-V networking performance features and that you’re in line with the support policy for Windows Server 2022 Hyper-V​(Link).

Sources:

• Microsoft Docs – Features removed or deprecated in Windows Server 2022: Hyper-V switch no longer supports LBFO teams​
  docs.microsoft.com
  .
• Microsoft Docs – Windows Server Supported Networking Scenarios: Introduction of Switch Embedded Teaming (SET) for Hyper-V and SDN​
  learn.microsoft.com
  .
• Microsoft Docs – Azure Stack HCI Networking (Host network requirements): SET overview and requirements (symmetric NICs, up to 8 adapters, supported algorithms)​
  learn.microsoft.com
  ​
  learn.microsoft.com
  ​
  learn.microsoft.com
  .
• Microsoft Docs – Hyper-V PowerShell Reference: Set-VMSwitchTeam parameters (SwitchIndependent only, LB algorithms HyperVPort/Dynamic)​
  learn.microsoft.com
  ​
  learn.microsoft.com
  .
• Microsoft Docs – Hyper-V PowerShell Reference: Using Get-VMSwitchTeam to view SET team members​
  learn.microsoft.com

Failover Cluster VM Load Balancing in Windows Server

Windows Server 2016 introduced the Virtual Machine Load Balancing feature for Failover Clusters. This feature optimizes node utilization by redistributing VMs based on memory pressure and CPU utilization. In this blog post, we will explore the command and usage of this feature.

Heuristics for Balancing:

VM Load Balancing considers two heuristics:

• Current Memory pressure: Evaluates the memory usage of each node.
• CPU utilization: Monitors CPU usage averaged over a 5-minute window.

Controlling Aggressiveness of Balancing:

To configure the balancing aggressiveness:

Open PowerShell.
Run (Get-Cluster).AutoBalancerLevel = <value>

AutoBalancerLevel values:

1. (default): Low aggressiveness, moves VMs when host is >80% loaded.
2. Medium aggressiveness, moves VMs when host is >70% loaded.
3. High aggressiveness, averages nodes, and moves VMs when host is >5% above average.

Controlling VM Load Balancing:

To configure when load balancing occurs:
Using Failover Cluster Manager:

1. Right-click on cluster name, select "Properties."
2. Go to the "Balancer" pane and configure desired settings.

Using PowerShell:

1. Open PowerShell.
2. Run (Get-Cluster).AutoBalancerMode = <value>

AutoBalancerMode values:

• 0: Disabled.
• 1: Load balance on node join.
• 2 (default): Load balance on node join and every 30 minutes.

VM Load Balancing vs. SCVMM Dynamic Optimization:

For deployments without SCVMM, VM Load Balancing provides in-box functionality. However, for SCVMM deployments, SCVMM Dynamic Optimization is recommended for load balancing. SCVMM automatically disables VM Load Balancing when Dynamic Optimization is enabled.

PowerShell Quick and dirty add a user to AD

New-ADUser <USERNAME>
Set-ADAccountPassword <USERNAME> -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "<PASSWORD>" -Force -Verbose) -PassThru
Add-ADGroupMember -Identity "<GROUPNAME>" -Members <USERNAME>
enable-adaccount -identity "<USERNAME>"

Backing up a Windows Domain Controller

This will depend on number of domain controllers you have but the over all idea is that if you have a DC running on your network it is best practise to use backup software that is Application aware as restoring the DC in a crash consistent state may lead to data lost within the Active Directory.

Single Domain Controller network
Application Aware backup can be optional but really why chance it.  If the backup that was taken was not application aware it may suffer data lost but should be ok ish.

Multi Domain Controller network
100% Application aware,  if you restore a single DC in to a network with multiple DC you will end up triggering a USN Rollback and this is a silent error.

Also if you are restoring the DC the backups age can be no longer then the AD tombstone lifetime or again you will have issues.

If the DC is 2012 or higher it has added support for Hyper-Visor Generation ID (GenID). This allows the virtual guest to detect the disk volumes that have a new ID, and respond to the new GenID. In Active Directory, Directory Services reacts as if the domain controller was restored from a backup. It then generates a new Invocation ID. By using the new Invocation ID, the database instance can to safely re-enter replication in the forest.

Virtualizing Domain Controllers using Hyper-V | Microsoft Docs

Virtual Active Directory Domain Services Domain Controllers Hyper-V | Microsoft Docs

Determine the tombstone lifetime for the forest | Microsoft Docs

How to detect and recover from a USN rollback in a Windows Server-based domain controller - Windows Server | Microsoft Docs

How to back up and restore domain controllers on Hyper-V (altaro.com)

Re-registering VSS Writers on Windows Server

 Some times when you have a retryable error in VSS its a good step to re-register the dll and restart the service.

to do this you will need to run the following commands in command prompt as admin

c:
cd c:\windows\system32
net Stop VSS
net Stop SWPRV
regsvr32 /s ole32.dll
regsvr32 /s oleaut32.dll
regsvr32 /s vss_ps.dll
vssvc /register
regsvr32 /s /i swprv.dll
regsvr32 /s /i eventcls.dll
regsvr32 /s es.dll
regsvr32 /s stdprov.dll
regsvr32 /s vssui.dll
regsvr32 /s msxml.dll
regsvr32 /s msxml3.dll
regsvr32 /s msxml4.dll
vssvc /register
net Start SWPRV
net Start VSS
pause

doing it as a bat file saves some time

Powershell Script to reset Windows 2016+ Remote Desktop Host firewall

This a quick script to reset a Windows Servers firewall and insert the fix for cleaning down the rules when user logs off on a Remote Desktop Host.

#Powershell

Remove-Item "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System"
New-Item "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System"
Remove-Item "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\AppIso\FirewallRules"
New-Item "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\AppIso\FirewallRules"
(New-Object -ComObject HNetCfg.FwPolicy2).RestoreLocalFirewallDefaults()
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy' -Name  'DeleteUserAppContainersOnLogoff' -Value '1' -PropertyType 'DWORD' –Force

#EOF

Getting started with Windows AppLocker

AppLocker is a great way to limit the applications a user has access to within Windows 10 or Remote Desk Host systems.

Its quick and easy to get going and once its up and running you can add and change as needed.  Ideally you wan to start it in audit mode only as this way you will get to see what is happening on the Remote Desktop Hosts or the local workstation.

At first you are going to need to make a GPO and give it a name.  it runs at the computer level and not the user so you can disable the user part of the GPO if you do that sort of thing.

The settings are located in Computer Configuration > Polices > Windows Settings > Security Settings > Application Control Polices > AppLocker

Once you are there right click on the "AppLocker" and select "Properties" and mark the polices wish to enforce.

I would suggest at first you set it audit only, so you can monitor what would of happened if it was used.

Once you have set it to audit click "Ok" which will bring you back to the GPO and the AppLocker polices.

Right click on each policy you have enabled and select "Create Default Rules"

This will give a base line of how it just look.

From here you can adjust and add as needed,  just be carful with how many rules you make as each time an application runs the AppLocker will run the rule set until it finds a match and if not kept lean could appear to slow down applications and GPO processing.

Some system variables can be used in path rule condition and some can not,  I found that %USERPROFILE% was not accepted but you can replace it with a wildcard as such "C:\Users\*\APPDATA\LOCAL\MICROSOFT\TEAMS\" say if you wish Microsoft Teams to still work.

Once the policy is set up the only thing left is that you need is to start the Application Identity service other wise the AppLocker will not be enabled on the RDH / local workstation.  you can do this in the GPO under the "System Services" part not the "Services" part but I also like to stick a start for it in "Services" too.

Now its up and running you can check the devices event logs to see what is happening,  the AppLocker logs can be found in.

Applications and Services Log > Microsoft > Windows > AppLocker

Each policy has its own log and Event ID:8003 shows what would of been blocked if the policy was enforced.

Monitor this log for sometime and adjust the AppLocker rules until you are happy then switch to enforce on the GPO.

AppLocker (Windows 10) - Windows security | Microsoft Docs

Requirements to use AppLocker (Windows 10) - Windows security | Microsoft Docs

Optimize AppLocker performance (Windows 10) - Windows security | Microsoft Docs

Understanding the path rule condition in AppLocker (Windows 10) - Windows security | Microsoft Docs

Using Event Viewer with AppLocker (Windows 10) - Windows security | Microsoft Docs

Configure the Application Identity Service | Microsoft Docs

IIS HTTPS redirect via web.config

 Open web.config and insert the following

<system.webServer>   
   <rewrite> 
      <rules> 
      <rule name="Force HTTPS" enabled="true">   
   <match url="(.*)" ignoreCase="false"/>   
   <conditions>   
      <add input="{HTTPS}" pattern="off"/>   
   </conditions> 
   <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent"/> 
      </rule> 
      </rules> 
   </rewrite>
</system.webServer>

If you already have <system.webserver> headings,  just insert this code in there and remove the duplicate heading.

If you using Lets encrypt for SSL you will need to do the following instead

         <rewrite>
            <rules>
                <rule name="Allow LetsEncrypt" patternSyntax="Wildcard" stopProcessing="true">
                    <match url=".well-known/*" />
                    <action type="None" />
                </rule>
                <rule name="Redirect HTTP to HTTPS" patternSyntax="Wildcard" stopProcessing="true">
                    <match url="*" ignoreCase="false" />
                    <conditions>
                        <add input="{HTTPS}" pattern="off" />
                    </conditions>
                    <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" />
                </rule>
            </rules>
        </rewrite>

Port Exhaustion and DNS server on Windows 2012 / 2008

Seen an old issue on some servers where the DNS server starts to trigger port exhaustion on a server, this can lead to the server starting to act really weird, applications will start the time out, window shares will stop working but some may remain if the connection was made before it happened.

The problem is that once you have it you can not check as the server is half locked up and may not running any applications so you have to reboot which in turn removes the issue.

but if its DNS getting out of control you can see this by running the following as administrator in cmd

netstate -aon

Which will show you all the ports that the system has open,  if you notice a process id taking an usually amount of ports, say like the DNS Server process taking a lot even when restarted you can limit this with the follow reg key.

• Open regedit.exe and expand the HKLM hive
• Navigate to SYSTEM\CurrentControlSet\services\DNS\Parameters
• Create a new DWORD value named SocketPoolSize
• Set a decimal value between 0 and 10000
• Restart the DNS Server service: net stop dns && net start dns

I would recommend starting at 500 and see the network response and if you get any DNS issue increase until you get a nice balance.

I would also recommend DNS servers to be they own OS and not mixed with everything else like a resurrected SBS system as they where the primary sources of port exhaustion.

Port Exhaustion and You (or, why the Netstat tool is your friend) - Microsoft Tech Community

Windows Remote Desktop host seeing alot of .BACKUP-## folders in C:\Users

 Not 100% show on why this happens but it appears to be related to User Profile disks and users not logging off correctly and some issues with he UPD storage.

First step would be to put limits in place on the sessions times so that users get logged out even then they forget too.  Staff training also would be a bonus on how to do it correctly.

Once you have that set you are still going to see a few and they are going to need to be cleaned down.  a good script I have found is located here

PowerShell/Remove-LocalUPDProfiles.ps1 at master · andy2002a/PowerShell · GitHub

And it uses the Delprof2 application from here

Download Delprof2, SetACL (Studio) • Helge Klein

This cleans down the profiles and check if the user is in the system before it does.  I normally run it at night using a schedule.

Also if you are storing your UPD on a share I would recommend disabling share caching on the share its self.  This can have a performance impact but its more stable when logging off.

Remote Desktop Host firewall is filled with multiple firewall rules

Every time a user connects in to the RDH,  firewall rules are made for the users Windows Apps but never cleaned down.

This can have a few issues linked to it like Black screening on the host or the start menu not displaying but depending on the Windows version you mileage will vary.  In all case it can lead to slowing down of the system.

For Windows Server 2016 you will need to confirm the following update is installed KB4467684,  Server 2019 should already be able to do this but I would bring it in line with all updates to just be sure.

Make a GPO if you have more then 2 RDH and put this Key in place.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy
DeleteUserAppContainersOnLogoff (DWORD)
Value: 1

No Microsoft document appears to back this up but it is listed in a few updates and talked about as a known issue under KB4467684

Windows Sysprep for Virtual Machine

1.  run command prompt as Administrator
2. cd C:\Windows\System32\Sysprep
3. run "sysprep.exe /oobe /generalize /shutdown /mode:vm"

Windows Server Performance issues - Power options

 This is a little basic, but when looking at server performance make sure that the Power options are set to High Performance

This has a impact on the system and can help with some low level performance issues.  all servers guest and hosts.

Can be done via group policy Computer > Administrative Templates > System> Power Management > Select An Active Power Plan

Windows Hyper-V 2019 failed merge of snapshot with error 0x8007054F

 This is not a good fix and am not happy with it... seems a little too much like the nuclear option but it works and at the moment Microsoft are not being to forthcoming with answers and we seem to be stuck between the backup company and them pointing the fingers at each other,

I will update if we get a better fix.

But for now if you are seeing phantom snapshots where if you restart the Hyper V machine management server it will try to merge then fail with the following error code

0x8007054F

The issue appears to be the root parent, not being able to merge with the last checkpoint.  so you could roll all the AVHDX files back to the first one and that last one will not merge back with the primary disk.

Update #1 (02/12/2020)
After manually merge a few servers it is clear the issue is only with the System drive / First drive in the VM config.

Not sure if it because its the system drive or its the first one in the list in the VM config, but removing it from the VM config allows it too start merging the other drives as soon as the config is save.  this has allowed us to save a lot of time and cut down the work we need to do in the sort time.

Update #2 (07/12/2020)
Seems update 1 was false.  Although all up to that date had been the system drive / first one in the VM config the last two I cleaned up was data drives.  both at the end of the VM config list.

Still waiting on an update from Microsoft on this.

Update #3 (14/01/2021)
Microsoft are asking for the VM to be deleted and remade so that it makes a new VM ID,  we are testing this and will update if this has an impact.

Update #4 (09/02/2021)
The VM we have remade have not had issue with check pointing but the others have not either so its still up in the air at the moment.

Update #5 (10/03/2021)
Confirmation this week that the issue has returned on guests where we have not remade the VM config but the ones we have are still running fine and merging back even on the same host.

Short term fix
The quickest way I have found so far to resolve this is to do the Following

1. Shutdown the virtual machine
2. Break and remove replication if its enabled
3. Open the virtual machines settings
4. Take a note of the disk and location of the VM has set,  should end in a AVHDX
5. Remove the disk
6. Open Hyper-V and select "Edit Disk" point it to the AVHDX you noted in point 4 and select "Merge"
7. Once on the Merge options select new disk and give it a name and a location
8. Attach this new disk to the virtual machine in the same controller as the one you removed
9. Boot the VM and confirm its working
10. Remove old VHDX and AVHDX files
11. Enable replication if you disabled it.

Doing it this way can be risky so always check your backups but it does work.

Windows Assessment and Deployment Kit (Windows ADK)

Windows Assessment and Deployment Kit (Windows ADK) is a great tool for helping you see performance issues with signing in and booting up a system.

I have used it for Remote Desktop hosts to see where the processing is getting tied up.

Just need to download the right version from

https://docs.microsoft.com/en-us/windows-hardware/get-started/adk-install

When you are installing make sure you select the "Windows Performance Toolkit"

when its finished opened cmd as Administrator and type the following

xperf -on PROC_THREAD+LOADER+INTERRUPT+DPC+PROFILE+DISK_IO+HARD_FAULTS+DRIVERS+NETWORKTRACE+ALL_FAULTS -stackwalk profile -SetProfInt 1221

Then get the user to log in or log off depending on what your monitoring and once its finished switch back to the user that ran the above command and type

xperf -d <filename>.etl

This information was found on

https://forums.ivanti.com/s/article/HOWTO-Create-Detailed-User-Logon-Performance-Logging-with-Windows-Performance-Analyzer?language=en_US

A program is trying to send an e-mail message on your behalf warning in Outlook

 If you are using a Remote Desktop host and Outlook, you may come across an issue with 3rd party applications trying to send email.

Outlook will give you an warning saying that "A program is trying to send an e-mail message on your behalf"

The quick fix is to add a reg key (DWARD) setting the ObjectModelGuard to 2 as outlined in the following

https://docs.microsoft.com/en-us/outlook/troubleshoot/security/a-program-is-trying-to-send-an-email-message-on-your-behalf

The location changes based on if you have Office MSI, click to run, and 32 bit or 64 bit installed but its also in the following key

Office\<x.0>\Outlook\Security

x being the version of Outlook installed.

If this does not work you can also try the following keys in the same location

"promptsimplemapisend"=dword:00000002
"promptsimplemapinameresolve"=dword:00000002
"promptsimplemapiopenmessage"=dword:00000002
"promptoomsend"=dword:00000002
"promptoommeetingtaskrequestresponse"=dword:00000002
"promptoomaddressinformationaccess"=dword:00000002
"promptoomsaveas"=dword:00000002
"promptoomformulaaccess"=dword:00000002
"promptoomaddressbookaccess"=dword:00000002
"adminsecuritymode"=dword:00000003

But this was the older way to do it and ObjectModelGuard should be the go to at first.