Step by Step: How To Deploy Hyper-V Extended Port ACLs in System Center Virtual Machine Manager 2012 R2 with UR8 #HyperV #SCVMM

8 min read

Hello folks,

Your feedback is very important to the VMM team. Microsoft is listening to you. The requested features on user voice for Virtual Machine Manager (VMM) 2012 R2 UR8 are now available, deploy extended Hyper-V Port ACLs and support for Storage Spaces Tiering .

For the complete list of features that included in Update Rollup 8, please check here. As you already know that deploying extended Port ACLs and Storage Spaces tiering in VMM was not possible.

The good news is, the Virtual Machine Manager (VMM) team has announced support to deploy extended Hyper-V Port ACLs and Storage Spaces Tiering in VMM 2012 R2 Update Rollup 8.

In today’s blog post, I will show you how to deploy and validate extended Port ACLs, and in the next post I will walk you through how to deploy Storage Spaces Tiering in SCVMM 2012 R2 UR8.

For more information about Extended Port ACLs and how to deploy them natively in Hyper-V, please make sure to check this post Hyper-V Virtual Switch Extended Port ACLs in action.

After you install and verify Update Rollup 8 for Virtual Machine Manager here, you can move to below section:

With the introduction of VMM 2012 R2 UR8 update, administrators can now centrally create and manage port ACLs for their tenants VMs.

What you can do with this Feature?

  • Define ACLs & their ACL Rules.
  • Attach the ACLs created to VM Network, Subnets or Virtual Network Adapters.
  • Attach the ACL to a Global ACL for all Virtual Network Adapters.
  • Verify ACL and ACL Rules.
  • View & Update ACL Rules configured on the vNIC.
  • Delete ACL Rules.

Each of these actions are covered in more details below. Please note that this functionality is only exposed through PowerShell at the moment and will not reflect in the VMM Console UI. Please vote on user voice if you want to manage Port ACLs in the VMM Console as well.

Defining new ACL & their Rules

You can now create ACLs & their ACL rules directly from within VMM using PowerShell. The PowerShell module for Virtual Machine Manager has been expanded with 8 new cmdlets.

The PowerShell cmdlet to create a New ACL is the following:

New-SCPortACL –Name <string> [–Description <string>] followed by name and description for the ACL. To define the ACL rules, you need to use New-SCPortACLRule

New-SCPortACLRule -PortACL <PortACL> -Name <string> -Action <Allow | Deny> -Type <Inbound | Outbound> -Priority <uint16> -Protocol <Tcp | Udp | Any> [-SourceAddressPrefix <string: IPAddress | IPSubnet>] [-SourcePortRange <string:X|X-Y|Any>] [-DestinationAddressPrefix <string: IPAddress | IPSubnet>] [-DestinationPortRange <string:X|X-Y|Any>] [-Description <string>]

In this article, I will create a new ACL rule to allow HTTP traffic from all subnets, then limit RDP traffic only to a specific IP Subnet, and deny all other traffic.

New-SCPortACL –VMMServer SCVMM01 –Name DEMO-ACL01 –Description "Allow HTTP All, Limit RDP Access"

As you can see after you create a new ACL, the PortACLRules {} value is empty.

Next, we need to define ACL rules using New-SCPortACLRule –PortACL where <PortACL> is the new ACL created in the previous step.

$SCPortACL = Get-SCPortACL -VMMServer SCVMM01

New-SCPortACLRule -VMMServer SCVMM01 -Name "HTTPRule" -PortACL $SCPortACL -Description "Allow HTTP Rule" -Action Allow -Type Inbound -Priority 100 -Protocol Tcp -SourcePortRange 80 –Verbose

One important point to mention about Priority in VMM versus Weight in Hyper-V Port ACLs, If you checked my previous post about Hyper-V Virtual Switch Extended Port ACLs in action, you will notice that the higher Weight value will take precedence, however in VMM the lower Priority value will take precedence.

Next, we need to allow RDP access from a specific MGMT subnet.

New-SCPortACLRule -VMMServer SCVMM01 -Name "RDPRule" -PortACL $SCPortACL -Description "Allow RDP Rule From MGMT Subnet" -Action Allow -Type Inbound -Priority 110 -Protocol Tcp -SourcePortRange 3389 -DestinationAddressPrefix –Verbose

