DirectAccess in PowerShell

Managing DirectAccess in PowerShell will be possible with Windows Server 8. In fact, it is already possible with the Beta version available since end of February 2012. We only need a good documentation for that. Microsoft started to publish some part Direct Access Client Cmdlets in Windows PowerShell. Time to play with DirectAccess.

Warnings first

Information provided in this post are based on my hand-on experience of Windows Server 8 Beta and limited documentations available on Microsoft TechNet. For theses reasons, don’t try to use information provided in this post to setup your DirectAccess infrastructure based on a Beta version on your production environment. Remember, it’s not supported, even by me.


For this PowerShell demonstration, I will consider that :

  • Windows Server 8 beta server is already member of my domain
  • Network interface are correctly configured
  • Network Interface correctly named and ordered
  • Required certificate are provisioned


DirectAccess is now a part of a role

It’s no longer a feature but a part of the Remote Access role. Let’s install it with a PowerShell command and associated management tools :

Add-WindowsFeature –Name DirectAccess-VPN –IncludeManagementTools



Let’s check Everything is on place

Install-RemoteAccess –Prerequisite



Find your IPHTTPS certificate

I’m not a PowerShell expert, there might have some new magic trick in PowerShell V3 but my old trick works for a while :

$IPHTTPS = (Get-ChildItem Cert:\\LocalMachine\My | Where {$_.Subject -like « CN=DA.DirectAccessLab.Fr* »})

Write-Host $IPHTTPS



Initial configuration

That a big change for me. I’ve been working with DirectAccess since first beta of Windows 2008 R2. It was long and complex to set it up. And now With a single PowerShell Commandlet, you can do it :

Install-RemoteAccess -DAInstallType FullInstall -ConnectToAddress DA.DIRECTACCESSLAB.FR -ClientGPOName « DirectAccesslab.Lan\DirectAccess Clients GPO » -ServerGPOName « DirectAccesslab.Lan\DirectAccess Server GPO »-InternalInterface LAN

-InternetInterface INTERNET -NLSURL https://nls.directaccesslab.lan -Force



This command will :

  • Configure DirectAccess for a full access scenarios with selected network cards
  • Users will be using DA.DirectAccessLab.Fr as FQDN for the IPHTTPS protocol
  • A Server-side GPO will be created
  • A Client-Side GPO will be created
  • My Network Location Server is already available on my LAN


Let’s check everything is in place :




As we can see there are some parameters that need to be fixed. Let start with the Client-Side parameters.


Client-Side parameters

Let start with the beginning and , let’s configure the security group to be used for the Client-Side GPO of DirectAccess. I will start to add a new security group.

Set-DAClient –SecurityGroupNameList “DirectAccesslab.Lan\DA Clients”




Before removing the default group proposed by the initial configuration. I want to scope DirectAccess deployment more precisely :

Remove-DAClient –SecurityGroupNameList “DirectAccesslab.Lan\Domain Computers”




Let’s finish DirectAccess Client-Side configuration by disabling WMI filtering on the Client-Side DirectAccess Client GPO :

Set-DAClient –OnlyRemoteComputers Disabled




Network Connectivity Assistant

Network Connectivity Assistant is the new Name of the DirectAccess Connectivity Assistant.Let’s configure these parameters with a single CommandLet :

Set-DAClientExperienceConfiguration -PolicyStore « DIRECTACCESSLAB.LAN\DirectAccess Clients GPO » -UserInterface $True -SupportEmail  -CorporateResources {HTTP:http:dc.directaccesslab.lan} -PreferLocalNamesAllowed $True -FriendlyName « DirectAccess Connection » -IPSecTunnelEndpoints {PING:2002:836B:2:836B:2; PING:2002:836B:2:5::1}

Get-DAClientExperienceConfiguration -PolicyStore « DIRECTACCESSLAB.LAN\DirectAccess Clients GPO »




Note : 6to4 addresses used as Dynamic End Point are separated by a “;” and not a ‘,’. It’s normal as I’m French and using a French Keyboard. For this reason, it’s a different separator.


Finalizing Server-Side Configuration

Default configuration performed by the Install-RemoteAccess CommandLet is almost perfect, except on one point. Even if Microsoft allow us to configure DirectAccess to operate without IPsec certificate, this configuration does not seems to be compatible with Network Access protection. For this reason, I need to configure witch AC will be used for IPsec Certificate. First, I need to locate my internal ADCS certificate with the following CommandLet :

$CA = (Get-ChildItem Cert:\\LocalMachine\Root | Where {$_.Subject -like « CN=INET* »})

Write-Host $CA

Set-Daserver -IPSecRootCertificate



And configure it in the Server-Side on the DirectAccess group policy :

Set-DAServer –IPsecRootCertificate $CA





Configuring extendted DirectAccess options

My favorite DirectAccess option is Network Access Protection. So let’s configure it with the Set-DAServer CommandLet :

Set-DAServer –HealthCheck Enabled




Note that this Network Access Protection configuration is not complete as compliance is not required to enable the user IPsec tunnel.


Adding some management servers

Because Desired Configuration Manager (DCM) is my new Gameboy I want my DirectAccess clients computers to be managed by it. For this reason, I must add it to the list of the management servers allowed to use the IPsec Infrastructure Tunnel.

Add-DAMgmtServer –MgmtServer SCCM.DirectAccesslab.Lan




And Now it should works

Let’s see the state of each component involved in DirectAccess. We can also get server-side statistics and current DirectAccess sessions :





With Windows 8, Microsoft made big improvement in the manageability of it’s operating systems. PowerShell generalization to all roles and features is really helpful. I will spend some time on these PowerShell commandLet to create a script for my future DirectAccess deployments.


This post was updated to include Powershell commands.


BenoîtS – Simple and Secure by Design but Windows 8 compliant!


Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.