Manage Out with Direct Access on UAG

Having implemented Direct Access with UAG (Microsoft Unified Access Gateway) at a customer location there were some questions when we were done. Their helpdesk is using SCCM (System Center Configuration Manager) and the remote management tools included, how would they go about managing the clients? Would that work even if the user wasn’t logged in? Well, after some research we found out that they could actually manage the client if someone was logged in. If nobody was, no remote management would occur.

The reason? Well, traffic initiated from the inside of the network have to go through the management tunnel if nobody is logged in. For that to happen the servers or workstations that wish to communicate have to be included in the management group. If you’re going to use a management server or workstation for your work it’ll have to be IPv6 capable too because DA / UAG won’t translate IPv4 to IPv6 for traffic initiated from the inside.

UAG configuration:

The UAG needs to include ALL the computers you want to use for remote management of DA clients where nobody is logged on. Ie using the management tunnel. As soon as a user logs on communication can occur on the user tunnel.

Client configuration:

If you’re using mobile connections you’ll need to make sure that they will register their address in DNS. If you don’t do this your clients won’t register, and you won’t be able to find them from your internal network.

(click for Lightbox)

Clients needs to have their firewall configuration updated with rules that allow the traffic you need, for example RDP. Please note that the profile you must use for this is the PUBLIC profile since that’s the one applied when the DA client is connected from the internet. You must also allow “edge traversal” for these rules to work over all tunnels.

(click for Lightbox)

More resources for manage out with Direct Access:

Direct Access / UAG Troubleshooting Steps

I spent last week installing, configurating and troubleshooting UAG for Direct Access. Considering that nobody likes troubleshooting, I thought I’d share some tips and a list of the steps I took to get it up and running.

This guide/list focuses on troubleshooting Direct Access through Microsoft Forefront Unified Access Gateway (UAG), but also applies on Direct Access enabled through Windows Server 2008 R2.

Thanks to Hasain Alshakarti for answering all my questions and giving me a quick lesson on PKI!

Try to test your first client from the same network as your outside addresses on your DA/UAG, I’ve spent almost a day troubleshooting a configuration where it turned out that the 3G operator blocks 6to4 (IP Protocol 41). If it works on that network, then you can try it out with 3G.

If it doesn’t work then, you’ll need to create another GPO that disables 6to4 which will make your clients use either Teredo or IPHTTPS instead. Check the netsh-section further down for how to disable it manually. If you don’t it might work with some operators and not work with others, troubleshooting this when your users are road warriors isn’t as fun as one might think…

Note on images: All ip’s / hostnames are masked for customer security.

Server side:

External interface

IPv4 + Ipv6 enabled
Two consecutive IP’s entered
No DNS – This forces the server to always lookup in the internal DNS / through forwarders
No client for Microsoft networks
No file / printer sharing

(click for Lightbox)

Internal interface

No gateway
Internal DNS

(click for Lightbox)

Client side:
Check certificate – Needs to contain a subject name or SAN (Subject Alternative Name) which matches the DNS name of the client. (This also applies to the certificate used for the UAG-server’s SSL-connection.) If the certificate is not properly configured you’ll most likely get eventid 4653 for IPSec.

(click for Lightbox)

Checking the tunnels:
Start Windows Firewall with Advanced Security
Open Monitoring, Security Associations and check under Main + Quick Mode that your tunnels are established. This could also be done with netsh, see below.

(click for Lightbox)


(click for Lightbox)

Show main/quick mode connections (read here for more information on IPSec and connections)

netsh advfirewall monitor
show mmsa
show qmsa

Show 6to4 adapter state
netsh int 6to4
show state

Show Teredo adapter state
netsh int teredo
show state

Show IPHTTPS adapter state
netsh in http
show int

Show dns client settings
netsh dnsclient
show state

Show DNS effective name resolution policy table(NRPT)
netsh namespace
show effective

Useful resources and reading:
A useful 6to4 calculator –

Designing a Direct Access solution –
Direct Access Management –
The Direct Access Test Lab Step-by-Step Guide –
General troubleshooting for Direct Access –

Hope that you’ll get it up and running. I have another post drafted that will deal with the “manage out”-perspective that will allow you to remotely manage / access your clients, will post ASAP!

NIC Teaming in Server Core or Hyper-V Server

Teaming with Intel ProsetCL
Teaming with Broadcom BACScli

If you’re running Server Core or Hyper-V Server 2008 R2 you’ve probably come across the problem of teaming nics. No matter which hardware vendor you choose, they all have they’re special way of doing things. Helping an old colleague out the other day it made me realize that it’s not as straightforward as it is in the full version, so I’ve tried it out with both Intel and Broadcom nics. Which you of course know covers the servers from both HP and Dell (where I work, shameless plug).

Installing the Broadcom software to support network teaming in Server Core / Hyper-V Server

Before you start you must install the prereq’s for the drivers, that comes down to .Net 2.0, .Net 2.0 WOW64 and SNMP.
The easiest way is to use OcSetup to install them:

Start /w ocsetup NetFx2-ServerCore
Start /w ocsetup NetFx2-ServerCore-WOW64
Start /w ocsetup SNMP-SC

The “/w” will let you wait during installation so you know when it’s finished, please note that roles/features are case sensitive for ocsetup so type it as it looks…

When that’s done you’ll need to download the 14.1.x-version of the BACS from Dell’s site and extract them to somewhere on your drive, default is c:broadcom. Navigate to the c:broadcomdriver_management_apps_installer and run setup.exe.

The wizard kicks in and when you’re done you can team your nics (and change other things too) through the c:/program files/broadcom/bacs.exe utility.

Installing the Intel software to support network teaming in Server Core / Hyper-V Server

Turns out that Intel has their own great post on the subject of command line installations which you can find at

A short rundown otherwise is that you’ll need the setup.exe program for your nic, then you have multiple choices on how to install them. The base driver can be installed through the included pnputil.exe for Server Core or you could use the Intel setup.exe instead.

This is from Intel’s site and shows you what switches does what:

Setup.exe support the following command line parameters:

Parameter Definition
ANS Advanced Network Services
“0”, do not install ANS. If ANS is already installed, it will be uninstalled.

“1”, install ANS (default).

NOTE: If the ANS parameter is set to ANS=1, both Intel PROSet and ANS will be installed.

DMIX PROSet for Windows Device Manager
“0”, do not install Intel PROSet feature. If the Intel PROSet feature is already installed, it will be uninstalled.

“1”, install Intel PROSet feature (default).

NOTE: If DMIX=0, ANS will not be installed. If DMIX=0 and Intel PROSet and ANS are already installed, Intel PROSet and ANS will be uninstalled.

SNMP Intel SNMP Agent
“0”, do not install SNMP. If SNMP is already installed, it will be uninstalled.

“1”, install SNMP (default).

NOTE: Although the default value for the SNMP parameter is 1 (install), the SNMP agent will only be installed if:
The Intel SNMP Agent is already installed. In this case, the SNMP agent will be updated.
The Windows SNMP service is installed. In this case, the SNMP window will pop up and you may cancel the installation if you do not want it installed.

BD Base Driver and IOATDMA Driver
“0”, do not install the base driver.

“1”, install the base driver (default).

LOG [log file name]
LOG allows you to enter a file name for the installer log file. The default name is C:UmbInst.log.

-a Extract the components required for installing the base driver and I/OAT driver to C:Program FilesIntelDrivers. The directory where these files will be extracted to can be modified unless silent mode (/qn) is specified. If this parameter is specified, the installer will exit after the base driver and I/OAT driver are extracted. Any other parameters will be ignored.
-f Force a downgrade of the components being installed. NOTE: If the installed version is newer than the current version, this parameter needs to be set.

How to install the base driver on Windows Server 2008 and Windows Server 2003:

:Setup DMIX=0 ANS=0 SNMP=0

How to install the base driver on Windows Server 2008 and Windows Server 2003 using the LOG option:

:Setup LOG=C:installBD.log DMIX=0 ANS=0 SNMP=0

How to install Intel PROSet and ANS silently on Windows Server 2008 and Windows Server 2003 (32-bit version):

:Setup DMIX=1 ANS=1 /qn

How to install Intel PROSet without ANS silently on Windows Server 2008 and Windows Server 2003 x64 Edition:

:Setup DMIX=1 ANS=0 /qn

How to install components but deselect ANS for Windows Server 2008 and Windows Server 2003:

:Setup DMIX=1 ANS=0 /qn /liew C:install.log

The /liew log option provides a log file for the DMIX installation.

To install teaming and VLAN support on a system that has adapter base drivers and Intel PROSet for Windows Device Manager installed, type the command line :Setup ANS=1.