All posts tagged Important Links

DirectAccess on the Microsoft Surface Pro

At Microsoft TechEd North America 2013 I had the privilege of (finally!) acquiring both a Microsoft Surface RT and a Surface Pro. I’d been wavering back and forth on which one to purchase for many months. As it turned out, my indecision (and admittedly some procrastination!) paid off. As you are probably aware, Microsoft was offering the Surface RT 64GB for $99.00 USD and the Surface Pro 128GB for $399.00 USD to TechEd attendees and third-party speakers. Needless to say I purchased both! I love the Surface RT for general Internet use like web browsing, e-mail, etc. The battery life is great and having Office apps is tremendously productive. However, as a technology geek I really like the power and flexibility that the Surface Pro offers. Since it is a full-fledged PC, I can install whatever software I like on it.

Being able to join a domain and enable DirectAccess would, of course, be the icing on the cake. The Surface Pro comes pre-installed with Windows 8 Professional, which means I can join a domain but unfortunately it doesn’t support DirectAccess. My plan was to wipe the device and reload Windows 8 Enterprise when I returned from the conference. As luck would have it, I ran in to my good friend and fellow Microsoft MVP Jordan Krause, and I was surprised to find that he had already upgraded his Surface Pro to Windows 8 Enterprise, joined it to his domain, and had enabled DirectAccess right there at TechEd! How did he do this so quickly? It turns out that it is as simple as mounting the Windows 8 Enterprise ISO and performing an in-place upgrade by launching setup.exe. And no, contrary to what some have said, you can’t simply input your Windows 8 Enterprise license key and magically turn Windows 8 Professional in to Windows 8 Enterprise. It will of course activate, but it will still be Windows 8 Professional unless and until you perform the actual upgrade to Windows 8 Enterprise using the installation media.

So, upon returning home from TechEd I promptly upgraded my Surface Pro to Windows 8 Enterprise using the steps Jordan outlined here. Worked like a charm! I was able to join my lab domain and successfully establish DirectAccess connectivity on the Surface Pro. I did encounter a few issues when I attempted to refresh the device, however. To reset the device, I clicked Settings on the charms menu (swipe-in on the right or Window Key+C) and clicked Change PC Settings. Next I selected General and chose the option to Refresh your PC without affecting your files and received the following error message:

Insert media. Some files are missing. Your Windows installation or
recovery media will provide these files.

Insert Media on the Surface Pro

Selecting the option to Remove everything and reinstall Windows yielded the same error. Fortunately it was easy enough to resolve. To begin, I created a folder on the C: drive called WinRec. Next, I mounted the Windows 8 Enterprise ISO, navigated to the \Sources folder and copied install.wim to C:\WinRec. Finally, I opened an elevated command prompt and executed the following command to register this file as a recovery image:

reagentc.exe /setosimage /path C:\WinRec /target C:\Windows /index 1

Now when I select the option to Refresh your PC without affecting your files or Remove everything and reinstall Windows the process continues normally. Once the process is complete, there will be a few drivers missing which you can download here. After that everything was good to go! Obviously the solution I’ve described here is only really effective for one-off deployments of Windows 8 Enterprise on the Surface Pro. If you’re considering an enterprise-wide deployment, have a look at the Surface Pro Enterprise Deployment Guide [PDF], which includes detailed, prescriptive guidance for deploying Windows 8 Enterprise on the Surface Pro.

3 Comments
by Richard M. Hicks on June 14, 2013  •  Permalink
Posted in Important Links, Remote Access, Surface Pro, Windows 8
Tagged , , , , , , , ,

Posted by Richard M. Hicks on June 14, 2013

https://directaccess.richardhicks.com/2013/06/14/directaccess-on-the-microsoft-surface-pro/

Disconnecting DirectAccess Clients on Windows Server 2012

DirectAccess provides seamless and transparent, always-on remote network connectivity. It does this without requiring action from the user. While this is an important feature and benefit of a DirectAccess remote access solution, it can also present a challenge for security administrators when a DirectAccess client device is lost or stolen.

To prevent a DirectAccess device from establishing remote network connectivity, simply disable or delete the device’s computer account in Active Directory. This will prevent the establishment of the IPsec tunnels, which are authenticated in part using the computer account and Kerberos. The caveat here is that this will not terminate a session that is already established. In this scenario it will be necessary to also proactively disconnect the already established IPsec tunnels from the client in question. To accomplish this, open an elevated PowerShell prompt on the DirectAccess server and execute the following command:

