Friday, 16 December 2011

Thinking of Customising Forefront UAG? This Upcoming Book Might Help!

When it comes to customising Forefront UAG (and its predecessor IAG) there is limited information available. There is some good content available over at (thanks Idan) and also in various wikis/blogs, but even with code samples you can find dotted around the web, it can still be pretty difficult to put the customisations into place without a better understanding of how UAG customisation really works.

I have done some UAG customisation work to various levels (but no way near as much as some of my fellow Forefront MVPs like Idan Plotnik and Alexandre Giraud) but I am certainly not a web developer and found it pretty hard going at times to be honest.

So, why am I telling you all this? Well, two friends/colleagues from Microsoft named Erez Ben-Ari and Rainier Amara have come to your (and my!) rescue by writing a book all about UAG customisation. It will be called, not surprisingly; Mastering Microsoft Forefront UAG 2010 Customisation and can be ordered in various formats from the link below:

Mastering Microsoft Forefront UAG 2010 Customization

The book is available to pre-order now and should be finally released in February 2012. I have already pre-ordered my eBook copy and I am looking forward to finding out all the secret sauce about UAG customisations that these guys can dish up! Yum Yum Smile 

One of my other good friends and fellow Forefront MVP, Richard Hicks, is also technical reviewer for the book (you might notice we like to ‘keep it in the family’ here in the Forefront MVP club) for which I am very envious, as he gets to see the book before the rest of us mere mortals!

So, go pre-order (or order if you are reading this blog after the book is released) your copy now!!

If you work with UAG as part of your day, or are looking at implementing the product, I think this book will become a must read guide and a great addition to your technical bookshelf.

Good luck with the book guys and thanks for all your efforts!

P.S. I look forward to celebrating the release with all the other Forefront MVPs and friends when in Seattle for the 2012 MVP Summit in late February…

Tuesday, 6 December 2011

Forefront TMG/UAG: Useful Tools and Scripts

I spend a fair bit of time deploying both Forefront TMG and Forefront UAG for customers and therefore have defined a pretty good build checklist that I follow for every deployment. This makes implementations easier to support as we have a standard build and standard toolset available for every customer. As part of these deployments, I install some core tools and also run several scripts to provide a solid foundation for both products.

I thought it may be useful to share my experience and provide the community with some advice for more polished and supportable TMG/UAG deployments.


Please Note: As Forefront UAG includes an instance of Forefront TMG, it is recommended to install all tools, but only run the scripts defined in the ‘Scripts: General’ section on UAG servers.


In terms of tools, my standard build would normally include the following tools:

Forefront TMG Best Practice Analyser which can be downloaded here.

This tool should be pretty self-explanatory and should be installed on every Forefront TMG server to look for common problems and configuration errors. Run this tool at least once when you have completed your Forefront TMG installation and configuration.

Forefront UAG Best Practice Analyser which can be downloaded here.

This tool should be pretty self-explanatory and should be installed on every Forefront UAG server to look for common problems and configuration errors. Run this tool at least once when you have completed your Forefront UAG installation and configuration.

Network Monitor which can be downloaded here.

This tool should be pretty self-explanatory and should be installed on every Forefront TMG/UAG server to aid troubleshooting when the time comes. Network Monitor is also a prerequisite for using the Data Packager element of the Forefront TMG Best Practice Analyser.

Please Note: Additional Forefront TMG tools can also be downloaded from here, but I don’t tend to install all of these by default.

Scripts: General (Applicable to TMG and/or UAG)

In terms of general scripts, my standard build would normally include:

SetNetBTNodeType.reg which can be downloaded here.

This script is used to prevent NetBIOS broadcast traffic (and thereby dramatically
improve TMG performance) by configuring Windows as a peer-node host using the NetBT NodeType registry value. Props for this particular registry setting goes to the Microsoft Forefront TMG Administrators Companion book, which is highly recommended! Winking smile

SetServiceDependencies.bat which can be downloaded here.

Since Forefront TMG Service Pack 1 and above, I have had numerous occasions where Forefront TMG server takes a long time to reboot. These problems are well documented on various forums and blogs and I am still unsure if the issue has been fully fixed, even in the latest service pack level. To combat these problems, we which lies with the failure to start the Microsoft Forefront TMG Control service (isactrl) within a timely fashion, it is possible to change/reset the dependencies of the Forefront TMG Control service, thereby eliminating the problem.

An example blog post detailing the problem can be found here.

RemoveWeakVersions2k8.reg which can be downloaded here.

This script is used to disable SSL version 2 which is enabled by default with Windows Server 2008/R2.

Disabling SSL v2 is a well versed security recommendation as it suffers from several cryptographic flaws and has been deprecated for several years. You can validate this change has been completed successfully using the Qualys SSL LABS: SSL Server Test available here.

Scripts: Web Proxy (N/A to UAG)

