UAG offers, by default, three ways to access Exchange: Outlook Web Access, Exchange ActiveSync, and Outlook Anywhere. ActiveSync is the instrument for mobile users to synchronize their exchange e-mail messages, calendar information, contact, task data, and so on; that is why we are especially interested in it. Similarly, UAG authenticates the user and then enables access to the Exchange information, giving us an additional security layer between the Internet and the Exchange servers.

To publish ActiveSync, we add an application to the trunk the same way we did for SharePoint and we select a Web value from the list of applications. Here we have selected Microsoft Exchange Server (all versions) from the list:

Then we have to select the version of Exchange that we deployed in our environment, and the services we will enable through UAG (in this example we will go with Exchange ActiveSync only):

We will be asked for an application name (in our example, ActSync), and then we will have to select the end point policies (again, nothing new, it is the same part of the wizard that we have seen before). Depending on the kind of Exchange infrastructure we have, we will select a single server or a farm (we have a single server), and then we are requested to insert the name of our Exchange Server and it will be the internal name of the server, so that we are not exposing the mail services directly to the Internet.

We have the Exchange paths automatically configured by the wizard. The Public host name value we are giving is the FQDN that we want to use to publish the Exchange service (pointing it to the public IP of the UAG server).

The next screen of the wizard will ask for the authentication server. Looking at the following screenshot, we are able to see that there is no free selection of Authentication Method, and that Allow rich clients to bypass trunk authentication is selected by default with no way of changing the settings:

However, the option will allow clients to bypass the trunk's authentication and use basic authentication or NTLM authentication, and that is something we need to use ActiveSync for. We will receive a final warning message stating that rich clients (mobile devices in our scenario) cannot be authenticated through the portal directly.

The next screen will give us the opportunity to customize the link on the portal.

Next we will have to configure the authorizations and then we will have finished the configuration on the server side.

The last step is, as usual, to activate the new UAG configuration.

