Resolving Windows Server DirectAccess Network Location Server DNS Scavenging Issue.

A few weeks after deploying DirectAccess in my infrastructure environment, I encountered an issue where DirectAccess stopped working . My first step was to check the Operational Status of DirectAccess in the Remote Access Management console of the DirectAccess server.

The Network Location Server status was flagged as Critical as indicated in the screen shot.


My first step was to attempt to ping the the network location server DNS record:

PS C:\Windows\system32> ping
Ping request could not find host Please check the name and try again.

I opened the DNS console and couldn’t find the the DNS record for the NLS record. The record was deleted because I have DNS scavenging turned on in my environment.

To resolve this issue, I ran through the DirectAccess Server Infrastructure Server Setup wizard. After running through the wizard, I clicked Finish to apply the changes and create the Network Location Server DNS name automatically. After confirming the DNS name was created successfully in the DNS console, right click on the NLS record and select properties to turn off “Delete this record when it becomes stale” . Click apply and Ok . This step should prevent DNS Scavenging from removing the record at the next aging cycle.


I hope someone finds this helpful as it helped me.

Posted in DirectAccess | Tagged , , , , | Leave a comment

Configuring Azure Site to Site VPN to my On-Premise Infrastructure using the Azure Classic Portal.

I’ve been exploring the requirements for extending my on premise infrastructure to the Microsoft Azure IaaS public cloud. Azure Site to Site IPsec VPN is a key part of achieving that objective.There are two deployment models in Azure; the Azure Service Manager(Using the Azure Classic Portal) and the Azure Resource Manager (the new Azure Portal). My deployment steps in this implementation use the Azure Classic Portal. Moving forward though, I intend to use the Azure Resource Manger for future deployments.The following are key requirements:

1) Public IP Addresses of both VPN Endpoints (Azure and On Premise environments).
2) A Pre-shared key.
3) Remote Networks of both Endpoints.

Azure Side VPN Components:

1) Azure Virtual Network and address space.(The private address range with Subnet Mask. Allows you to add private IP Addresses to your servers and Azure side virtual machines.)
2) Local Network.(Public IP Address of the Endpoint we are establishing a VPN with.Also contains the remote networks which can be found at the remote endpoint.This tells the VPN where it might find our on premise networks.)
3) The Azure Gateway.(The public IP of our Azure Endpoint.Routing type is set up here:Dynamic Routing enables multi site to site VPN and Static routing enables only Site to Site VPN.)
4) The Azure VPN Scripts.(Azure generated VPN script that auto configures the remote endpoint on premise RRAS Server).

The IP Address space in Azure is specified using the CIDR notification (Classless Interdomain Routing. A way of subnetting networks into smaller networks to save addresses).

Required Azure VPN Firewall Ports:
UDP 1701
UDP 4500
UDP 500
Protocol 50

The steps are as follows:

1) Login to
2) Navigate to the Networks tab and click on the Create a virtual network link.


3) On the Virtual Network Details page, enter a name for your virtual network and location and click next.


4) Ignore the DNS Servers and VPN Connectivity page and click next.
5) On the Virtual Network Address Spaces page, enter your designated address space and subnet.I’m using the Class B for my address space which gives me 254 hosts. For the subnet, I’m using a /27 subnet which will give me 30 hosts. I renamed my subnet to AzureSubnet. I still have enough address spaces for my gateway network. I can add more subnets and rename them if I choose to. Click next;

IP Address Space :
Address Class : Classless /24
Network Address :

Subnet-1 Address :
Subnet Mask :
Hosts per Subnet : 30



6) In the next step, we will create the Local Network. The Local Network defines the IP Address space of our On Premise remote networks. Still on the “Networks” page, navigate to the “Local Networks” tab and click on the Add a local network link. On the Specify your local network details, enter a name for the On Premise endpoint network and corresponding public IP Address is available.Click next.


7) On the Specify the address space page, enter the address space of the On-Premise remote endpoint network you intend to work with and finish.


8) Create the DNS Servers. Still on the networks page, select the DNS Server tab. Click on the Register a DNS server link to create a DNS server. I’m using my On Premise DNS server.



9) In the next step, we’ll configure the Gateway network. On the “Networks” page, under the virtual network tab, click on the newly created virtual network.On the virtual network page, select the Configure tab.In the dns servers section, select the newly created DNS server.In the Site-to-Site Connectivity section, tick the “Connect to the local network” box. For the “Local Network” field, select the On-PremiseInfra local network from the drop down.

In the Virtual Network Address Spaces, Azure automatically added the Gateway network with the /29 in the address space with 3 host addresses. Save the configuration changes.



10) On the Dashboard tab, click on the Create Gateway button at the bottom of the page and select Dynamic Routing to create the Gateway.


As indicated in the following screen shot, the Gateway was created successfully but is still disconnected.


11) In the next steps, we will setup and configure the On Premise RRAS (Routing and Remote Access Server ) for connection to the Azure VPN endpoint.For this step, I have created a virtual machine running Windows Server 2012R2 to act as the RRAS server. I’m using the RRAS server as my On Premise endpoint router because it supports Dynamic Routing.

