All posts tagged administration

PowerShell is an important skill for administrators supporting Microsoft workloads including DirectAccess and Always On VPN. Using PowerShell to install required roles and features is much simpler and quicker than using the Graphical User Interface (GUI), with only a single command required to accomplish this task. Some settings aren’t exposed in the GUI and can only be configured using PowerShell. In addition, PowerShell makes the task of troubleshooting DirectAccess and Always On VPN much easier.

Learn PowerShell

One of the best resources for learning PowerShell is the book Learn PowerShell in a Month of Lunches authored by Microsoft MVPs and recognized PowerShell experts Don Jones and Jeff Hicks. This book, now in its third edition, should be considered essential reading for all Microsoft administrators. Click here for more details.

Learn PowerShell Scripting

Recently Don and Jeff released a new book entitled Learn PowerShell Scripting in a Month of Lunches. This new book builds upon the skills learned in their first title by focusing on the development of PowerShell scripts to automate many common administrative tasks. PowerShell scripts can also be used to build custom, reusable tools to more effectively manage and monitor Microsoft workloads. Click here for more details.

PowerShell for the Future

In my experience, far too many administrators today lack crucial PowerShell abilities. Don’t get left behind! PowerShell is rapidly becoming a required skill, so get these books and start learning PowerShell today!

From a client perspective, DirectAccess is an IPv6 only solution. All communication between the DirectAccess client and server takes place exclusively over IPv6. This can make things challenging for network engineers tasked with administering network devices using SSH over a DirectAccess connection. Often network devices don’t have corresponding hostname entries in DNS, and attempting to connect directly to an IPv4 address over a DirectAccess connection will fail.

To resolve this issue, it is necessary to create internal DNS records that resolve to IPv4 addresses for each network device. With that, the DNS64 service on the DirectAccess server will create an IPv6 address for the DirectAccess client to use. The NAT64 service will then translate this IPv6 address to IPv4 and connectivity will be established.

However, for many large organizations this might not be feasible. You may have hundreds or thousands of devices on your network to administer, and creating records in DNS for all these devices will take some time. As a temporary workaround, it is possible to determine the NAT64 IPv6 address for any network device and use that for remote network administration.

The process is simple. On a client that is connected remotely via DirectAccess, resolve the name of a known internal server to an IP address. The quickest and easiest way to do that is simply to ping an internal server by its hostname and note the IPv6 address it resolves to.

Now copy the first 96 bits of that address (everything up to and including the 7777::) and then append the IPv4 address of the network device you wish to manage in familiar dotted-decimal notation. The IPv6 address you create should look something like this:

fd74:45f9:4fae:7777::172.16.1.254

Enter this IPv6 address in whichever tool you use to manage your network devices and it should work. Here’s an example using the popular Putty tool connecting via SSH to a network device in my lab.

Figure 1 – DirectAccess Client IPv6 Prefix w/Appended IPv4 Address

Figure 2 – Successful connection over DirectAccess with Putty.

Going forward I would strongly recommend that you make it part of your normal production implementation process and procedures to create DNS records for all network devices. In the future you’ll absolutely have to do this for IPv6, so now is a good time to get in the habit of doing this. It will make your life a lot easier, trust me!

Please note that adding entries to the local HOSTS file of a DirectAccess client does not work! The name must be resolved by the DNS64 service on the DirectAccess server in order to work properly. Although you could populate the local HOSTS file with names and IPv6 addresses using the method I described above, it would cause problems when the client was on the internal network or connected remotely using traditional client-based VPN, so it is best to avoid using the HOSTS file altogether.

The Microsoft Surface Pro 4 was made available for sale to the public on October 26, 2015. The latest in a line of powerful and flexible tablets from Microsoft, the Surface Pro 4 features a full version of the Windows 10 desktop client operating system and includes more available power, memory, and storage than previous editions. Significant improvements were also made to the keyboard and pen. The Surface Pro 4 is designed to be an all-in-one laptop replacement, enabling users to carry a single device for all of their needs.

Surface Pro 4 and the Enterprise

Microsoft is pushing the Surface Pro 4 heavily to large enterprise organizations by expanding the resale business channel and offering the device through companies like Dell and HP. In fact, Microsoft has made the Surface Pro 4 available through more than 5000 business resellers in 30 global markets. This new enterprise sales initiative strives to deliver world class service and support for enterprise customers adopting the new Surface Pro 4, and includes a new warranty offer and a business device trade-in program designed to promote the adoption of Surface and Windows 10 in the enterprise.

In addition, Microsoft will have a training program for IT management and support professionals as well as new Windows users that will help streamline the deployment of the Surface Pro 4 and Windows 10. Organizations are rapidly adopting the Surface Pro 4 and Windows 10, as Microsoft has already signed on a number of high-profile companies in the retail, financial services, education, and public sector verticals. Today, Microsoft has deployed Windows 10 to over 110 million devices since it was released in late October 2015, making it the most rapidly adopted operating system in their history.

Enterprise Requirements