The process to configure ActiveSync on a mobile device varies from client to client and from version to version. In Windows Phone 7.5, for example, we will have to go to Settings | email+accounts | add an account with advanced setup, and insert the configuration data (we could also go with the Outlook account configuration, again it's a matter of how Exchange is configured in your company).

In our scenario, we will select Exchange ActiveSync.

The information required for ActiveSync is the same we use for Exchange, but the server URL is the one we've configured when publishing Exchange ActiveSync (in our example, UagMail.Domain.Com).

Microsoft Dynamics CRM is a customer relationship management (CRM) application supported in an out of the box fashion by UAG. UAG makes it easy to enable external users and partners to use Dynamics, granting a high level of security. Talking about mobile devices, it is important to remember that in UAG SP2, when we publish Dynamics CRM, the console shows the default access, upload, and download end point policies in use, but Dynamics always uses application-specific policies, overriding the end point policy.

For example, a Dynamics CRM application will always use the CRM upload and CRM download policies (and so it is important to configure these policies to work with our mobile devices).

The request to publish Lync using UAG is something we often have (for various reasons). However, the right answer to this request is that UAG is able to publish only the web services of Lync and not Lync Mobility. In addition, the fact that we have TMG running on the same host is absolutely not relevant (that is, we cannot use the TMG deployment of UAG to do the work we have to do with a dedicated server). I suggest reading the entire article UAG, Lync Mobility and other Lync clients from Ben Ari's UAG blog to clear any doubts (http://blogs.technet.com/b/ben/archive/2012/11/09/uag-lync-mobility-and-other-lync-clients.aspx).

Anyway, for the web services of Lync, there is a dedicated wizard (in the usual Add Application Wizard).

After we have added Lync to our portal, we will see three new applications, as shown in the following screenshot:

There are also workarounds to publish Lyncdiscover that is used from an external network to auto-discover information for mobile clients, and that is not in the list of the applications automatically configured by the wizard. One of the solutions (if we want to configure the aforementioned service in UAG) is Publish Lync with UAG (http://adfordummiez.com/?p=326), published by Rune Sørensen

UAG uses the user agent string (that each device sends) to select the best portal for the end point (in our situation, as we said previously in the text, the choice is between the Premium mobile portal and the Limited portal). The basic information is in the TechNet article Customizing the detection module available at http://technet.microsoft.com/en-us/library/ff607404.aspx.

For example, let's try to force Windows Phone 7.5 to use the Limited portal.

The user agent string is:

Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0; HTC; T8788)

One way of reaching the result is to remove the following strings:

<DetectionExpression Name="WindowsCE" Expression='Platform Contains "windows mobile" OR Platform Contains "wince" OR Platform Contains "windows ce" OR UserAgent Contains "windows phone" OR UserAgent Contains "windows mobile"' DefaultValue="false" />
<DetectionExpression Name="IE" Expression='Browser Contains "ie" OR Browser Contains "msie"' DefaultValue="false" />

And then we modify DetectionExpression dedicated to LimitedMobile:

<DetectionExpression Name="LimitedMobile" Expression='Browser Contains "ie" OR Browser Contains "msie"' DefaultValue="false" />

As expected, we will have the Limited portal login page (text only) on a device that, by default, is enabled to the Premium mobile portal, as shown in the following screenshot:

Another way of changing the detection module results is by editing the mobile.browser file that contains the definitions of the mobile devices. The previous test will be useful to explore another UAG feature.

The user of a mobile device that is restricted to the Limited portal is offered the opportunity to insert a Personal Identification Number (PIN) value.

Using the PIN, UAG requires the username and the password only once.

From now on, every time the user tries to access a resource using UAG, he/she is required only to insert the PIN. The idea is to simplify the login phase, thus reducing the number of passwords to type on mobile devices. The PIN system uses encrypted cookies saved on the end point. After the first logon, every time the user tries to access a resource using UAG, the device only sends the cookie that is decrypted on the UAG server. The configuration related to the use of PINs is saved in the config.xml file, located at <UAG path>\von\InternalSite\Mobile\.

UAG supports the customization of various elements to keep the user experience in line with our company standards.

A good starting point, if we want to tailor the portal to our company's identity, is the TechNet article Customizing the portal available at http://technet.microsoft.com/en-us/library/ff607389.aspx.

The example that will follow uses the CustomUpdate mechanism, which is a one-of-a-kind UAG. We can try and populate some folders within the UAG folder structure that are known to contain custom files, and UAG will automatically incorporate them into its code. To give you an idea, the easiest way to replace existing images is to give the custom files the same names as the ones we're going to replace, and put them in the CustomUpdate folder (for example, for the login page, <UAG path>\InternalSite\Images\CustomUpdate).

This is a way of customizing the UAG look with low risk and low impact on the existing code (to roll back, we simply have to remove the custom contents).

Back to our (simple) customization example; we want a warning message displayed on mobile devices that are requesting access. We will achieve that by applying a modification of the default text.

The easiest way to create custom texts is to edit the XML files located at <UAG path>\von\InternalSite\Languages\CustomUpdate.

There are XML files for many languages, for example, users with the English language will read text located in the en-US.xml file.

The first screen we have that opens the UAG from a mobile device has a header reading Application and Network Access Portal.

So if we want to customize it, we have to copy the en-US.xml file in the CustomUpdate folder and modify the line reading:

<String id="2" _locID="2">Application and Network Access Portal</String> 

For example, we could use the following string:

<String id="2" _locID="2">Custom Company UAG Portal : Authorized Users Only</String

A large part of the UAG security is based on a mechanism known as Endpoint Detection. When the user accesses the UAG portal, a series of controls are performed on the client for security and compliance reasons. We are able to manage endpoint access policies at three different levels: trunk, portal, and application (in the following screenshot, we can have a look of the policies at the trunk level):

Every time a client tries to connect, UAG uses the detection component (which is part of the client components) to assess the security status of the client and to trigger policy actions.

The client must install some software components on the local machine (Forefront UAG endpoint components). The issue with mobile devices is that the two versions of the components (ActiveX and Java Applet) are not supported on mobile devices, and so all the clients falling in this category are classified as "Other Devices". The only operation supported is using the device ID (with Microsoft Exchange Server 2010) to limit the use of ActiveSync at the user's mailbox level (and that's not something strictly related to UAG) as explained in the TechNet article Disable a Mobile Phone for Exchange ActiveSync at http://technet.microsoft.com/en-us/library/bb232080.aspx.