In my System Center Virtual Machine Manager 2012R2 environment, I’ll create the external host virtual switch for connecting the Azure virtual machine to the internet.


12) In the SCVMM 2012R2 VMs and Services pane, I’ll console into the virtual machine designated for the Azure VPN setup and rename the network adapters. Select the designated external network adapter and rename it to External.Rename the internal NIC to Internal. In the network properties for the External NIC, enter the IP Address configuration as follows:




13) After configuring the networking on the RRAS Virtual Machine, we’ll proceed to to setup RRAS by downloading the “VPN Device Script” from the Azure portal.Navigate to “Networks”, click on the virtual network and on the Dashboard page, download the VPN script. On the “Download a VPN Device Configuration Script” page, select Vendor as Microsoft, platform is RRAS and operating system is Windows Server 2012 R2. After download, rename the VpnDeviceScript.cfg file to VpnDeviceScript.ps1 (PowerShell file):


14) Run the VpnDeviceScript.ps1 script to auto install and configure routing and Remote Access on the endpoint rras virtual machine.


It might seem the script run ended in error. But in the few times I have run through this process, I find that the script actually executed successfully and RRAS was well setup. This can be verified by logging into the Azure portal to find that the gateway automatically established a vpn connection to my On Premise network.


15) In this step, I will setup a virtual machine in Azure to test connectivity with my on premise infrastructure and extend my on premise network to Azure cloud. Login to the Azure classic portal, navigate to the Virtual Machines option and click on the Create a virtual machine link.


On the “New” page, select Compute-Virtual Machine and select the “From Gallery” option which allows you to better customize your VM.


On the “Choose an Image” page, I selected Microsoft, Windows Server, and Windows Server 2012 R2 Datacenter . Click next.


On the “Virtual machine configuration”, I filled the values as shown in the screen shot. Click next.


It is important that we pay attention to this screen. The Cloud Service DNS Name must be unique. To make sure the server goes into my virtual network, I made sure to select my virtual network (AzureLabNetwork) in the Region/Virtual Network field. I left the default endpoint configurations of the Remote Desktop and PowerShell ports for access to the VM.This field can be edited as needed.Click next to install the VM agent and Finish.


It took about 5 minutes to complete the provisioning process for the VM.


I can verify the internal IP Address of the Azure Virtual Machine by clicking on the VM instance and selecting the Dashboard tab.


By default, Ping is disabled on the Azure VM. The Windows Firewall is turned on . I turned off the firewall (it’s a test environment. Another option is to create an Allow Firewall rule for Ping packets. To test vpn connectivity, I was able to successfully rdp into the Azure VM using it’s internal IP Address from my on premise RRAS server. I can also successfully ping the Azure VM on it’s internal IP Address from my on premise RRAS server as shown below and vice versa.



We can verify from the above screen shot that the Azure Virtual machine is using the on premise domain controller ( as it’s DNS server. I have configured a route to the Azure virtual network on my on premise Cisco router/gateway:

LabL3Switch(config)#ip route

This will enable connectivity from the rest of the on premise network to the virtual network and vice versa, I can ping a local network machine by name.At this point I could go ahead and configure the Azure VM as a domain controller for on premise to Azure virtual network multi master replication and domain controller redundancy. The Azure virtual machine will require a static IP Address if it is to be configured as a domain controller. This can be achieved by using the new Azure Portal (ARM) as indicated in the following screen shot:


Posted in Azure, Azure VPN | Tagged , , , , , , , , , , | Leave a comment

Force Disable of Azure Replication from Orphaned On Premise Hyper-V Virtual Machine.

After successfully stopping and removing protection for one of my replica virtual machines in Azure Site Recovery, I observed that the on premise primary virtual machine replication status changed to a failed state. This would be normal behavior considering that replication settings at the Azure target had been removed.


My attempts at disabling replication at the primary VM via the GUI failed. I encountered the following error shown in the screen shot below trying to remove it using the PowerShell cmdlet: Remove-VMReplication -VMName w81:


Please note that I had initially setup Hyper-V (non-SCVMM) to Azure VM replication. The on premise Hyper-V host seemed to believe that the VM replication is still being managed by Azure. After doing some research, I found a four line code on the Microsoft Azure website under the section “Clean up protection settings manually (between Hyper-V sites and Azure)” , that utilizes the WMI Object.

$vmName = "SQLVM1"
$vm = Get-WmiObject -Namespace "root\virtualization\v2" -Query "Select * From Msvm_ComputerSystem Where ElementName = '$vmName'"
$replicationService = Get-WmiObject -Namespace "root\virtualization\v2" -Query "Select * From Msvm_ReplicationService"

I downloaded and saved the script as a PowerShell function (Remove-OrphanedVMReplication.ps1) after replacing the "SQLVM1" string with the name of my virtual machine. I ran the script in a PowerShell console as Administrator and it successfully disabled replication at the primary on premise VM.


After further research, I will add that Azure Site Recovery has two options for removing a replicated item from Azure:

1) Disable Protection for the Machine (Recommended). As stated in the screen shot, this option will remove the machine and it will no longer be protected by ASR. Protection configuration and settings will be automatically cleaned up. Leaving the on premise Primary VM in a clean replication state.


2) Stop Managing the Machine. Also, as shown, this option removes the replica VM and it will no longer be available in ASR. The Protection settings for the Primary on premise VM will be unaffected, leaving the administrator with the clean up task as described with the script above. I had used this option to remove the replica VM above. This left the on premise VM in the state that required a manual clean up.