One of the primary motivating factors for enterprise organizations migrating to the Surface Pro 4 is cost reduction. The Surface Pro 4 functions as both a full PC and a tablet, eliminating the need for users to carry two devices. More importantly, it eliminates the need for IT to procure, manage, and support two different hardware and software platforms (for example a Windows-based laptop and an iPad). Additionally, IT organizations can leverage their existing Windows systems management infrastructure and expertise to deploy and maintain their Surface devices.

DirectAccess and the Surface Pro 4

For organizations seeking to maximize their investment in the Surface Pro 4 with Windows 10, implementing a secure remote access solution using Windows Server 2012 R2 DirectAccess is essential. DirectAccess provides seamless and transparent, always on secure remote corporate network connectivity for managed (domain-joined) Windows clients. DirectAccess enables streamlined access to on-premises application and data, improving end user productivity and reducing help desk costs. DirectAccess connectivity is bi-directional, making possible new and compelling management scenarios for field-based assets. DirectAccess clients can be managed the same way, regardless if they are inside or outside of the corporate network. DirectAccess ensures that clients are better managed, consistently maintained, and fully monitored.

Windows 10 and DirectAccess

The Surface Pro 4 with Windows 10 provides full support for all enterprise features of DirectAccess in Windows Server 2012 R2, including automatic site selection and transparent fail over for multisite deployments, as well as scalability and performance improvements. In addition, supportability for Windows 10 clients is much improved with DirectAccess GUI integration and full PowerShell support. Additional information about how DirectAccess and Windows 10 are better together, click here.

Additional Cost Savings

DirectAccess does not require any additional software to be installed on the client, and does not incur per user licensing to implement. Another benefit is that DirectAccess can easily be deployed on most popular hypervisors such as Hyper-V and VMware, eliminating the need for expensive proprietary hardware-based remote access solutions and taking full advantage of current investments in virtual infrastructure. Additionally, existing Windows systems management skill sets can be leveraged to support a DirectAccess implementation, eliminating the need for expensive dedicated administrators.

Note: Windows 10 Enterprise edition is required to support DirectAccess, and it is assumed that large organizations will be deploying Surface Pro 4 with Windows 10 Enterprise.

Summary

The Surface Pro 4 is the thinnest, lightest, and most powerful Surface tablet ever. It features Windows 10, and it can run the full version of Office and any other applications you need. The Surface Pro 4 is aimed squarely at large enterprises, governments, and schools. Not coincidentally, these verticals are also excellent uses cases for DirectAccess. DirectAccess is the perfect complement to the Surface Pro 4 and Windows 10 in the enterprise, as it helps organizations address the unique pain points of large scale enterprise adoption of Windows devices. DirectAccess allows the Surface Pro 4 to be much more effectively managed, while at the same time significantly improving the end user experience.

To realize the full potential of your Windows 10 and Surface Pro 4 deployment, consider a DirectAccess consulting engagement. By leveraging our experience you’ll have the peace of mind knowing that you have deployed DirectAccess in the most optimal, flexible, secure, and highly available manner possible. For more information about a DirectAccess consulting engagement, click here.

Name resolution and proper DNS server configuration is vital to the functionality of DirectAccess. When performing initial configuration of DirectAccess, or making changes to the DNS server configuration after initial configuration, you may notice the operations status for DNS indicates Critical, and that the operations state shows Server responsiveness.

Highlighting the DNS server on the Operations Status page and viewing the details shows that DNS is not working properly with the following error message:

None of the enterprise DNS servers <IPv6_address> used by DirectAccess
clients for name resolution are responding. This might affect DirectAccess
client connectivity to corporate resources.

There are a number of things that can contribute to this problem, but a common cause is an error made when assigning a DNS server to a specific DNS suffix. An inexperienced DirectAccess administrator might specify the IPv4 address of an internal corporate DNS server, which is incorrect. The DNS server IPv4 address should be the address assigned to the DirectAccess server’s internal network interface.

The best way to ensure that the DNS server is configured correctly for DirectAccess is to delete the existing entry and then click Detect.

An IPv6 address will be added automatically. This is the IPv6 address of the DNS64 service running on the DirectAccess server, which is how the DNS server should be configured for proper DirectAccess operation.

Once the changes have been saved and applied, the DNS server should once again respond and the status should return to Working.

DirectAccess in Windows Server 2012 R2 supports many different deployment configurations. It can be deployed with a single server, multiple servers in a single location, multiple servers in multiple locations, edge facing, in a perimeter or DMZ network, etc.

Global Settings

There are a number of important DirectAccess settings that are global in scope and apply to all DirectAccess clients, such as certificate authentication, force tunneling, one-time password, and many more. For example, if you configure DirectAccess to use Kerberos Proxy instead of certificates for authentication, Windows 7 clients are not supported. In this scenario it is advantageous to have a second parallel DirectAccess deployment configured specifically for Windows 7 clients. This allows Windows 8 clients to take advantage of the performance gains afforded by Kerberos Proxy, while at the same time providing an avenue of support for Windows 7 clients.

