If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our ISAserver.org Real Time Article update newsletter.
Introduction
UAG1 SP1 RC was released recently and I’ve been watching Tom working with it from dawn to dusk. As you can imagine, he’s been talking a lot about it and I’ve been learning about all the cool new features and capabilities built into this Service Pack. One thing is for sure – this Service Pack is more than just bug fixes and minor code updates. UAG SP1 RC includes a whole slew of new features for the UAG DirectAccess admin. In fact, I was so impressed that I installed it on my own DirectAccess server. And I’m happy to say to I haven’t run into any problems with stability or performance yet.
Step 1: Clients and GPOs
After you install UAG SP1 RC, you’ll immediately notice that the look and feel of the UAG DirectAccess configuration interface has changed. First and foremost, there are many more configuration options! If you haven’t downloaded and installed UAG SP1 RC yet, you can find it here.
After you click on the DirectAccess node in the left pane of the console, you’ll see something similar to Figure 1 below. There are still four steps to the wizard, but now a couple of the steps have one or more configuration options that we didn’t see with the previous version of the UAG DirectAccess wizard. The first step is the Clients and GPOs step and here you configure the client side of the UAG DirectAccess configuration.
Figure 1
Let’s get started by clicking the Edit link in the Step 1 Clients and GPOs section, as seen in Figure 2.
Figure 2
This starts the UAG DirectAccess wizard. In the first step, you will immediately see a new option that wasn’t available in the previous version of the UAG DirectAccess wizard. This option, Allow DirectAccess clients to connect to internal networks, and enable remote management of DirectAccess clients, was the default setting with the previous version of the UAG DirectAccess wizard. However, the second option, Enable remote management of DirectAccess clients only, is new in the GUI (although you were previously able to configure this by manually editing the Registry). This option allows you to enable a “manage only” scenario, so that access to the intranet is only available through the first tunnel (known as the infrastructure tunnel). When this is enabled, DirectAccess clients can only connect to management servers over the infrastructure tunnel, and management servers can connect to DirectAccess clients over the infrastructure tunnel.
The option Allow only services running under the client computer account to access infrastructure servers used for remote management, shown in Figure 3, prevents processes running under the user context from connecting to resources on the intranet. When this option is enabled, the DirectAccess client computer can run agents and other software that run under the context of the local machine account to connect to management servers on the intranet, but code running in the context of the logged on user account will not be able to use the infrastructure tunnel to connect to the intranet. This can increase the level of security for the “manage only” scenario.
Figure 3
One of the things that DirectAccess administrators asked for was more flexibility in deploying the GPO settings that control DirectAccess client and server behavior. Well, Microsoft listened to them and significantly improved the user interface for deploying GPOs settings. In the figure below, you can see that you now have two options:
- Automatically generate the following GPOs for DirectAccess policies
- Save the UAG DirectAccess settings to these existing GPOs
If you select the first option, the UAG DirectAccess wizard will suggest some default GPO names and locations. One thing you’ll notice is that the names are easier to remember, as there is no GUID included in the GPO names. If you click the Modify button, you can make some changes.
Figure 4
In Figure 5 below, you can see that you can modify the Group Policy object names and locations. These are the following:
- UAG DirectAccess Client Policy. This policy is applied to UAG DirectAccess clients.
- UAG DirectAccess Server Policy. This policy is applied to UAG DirectAccess servers (all servers in a UAG array would be included if you had an array).
- Application Server Policy. This policy is applied to clients and management servers for which you have configured end-to-end security.
Figure 5
If you select the Save the UAG DirectAccess settings to these existing GPOs option and click Assign, you will see the GPOs Designated for UAG DirectAccess Policy, shown in Figure 6 below. In this dialog box, you can enter the names of the UAG DirectAccess Client Policy, UAG DirectAccess Server Policy and Application Server Policy. Note that you’ll want to create these GPOs before you configure the UAG DirectAccess wizard to use these GPOs. Also be aware that the wizard will overwrite the settings in these GPOs each time you run the wizard, so you need to keep this in mind if you create custom DirectAccess related settings in these GPOs.
Figure 6
Another thing that those who were using UAG DirectAccess really wanted was the ability to assign DirectAccess clients to OUs. Before UAG SP1, DirectAccess clients had to be assigned to a Security Group, and then you could put the DirectAccess client computer accounts into that Security Group. With UAG SP1, you can now choose: you can assign the computer accounts to a Security Group, or you can assign the DirectAccess client computer accounts to an OU, as shown in Figure 7. Note that this is an either/or choice; that is, you can’t use a combination of OUs and Security Groups.
Figure 7
New UAG SP1 RC DirectAccess Connectivity Assistant Settings
As part of the UAG DirectAccess configuration, there is also an option to configure the DirectAccess Connectivity Assistant (DCA). While there was a DCA that you could use with pre-SP1 versions of the UAG DirectAccess client, UAG SP1 RC includes an all new and improved DCA that adds new troubleshooting and OTP password support features.
Click the Client Connectivity Assistant link in the Step 1 Clients and GPOs section to start the configuration of the DCA, as shown in Figure 8.
Figure 8
The first option you’ll see is to let you specify whether or not you want to configure the DCA at all, as shown in Figure 9. If you select the No, I do not want to configure application settings at this time, that sort of ends things. If you select the Yes, configure application settings option, you are given the option to Allow users to use local name resolution instead of sending requests through the corporate DNS servers. This is a little confusing, since it’s not clear what happens if you enable this option. Here’s the “inside scoop” from Tom: when you enable this option, the users on the DirectAccess clients on the Internet will be able to essentially “disable” DirectAccess (functionally at least; it doesn’t actually disable DirectAccess) so that the user can work with the Help Test for troubleshooting purposes.
Figure 9
The DCA configuration wizard next presents you with a page that allows you to configure the connectivity verifiers used by the DCA to determine whether the DirectAccess client is connected to the intranet, as shown in Figure 10. You can configure connectivity verifiers for SMG, HTTP and HTTPS, as seen in the figure. There is also a helpful Validate Connectivity button so that you’ll know that the resource is actually reachable from the UAG DirectAccess server. An interesting tidbit that Tom told me is that if you configure an SMB based file share connectivity verifier, and if the file name on the share changes or disappears for some reason, the UAG DirectAccess server will actually recreate an empty file with the same name. Sounds interesting and I wonder if they’ll keep that feature when the UAG SP1 RC goes RTM.
Figure 10
The DCA wizard also allows to you configure the URL for the Help Site that users will be told to use if they have problems with DirectAccess connectivity. In Figure 11, you can see that you have two options:
- This UAG portal. Use this if you have an existing portal site on the UAG server that publishes the help site
- This site (URL). If you aren’t publishing the help site, but are hosting it somewhere else, you can enter the URL for the site in the text box, as seen in the figure below. You can also enter a friendly name too. The users will then click on the friendly name if they are having problems with their DirectAccess connection.
Figure 11
Finally, the DCA includes a number of new diagnostic measures that will run when the user clicks on the Run Diagnostics link. After running the diagnostic tests, it will save the diagnostic files to a .cab file. The user can then email that .cab file to the UAG DirectAccess administrator. You can help your users out by entering the UAG DirectAccess administrator’s email address in the configuration interface, as seen in Figure 12 below. In addition to the diagnostics that the DCA has baked in, you can also run your own diagnostic scripts if you like, as part of the diagnostics process. In the specify the path and name of the diagnostics script text box, enter the path and name of the file. Note that the script should be stored on the DirectAccess client computer in a location that is accessible only with elevated permissions.
Figure 12
Summary
So there you go! In this article, we went over some of the new features included in UAG SP1 RC that are part of Step 1 DirectAccess Clients configuration. The new features, such as the DCA configuration, the ability to change the names and locations of the GPOs, and the ability to use OUs for DirectAccess client accounts, are all things that UAG DirectAccess administrators have been asking for. Also, I think the ability to easily enable the “manage only” scenario is quite cool, as this will make it very easy to deploy DirectAccess for “always managed” only without giving users access to the intranet – something I imagine would be very popular with schools and other organizations that are interested in total control and management and less interested in allowing users access to the intranet.
I hope you liked what you saw for the client configuration for UAG SP1 RC. In the next article, we’ll go over the new features and capabilities that are part of Step 2 DirectAccess Server. See you then!
If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our ISAserver.org Real Time Article update newsletter.