Next, we need to allow DNS/AD access for all subnets.

New-SCPortACLRule -VMMServer SCVMM01 -Name "ADDNS-Rule" -PortACL $SCPortACL -Description "Allow AD/DNS Rule" -Action Allow -Type Inbound -Priority 115 -Protocol Any -DestinationAddressPrefix -Verbose

Last but not least, we will deny all remaining traffic.

New-SCPortACLRule -VMMServer SCVMM01 -Name "DenyALL" -PortACL $SCPortACL -Description "Deny All Rule" -Action Deny -Type Inbound -Priority 120 -Protocol Any -SourcePortRange Any –Verbose

If you run, Get-SCPortACL you will see four ACL rules that have been added to the ACL.

Attaching Port ACLs

After defining the new ACL and their rules, we need to attach them, Port ACLs can be attached to a VM Network (for No-Isolation type only) or to a VM Subnet (Hyper-V Network Virtualization HNV, VLAN and External isolation type) and/or to (Virtual Network Adapters). ACL to VM Network/Subnet is a 1:1 relationship. However, one ACL can be attached to multiple Virtual Network Adapters. You can attach the new ACL using the below Powershell cmdlets for each type:

VM Network (only No Isolation type VM Network):

New-SCVMNetwork –PortACL <NetworkAccessControlList> [Rest-of-the-parameters]

Set-SCVMNetwork –PortACL <NetworkAccessControlList> –RemoveNetworkAccessControlList [Rest-of-the-parameters]

These rules will be applied to all VM virtual network adapters connected to this network.

VM Subnet (only VM Subnets – Hyper-V Network Virtualization HNV, VLAN and External):

New-SCVMSubnet –PortACL <NetworkAccessControlList> [Rest-of-the-parameters]

Set-SCVMSubnet –PortACL <NetworkAccessControlList> –RemoveNetworkAccessControlList [Rest-of-the-parameters]

These rules will be applied to all VM virtual network adapters connected to this Subnet.

Virtual Network Adapter (includes Host vNIC and vmNICs in both cmdlets):

New-SCVirtualNetworkAdapter –PortACL <NetworkAccessControlList> [Rest-of-the-parameters]

Set-SCVirtualNetworkAdapter –PortACL <NetworkAccessControlList> –RemoveNetworkAccessControlList [Rest-of-the-parameters]

These rules can be attached to multiple Virtual Network Adapters including Host vNIC if you are using Converged Network Fabric in VMM

In this demo, I will attach the new ACL to VM Network (No Isolation), so the ACL rule will be applied to all Virtual Machines vmNICs connected to this network.

I will attach the newly created ACL using Set-SCVMNetwork because the VM Network exist in my environment, then followed by the parameter <PortACL> which is the new ACL created in the previous step.

$SCPortACL = Get-SCPortACL -VMMServer SCVMM01 
$SCVMNetwork = Get-SCVMNetwork | where {$_.Name –eq "Corp VM Network"}
Set-SCVMNetwork -VMMServer SCVMM01 -PortACL $SCPortACL -VMNetwork $SCVMNetwork –Verbose 

To confirm if the ACL is attached to VM Network, you can use Get-SCVMNetwork:

Get-SCVMNetwork | Where {$_.Name -eq "Corp VM Network"} | FL Name, IsolationType, PortACL

Verify ACL and ACL Rules

Now in order to verify and test the ACL and ACL rules is being applied to the Virtual Machines virtual network adapters connected to VM network, you need to refresh the VM and then remediate the vmNICs in VMM Admin Console.

After you refresh the VM, click on the Fabric Node and then click on Virtual Machines in the Ribbon.  Select the virtual adapter that you applied the ACL to, you should see the Network Compliance show up as “Not Compliant“. When the adapter is in this state, the Remediate button should be enabled.  Click it and the ACL should take affect at this time.

Let’s remediate all adapters and then test the ACL.

After you remediate the vmNIC adapter, you can verify the Extended Port ACL by accessing the Hyper-V host and run (Get-VMNetworkAdapterExtendedAcl)

As you can see the ACL rules are applied, please remember Weight in Hyper-V Port ACLs (higher value will take precedence!).

Let’s see this in action!

As you can see Ping failed, however HTTP on port 80 is reachable.

The next test is to check RDP access from the management VLAN.

RDP is accessible from the management subnet.

Now let’s check RDP access from different subnet.

And finally, let’s check other type of traffic…

Fantastic! everything is working as expected.

Viewing ACL Rules

To view the ACLs & ACL Rules, you can use the following PowerShell cmdlets:


ParamSet 1: All/By Name

Get-SCPortACL [-Name <>]

ParamSet 2: By id

Get-SCPortACL -Id <> [-Name <>]


ParamSet 1: All/By Name

Get-SCPortACLRule [-Name <>]

ParamSet 2: By id

Get-SCPortACLRule -Id <>

ParamSet 3: By AccessControlListId

Get-SCPortACLRule –PortACL <NetworkAccessControlList>

Updating ACL Rules

When you update the ACL attached to virtual network adapters, the changes are reflected in all the network adapter instances using that ACL. For an ACL attached to a VM Subnet or VM Network, all the network adapter instances connected to that subnet/network are updated with the new changes.

Note: The task of updating ACL Rules “physically” on individual network adapters is done in parallel in a one-try best-effort scheme – for those that can’t be updated for any reason are marked “security incompliant” but the task finishes successfully with an error message stating the network adapters that were not updated successfully. Security incompliant here refers to compliance errors on a virtual network adapter due to mismatch in expected vs actual ACL rules. As per existing model, the adapter has a compliance state of “Not compliant” along with relevant error messages.

To update an ACL rule, we need to use Set-SCPortACLRule

Set-SCPortACLRule [-PortACLRule] <PortACLRule> [[-Description] <string>] [-Type <PortACLRuleDirection> {Inbound | Outbound}] [-Action <PortACLRuleAction> {Allow | Deny}] [-SourceAddressPrefix <string>] [-SourcePortRange <string>] [-DestinationAddressPrefix <string>] [-DestinationPortRange <string>] [-Protocol <PortACLRuleProtocol> {Tcp | Udp | Any}]

I will update the “DenyAllInbound” rule to deny only a specific IP subnet.

Set-SCPortACLRule -PortACLRule $SCPortACLRule -DestinationAddressPrefix

Deleting ACL & ACL Rules

An ACL can only be deleted if there are no other dependencies attached to it. Dependencies include VMNetwork/VMSubnet/VMNetworkAdapter/GlobalPortACL attached to the ACL. When you try to delete a PortACL using the PowerShell cmdlet it will detect if the PortACL is attached to any of the dependencies and will throw appropriate error messages.

Note that deleting a VM subnet/network adapter automatically removes the association with that ACL. An ACL can also be dis-associated from the subnet/network adapter by modifying the subnet/network adapter.

PowerShell cmdlet to delete an ACL:

Remove-SCPortACL -PortACL <NetworkAccessControlList>

PowerShell cmdlet to delete an ACL rule:

Remove-SCPortACLRule -PortACLRule <NetworkAccessControlListRule>

Out of Band Changes to ACL Rules

If you are doing Out of Band (OOB) changes to ACL Rules from Hyper-V vSwitch side, VM Refresh in VMM will show the NIC as “Security Incompliant“. The Network Adapter can then be repaired from VMM using the below PowerShell Cmdlet. However, remediation will overwrite all the Rules done from Hyper-V side with the rules as expected by VMM!

Repair-SCVirtualNetworkAdapter – VirtualNetworkAdapter <VirtualNetworkAdapter>

More Information

The description of the Update Rollup 8 for System Center 2012 R2 Virtual Machine Manager is here.

Until then… see you in the next post!


About Charbel Nemnom 560 Articles
Charbel Nemnom is a Cloud Architect, ICT Security Expert, Microsoft Most Valuable Professional (MVP), and Microsoft Certified Trainer (MCT), totally fan of the latest's IT platform solutions, accomplished hands-on technical professional with over 17 years of broad IT Infrastructure experience serving on and guiding technical teams to optimize the performance of mission-critical enterprise systems. Excellent communicator is adept at identifying business needs and bridging the gap between functional groups and technology to foster targeted and innovative IT project development. Well respected by peers through demonstrating passion for technology and performance improvement. Extensive practical knowledge of complex systems builds, network design, business continuity, and cloud security.

Be the first to comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.