I always said if I had an opportunity to write something about DirectAccess, I would at some point say "DirectAccess rocks", and so there it is. I spend at least part of everyday describing the technology to new folks and comparing it to a traditional VPN connection, but there really is no comparison. Your users either have to launch a VPN client, or they don't. You either have to install and configure and update that VPN client software, or you don't. You either wait around for employees to choose to connect their VPN so that you can push security updates and settings at them, or you don't. DirectAccess is basically automatic VPN, and after years of talking about it on phone calls and at shows, I am convinced that I can get anyone interested in it. Though the technology has been around in one flavor or another for four years now, it is still a brand new concept to many, and all it takes is a few minutes to get anyone who has ever used a VPN interested in never having to use one again.

Unfortunately, a lot of DirectAccess implementations are halted before they even start, and it's really unnecessary. Part of the problem is IPv6; as soon as admins hear that DirectAccess uses IPv6, they immediately discount it as something that does not apply to them. This is completely untrue; you don't actually have to know anything about IPv6 or use it at all inside your network to get DirectAccess working! Another "problem" that I address all the time is that there are so many different ways in which DirectAccess can be implemented, how is one supposed to sift through and figure out what is best for them? This is a large part of the intention of this book, to clear the air on the options that are out there, and particularly address them from a set of "Best Practices" glasses. We are going to talk about specific settings and some general ideology about how to make DA work its hardest for you and your organization, and have a little fun along the way.

Implementing DirectAccess is quite literally my day job, and the ideas and steps outlined in this book reflect my own experience and knowledge directly from the field. We all know that implementation of technology rarely goes according to plan, and I hope that you can take some of the speed bumps that I have overcome along the way and apply them to your own situations to make your installation as seamless as possible.

If you have done some reading on DA, you may be aware that there are two different server platforms which can provide DirectAccess. Well, there are three technically, but the original iteration in native Server 2008 R2 was quite difficult to handle, and I have yet to run across a network with it running. The other two, of which I still actively install both very regularly, are UAG DirectAccess and Server 2012 DirectAccess. As you can infer from the name, the latter runs on Server 2012 and is simply a role that you can add into Windows (don't do this until you read Chapter 1, DirectAccess Server Best Practices). UAG, on the other hand, is a software platform that needs to be installed on top of Server 2008 R2. If one is Server 2008 R2 and the other is Server 2012, why would anybody still be doing UAG? Both platforms provide DirectAccess connection for Windows 7 and Windows 8 client computers, but the two platforms handle non-DirectAccess machines very differently.

In Server 2012, you have the option to provide regular RRAS VPN connectivity, so if you still have Windows XP clients or Macs or smartphones with a VPN software client installed, you can connect those guys through the server via regular VPN. This may be beneficial, or it may be downright scary, depending on your perspective. With the UAG platform, you again have Windows 7 and Windows 8 running DirectAccess, and you also have the ability to publish SSLVPN portals out on the Internet. These portals enable browser-based access from home computers, kiosks, mobile devices, and so on, in a selective, locked-down way. There are already great books available on UAG and everything that it stands for so I won't say any more than that, but I wanted to make the point that UAG is still today a valid option for implementing DirectAccess, if those other features are important to you. Or you could, of course, have a server running UAG for those down-level clients, and a separate server running DirectAccess on Server 2012, if that is your preference.

Anyway, the point of this section is to simply say that the information contained within this book applies specifically to Server 2012 DirectAccess, but all of the concepts can absolutely also apply to UAG DirectAccess. I used Server 2012 to create my command output, screenshots, and for all of the verbiage within the book. But all of the security concepts and guides to troubleshooting client-side scenarios really apply to either solution.

I had a lot of fun putting this together, and I hope you get some enjoyment out of reading it. I genuinely believe that DirectAccess is the future of remote access. It is one of those rare gems in the IT world where your department can receive a well-deserved slap on the back by the end users and executive team. Trust me, it's that cool.

Chapter 1, DirectAccess Server Best Practices, describes the step-by-step procedure you should take to prepare your DirectAccess server. Following the procedures listed here will ensure that your server adheres to critical security practices.

Chapter 2, DirectAccess Environmental Best Practices, brings detail to the infrastructure and environmental considerations that need to be taken when implementing DirectAccess. Many common implementation questions are also addressed.

Chapter 3, Configuring Manage Out to DirectAccess Clients, brings some clarity to that mysterious thing they call ISATAP. Most of us have heard of it, and maybe know that it has something to do with managing your DirectAccess clients, now let's take an in-depth look into whether or not you actually need it, and how to correctly utilize it when you do.

Chapter 4, General DirectAccess Troubleshooting, will enable you to make sense of those client log files, pointing out the important sections and what they mean. With the information provided here, you should be able to diagnose a connection within a matter of seconds.

Chapter 5, Unique DirectAccess Troubleshooting Scenarios, is an interesting walk through some of the cases I have worked which you may not encounter every day. Understanding the causes and resolutions to these issues could be the difference between minutes and days when it comes to diagnosing these issues.

Many of you will already have DirectAccess in your environment, and as such you probably already have everything you need. I suppose that is not necessarily true, as after reading through some of the environmental considerations, you may choose to enforce some additional measures that could mean you introduce a couple of new items in your network, but I will let the chapters themselves speak to that. For anyone new to this technology, DirectAccess is heavily integrated with the domain, utilizing groups and Group Policies for configuration, so running a network where Active Directory exists is a must. You will also need a server which you are planning to turn into your DirectAccess server, running Windows Server 2012. Any client computers that you want to connect through this server must be Windows 7 Enterprise, Windows 7 Ultimate, or Windows 8 Enterprise, and it would be a good idea to have at least one of those guys ready so that you can test when finished with the configuration.

This book will be of interest to any existing DirectAccess administrator, and to anyone interested in learning more about the technology before diving in for themselves. Although the topics covered here are geared for the specific purposes of enhancing DirectAccess, I also encourage any administrator who has the unfortunate task of dealing with a tradition VPN on a day-to-day basis absolutely do all the reading they can on this technology, and cut over to it as quickly as possible to save themselves time, money, and headaches.

In this book, you will find a number of styles of text that distinguish among different kinds of information. Here are some examples of these styles, and an explanation of their meaning.

Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "Now, before you get all huffy with me, yes I do know about the new feature in Server 2012 DirectAccess that allows the second encryption to be null".

Any command-line input or output is written as follows:

Route add –p 192.168.2.0 mask 255.255.255.0 192.168.1.1 IF 13

New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: " Now click on the Advanced… button to open the Advanced TCP/IP Settings window where we will make a few more changes".

Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.

To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title via the subject of your message.

If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.

Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.