Parallel Deployments

To the surprise of many, it is indeed possible to deploy DirectAccess more than once in an organization. I’ve been helping customers deploy DirectAccess for nearly five years now, and I’ve done this on more than a few occasions. In fact, there are some additional important uses cases that having more than one DirectAccess deployment can address.

Common Use Cases

QA and Testing – Having a separate DirectAccess deployment to perform testing and quality assurance can be quite helpful. Here you can validate configuration changes and verify updates without potential negative impact on the production deployment.

Delegated Administration – DirectAccess provides support for geographic redundancy, allowing administrators to create DirectAccess entry points in many different locations. DirectAccess in Windows Server 2012 R2 lacks support for delegated administration though, and in some cases it may make more sense to have multiple separate deployments as opposed to a single, multisite deployment. For example, many organizations are divided in to different business units internally and may operate autonomously. They may also have different configuration requirements, which can be better addressed using individual DirectAccess implementations.

Migration – If you have currently deployed DirectAccess using Windows Server 2008 R2 with or without Forefront UAG 2010, migrating to Windows Server 2012 R2 can be challenging because a direct, in-place upgrade is not supported. You can, however, deploy DirectAccess using Windows Server 2012 R2 in parallel to your existing deployment and simply migrate users to the new solution by moving the DirectAccess client computer accounts to a new security group assigned to the new deployment.

Major Configuration Changes – This strategy is also useful for scenarios where implementing changes to the DirectAccess configuration would be disruptive for remote users. For example, changing from a single site to a multisite configuration would typically require that all DirectAccess clients be on the LAN or connect remotely out-of-band to receive group policy settings changes after multisite is first configured. In addition, parallel deployments can significantly ease the pain of transitioning to a new root CA if required.

Unique Client Requirements – Having a separate deployment may be required to take advantage of the unique capabilities of each client operating system. For example, Windows 10 clients do not support Microsoft Network Access Protection (NAP) integration. NAP is a global setting in DirectAccess and applies to all clients. If you still require NAP integration and endpoint validation using NAP for Windows 7 and Windows 8.x, another DirectAccess deployment will be required to support Windows 10 clients.

Requirements

To support multiple Windows Server 2012 R2 DirectAccess deployments in the same organization, the following is required:

Unique IP Addresses – It probably goes without saying, but each DirectAccess deployment must have unique internal and external IPv4 addresses.

Distinct Public Hostname – The public hostname used for each deployment must also be unique. Multi-SAN certificates have limited support for DirectAccess IP-HTTPS (public hostname must be the first entry in the list), so consider using a wildcard certificate or obtain certificates individually for each deployment.

Group Policy Objects – You must use unique Active Directory Group Policy Objects (GPOs) to support multiple DirectAccess deployments in a single organization. You have the option to specify a unique GPO when you configure DirectAccess for the first time by clicking the Change link next to GPO Settings on the Remote Access Review screen.

Enter a distinct name for both the client and server GPOs. Click Ok and then click Apply to apply the DirectAccess settings for this deployment.

Windows 7 DirectAccess Connectivity Assistant (DCA) GPOs – If the DirectAccess Connectivity Assistant (DCA) v2.0 has been deployed for Windows 7 clients, separate GPOs containing the DCA client settings for each individual deployment will have to be configured. Each DirectAccess deployment will have unique Dynamic Tunnel Endpoint (DTE) IPv6 addresses which are used by the DCA to confirm corporate network connectivity. The rest of the DCA settings can be the same, if desired.

Supporting Infrastructure

The rest of the supporting infrastructure (AD DS, PKI, NLS, etc.) can be shared between the individual DirectAccess deployments without issue. Once you’ve deployed multiple DirectAccess deployments, make sure that DirectAccess clients DO NOT belong to more than one DirectAccess client security group to prevent connectivity issues.

Migration Process

Moving DirectAccess client computers from the old security group to the new one is all that’s required to migrate clients from one DirectAccess deployment to another. Client machines will need to be restarted to pick up the new security group membership, at which time they will also get the DirectAccess client settings for the new deployment. This works seamlessly when clients are on the internal network. It works well for clients that are outside the network too, for the most part. Because clients must be restarted to get the new settings, it can take some time before all clients finally moved over. To speed up this process it is recommended that DirectAccess client settings GPOs be targeted at a specific OUs created for the migration process. A staging OU is created for clients in the old deployment and a production OU is created for clients to be assigned to the new deployment. DirectAccess client settings GPOs are then targeted at those OUs accordingly. Migrating then only requires moving a DirectAccess client from the old OU to the new one. Since OU assignment does not require a reboot, clients can be migrated much more quickly using this method.

Summary

DirectAccess with Windows Server 2012 R2 supports many different deployment models. For a given DirectAccess deployment model, some settings are global in scope and may not provide the flexibility required by some organizations. To address these challenges, consider a parallel deployment of DirectAccess. This will enable you to take advantage of the unique capabilities of each client operating system, or allow you to meet the often disparate configuration requirements that a single deployment cannot support.