Posted in Azure, Azure Site Recovery, Azure VPN | Tagged , , , , , , , , , , , | Leave a comment

Secure Wireless Access and Authentication with Radius on WS2012R2 Network Policy Server .

Basic 802.1X Wireless network implementation requires an alphanumeric network key for access and authentication. In an enterprise environment this is not ideal. I’ve recently reconfigured and redesigned a client site’s WPAPersonal Wireless network for Radius (Remote Authentication Dial-In User Service) Authentication on an NPS (Network Policy Server) Server running on the Windows Server 2012R2 platform . Some of the benefits of this redesign are as follows:

1) User access control is managed with usernames and passwords in Active Directory. This replaces easily distributed and insecure network keys.
2) Administrators can more easily manage user and device credentials and centrally revoke access if and when necessary.

In this post, I provide my configuration steps in setting up Microsoft Protected Extensible Authentication Protocol with Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) version 2 authentication. The wireless network is built on the UniFi brand of Access Points with the Windows Server 2012 R2 Network Policy Server (NPS) as the RADIUS server.

Configuration and Setup Elements:
1) WS2012R2 Certificate Authority Server.
2) Network Policy Server on WS2012R2.
2) UniFi AC Access Points and Controller.
4) Group Policy Object configuration for Certificate Auto-enrollment and Wireless 802.1X.


Install and Configure the Active Directory Certificate Services and Certification Authority Role using PowerShell.

Use the following PowerShell cmdlet to install Active Directory certificate services for a Certification Authority role service on a domain joined member server.

Install-WindowsFeature -Name ADCS-Cert-Authority -IncludeManagementTools

Please note that after installation, the Certificate Authority Server will need to be configured as an Enterprise Certificate Root CA. Microsoft has a detailed step-by-step instruction on setting up an Enterprise CA server at the following NPS Server Certificate: CA Installation link.
A summary of the server configuration is as follows:

After the role installation, open the Server Manager console. On the Server Manager tab, click on the Configure Active Directory Certificate Server link and follow the wizard page.

On the Select Role Services page, ensure that Certification Authority is selected, select any additional role services that you require, and then click Next .

On the Specify Setup Type page, ensure that Enterprise is selected, and then click Next .

On the Specify CA Type page, click Root CA , and then click Next .

On the Set Up Private Key page, ensure that Create a new private key is selected, and then click Next .

On the Configure Cryptography for CA page, keep the default settings or change them according to your requirements. Note that the default Key character length is 2048, which is twice as large as previous default key character lengths of 1024. Depending on your network size and traffic, you might want to adjust the size of the key character length. Click Next .

On the Configure CA Name page, keep the suggested common name for the CA or change the name according to your requirements, and then click Next .

On the Set Validity Period page, in Select validity period for the certificate generated for this CA , type the number and select the time value (years, months, weeks, or days) that determines the date upon which certificates issued by the CA will expire. The default setting of five years is recommended. Click Next .

On the Configure Certificate Database page, in Certificate database location and Certificate database log location , specify the folder location for these items. I kept the default locations. If you specify locations other than the default locations, ensure that the folders are secured by using access control lists (ACLs) that prevent unauthorized users or computers from accessing the CA database and log files. Click Next , and then click Finish .

Configure Certificate Autoenrollment for the Designated Network Policy Server.

In this section, I’ll configure the certificate template that Active Directory® Certificate Services (AD CS) uses as the basis for the server certificate that will be enrolled to the Network Policy Server (NPS).

1) Login to the CA server running WS2012 R2, and open the Certificate Authority console.

2) In the CA management console, expand the tree, and right click on the Certificate Templates folder and select Manage.


3) In the Certificate Templates console, all of the certificate templates are displayed in the details pane.

4) In the details pane, click the RAS and IAS Server template. On the Action menu, click Duplicate Template . In the Duplicate Template dialog box, select the template version appropriate for your deployment, and then click OK . The new template properties dialog box opens.

5) On the General tab, in Display Name , type a new name for the certificate template. I renamed my template to RAS and IAS Server2.



6) Click the Security tab. In Group or user names , click RAS and IAS Servers . In Permissions for RAS and IAS servers , under Allow , select the Enroll and Autoenroll permission check boxes, and then click OK .


7) Back on the Certificate Authority page , expand the CA name, and then right click Certificate Templates, select New , and then click Certificate Template to Issue . The Enable Certificate Templates dialog box opens.

8) In Enable Certificate Templates , click the name of the certificate template you just configured, and then click OK . For this deployment, I changed my template name to RAS and IAS Server2, so I’ll click RAS and IAS Servers2 , and then click OK .


9) On the same server, open the Group Policy Management Console. Right click on the GPO folder and select New to create a new GPO . in the name field, enter a name for the new GPO. I called mine the NPS Certificates Policy. Click OK.