In the Monitoring, maintaining, and troubleshooting section we will talk about the endpoint monitoring tools we have in UAG.

Earlier in the book, when we configured the first trunk, we said that we were able to use UAG access policies or Microsoft Network Access Protection (NAP).

Now you could be wondering if selecting NAP would be a better solution to enforce endpoint policies. Sadly, the answer is most likely a no. NAP requires a client-side agent and enforcement client that are not available for mobile devices, so the best we could get is to set a generic policy (that's something similar to what we have with UAG policies and is really more complicated).

On a mobile device, having to input a password for every application we use is a time-consuming (and error-prone) activity.

UAG helps us in this case because when a client authenticates during the login process to UAG, we are able to delegate authentication and use the same credentials for different applications in the same trunk.

That's something we are able to set, selecting an application in the selected trunk, opening the Web Settings tab, and configuring Use single-sign on to send credentials to published applications.

If the published server is using an HTTP-based schema (Basic, NTLM, and Integrated Windows Authentication), we have to use 401 request. If we have a form-based authentication, activate the HTML form radio button. The Both selection is to address a scenario in which the two authentication methods are required together. We have already explored Allow rich clients to bypass trunk authentication, which is needed for services that cannot authenticate using the trunk's authentication, and that requires a direct basic or NTLM authentication. The last option, Use Kerberos constrained delegation for single sign-on, requires the trunk to authenticate using any method, and then UAG will perform the SSO presenting a Kerberos ticket to the backend web application.

UAG creates a backup of our configuration when we activate a modification (as we have seen in the previous examples).

By default, the configuration is saved in the <UAG path>\Backup folder, and it contains the trunk and application configuration in an XML file. If we want to export or import our configuration manually, we can use the UAG management console and on the File menu, select Export (or Import).

Alternatively, we can use the ConfigMgr command (<UAG path>\utils\ConfigMgr\ ConfigMgrUtil.exe) to export:

ConfigMgrUtil Export (-exp) xml_file password [comment] 

Or to import:

ConfigMgrUtil Import (-imp) xml_file password

The aforementioned actions are useful also if we want to create additional servers (for a lab environment, for example).

The Forefront UAG registry keys TechNet article (http://technet.microsoft.com/en-us/library/ee809087.aspx) contains some of the tasks we are able to launch only from the registry (like the previous backup and restore operation with unmatched UAG versions)

The UAG Web Monitor is the tool we use to verify information about the activities related to sessions, applications, users, and so on.

It's located in the UAG management console, and it's installed by default.

In the UAG Web Monitor, we will have data about active sessions, session statistics, server status, reports, and endpoint information (and more). For example, as we said, when talking about endpoint policies, we are able to read information about the client with an Active Session (going to Session Monitor, Active Sessions, and selecting the Session ID we want to examine). In the following screenshot we have information about the endpoint:

And in the next screenshot we have information about the session parameters (we are using a Windows Phone Emulator):

Standard tools, such as the Web Monitor we talked about previously, often do not provide enough information on errors and events related to UAG. Luckily UAG uses a mechanism known as Event Tracing for Windows (ETW) that we are able to configure using a graphical interface Trace.HTA.

It's launched using the LaunchHTA.VBS script in <UAG path>\common\bin\tracing.

The amount of information registered and managed here is huge, but there are a couple of really good articles about Trace.HTA from where we could get started on the use of the tool, first from Ben Ari's UAG and IAG blog (again) and the second one from Frédéric ESNOUF's blog: