17 Jul 2013

Direct Access 2012 Installation Fun

We've recently upgraded our environment from Windows XP to Windows 7 Enterprise and therefore I thought it worthwhile to see what all the fuss was about regarding DA.

Instead of using UAG and Server 2008 R2, I took a shortcut and went straight for DA with Server 2012. Below are a few of the issues that I experienced and their associated fix.

Network Location Server

It's worth noting that when considering the placement of the Network Location Server, that it's not a good idea to place it on the DirectAccess server. This is due to DA configured clients, misjudging that they are outside the corporate infrastructure when the NLS is unreachable. When the NLS is unavailable they will attempt to connect to their DA server which will also be unavailable (it's the same server in this case) therefore putting the machines into a loop and disrupting their connectivity.

Do yourself a favour, build a separate NLS and consider using VMware Fault Tolerance (as an example - there are other virtualisation technologies) to ensure that it's always available in the event of a hardware failure.

The adapter configured as external-facing is connected to a domain
When configuring the server, no matter what config I used, the 'Domain' profile was being associated with the external NIC, this is a problem due to the Network Location Awareness functionality within the Operating System which I could not resolve elegantly. After much Googling I resorted to a Block rule in the Windows Firewall.

General: Block the Connection
Scope: 2x External IPs
Programs and Services: Services - Network Location Awareness - NLASVC

Once configured, disable and re-enable the external interface and it should be associated with a public profile.

There is no valid certificate to be used by IPsec which chains to the root/intermediate certificate configured to be used by IPsec in the DirectAccess configuration.
The fix was to allow the DirectAcess server to auto enrol it's own Computer Certificate, even though a Server Authentication cert was present in it's Local Computer Cert Store. The Enhanced Key Usage on our Computer  Certificate Template includes Server Authentication and Client Authentication, I believe that it's the Client Authentication that made the difference.

8 Jan 2013

Adventures when upgrading SCCM 2012 to SP1

I recently upgraded our newly installed SCCM 2012 RTM infrastructure to SP1 after it's release in late December and after doing so I encountered a number of issues, below are the issues that I experienced and the associated fixes.

Broken MDT Database Connectivity

We have MDT 2012 U1 integrated with our SCCM infrastructure and use the MDAC based database functionality to lookup various details but after the SP1 upgrade,  the following errors could be found in the BDD.log;
Unable to create ADODB.Connection object, impossible to query SQL Server: ActiveX component can't create object (429)
After some research and forum posts I managed to confirm that the upgrade process had removed MDAC from the MDT Boot Image and therefore crippling database connectivity when inside WinPE. To resolve this, I found it necessary to recreate the the MDT Boot Image from within the SCCM Admin Console.

Misassignment of drive letters during OSD of Windows 7

Another side effect of the SP1 upgrade was that previously working Windows 7 images were installing but assigning drive letters D: or E: instead of the normal C: drive assignment. This appears to be a result of the introduction of the new Task Sequence variable OSDPreserveDriveLetter. When investigating my existing Task Sequences I found that a new step had been added to named 'Set Variable for Drive Letter' which declares the value of this variable as False. By changing this value to True, this ensures that the intended drive letter assignment is honoured and therefore future OS drives are assigned C:.