In terms of web proxy specific scripts, my standard build would normally include:

SetTemporaryStorageSettings.vbs and ShowTemporaryStorageSettings.vbs which can both be downloaded here.

Until quite recently, I was unaware that Forefront TMG Malware Inspection imposed a maximum disk space, in megabytes, that may be allocated for temporary disk storage for a single client  during malware inspection. The default maximum disk space is set at 50MB, which sometimes needs adjusting depending on the different customer environments. This script can therefore be used to set (or show) the default temporary storage limits to something more appropriate. It is a shame you cannot modify these parameters from within the Forefront TMG console, but this makes the script all the more useful and valuable.

More information (including other temporary storage limit settings) can be found here.

UseDNSforWPAD.vbs which can be downloaded here.

Based upon information provided in this blog article and personally experiencing problems with the WPAD.DAT file containing the IP address of the RAS adapter instead of the correct server primary internal IP address; I started using this script which instructs TMG to use the DNS name of array members (or server) instead of IP addresses in the WPAD script.

Please Note: With the advent of Forefront TMG SP2, using Kerberos with an NLB web proxy array is now much improved as discussed here.

Scripts: Web Publishing (N/A to UAG)

In terms of web publishing specific scripts, my standard build would normally include:

EnableSP2FBACookieSharing.vbs which can be downloaded here.

By default, a Forefront TMG forms-based authentication cookie is only valid on the array member that generated the cookie. If a client request that contains an authentication cookie from one array member is sent to a different array member, the client is asked to re-authenticate. This behaviour may occur when a node is taken offline. Or, this behaviour may occur if the client source IP changes between requests that affect which array member handles the incoming request.

Forefront TMG Service Pack 2 added functionality to support cookie sharing across array members. To do this, SP2 enables support for the cookie encryption keys to be shared across array members.

Please Note: To support sharing cookie encryption keys, the array members must be domain-joined. Be aware that this script does not work for workgroup-based array members.

As this is a pretty significant change in functionality, for the better, I now run this script by default when deploying standalone or EMS-managed arrays where array members meet the domain joined prerequisite.

More information on this new SP2 feature is available here.

Other Important Build Configuration

I wasn’t planning on talking about standard build configuration as this blog post was meant to be dedicated to tools and scripts, but I think they are actually hugely relevant when deploying TMG/UAG server. Hence I have included two key baseline configuration tasks for any TMG/UAG implementation

In addition to installing the above tools and scripts, it is also vital to configure TMG and UAG server network adapter settings and bind order appropriately. More information on this particular aspect is provided in the following TechNet Wiki articles:

Recommended Network Adapter Configuration for Forefront TMG Standard Edition Servers

Recommended Network Adapter Configuration for Forefront TMG Enterprise Edition Servers

Recommended Network Adapter Configuration for Forefront UAG Servers

And finally, make sure you have applied the latest updates and service packs for TMG and/or UAG; at the time of writing, this is Forefront TMG Service Pack 2 (build version 7.0.9193.500) and Forefront UAG Service Pack 1 Update 1 (build version 4.0.1773.10100).

I hope you find these tools and scripts useful and have learned something new to improve your own TMG/UAG deployments. If you have other tool and scripts recommendations, please drop me a comment below and I will endeavour to add these to the list.

Forefront TMG: Antivirus Exclusions Process Path Correction

I noticed recently that the TechNet documentation titled Considerations when using antivirus software on FF Edge Products available here contains an error within the Forefront TMG section.


The process exclusion for ReportingServicesService.exe is defined with a path of:

%ProgramFiles%\Microsoft SQL Server\MSSQL10.ISARS\MSSQL\Binn\ReportingServicesService.exe

and this should actually read:

%ProgramFiles%\Microsoft SQL Server\MSRS10.ISARS\Reporting Services\ReportServer\bin\ReportingServicesService.exe

I have provided feedback on the page, but until this gets changed, you may want to update your existing deployments with the correct process exclusion path.

Hope this helps!

Friday, 2 December 2011

Forefront UAG: The DirectAccess NLB Helper Driver Cannot be Activated Error

This is a rare problem but I have personally experienced this problem twice now and as there appears to be no other reported instances on the Internet, I thought it might be useful to share it in case anyone else experiences the same issue.

The customer in question has a three node UAG array and without warning, the first built node (which is also the Array Manager) failed to activate with a The DirectAccess NLB Helper Driver cannot be activated error. This was also accompanied by the following event log entries:



The other two array members appeared to activate just fine, and DirectAccess connections appeared to be working as usual across the array. However, I suspected that DA connections via the problematic array member would actually be failing to operate correctly, or new connections may not establish successfully. Either way, it needed fixing ASAP!

The UAG DirectAccess NLB Helper driver is discussed in more detail here and basically provides bi-directional affinity for DA clients when using NLB for a Forefront UAG DirectAccess array. This helper is also commonly termed ‘daeng’.