Get-NetIPsecMainModeSA | where {$_.RemoteFirstId.Identity –like “*computer_name*”} | Remove-NetIPsecMainModeSA

For example, to terminate established IPsec tunnels for a computer name CLIENT1 the command would look like this:

Get-NetIPsecMainModeSA | where {$_.RemoteFirstId.Identity –like “*client1*”} | Remove-NetIPsecMainModeSA

When the client attempts to reestablish its connection it will fail to authenticate because its computer account is no longer valid in Active Directory. Now the trick is to get those users to tell us immediately when they’ve lost their laptops. That’s an entirely different problem, however. 😉

Special thanks for my good friend Jason Jones for his input on this solution. Thanks JJ!

21 Comments
by Richard M. Hicks on June 11, 2013  •  Permalink
Posted in Important Links, Remote Access, Windows Server 2012
Tagged , , ,

Posted by Richard M. Hicks on June 11, 2013

https://directaccess.richardhicks.com/2013/06/11/disconnecting-directaccess-clients-on-windows-server-2012/

The Drawbacks of Supporting Windows 7 Clients with Windows Server 2012 DirectAccess

Windows Server 2012 DirectAccess includes many new features to enhance scalability and performance. To take full advantage of many of these capabilities you must use Windows 8 Enterprise edition for your DirectAccess clients. Windows 7 Enterprise and Ultimate clients are supported, but there are a few important features that can’t be leveraged. Here are some examples:

IP-HTTPS Improvements – Windows Server 2012 supports NULL encryption for the IP-HTTPS IPv6 transition protocol. This eliminates the performance penalty and negative scalability caused by needlessly redundant encryption of DirectAccess client communication (IPsec encrypted traffic encrypted again with SSL/TLS). Windows 8 clients only request these NULL encryption cipher suites when establishing DirectAccess connectivity. However, Windows 7 clients do not support NULL encryption and will instead request an encrypted cipher suite when performing SSL/TLS negotiations.

Automatic Site Selection for Multi-Site – With Windows Server 2012 the administrator can configure multiple DirectAccess gateways to provide geographic redundancy for DirectAccess clients. Windows 8 clients are configured to intelligently select the nearest entry point and automatically reconnect to another gateway if the connection to the originally selected entry point fails. In contrast, Windows 7 clients can be configured for only a single entry point. The Windows 7 client is unaware of any other entry points and if the original connection becomes unavailable for any reason it will not have corporate network access until that entry point is back online.

Public Key Infrastructure (PKI) – The removal of the requirement to have an internal PKI to support DirectAccess clients is a popular feature for many organizations wanting to deploy DirectAccess (I don’t necessarily agree with this, but that’s the subject of another post!). Although Windows Server 2012 DirectAccess can be configured to use self-signed certificates, this deployment model is only supported for Windows 8 clients. If you plan to provide support for Windows 7 clients you will need a working internal PKI.

DirectAccess Connectivity Assistant – The Windows 8 client includes native functionality to indicate the status of DirectAccess connectivity and also includes a facility with which to quickly gather detailed log data for troubleshooting. Windows 8 clients can also establish DirectAccess connectivity when they are located behind an authenticating web proxy. For Windows 7 clients, the DirectAccess Connectivity Assistant (DCA) provides some of this functionality, but it is an optional component that must be deployed separately. Even with the DCA installed, Windows 7 clients cannot establish DirectAccess connections when a web proxy server requires authentication.

Although Windows 7 Enterprise and Ultimate editions are supported for DirectAccess when connecting to a Windows Server 2012 DirectAccess server, Windows 8 Enterprise clients should be deployed whenever possible to ensure the best and most complete experience.

10 Comments
by Richard M. Hicks on June 6, 2013  •  Permalink
Posted in Important Links, Windows 7, Windows 8, Windows Server 2012
Tagged , , , , ,

Posted by Richard M. Hicks on June 6, 2013

https://directaccess.richardhicks.com/2013/06/06/the-drawbacks-of-supporting-windows-7-clients-with-windows-server-2012-directaccess/

« Older Posts
Newer Posts »