10) Open Computer Configuration , Policies , Windows Settings , Security Settings , and then select Public Key Policies. In the details pane, double-click Certificate Services Client – Auto-Enrollment . The Certificate Services Client – Auto-Enrollment Properties dialog box opens.

11) In the Certificate Services Client – Auto-Enrollment Properties dialog box, in Configuration Model , select Enabled . Select the Renew expired certificates, update pending certificates, and remove revoked certificates check box. Select the Update certificates that use certificate templates check box, and then click OK .


12) After you complete this procedure, servers running NPS automatically enroll a server certificate when Group Policy is refreshed. To refresh Group Policy, restart the server or, at the command prompt, run gpupdate . In the next section, I will install NPS. After the install, I’ll run gpupdate to auto enroll a server certificate for the NPS server.

Install and Configure the Network Policy Server Role using PowerShell.

Check for and verify availability of the Network Policy feature:


Install the Network Policy role using PowerShell:


Run gpupdate to autoenroll the Network Policy server for a server certificate.

Configure the Radius Client:

Open the Server Manager console and highlight the “All Server” command. Select the current server.

Navigate to the Tools menu and select the “Network Policy Server” command. This should open up the Network Policy Server console:


In the Network Policy Server console, expand the ‘Radius Clients and Servers’ folder, “Radius Clients” sub folder and select the New command.

In the “New Radius Client” dialog, enter the values for the following fields indicated the following screen shot and click ok. The Address field refers to the IP Address of the Access point. Run through this step for as many Access points and clients that need to be setup on the Radius server:



Configure Wireless Policy:

Highlight the NPS server folder, under the standard configuration drop down, select the “Radius Server for 802.1X Wireless or Wired Connections” standard config

Click the “Configure 802.1X” link.

In the “Select 802.1X Connection Type” window, select the “Secure Wireless Connections” option and leave the default name or change as needed. Click next.


In the “Specify 802.1X Switches” page verify that the Access Points configured under Radius Clients are in the list.Click next.

In the “Configure Authentication Method” page, select an EAP type from the drop down. I selected the “Microsoft:Protected EAP”.


Still on the “Configure an Authentication Method” page, click the Configure button to open the “Edit Protected EAP Properties” page.Add the EAP Type of “Secured Password (EAP-MSCHAPv2) and select the NPS server name for the “Certificate Issued to” field. This field is autopopulated because we already enrolled the NPS for a Network Policy certificate by running gpupdate.


In the “Specify User Groups” page, click Add to enter an Active Directory group for allowing access to group members based on the network policy. Click next.


Click next on the “Configure Traffic Controls” page.

On the “Completing New IEEE 802.1X Secured Wired and Wireless” page , click finish.

Configure Group Policy Object for Wireless Clients running Windows Vista and Later.

1) Open Group Policy Management Console. Right click on the GPO folder and select New to create a new GPO . in the name field, enter a name for the new GPO. I called mine the NPS Clients Configuration Policy. Click OK.

2) Open Computer Configuration , Policies , Windows Settings , Security Settings , and then right click Wireless Network (IEE802.11) Policies and select to “Create a New Windows Vista and Later Releases Policy”.

3) On the General tab, in Policy Name , type a new name for the policy, Lab Wireless Network Policy. In Description , type a description of your policy. Select the Use Windows WLAN AutoConfig for clients check box to specify that WLAN AutoConfig is used to configure wireless network adapter settings.

4) Still on the General tab, in the ‘Connect to available networks in the order of profiles listed below: section, click Add and then select Infrastructure to add and configure a new wireless profile. This will open a New Profile properties page.

5) On the Connection tab, in Profile Name, type a name for the profile. In Network Name(s) (SSID), type the service set identifier (SSID) for your wireless APs, and then click Add .

6) To specify that wireless clients automatically connect to wireless APs for which the SSID is specified in Network Name(s) (SSID) , select Connect automatically when this network is in range .



7) Click the Security tab. In Select the security methods for this network , in Authentication , I selected WPA2-Enterprise for my Access points. In Encryption , I selected AES. The settings for both Authentication and Encryption match the settings configured on my wireless AP.

8) In Select a network authentication method , I selected Microsoft: Protected EAP (PEAP) . In Authentication mode , I selected: User authentication. In Max Authentication Failures I entered 2. I enabled the check box for Cache user information for subsequent connections to this network.

9) Click Properties of the network authentication method, the Protected EAP Properties dialog box opens. In Protected EAP Properties , I enabled “Verify the server’s identity by validating the certificate” check box and the “Connect to these servers:” check box. I entered the fully qualified domain name of my radius server(NPS Server) in the text field.

10) In Trusted Root Certification Authorities , I selected the trusted root certification authority (CA) deployed in my domain as described earlier in this post that issued the server certificate to my server running Network Policy Server (NPS). Please note that this setting limits the trusted root CAs that clients trust to the selected CAs. If no trusted root CAs are selected, then clients trust all root CAs listed in their trusted root certification authority store.

11) For “notifications before connecting”, I selected “Tell user if server name or root certificate is not specified”.

12) In Select Authentication Method , select Secured Password (EAP-MS-CHAP v2) . Enable PEAP Fast Reconnect, by selecting Enable Fast Reconnect . Click Configure . In the EAP MSCHAPv2 Properties dialog box, verify Automatically use my Windows logon name and password (and domain if any) is selected, click OK , and then click OK to close Protected EAP Properties .



13) On the Network Permission tab you can use the tick boxes to restrict clients to infrastructure networks or only GPO profiled allowed networks if you wish.

Configure my Unifi Wireless Access Points.

1) I’m using the Unifi Access Points. I’ll login, create a new wireless network and configure for Radius parameters with the highlighted values.


The IP Address field references the IP Address of the Network Policy server. I made sure to match the Radius Server Password/Shared Key with the shared key configured for the Access Point in the Network Policy Server in the “Install and Configure the Network Policy Server Role using PowerShell” section.

Connect Client PC Running Windows 10 to the Wireless Network.

To test the Radius configuration, login to a Windows laptop and run gpupdate to apply the Group Policy settings to the client machine. The screen shots below show the before and after status of the ITTEST Wi-Fi profile. You can choose to enter your username and password manually or check the box to connect automatically.




Posted in Active Directory, Network Policy Server, Radius Server | Tagged , , , , , , , , , , | Leave a comment

Configuring Networking using SCVMM2012 R2 and Windows Server 2012R2 DHCP Server.

There’s a number of moving parts to be considered while configuring logical networking in System Center Virtual Machine Manager 2012 R2 . In this post, I attempt to document my steps in creating and configuring the Logical networks, logical switches, Port profiles, VM networks and Network sites/Logical network definitions that enable the extension of my Windows Server 2012 R2 DHCP based network with multiple Vlans and subnets into the Virtual Machine Manager networking space.

There are a lot more modifications that can be made to suit specific design goals, but I hope to use this post to note the basic sequence of steps and elements that I think need to be in place to help expand on any further infrastructure design and hosting objectives.

My configuration steps are outlined as follows:

1) Login to the System Center Virtual Machine Manager 2012 R2 Console and navigate to the Fabric workspace.

2) Select and right click on the Logical Network folder and select to “Create Logical Network”.


3) On the “Create Logical Network Wizard Name” page, enter a name for the network: CorpNet. Select the “One Connected Network” option and tick the box to “Create a VM network with the same name to allow virtual machines to access this logical network directly”. Click next.


4) On the Network Sites page, click Add to auto create a network site. In the host groups that can use this network site section, check the box to select all host groups. In the associated vlans and ip subnets section, click insert row to add the designated corporate vlan . Since we are extending the corporate subnet, we don’t have to enter the CIDR notation for the corresponding VLAN 40. I renamed the Network Site to “Corp Net Site Vlan 40”. Before clicking the finish button, I prefer to view the PowerShell script for the Logical Network creation process and save the script for future use. Click next to confirm the settings and finish.



5) The next logical sequence of steps in this process will be to create a Logical switch for this network. But I’ll take a pause to create a Port Profile to be used by the logical switch for the VM host.Uplink Port Profiles define which logical networks can be connected to through these ports. Still in the Fabric workspace, navigate to the Port Profiles folder under Networking. Right click on Port profile and select “Create Hyper-v Port Profile”. On the General page, enter a name for the port profile: “Corpnet Trunk Port Profile”. For the “Type of Hyper-v Port Profile, select Uplink Port Profile. Select Dynamic for Load balancing algorithm and Switch Independent for Teaming mode. Click next.


6) In the Network Configuration page, select the network site and associated logical network to be mapped to this Port Profile and click next. On the next page, confirm settings, use the View Script button to view and save the port profile creation PowerShell script for future reference and finish.


7) Still on the Fabric work space, right click on the Logical Switches folder and select to Create Logical Switch. On the General page, enter a name and description for the Logical switch as “CorpNet Switch”. I have no interest in enabling SR-IOV at this time. Click next.


8) On the Extensions page, select the Microsoft Windows Filtering platform and click next.

9) On the Uplink page, select Team as the Uplink mode and add the just created CorpNet Trunk Port Profile as the uplink port profile. Click next.


10) On the Virtual Ports page, I selected the Medium Bandwidth label. Confirm the settings, view the PowerShell script and save, then finish.

11) In the next step, I’ll associate the new logical switch to both of my cluster nodes to make it highly available.The first host/node is Lab01. Still in the Fabric work space,navigate to the host/cluster group with the designated host with name Lab01 and select the host in the Hosts pane. Right click on the Lab01 host and select Properties.


12) Select the Virtual switches tab. Select New Virtual Switch button and select the New Logical Switch option.


13) Make sure the new CorpNet logical switch is selected. In the host physical Adapter drop down menu, select the physical adapter NIC2 that’s been designated for this logical switch. Click OK.


14) Still on the Lab01 host properties page, click on the New Virtual Network Adapter to create a VM adapter off of the CorpNet logical switch. In the VM Network field, browse to select the CorpNet VM Network. Check the Enable Vlan box and select the VLAN ID 40 in the drop down. In the Port Profile classification, select the configured Medium bandwidth label. Click OK. I followed the same steps for the second cluster node/host Lab00.


15) Still on the Lab01 host/node Properties page, navigate to the Hardware tab and scroll to the designated Physical Adapter NIC2. Check the “Available for Placement” box to make the logical network configurations available to this adapter and by extension the Virtual Machines on this host/node.



16) In the next step, I will associate a Virtual Machine W10VM on the Lab01 host to the new logical network via the VM Network CorpNet. In the SCVMM 2012R2 console, navigate to the VMs and Services work space. In the VMs pane, select the Virtual Machine W10VM that will be used to test the new network. Right click on the VM and select Properties. In the W10VM properties page, select the Hardware Configuration page. Under the Network Adapters page, select the existing network adapter 1. Under Connectivity, select “Connected to a VM Network”.


17) For the “VM Network” field, browse to select the CorpNet VM Network on the “Select a VM Network” page , then click OK. Check the Enable VLAN check box and select VLAN ID 40 from the drop down. This VLAN ID was configured as part of the network site configuration. Under the Virtual Switch section, select Logical switch and select the CorpNet Switch from the drop down. View the script and save for future reference. Click OK.



18) To complete the test, start a SCVMM 2012R2 console connection to the W10VM virtual machine and login. Open a PowerShell console and run ipconfig /release and ipconfig /renew to confirm that the VM IP Address is in the VLAN 40 subnet of subnet as assigned by the DHCP Server.


As a side note, I will add that the upstream Cisco switch port to the physical network adapter on host Lab01 had already been configured as a Cisco Trunk port. This will allow any VLANs configured in the network site for the Logical network to pass through to the Virtual Machine via the VM Network.

Posted in SCVMM2012 R2, SCVMM2012R2, System Center 2012 R2, Virtual Machine Manager 2012 R2, Virtual Machines, vlan, VMM2012R2 | Tagged , , , , , , , , , | Leave a comment

Deleting SCVMM 2012 R2 Logical Network Definitions with PowerShell.

Attempting to delete a SCVMM 2012R2 logical network throws an exception as shown in the screen shot below because there are other dependencies like the Port Profiles, logical switches and other network objects still depending on it.


The “View Dependent Resources” page displays the current Logical network definition dependencies preventing the Logical network from being removed.


We can remove the network definitions with PowerShell after which we delete the logical network.


Get-SCLogicalNetworkDefinition -LogicalNetwork "Test Logical Network" | Remove-SCLogicalNetworkDefinition -Verbose

The PowerShell script gets the specified Logical network definition for the specified LogicalNetwork parameter and pipes the result to the Remove-SCLogicalNetworkDefinition

In the next script, we use the Get-SCLogicalNetwork to retrieve the specified Logical network and pipe the result to the Remove-SCLogicalNetwork

Get-SCLogicalNetwork -Name "Test Logical Network" | Remove-SCLogicalNetwork -Verbose


Running the Get-SCLogicalNetwork -Name "Test Logical Network" doesn’t return any value. This confirms the removal was successful.

Posted in SCVMM2012R2, System Center 2012 R2, VMM2012R2, Windows Server 2012 R2 | Tagged , , , , , | Leave a comment

My Step-by-Step DirectAccess Configuration on Windows Server 2012 R2.

Windows Server DirectAccess is an awesome and exciting feature. It’s a Windows Server role service that enables windows domain-joined machines to have always on and seamless connection to the corporate infrastructure securely over the internet without the need for traditional Virtual Private Network (VPN). The DirectAccess infrastructure has a lot of moving parts. Any dysfunction or misconfiguration in one of it’s components can halt and disrupt the entire DirectAccess deployment.Some key points:

a) It hugely facilitates the process of implementing the Password expiration and change Group Policy for telecommuter users.
b) It eliminates the need for end user initiated VPN (or other) connections. (Making the end user’s experience even simpler)
c) Help desk administrators can more easily administer telecommuter end user ticket issues(Manage out capabilities).
d) Securely and seamlessly extending my I.T. infrastructure environment over the internet.IPSec and HTTPS(SSL certificate) encrypt the traffic between client and DirectAccess server to prevent interception. In addition, Windows Firewall must be enabled end-to-end before a successful DirectAccess connection can be made.
e) DirectAccess utilizes IPv6. Since Windows Server 2012 DirectAccess can now be configured behind a firewall using NAT (Network Address Translation) with a single NIC. This deployment model requires the IP-HTTPS transition technology.

The following sections outline my Configuration and deployment steps.

1) Build a Windows Server 2012 R2 Virtual Machine :
Start by provisioning a Server 2012 R2 virtual machine on a Hyper-V host (any hypervisor host will do) . The Virtual Machine is configured with the option of a single network adapter. Join the server to the domain and configure it with a static IP Address matching your internal subnet. Download and install the operating system updates. This machine will be configured later as the Direct Access Server.

2) Setup an External DNS record:
Create a public DNS record with your DNS provider or your public DNS server. In my case, I created a This DNS record will be configured later on the Company firewall to point to the DirectAccess server .

3) Configure Firewall Rules for DirectAccess:
The DirectAccess service primarily needs port 443 to be configured on the perimeter firewall. Configure a NAT policy and Firewall access rule for port 443 to point to the internal DirectAccess virtual machine’s IP Address.

4) Prepare for Certificate Requirements and install the Certificate on the DirectAccess server:
The DirectAccess security model depends hugely on certificate services. I started out by trying to deploy Active Directory Certificate services and configuring CRL (Certificate Revocation List) distribution points . It’s an involved process I hope to blog about soon. But for this post, I used a public wildcard SSL certificate acquired from Godaddy. Make sure the certificate Subject name matches the the fqdn of the DNS record in step 2 above “”. My wildcard ssl certificate is “*”. Download the certificate and import into the DirectAccess server personal certificate store using the Certificates mmc console. Using a certificate issued by a public CA like Godaddy is recommended. It spares you the long and involved task of configuring an internal certificate revocation list distribution point for access from the internet.

5) Create Active Directory Security Group:
The DirectAccess role service gives the option to enable DirectAccess for all domain joined mobile computers or for a subset of mobile computers defined within an Active Directory group. I created an active directory security group for all the mobile computers that will be licensed for DirectAccess. In the following screenshot, I used PowerShell to create a “DirectAccessComputers” AD group. The first script used the “-WhatIf” parameter to confirm that the syntax is correct:


Use the following cmdlet to add a single or multiple computers (multiple computer objects should be comma-separated) to the Active Directory security group:

Add-ADGroupMember -Identity DirectAccessComputers -Members "CN=W10LAPTOP,OU=IT,OU=Hardware,DC=labcompany,DC=net"

6) Verify Windows Client Operating System Requirements:
DirectAccess is enabled solely on the Enterprise versions of windows clients OSes. Windows 7 Enterprise and Ultimate, Windows 8.1 Enterprise and Windows 10 Enterprise. In my environment, we are in the middle of a Windows 10 roll out for all clients. For this reason my DirectAccess configuration is targeted towards Windows 10 Enterprise clients. This eliminates the need to configure workstation authentication certificates for Windows 7 Enterprise clients.

7) Install and Configure DirectAccess:
Install the DirectAccess role service by starting Server Manager, clicking the Manage tab and selecting the “Add Roles and Features” command. Click next three times on the “Add Roles and Features Wizard” page till you get to the “Select Server Roles page and select the Remote Access check box:


Click next three times and select the “DirectAccess and VPN(RAS)” check box on the “Select Role Services” page:


Click to add features and continue to click “Install” to install the DirectAccess role service.A restart is not required after the installation.Open the Remote Access Management console under the Tools tab in Server Manager to start the configuration of DirectAccess.

In the Remote Access Management console, select the DirectAccess and VPN role service and click on the “Run the Remote Access Setup Wizard”.

On the “Configure Remote Access” page, select Deploy DirectAccess Only:


a) After the prerequisite check, on the Setup page, click configure on the Step 1 task to configure remote client settings. On the DirectAccess Client Setup page, select to Deploy full DirectAccess for client access and remote management. Click next.

On the Select Groups page, I chose not to “Enable DirectAccess for mobile computers only” since I want to control what devices have DirectAccess enabled. I also chose not to enable “force tunneling” . Use the Add button to add the Active Directory group for computers to be enabled for DirectAccess. This group was created and populated in Step 6 above. Click next:


On the “Network Connectivity Assistant” page, enter a Help desk email address and rename the DirectAccess Connection name if needed.Select the ‘Allow DirectAccess clients to use local name resolution” option.In the table, add a resource that will be used to determine connectivity to the internal network. A default web probe is created automatically if no other resource is configured. You can configure this task with the fqdn of a domain resource that can be reached via ping or port 80 http. I left the table blank to let DirectAccess configure a default web probe on the DirectAccess server. Click finish.


b) Click configure on the Step 2 “Remote Access Server” task. On the “Network Topology” page, type the name of the public fqdn of the DirectAccess server configured in step 2 above (this name matches the subject name of the IP-HTTPS certificate in step 2 above). In my environment, I selected the “Behind an edge device (with a single network adapter)” deployment topology. Click next:


c) On the “Network Adapter” page, confirm the details of the Ethernet adapter in the DirectAccess server. Use the Browse button to select the IP-HTTPS certificate installed in step 4 above. Click next:


d) On the ‘Authentication’ page, select to use “Active Directory Credentials” for user authentication. I don’t need to enable DirectAccess on Windows 7 clients since my clients are running Windows 10 Enterprise. I don’t need to enforce compliance for NAP at this time. Click finish.

e) Click configure on the Infrastructure server task for step 3. On the “Network Location Server” page, I chose to use the Remote Access server as the Network Location server and select the option to use a self signed certificate.The Network Location Server is used by DirectAccess clients to determine if they are inside or outside of the corporate network. Based on NLS reachability, the DirectAccess client will decide if it should attempt to establish DirectAccess connectivity to the tunnel endpoints specified by the DirectAccess configuration. If the DirectAccess client can connect to the NLS, it assumes it is inside the corporate network and does not establish DirectAccess connectivity. If it cannot connect to the NLS, the DirectAccess client assumes it is outside of the corporate network and attempts to establish DirectAccess connectivity. For this reason it is essential that the NLS be exempted from the Name Resolution Policy Table (NRPT) and its hostname only be resolvable on the Internal network. The hostname of the NLS should never be configured in public DNS. In addition, the NLS should not be reachable via the public Internet. Click next:


f) On the DNS page, the DirectAccess wizard automatically populates the “Name Resolution Policy Table” (Nrpt) with your internal dns domain suffix and the IPv4 Address of the DirectAccess server. It also creates a default internal DirectAccess-NLS dns record as indicated in the following screenshot:


However, after initial configuration of DirectAccess I noticed that the operations status for DNS was indicated as Critical. After some research, I found a resolution to this error. The DNS server IPv4 address specified in the table is the address assigned to the DirectAccess server’s internal network interface. But this address should be the IPv6 address not the IPv4 address. To resolve this, right click on the current DNS suffix and select Delete to remove the current dns suffix and IPv4 configuration :


Right click on a blank field and select “New” to create a new DNS server entry,


On the “DNS Server Addresses” page, enter the dns suffix name of your internal network and click detect, then click validate. The IPv6 address will be added automatically. Click Apply to continue.This is the IPv6 address of the DNS64 service running on the DirectAccess server, which is how the DNS server should be configured for proper DirectAccess operation.



For the local name resolution option, select the recommended “Use local name resolution if the name does not exist in DNS or the DNS servers are unreachable when the client computer is on a private network” and click next.

g) The “DNS Suffix Search List” page can be left as is with the default dns suffix configuration and click next:


h) On the management page, add the fqdn of any available SCOM 2012R2 or SCCM 2012 R2 machines on your network. DirectAccess can auto detect any management servers in your network and auto-populate this field after the initial configuration.Click finish:


Click finish on the Remote Access Setup page, save a copy of the settings to the desktop for later viewing and click Apply.


The wizard auto creates 2 key GPO policies , DirectAccess Server Settings and DirectAccess Client Settings . Restart the server after applying the settings. In the Remote Access deployment, configuring application servers is an optional task, so I chose to ignore the tasks in this step. The Operations Status page should look as shown in the screen shot after all tasks are completed. Any errors will be reported on this page:


Before successfully testing the DirectAccess deployment, correctly setting the Firewall configuration on the Server and Client is a prerequisite. I created two Firewall Group Policies:

1) “Firewall-Settings-DirectAccess-Server” is linked to the DirectAccess Server OU and security filtering was applied specifically to the DirectAccess Server.

2) “Firewall-Settings-DirectAccess-Clients” is linked to the DirectAccess Clients OU. The security filtering was applied to the ‘DirectAccessComputers’ Active Directory Security group.

In each of the Group policies, the Domain, Private and Public firewall profiles need to be turned on with inbound and outbound connections set to “Allowed” based on your set rules. The DirectAccess rules have already been auto-created on the server based on the auto generated during DirectAccess configuration. Following are screen shots of the GPO settings:




I would add that Firewall Group Policies need to be configured properly for DirectAccess connections to be successful. Also, the Domain Firewall Group Policies need to be correctly setup to ensure that the “Remote Client Status” console on the DirectAccess server displays the current state of all IPHTTPS connected clients. In my experience, the Firewall group policy object settings are not to be confused with the Firewall settings in the Local machine store of both the clients and Server. The local store settings can be accessed and edited using either :

1) Netsh advfirewall show and Netsh advfirewall set cmds.

2) Get-NetFirewallProfile and Set-NetFirewallProfile cmdlets.

While successful DirectAccess connections can be made if the firewall local store settings on both the client and server match each other, “Connected Clients” status will not be displayed in the “Remote Client Status” console. Only after configuring the Firewall Group Policies as explained above was I able to report on IPHTTPS connections. The following PowerShell script will display historical data for ConnectionType DirectAccess for the last one day:

Get-RemoteAccessConnectionStatistics -StartDateTime (Get-Date).AddDays(-2) -EndDateTime (Get-Date) | ?{$_.ConnectionType -eq 'DirectAccess'}|ft ClientIPAddress, UserName, ConnectionDuration, ConnectionType, ConnectionStartTime


You can test the deployment using a Windows 10 Enterprise DirectAccess client. Unplug from the internal network and connect to an external network by wifi or any available means. On the client, the DirectAccess tab shows the status of a successful connection:


The PowerShell cmdlet Get-DAConnectionStatus shows the status of a successful connection:


The Get-RemoteAccessConnectionStatistics PowerShell cmdlet displays the statistics of real-time, currently active DirectAccess (DA) and VPN connections and the statistics of DA and VPN historical connections for a specified time duration. Following is a screen shot of the cmdlet result:


I can ping internal network resources successfully. Since DirectAccess primarily works with IPv6, the ping returns the ipv6 addresses of internal network resources. IPv6 must be enabled on the clients for DirectAccess to work. I’ll quickly add that DirectAccess makes use of the IP-HTTPS IPv6 transition technology to enable it work in IPv4 environments :


The Get-DAClientExperienceConfiguration cmdlet returns the configuration for the DirectAccess client user experience :


Posted in DirectAccess, Powershell 4.0, Remote Access, Windows Server 2012 R2 | Tagged , , , , , , , , , , , , , , , , , | 3 Comments