The first time I saw this problem, I spent quite a bit of time on it and also contacted some of my Microsoft contacts to see if they had seen this before – I came up blank. Microsoft hadn’t seen the issue before from what I could tell and due to time constraints I had no option but to rebuild the UAG server (I was still in the build/deployment stage of the project and had no server backups at that time).

After seeing the problem occur again whilst looking at another UAG array issue, this time the customer managed to fix it themselves (I hate it when they do that Smile) with the following solution:

By issuing the following command:

sc query daeng

they received a response of Driver not running and upon investigation found that the daeng.sys file was actually missing from the %Program Files%\\Microsoft Forefront Unified Access Gateway\common\bin\ folder.

They copied the daeng.sys file from one of the other array members and then issued the following command:

sc start daeng

the driver now successfully started (strangely enough!); a reboot later and UAG then successfully activated on that array member – all  was calm in a world called UAG Smile

I am not 100% sure what caused the problem, but it appeared to be primarily related to missing files on the affected Forefront UAG server. Why the files were missing is something I (or they) haven’t been able to solve (which worries me) but it is still interesting to understand the solution that was required in any case.

Hope this helps!

Tuesday, 8 November 2011

Limiting ISATAP Services to UAG DirectAccess Manage Out Clients

A common requirement or ask for most UAG DirectAccess deployments is the need to remotely manage DirectAccess clients when they are away from the corporate network. This is often termed ‘manage out’ and is one of the major benefits of a UAG DirectAccess solution when compared to traditional VPN remote access solutions. The ability to reach a managed client, irrespective of their location, irrespective of whether they are logged in, is a power tool for IT administrators.

However, the need for corporate connected manage out clients to be IPv6 capable often presents a challenge if the customer is not running IPv6 within their environment. This challenge is often met by configuring an intranet transition technology called ISATAP (Intra-Site Automatic Tunnel Addressing Protocol).

Unfortunately, the ISTAP mechanism uses a hard coded DNS lookup process that is automatically enabled on on Windows Vista, Windows 7 and Windows Server 2008/R2. This DNS lookup requires the creation of a global ‘’ DNS host record, and this will ultimately enable ISATAP, and automatically assign IPv6 addressing and prefix information, across the entire Windows Vista+ environment. In some scenarios, enabling IPv6 support using ISATAP is desirable, but for many deployments, adding IPv6 capabilities to all Windows systems is not desirable; especially when Windows will naturally favour IPv6 communications over IPv4. For many customers, the cultural change this IPv6 preference brings to a desktop and/or server administrator is more than a little confusing, and definitely not something that should be enabled globally without some thought.

So, how do we provide the IPv6 capabilities required for UAG DirectAccess manage out, whilst still preserving a more traditional IPv4 experience for other Windows systems?

The main way to solve this problem is to move away from using the global ‘’ DNS host record that is hard coded into all Windows Vista+ systems, and use a custom ISATAP router name that is specific to your environment. With this DNS host record created, all we need to then do is enabled specific clients to use this custom ISATAP router name and we have a mechanism of controllers ISATAP on our terms.

Please Note: An alternate approach using HOSTS files is feasible for very small deployments, but this has limited scalability and does not allow for the creation of an ISATAP DNS record that contains a VIP and multiple DIPs, as required when using a UAG DirectAccess array. Therefore this approach is not recommended outside of a lab environment.

In my opinion, the best way to achieve this technically is by way of Group Policy and a dedicated Windows security group for manage out clients, as follows:

Step 1: Create a Custom ISATAP DNS Record

Create a new DNS record called [something], or similar.

Step 2: Create a Windows Security Group

Create a new Windows security group called UAG DirectAccess Manage Out Clients. or similar.

Step 3: Create a New Group Policy

Using GPMC, create a new group policy object called UAG DirectAccess: Manage Out Clients (Enable ISATAP) or similar, with the following properties:


Under the Scope tab, remove Authentication Users from the Security Filtering section and add the Windows security group created above; UAG DirectAccess Manage Out Clients in our example.


Under the Details tab, set the GPO Status to User configuration settings disabled


Edit the newly created GPO and define the following settings:

Computer Configuration | Policies | Administrative Templates | Network | TCPIP Settings | IPv6 Transition Technologies

ISATAP Router Name: Enabled

Enter a router or relay name: [something]


ISATAP State: Enabled

Select from the following states: Enabled State


Once completed, this should result in the following output in the Settings tab:


Step 4: Add Computer Accounts to Windows Security Group

All that now needs to be done is to add the computer accounts for machines that will be used for remote management of DirectAccess clients to the UAG DirectAccess Manage Out Clients Windows security group.

Please Note: It will be necessary to reboot clients and servers after adding them to the UAG DirectAccess Manage Out Clients windows security group before the new GPO will be applied.

Once this has been done, the specific manage out clients that you have defined by group membership should now receive an ISATAP addressing and prefix information making them IPv6 capable.

Once configured correctly, you should receive a 2002:WWXX:YYZZ:8000:5efe:w.x.y.z format address (or similar) on the ISATAP adapter and will be able to remotely manage DirectAccess clients from this predetermined group of manage out machines.

Please Note: If the ISATAP adapter address assignment is not successful, it may also be necessary to use the following command to refresh the adapter state: sc control iphlpsvc paramchange

Hope this helps!

Thursday, 20 October 2011

Single-Label DNS Domain Names and Forefront UAG DirectAccess SP1

Single-label DNS domain names consist of a single word or label like .global or .lan and often look like top-level domain names (albeit illegal ones). One of the biggest problems with single-label DNS names is that they cannot be registered with an Internet registrar.

A good article that covers configuring Active Directory domains by using single-label DNS names can be found here, with a general summary of:

Active Directory domain names should consist of two or more labels for the current and the future operating system and for application experience and reliability.

An article for general DNS Namespace planning can be found here that also advocates similar best practices.

In general, Microsoft does not recommend using single-label DNS names as discussed in the above articles.

However the term single-label is also, confusingly, used with the UAG DirectAccess TechNet documentation to refer to a different scenario. Within the UAG DirectAccess documentation the term single-label actually refers to unqualified, single-label names that are sometimes used for intranet servers so that you can specify a single name, such as http://intranet. This is an unfortunate overlapping of terms for two very different UAG DirectAccess concepts and is the first thing I wanted to highlight as part of this post. Those looking at the UAG DirectAccess documentation who may have come across the single-label DNS domain name term before when talking about an environment (one that a DNS domain name like .global for example) may consequently become quite confused. From this point on I will use the term single-label in this more traditional context and will abbreviate it to SLDNS.

The subject of SLDNS and UAG DirectAccess has come up a few times now, so I thought it would be useful to write a quick blog post with my views on the subject.

The first area of consideration for SLDNS is when defining Client Domains within Step 1: Clients and GPOs Configuration of the UAG DirectAccess wizard.

With the advent of Forefront UAG Service Pack 1, it appears that UAG DirectAccess no longer accepts the use of SLDNS and you will receive a An error occurred while loading the configuration. Please configure DirectAccess again error when attempting to Activate the UAG configuration after running the UAG DirectAccess wizard. I don’t believe UAG DirectAccess has ever supported this particular scenario, but I cannot find any documentation to confirm or dispute this statement at this time.

The second area of consideration for SLDNS is when defining DNS Suffixes within Step 3: Infrastructure Server Configuration of the UAG DirectAccess wizard.

This section of the wizard essentially allow you to define the Network Policy Routing Table (NRPT) which is used by DirectAccess clients for name resolution decisions. If you attempt to define a new DNS suffix and enter a SLDNS domain name, you will receive a The DNS suffix cannot be a DNS label error as shown below:


The final area of consideration for SLDNS is when defining Authentication Domains within Step 3: Infrastructure Server Configuration of the UAG DirectAccess wizard.

Again, in a similar way to when defining Client Domains within Step 1: Clients and GPOs Configuration of the UAG DirectAccess wizard, choosing an SLDNS for the Authentication Domains section will result in receiving a ‘An error occurred while loading the configuration. Please configure DirectAccess again’ error when attempting to Activate the UAG configuration after running the UAG DirectAccess wizard.

So, if you are running Active Directory DNS namespaces that use SLDNS domain names, or you have SLDNS namespaces in use somewhere within your organisation that need to be reached by DA clients, bear in mind that this will seriously impact your ability to deploy UAG DirectAccess without making some significant changes to your existing environment. Consequently, you would probably (unfortunately) do best to choose an alternate remote access solution, until you can “fix” your inherent DNS namespace design problem Winking smile

Wednesday, 28 September 2011

Forefront TMG Web Publishing Rule Test Results Report Errors on One or More Paths When Publishing SharePoint

A fair few of my working ISA Server and Forefront TMG deployments are used to publish and protect SharePoint environments.

The Problem

Since the gradual move of many customers to SharePoint 2010, I have noticed that the Test Rule button that is available as part of the web publishing rule created by the SharePoint Publishing Wizard, often produces errors, even though external access to SharePoint via Forefront TMG seems to be fully functional. As many customers use this feature as an initial sanity check for publishing rule configuration (as I do myself) this can actually lead many people to believe there is a SharePoint publishing problem, when in fact there isn’t! An example of the errors can be seen in the screenshot below:


After being asked by a few bemused customers why this was happening, I decided to investigate the issue at little further. This blog article provides an overview of my investigations, thought process and conclusions.

The Investigation

My first assumption was that this issue was introduced as customers moved from SharePoint 2007 to SharePoint 2010, combined with the fact that the SharePoint Publishing Wizard included with Forefront TMG appeared to defined the paths generically for SharePoint, as opposed to version specific. The paths also appeared unchanged from the same wizard in ISA Server, even though support for SharePoint 2010 wasn’t specifically added until Forefront TMG Service Pack 1 was released. As discussed above, I was confident that in most cases the issue was purely cosmetic and a failure in the Test Rule output didn’t specifically mean SharePoint publishing would fail or was configured incorrectly in any way.

After a bit of testing, it was apparent I could get consistent failures in the Test Rule feature for the following paths:

<Internal Site Name>/_vti_inf.html*

<Internal Site Name>/_upresources/

as shown in the screenshots below:



Confusingly, both paths didn’t fail consistently for different SharePoint environments I tested. Sometimes just one path would fail, other times both paths would fail. How strange Smile

After a bit more research on the _vti_inf.html* path, I discovered that this is specifically related to FrontPage Server Extensions (FPSE) and is common place on both SharePoint 2007 and SharePoint 2010 environments. However, having compared two different SharePoint 2010 environments I was getting Test Rule path failures for one, but not the other, which seemed very odd and inconsistent. Then I noticed that one of the SharePoint servers (the successful test result) was running on Windows Server 2008 and the other SharePoint server (the unsuccessful test result) was running on Windows Server 2008 R2. After a little more Googling, I determined that Microsoft removed support for FPSE running on IIS 7.5, which is the version of IIS now included with Windows Server 2008 R2. Consequently, I concluded that it would never be possible for the  _vti_inf.html* path check to succeed for a SharePoint server that is running on Windows Server 2008 R2. From further testing, I managed to confirm this theory across multiple customer environments that had this particular operating system platform hosting SharePoint.

After researching the _upresources/ path, it became apparent that there were very few search results that included the _upresources term in the context of SharePoint itself. Sure, there were lots of references to _upresources in the context ISA/TMG and SharePoint. After looking at numerous SharePoint deployments, I couldn’t find a single one that actually had a virtual directory called _upresources; a majority of them did, however, have a virtual directory called _wpresources. I decided to lookup the use of this folder and determined it was a folder that contains a web.config file used in Web Part resources and hence a pretty core part of any SharePoint deployment. This made me suspicious and my instant thought was “No, surely the wizard doesn’t contain an incorrect path statement or typo?” I looked back at documentation I have done for customers running ISA Server over the years, and saw the same _upresources/ path statement in those rules too. Maybe this issue had been around for a long time, and just never noticed and/or publically acknowledged by Microsoft in a KB article. Maybe SharePoint used to use this path, but it has been removed in more recent versions.

Knowing that the likelihood of this path being present on a SharePoint environment was pretty low, I was then intrigued as to why I was receiving successful results on some SharePoint environments; even after confirming the path was definitely not present with IIS.

After reviewing the IIS logs on two different SharePoint environments, I noticed that the path check was successful when IIS returned a HTTP 401 error, and not successful when IIS returned a HTTP 404 error. These results were echoed in the Test Rule output as shown below:



This made me think about authentication configuration within IIS. Further testing revealed that the SharePoint environment that returned the HTTP 401 error had been specifically configured with Anonymous Access disabled at the site level in IIS, as shown below:


The net result of this was that IIS would generate a HTTP 401 response, even though the requested path was not valid (remember _upresources didn't actually exist).

For the SharePoint environment with Anonymous Access enabled at the site level (as shown below), IIS would correctly generate a HTTP 404 response as the requested _upresources path was invalid and authentication was not required to access this resource.


So, given the actual configuration of the IIS site hosting SharePoint, we would get a HTTP 401 response or a HTTP 404 response. Consequently, the Test Rule function would indicate a success or failure based upon these error codes, as shown below:



As the Test Rule function is not able to provide credentials to IIS, I would assume that it is designed to treat HTTP 401 responses as an indication that the path is present and consequently pass the test. However, this logic seems a little flawed if you think about the implications of this logic when the path doesn’t actually exist but IIS requires authentication; but you could argue that one would expect Anonymous Access to be disabled at the IIS site level for a majority of SharePoint deployments that are protected by Forefront TMG. Unfortunately, I don’t really know enough about SharePoint to validate this statement.

The Conclusions

Based upon the above testing and findings, I concluded the following:

  • If you are running SharePoint on Windows Server 2008 R2, then the <Internal Site Name>/_vti_inf.html* path test will FAIL due to the lack of FPSE support in IIS 7.5.
  • If you are running your SharePoint site with Anonymous Authenticated disabled at the site-level then the <Internal Site Name>/_upresources/ path test will SUCCEED as IIS will respond with a HTTP 401 error.
  • If you are running your SharePoint site with Anonymous Authenticated enabled at the site-level then the <Internal Site Name>/_upresources/ path test will FAIL as IIS will respond with a HTTP 404 error.

As it is not possible to easily modify the path statements added by the SharePoint Publishing Wizard, I believe the issue will need to be fixed by Microsoft within the wizard code in order to correct the paths, or logic, and remove the undesired results provided above. For now, I hope this blog article at least puts your mind at rest if you have experienced the problem first hand and then assumed you had done something wrong. The chances are that if at least one of the path tests succeeds, you should be good to go…

Please Note: I am currently trying to confirm my findings and conclusions with Microsoft, so I will update the article when I have more information.

UPDATE: Spoke to a couple of contacts at Microsoft (thanks Jim and Yuri) and it does look like the incorrect _upresources path is indeed a TYPO and the HTTP 401 success behaviour is by design, as discussed here:

Wednesday, 11 May 2011

TechNet Wiki: Forefront TMG/UAG Articles Published

I have spent some time recently converting a few of my more recent/popular blog posts into TechNet wiki articles. This has given me an opportunity to update the articles in some cases, but more importantly, allows the articles to become ‘community dynamic’ based upon changes, feedback and comments. I am hoping these articles will also have higher visibility as the TechNet Wiki content is highly optimised for search engines which means that people should find the content more easily and quicker.

At this time I have published the following articles:

Forefront UAG SP1 Endpoint Assessment Changes Impact Mobile Devices

Forefront UAG DirectAccess: Application Compatibility Table

Problems Accessing SharePoint 2007 RSS Feeds via Forefront UAG

Should I Place Forefront TMG at the Edge of My Network?

Recommended Network Adapter Configuration for Forefront TMG Standard Edition Servers

Recommended Network Adapter Configuration for Forefront TMG Enterprise Edition Servers

Recommended Network Adapter Configuration for Forefront UAG Servers

You can also search for articles I have written (or contributed to) using the following link:

Search TechNet Wiki for My Articles

Watch out for more Wiki articles in the near future…

Thursday, 7 April 2011

UAG DirectAccess: A More Enjoyable Deployment Experience!

Having just finished a UAG DirectAccess proof of concept (POC) project for a long-standing customer, I am feeling rather upbeat. As a security guy, I often find myself with a relatively negative mind-set as I am often helping customers deploy Microsoft-based solutions to mitigate risk or reduce the potential exposure to security breaches or incidents.

Since working with customers on deploying UAG DirectAccess solutions, this is a much more enjoyable deployment experience and an altogether more positive mind-set compared to something like a server hardening project. This is because although DirectAccess is seen as a secure remote access solution, it is also seen as an business ‘enabler’ rather than a more traditional business ‘blocker’ that security deployments are often tainted with. Consequently, customers have a much more positive reaction which borders on ‘IT enjoyment’. It is also really interesting to see the ‘virtual cogs’ in their heads begin to turn when they see how DirectAccess will change their working environment and also the usability, productivity and manageability of the users that they support. Out of all the reactions, the shear transparency of DirectAccess seems to one of the remaining highlights for most people. However, it sometimes feels a bit deflating after a fair bit of hard “techie work” to hear them utter “Is that it?" or “That was easy!” when they see it working for the first time. There is no doubt that UAG DirectAccess is not quite so easy for the IT guy in terms of troubleshooting and support (or setup either, but at least I can help them out there). There is also the instant dependency that users will place upon the service with comments like “What, you want DirectAccess downtime? But I use it all the time!”

So what does a UAG DirectAccess POC involve? Well, it is very dependent upon the customer requirements of course, but I thought it might be interesting to provide a high-level overview of how I approached this recent POC and what was involved along the way…

First Day – Introduction to DirectAccess and Preparation of the Core Infrastructure Components

I always start a UAG DirectAccess POC with an overview of how DirectAccess works. This usually involves a very messy diagram (well, it’s messy when I am finished!) and a lot of technical tangents and a few bemused looks as the UAG DirectAccess pieces of the puzzle are laid bare, warts and all. Of all concepts discussed, I think IPv6 is probably the one that pushes most people out of their usual techie comfort zone; closely followed by PKI and certificates.

To fully understand DirectAccess, you need to a good grasp on various technologies; two of which are mentioned above. Luckily, most of these dependencies and prerequisite skills fall nicely within my general skillset from the last 15 years of working on Microsoft-based infrastructure security projects. Understanding IPv6 was probably my most challenging area whilst learning DirectAccess. I am certainly no IPv6 guru, by any means, but my netsh repertoire is improving and the fundamentals are starting to stick.

So, as part of preparing the infrastructure, I usually follow the high-level items detailed in my previous blog posts here or here. In this POC instance, the NLS web site would be hosted on a new VMware virtual machine and an existing Enterprise CA was able to provide the necessary certificates (although not as strictly configured to meet best practice as I would have liked).

With the NLS web site ready and PKI validated, we then begun installing and configuring a baseline UAG deployment before running the actual UAG DirectAccess Wizards. In this particular POC, the customer was using a Celestix WSA appliance which greatly reduces deployment time and makes my life a little easier. After whizzing through the Celestix quick start wizards, and the usual UAG Getting Started Wizard, we could then begin looking at enabling the DirectAccess features. The last thing to do was to issue a GlobalSign SSL certificate which would be used for the IP-HTTPS listener. It may be interesting to note that I always recommend using a certificate from a public CA for this role to simplify potential CRL publishing complications, and offload the responsibility of maintaining the CRLs to someone else.

However, time to call it a day I think… 

Second Day – A Working DirectAccess Client and Begin Basic Functionality and Application Testing

With the UAG server in place, we begun configuring DirectAccess using the in-built UAG wizards. Most of the decisions for the wizard were decided on the first day or were reviewed on the fly, with a little explanation along the way, to assist the decision making process. For this particular customer, they were using the same internal Active Directory DNS domain name as their external Internet DNS domain name. This adds some additional complication to the deployment, by way of needing to add NRPT exemptions in Step 4 of the UAG DirectAccess Wizard. This ensures that connections to Internet facing services would resolve using Internet DNS servers and not the DNS64 component of UAG. More information on this particular issue can be found here under the Split-brain DNS section and also here for UAG SP1.

With everything configured, we then used the Web Monitor to assess the health of the DirectAccess server roles. This gives us some confidence that server roles are good to go before even attempting to connect from a DirectAccess client.

The netsh commands described in this recent blog post usually provide a good sanity check that DirectAccess is enabled, configured and connecting, but I often supplement these with some “proper” testing like accessing file servers or intranet web servers. Be careful here that these servers are not accessible via the infrastructure tunnel, as this will not fully test that you have intranet tunnel access.

Testing produced the required results and things were going to plan. 

Please Note: Be careful when using PING and NSLOOKUP to test DirectAccess connectivity as discussed here.

In addition to manual testing, now was a good time to install the DirectAccess Connectivity Assistant (DCA), which is included as part of UAG SP1, on the test DirectAccess client. The GPO settings for DCA are now configured using the UAG DirectAccess wizard in UAG SP1, which makes life a little easier. The DCA reported DirectAccess connectivity is working so things were looking good!

So, with a working DirectAccess client, we can now begin performing some application compatibility testing to ensure core business applications function across the DirectAccess tunnels. It is not really possible to predict what applications may be used by a customer that are not compatible, so this stage of the POC is critical in order to achieve a successful outcome. I started a list of DirectAccess application compatibility in this blog post which defines some common known issues with possible mitigation techniques. However, in reality the customer just needs to test their core business applications using the new DirectAccess connection to determine if applications will work natively, or may require mitigation solutions or workarounds. The key requirement here is application support/awareness for IPv6 as discussed in more detail here.

After some initial testing, it was clear that some of the legacy LOB applications in use by this particular customer were going to be troublesome, so we would need to think about mitigation techniques for these. Other core corporate applications like email, web-based applications and file shares were all looking good.  

However, time to call it a day I think…

Third Day – Mitigation Techniques, Advanced Features and Tying Up Loose Ends

In my experience, the next day is often a “show and tell” and general Q&A day. Most folks are now familiar with the core concepts and begin exposing the solution to IT peers and other potential pilot users. This will often raise many additional questions, normally leading to testing new scenarios or applications that suddenly require consideration.

The third day will also often include the addition of some form of advanced feature or configuration extension; examples include:

  • Enabling Network Access Protection (NAP)
  • Enabling two-factor authentication using Smartcard or OTP
  • Adding a UAG portal to host the Secure Sockets Tunnelling Protocol (SSTP) Remote Network Access application which can be used as a DirectAccess fall back or mitigation solution.
  • Integration with an existing remote session technology like Citrix or Remote Desktop Services to provide a seamless mitigation solution (unlike SSTP) for specific applications.

The original expectation for this POC would be to move onto implementing two-factor authentication for DirectAccess at this point, however as it turns out, the deployment of an internal Citrix Secure Gateway for application compatibility mitigation was actually a higher priority at that stage.

For this particular POC, most of this day was then used to deploy and integrate an internal Citrix Secure Gateway solution for application compatibility mitigation, talk about the user impact of adding two-factor authentication to the solution (Smartcard or OTP via RSA) and also focusing on testing the remote management feature of DirectAccess clients (aka Manage Out).

We decided to call it a day at this point as we had a pretty usable deployment and more time would need to be spent on application testing and more internal “show and tell” stuff which they didn’t need me for…

So, that’s the anatomy of one particular UAG DirectAccess POC with a pretty standard deployment and some interesting, albeit common, challenges. This particular engagement involved three days; sometimes I get things done quicker and other times it can take longer, especially if the UAG portal features are also required or additional prerequisite work is required (like PKI setup).

Am I a geek for enjoying this stuff? Probably. Am I passionate about the technology? Definitely. Do I love DirectAccess? Of course!

If you need help understanding/designing UAG DirectAccess deployments, or just want help with your own UAG DirectAccess POC, you know who to call… Winking smile

Friday, 1 April 2011

UAG DirectAccess: Useful NETSH Commands

During UAG DirectAccess deployments, I will use several netsh commands as part of the initial deployment testing from a DirectAccess client. In the event of problems, this will often include include the use of additional advanced netsh commands which are more troubleshooting focused. After seeing these commands, many customers often ask for a list of the most useful ones that they can learn to assess and troubleshoot problems at the DirectAccess client. Consequently, I thought this might be something useful to document in a short blog post. The netsh tool is immensely powerful, but hopefully the following commands provide a good starting point to assess, understand and troubleshoot the DirectAccess client.

DirectAccess Client: Settings and Status

Useful Command: netsh dns show state

Description: This is probably the first and most useful command you will run, as it provides essential information on the current DirectAccess status and general configuration state.

Useful Command: netsh namespace show policy

Description: This command is used to display the Name Resolution Policy Table (NRPT) that has been defined within Group Policy.

Useful Command: netsh namespace show effectivepolicy

Description: This command is similar to the previous command but outputs the actual NRPT entries that are currently active on the DirectAccess client.

DirectAccess Client: Common Transition Technology Interfaces

Useful Command: netsh interface teredo show state

Description: This command shows the current status of the Teredo interface, if used at that time.

Useful Command: netsh interface httpstunnel show interfaces

Description: This command shows the current status of the IP-HTTPS interface, if used at that time.

DirectAccess Client: Windows Firewall Settings and Status

Useful Command: netsh advfirewall monitor show firewall

Description: This command is used to show the current status and configuration state of the local Windows Firewall.

Useful Command: netsh advfirewall show currentprofile

Description: This command is used to show the current Windows Firewall profile that is in use.

Useful Command: netsh advfirewall monitor show mmsa

Description: This command is used to show the current status of the Windows Firewall main mode security associations that are present when the DirectAccess infrastructure and intranet IPsec tunnels are active.

Useful Command: netsh advfirewall monitor show consec

Description: This command is used to show the current status of the Windows Firewall connection security rules which are used to define the DirectAccess infrastructure and intranet IPsec tunnels.

Please Note: The commands above have been shown in their verbose form for clarity, however many of the netsh parameter can actually be abbreviated for brevity. For example the ‘interface’ parameter is often actually entered as simply ‘int’.

To see these commands in action for both intranet and Internet scenarios, along with their respective outputs, I recommend you test drive the UAG DirectAccess Troubleshooting Test Lab Guide (TLG) available here.

Preparing an IPv6 Addressing Plan

For those looking at learning a little about IPv6 and guidance on addressing in the new 128bit world, SURFnet have written a useful document that is well worth reading. You can download an English translated PDF version (thanks to RIPE) titled Preparing an IPv6 Addressing Plan: Manual from here with more details also available here.


For a more in-depth learning experience and more detailed guidance, I would highly recommend the Understanding IPv6, Second Edition book written by Joe Davies (aka Cable Guy) as discussed here.


Friday, 14 January 2011

Using Exchange Client Access Server (CAS) Forms Based Authentication (FBA) with Forefront UAG is Not Supported (Now Enforced in SP1)

When publishing Exchange 2007 Outlook Web Access or Exchange 2010 Outlook Web App with Forefront UAG before SP1, it was possible to define the single sign-on method as HTML Forms. This allowed for the Exchange CAS servers to be configured with Outlook Web Access/App forms based authentication (FBA), and then utilise the HTML Form delegation capabilities of UAG to automatically populate the required username/password form fields based upon the credentials entered into the portal login page. This also made publishing Exchange Outlook Web Access/App easy to coexist with existing Exchange deployments that were already configured to use FBA.

However, although this appears to function correctly, it is not supported by the UAG product group for various integration reasons. Unfortunately, to make things worse, this single sign-on scenario is not (unhelpfully) covered in the UAG Support Boundaries document, so very few people outside of the product group ever realised this was actually an unsupported UAG configuration.

With the advent of UAG SP1, it is no longer possible to configure Exchange Outlook Web Access/App to utilise HTML Forms for single sign-on and basic (401) is now a mandatory option. Consequently, Exchange must be configured to utilise basic authentication and not Outlook Web Access/App FBA when used with UAG publishing.

In the Exchange publishing wizard you will now see no option to choose between 401 and HTML Forms:


Once the wizard is completed, an example of the new Authentication tab can be seen below with the HTML Forms option removed and basic defined as mandatory (unless using KCD):


In the event that you already have an existing Exchange application already configured defined, you will receive the following error in the UAG management console when editing the application:


Hopefully this information is useful for those of you publishing, or looking to publish, Exchange Outlook Web Access/App with Forefront UAG SP1…