A common question for UAG administrators is, can I provide anonymous access to a Web site, but require and prompt for authentication when a user clicks a link to access a specific part of the Web site?

Remember: the  definition of a Web Application in UAG is a combination of the Web server, the port and the path. Web application access is dependent on endpoint policy, authentication, and authorization. So you can certainly implement a solution where you prompt for authentication for some pages but not for others, even if they are all hosted on the same server.

The first step is to create a trunk that does not require authentication. Instructions for creating a trunk are here. Note that you’ll have to first create a trunk that requires authentication, and then modify its properties afterwards, so that it does not require authentication. Add your applications to the trunk, using these properties:

Application 1:

• Type: Other Web Application
• Web Server address and ports
• Path(s) to the portion of the Web site not requiring authentication, for example, /news
• No Authentication required

Application 2:

• Type: Other Web Application (same as Application 1)
• Web Server address and ports (same as Application 1)
• Path(s) to the portion of the Web site that do require authentication, for example, /secret
• Authentication required

Having implemented this, when a user requests /news, he will not be prompted to authenticate, but when he chooses /secret, he will be required to authenticate.

Take note that trunk Applications are evaluated on the basis of the order they appear in the trunk’s Applications List Box, so make sure that the application requiring authentication (Application 2 in our case) appears first in the list.

Authors:
Pradeep Bethi, Technical Solution Professional
Nathan Bigman, Content Publishing Manager

Reviewer:
Meir Feinberg, Technical Writer

A number of our Forefront UAG TechNet guides are now available for download in Word format on the Microsoft Download Center.

Available downloads include:

• Exchange solution guide - http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=59916b01-dd04-46e1-8afe-01af9da77167
• SPS solution guide - http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=9bcf1d69-89af-47d3-b0f1-5865936f4f00
• RDS solution guide - http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=d192c703-e30b-4d47-9992-12b84c7554cb
• CRM solution guide - http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=742701ff-574e-450a-bdeb-cf12a2ae4206
• Infrastructure planning guide  - http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=110b4c77-b411-4845-9b82-40a733b17003
• Array design and deployment guides - http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=00401e7f-c702-431b-a96f-7914c267f2b1
• Access control design and deployment guides - http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cc4ac298-8168-4e25-919b-48b3b3e5863b
• Endpoint component deployment design and deployment guides - http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=9cbbc75e-2c21-440f-b7dc-000ce4774c2b

For comments, feedback, and requests, contact the Forefront UAG User Assistance team at uagdocs@microsoft.com.

Thanks

Rayne Wiselman

Forefront UAG User Assistance Team

The secure socket tunneling protocol (SSTP) allows Web users authenticated by the Forefront UAG portal to access the published remote network. You can use Forefront TMG on UAG to configure who has access to what over SSTP VPN. In this example, we’ll block a specific user/group from accessing the entire Internal network on all protocols. You can also select specific protocols to block.

Note: You have to have a working AD with the previously defined users/groups to who you want to deny SSTP services connection.

Procedure:

1. Open the Forefront TMG Management console:

2. Right-click the Firewall Policy mode, select New, select Access Rule.

3. Give the rule a name, such as SSTP Block, and click Next.

4. On the Rule Action page, select Deny, and click Next. When rule conditions are met, access will be denied.

5. On the Protocols page, select All Outbound traffic, and click Next.

Note: This is the point in the procedure where you can choose a more granular approach – specify protocols you want to block.

6. On the Access Rule Sources page, click Add, and from Networks, select VPN Clients.

7. Click Next.

8. On the Access Rule Destinations page, click Add, and select Internal from the list of Networks, and click Next.

9. On the User Sets page shown below we’ll actually configure what we’ve set out to do – block specific users. Select All Users and click Remove.

10. Click Add, and on the Add Users dialog box shown below, select New. This kicks off the New User Set wizard. Name the new user set SSTP Deny.

11. On the Users page, click Add, and select Windows users and groups.

12. Browse to the right user/group, confirm it with the picker dialog, and close all of the dialogs. Click Next and complete the New User Set wizard.

13. Back in the New Access Rule wizard User Sets page, you can select the new user set, click Next and Finish to finalize the rule. You’ll also have to click Apply in the Forefront TMG console.

Remember, Forefront TMG rules are ordered, so if this rule is not near the top and another rule has these conditions and allows access, the request won’t even get to this rule denying access. So make sure this rule is at or near the top. You can read more about Forefront TMG access rules on TechNet.

You're done!

Daniel Slabodar, Automation and performance test engineer

Nathan Bigman, Content Publishing Manager, Anywhere Access Team

In IAG, we created Basic and Webmail trunks to publish a single Web application with a one-to-one connection, where one external IP address routes to a single backend Web application server. Basic and Webmail trunks are no longer available in UAG, so what happens now if you want to publish a single Web application directly, rather than requiring users to access an application via a UAG portal?

Basic and Webmail trunks provided limited functionality in IAG, and UAG aims to provide direct Web application publishing with the same flexibility and feature set as portal application publishing. In order to do this, UAG introduces a new feature known as application-specific public host names. For ISA Server/Forefront TMG users, this feature is similar to the link translation feature, and in UAG it provides an alternative to the HAT mechanism.

Using an application-specific public host name, you can publish Web applications directly via a portal trunk. When a user types the application public host name in a browser, rather than the portal public host name, the client endpoint connects directly to the application. When the UAG server receives a request for an application-specific host name, it performs authentication, and then automatically opens the required application, bypassing the UAG portal home page.  One issue to note - although this option allows users to access a Web application directly, it does require them to remember a public host name for each application published in this way.

So how do I publish a Web application with an application-specific host name?

1. When you create a portal trunk, ensure that the public host name of the portal trunk is fully qualified and contains at least two dots. For example uag.contoso.com.
2. Add the application to the trunk using the Add Application Wizard, available from the main property page of the trunk.
3. On the Select Application page of the wizard, click Web, and from the drop-down list select Other Web Application (application specific hostname).
4. On the Configure Application page, type in the name of the application. This is the name that appears on the portal application list, and it is also the default name used for the application on the portal home page, and in the home page toolbar.
5. On the Web Servers page, do the following:
   • In Paths, specify the path of the published Web app. Note that if you want to publish multiple instances of the same application public host name, ensure that you use a unique path for each instance.
   • In Public host name, specify the host name that the client will type in the browser to reach the Web application directly. Note the following:
     • In HTTPS trunks, we recommend that both the public host name of the trunk and the public host name of the application should be included on the server certificate used by the trunk.  Alternatively you can use a wildcard certificate. You can use names that do not match the certificate. In this case, ignore the certificate warning that pops up during trunk configuration. If names do not match, connecting endpoints will be presented with a browser warning that there might be a problem with the website’s security certificate, and must choose to continue for site access.
     • The application’s public host name must be in or above the domain-level namespace of the portal’s public host name.

• By default the application appears in the portal home page and toolbar using the application name you specified earlier in the wizard. If you want the application to be available for direct access only and not via the portal, on the Portal Link page, clear the setting Add a portal and toolbar link.

Anything else I need to do?

After completing the wizard, do the following:

• If you have published more than one instance of an application public host name, ensure that the application path for each instance is unique.
• Ensure that the application-specific host name is resolvable by a public DNS server.
• In the DNS entry, the application host name should resolve to the same IP address as the public host name of the trunk.
• Try accessing the application directly, by typing the application public host name in the browser of a remote client endpoint.

Author: Rayne Wiselman  (UAG User Experience Team)

Reviewers: Ran Dolev; Ophir Polotsky; Dan Herzog (UAG Supportability and Customer Support Team)

I’m pleased to announce that Forefront UAG has formally entered evaluation for Common Criteria Evaluation Assurance Level 2+ with TÜViT as the Common Criteria Testing Laboratory (CCTL), and has attained Evaluated Products List (EPL) status. The evaluation is being conducted by the Federal Office for Information Security (a German government agency known in English as the “BSI”). The BSI’s certification is recognized by all countries that accept the Common Criteria, including the USA, the UK, France, Japan and more than 20 other countries.

Since Common Criteria certification is a long process, attaining EPL status is significant for earlier purchase decisions: It means that the BSI reviewed and approved the detailed scope and content (the "Security Target") of the certification, and reflects a high level of confidence in the success of the certification. The Certification-ID assigned to UAG is BSI-DSZ-CC-678.

You will also be happy to know that Windows 2008 Server R2 and Windows 7 are undergoing certification. More information can be found on Tim Myer's blog.

References:

Products in the process of evaluation by the BSI are listed at https://www.bsi.bund.de/cln_165/ContentBSI/EN/topics/Certification/newcertificates.html. On the page, scroll down to the sentence “The following list includes products / systems where the applicant has agreed to publication before completion of the certification procedure.” At the time of writing, UAG is the most recent addition and appears first on the list.

For a brief description of the Common Criteria certification, see http://en.wikipedia.org/wiki/Common_Criteria

Author:
Noam Ben-Yochanan, Senior Program Manager

Reviewer:
David Strausberg, Technical Writer

The complete library of Forefront UAG RTM content is now available on the Library tab of our Forefront UAG TechCenter.  This content release is the result of a joint effort coordinated by the UAG User Experience team, in conjunction with the product group, field and support engineers, our community and customers. Together we planned, developed and reviewed the library content, in order to expand and improve the UAG ITPro documentation experience.

Using the content library

The content library is divided into a number of sections and guides, as follows:

Product Evaluation

The Product Evaluation section includes an overview of UAG capabilities; a list of new features; a summary of UAG architecture, a technical  overview of Forefront UAG DirectAccess, and information about the time-limited evaluation version.

Getting Started

In Getting Started, a number of resources help you to ramp up before you start planning and deployment. You can review the release notes, follow a step-by-step guide for a quick UAG DirectAccess lab setup, and read about support boundaries.

Planning and Design

The Planning and Design guides help you to evaluate possible UAG deployment designs, and to understand the planning required in order to implement a chosen design:

• Infrastructure design guide─This guide is intended as an aid for the system, network, and server administrators who are responsible for modifying corporate infrastructure in preparation for UAG deployment. It discusses network topology options, firewall requirements, domain and workgroup requirements, certificate and DNS requirements, and client prerequisites.
• Array design guide─The array design guide provides information about array and load balancing options, and helps you to identify a high availability design to suit your corporate requirements.
• UAG DirectAccess guide─This guide provides in-depth information about the DirectAccess design process, topology planning, and deployment options and prerequisites.
• Publishing design guide─The publishing design guide provides an overview of publishing concepts, and helps you to understand the design requirements for deploying a UAG publishing solution.
• Access control for publishing design guide─UAG provides a number of access control mechanisms, including client authentication, endpoint health checking against access policies, and portal application authorization. This guide provides an overview of these mechanisms, and explain the design decisions required in order to implement access control.
• Endpoint component deployment design guide─This design guide provides information about UAG endpoint components, and client requirements, and describes the design considerations involved in endpoint component deployment.

Deployment

After planning with the design guide, matching deployment guides walk you through the prerequisites and steps required in order to configure your chosen design. Deployment guides are provided for installation, array deployment, UAG DirectAccess deployment; application publishing, access control deployment, and endpoint component deployment.

In addition to these guides, the deployment section  contains a number of solution guides. These provide a one-stop shop for planning and deploying a specific publishing solution. Solution guides are available for:

• SharePoint publishing─This guide describes the advantages of publishing SharePoint via UAG; publishing prerequisites; and a step-by-step walkthrough for each publishing topology.
• Exchange services publishing─The Exchange solution guide summarizes the Exchange services you can publish with UAG; describes the benefits of publishing Exchange via UAG; and provides deployment steps for each Exchange publishing scenario.
• Dynamics CRM publishing─This guide summarizes the value added proposition in publishing CRM via UAG, and detailed steps for publishing.
• Remote Desktop Services (RDS) publishing─The RDS publishing guide provides an overview of why you should publish RDS via UAG, and steps for publishing both RemoteApp applications and Desktop Connections.

Operations

The Operations section currently contains a UAG customization guide, information about administering UAG servers and arrays, instructions for configuring monitoring and logging, and information about the UAG System Center Operations Manager (SCOM) Management Pack.

Technical Reference

The Technical Reference contains a number of useful reference topics, including:

• A reference for user interface (UI) fields in UAG wizards and property pages
• Information about the Activation Monitor console
• A list of logging fields provided when you log UAG activity to SQL Server
• A list of UAG registry keys that can be used to tweak settings that are not available via the UI

Enjoy! We’d love to get your feedback about what is and isn’t working for you, and are always happy to receive your requests for specific documents and content. Documentation feedback can be posted here, or sent directly to our team at  uagdocs@microsoft.com.

Rayne Wiselman

Forefront UAG User Experience Team

for MSDN subscribers, FYI -

UAG is now live on subscriber downloads.

You can see it at: http://msdn.microsoft.com/subscriptions/downloads

Available to Levels: VS Pro with MSDN Premium (Empower); Developer AA; MSDN Universal (Retail); VSTS Team Suite (VL); VSTS Architecture (VL); VSTS Development (VL); VSTS Test (VL); VS Pro with MSDN Premium (VL); MSDN Universal (VL); VSTS Database (VL); VS Pro with MSDN Premium (Retail); VSTS Test (Retail); VSTS Development (Retail); VSTS Architecture (Retail); VSTS Team Suite (Retail); VSTS Database (Retail); BizSpark Admin; BizSpark; 

Author: Oleg Ananiev

Hi,

Following up on the official announcement, I thought I'd write a quick note about our F5+UAG better together;

We recently finished working with F5 engineers on making sure F5 solution and UAG DirectAccess work together.

F5 published the solution guide in http://www.f5.com/pdf/deployment-guides/f5-uag-dg.pdf , and we support that configuration in our UAG 2010 release ,with integrated 3^rd party load balancer support for DirectAccess. (Our TechNet docs are located in http://technet.microsoft.com/en-us/library/ee690463.aspx)

I'm really excited to have a load balancing leader such as F5 working with UAG DirectAccess, and I'm sure it will enable UAG DirectAccess customers to enjoy a rich variety of load balancing scenarios utilizing the scalability, reliability, and advanced customization that  F5 offers.

Thanks

Ben Bernstein

As part of the UAG DirectAccess (RTM) solution we suggest an improved way of managing the Access Enabling Servers, aka "First Tunnel". These are the machines inside the domain which require access prior to the remote user's logon. Machine's such as Domain Controllers, NAP and various remediation servers require access in order to validate the client as a healthy domain joined machine; thus allowing secure access to the rest of the corporate resources.

The "Management Servers and DCs" User Interface:

This UI enables easy control and management of the servers that are published as "Access Enabling" for your organization. List your domains your NAP and remediation servers with ease, sit back and watch the IPSec policies at work.

You can organize your servers into logical groups, making it easier to audit changes and developments of your organization.

Features details:

· The new UI is divided into logical groups, making it easier tracking down specific machines based on their roles.

· You can add servers using a name, an IPv6 address or an IPv4 address. The result is that names and IPv4 addresses are resolved to actual v6 IPs (Native and/or ISATAP and/or NAT64) only at the final "Policy Generation" step, this way when networking changes occur you just regenerate the policies.

· The "Domains" group is unique, while you are required to add/remove domains manually. The DCs themselves are discovered and listed automatically. This is called a "discoverable" group, which means that members (servers) cannot be added or removed. However it is possible to "uncheck" (see below) them.

In future releases more groups (such as Windows Updates) may become "discoverable" groups, to ease the management process further.

· "Refresh" button causes all discoverable groups in tree to list their servers based on the most current information. For example, new DCs are added and deprecated DCs are removed, resulting in an up-to-date list of all the domains and their DCs.

· Unchecking a server will remove it from the final resolved list of the "Access Enabling" tunnel. This is useful when you want to list all servers of a specific group for future use, but currently want to grant access only to few. This is a practical way to balance existing health and remediation servers in favor of local and remote clients.

· Adding groups of your own, either to the "Management" or "Other" tree roots as you see fit. The groups are a loose logical arrangement, it is up to you to use the built-in groups or just add some of your own.

· Adding a single server. You can add a server name, IP address or a whole IPv6 prefix with a single click.

· Adding a list of server. This is a more advanced feature to populate large lists, either manually or by pasting from external lists (spread sheets, txt etc.).

· The end.

Managing the edge of your organization just made simpler with UAG.

Authors: Max Braitmaiere; Yaniv Naor

Reviewer: Meir Mendelovich

We are proud to announce that Forefront Unified Access Gateway (UAG) 2010 is Released To Manufacturing (RTM). Evaluation version (timebombed for 120 days) is already available on the web, click Download button below to try it now.

The commercial version of Forefront UAG will be available early January, on the Volume Licensing Service Center.

UAG was first introduced in the second half of 2007 and its release is a significant milestone in over 2 year’s journey, creating a world-leading Access solution. Building on its predecessor, Intelligent Application Gateway, UAG enables remote access via managed and unmanaged PCs and mobile devices. It integrates a deep understanding of applications, the health state of end user devices, and the user’s identity for greater security and reduced management costs.

While UAG provides a variety of connectivity options, such web publishing and SSL VPN tunnels, one of the best new features is UAG’s support and enhancements for Windows DirectAccess (DA). DA is the future of remote access allowing for seamless, always-on connectivity. Always-on keeps users happy as they are continually productive, but it also keeps administrators content as users are “always-managed.” UAG helps make DA deployments simpler, more extensible and easier to scale

Forefront UAG enables organizations to give employees (and trusted partners and vendors) secure remote access to corporate resources.  With its focus on application intelligence and granular access control, UAG is an ideal solution all of your remote access needs that provides centralized management and policy control across all users, devices, and network resources.

You can find a new guide for UAG which outlines the critical infrastructure design elements that are key to the successful implementation in Microsoft Solution Accelerators. Use this guide to shorten your Forefront UAG infrastructure planning and deployment time!

·         Download the IPD Guide for Microsoft Forefront Unified Access Gateway.

·         Visit the Forefront Unified Access Gateway page on TechNet to learn more.

We continue to improve our product so that it will best serve your needs. You can provide feedback and share your experience through our forum.

Follow us on our blog too; we're planning on providing you with continuous helpful information about the product.

Yossi Yossifon

Lately we've been getting quite a few questions on how to customize the portal in UAG.

As you probably already know, the portal in UAG is very different from the portal in IAG. The difference is not only in how UAG portals look and are structured, it's also in the technology used to create them. The portal in UAG is based on ASP .NET.

To help get you started, we’ve put together a couple of common customizations. Before we get down to the nitty-gritty stuff, there are a couple of guidelines you should be sure to follow during customization:

1. Always place customized files under the CustomUpdate folder. Otherwise these files will be erased each time you upgrade. Also, files placed in the CustomUpdate folder are replicated to other array nodes during activation – so you only have to make the changes once!

2. After an upgrade you should always test if the customizations you created are still working as planned. Bug fixes and new features may change how the portal behaves or is structured.

There’s an endless list of possible portal customizations. Below are just common examples of customizations. If you did a cool customization on your portal, tell us about it!

Figure 1. The UAG Portal before customization (notice the new look…)

Adding a personal touch

The first thing you will probably want to do is add some personal touches to the UAG Portal to reflect your organization.

1. Copy the file PortalHomePage\App_Themes\Office\office.css to the CustomUpdate folder at PortalHomePage\App_Themes\CustomUpdate\Office\office.css

2. Edit the office.css file in the CustomUpdate folder, as follows

a. To change the color of the portal title, find the .BigTitle style class and change the color attribute:

b. Rename the image file of your logo to Header_logo.gif and place it in the PortalHomePage\App_Themes\CustomUpdate\Office\Layout folder to automatically replace the existing logo.
Instead of renaming the file, you can place a file with any name in that folder and change the reference to it in office.css under the .topStripLeftCell style class :

c. To remove the gray background line from the header, we’ll edit the office.css file again and remove the background images from the style classes:

· .portalTitleCell

· .topStripWhiteSpacerCell

· .topStripPattern

· .topStripOrangeSpacerCell

· .topStripRightCell

3. Finally, we’ll change the title of the portal:

· Create a en-US.xml file in the PortalHomePage\Data\Languages\CustomUpdate folder.

· You only need to add nodes for strings you wish to customize :

· Repeat for other languages.

Figure 2. The UAG Portal customized with your title & logo

Adding a button to the toolbar

The UAG portal toolbar is easily customized by editing XML sitemap files. In this example, we’ll add a toolbar button that opens a popup window. Follow these instructions to add this to your site:

1. Copy the file PortalHomePage\Data\SiteMap\ToolBar\web.sitemap to the CustomUpdate folder at PortalHomePage\Data\SiteMap\ToolBar\CustomUpdate\.

2. Open the web.sitemap file in the CustomUpdate folder, and add a new sitemapNode to the file as follows:

<siteMapNode url="javascript:OpenNewPage()"

title="$Resources:Resource,102"

description="$Resources:Resource, 102"                

imageUrl="~/images/ToolBar/home.gif"

displayMode="OnlyImage"

target="_self"

selectable="true"/>

3. Set the sitemapNode values as follows:

a. In siteMapNode url, change the JavaScript function name (OpenNewPage()) to any name you choose.

b. In title and description, change the resource number (102) to correspond to a string ID in the language files, located at PortalHomePage\Data\Languages. If you want to add a new string, copy the file from the Languages folder to the Languages\CustomUpdate folder and add the string to the new file.

c. In imageUrl, point to the image you want to use.

d. In displayMode, leave the setting OnlyImage to use an image. If you want to use text only, modify the setting to TextOnly.

4. Copy the PortalHomePage\Standard.Master file to the PortalHomePage\CustomUpdate folder.

5. Open the Standard.Master file in the CustomUpdate folder and add the following code in the <head>  tag:
        <script type="text/javascript">

        //<!—

                var newWin = null;

                function OpenNewPage()

                {

                                                var windowName = siteName + secure + "new";

                                                if (newWin)

                {

                                if(!newWin.closed)

                                      newWin.focus();

                                else

                                         newWin = openNewWindow("index.html", windowName, 720, 590, true, true);

                }

                else

                                        newWin = openNewWindow("index.html ", windowName, 720, 590, true, true);              

                }

        //-->

        </script>

6. Replace newWin and "new" with a unique name.

7. Replace "index.html" with the target URL.

8. Replace the numbers 720, 590 with the width and height of the window.

Notes:

· The image and page URLs are relative to the PortalHomePage folder, unless an absolute address is given.

· Pages added under the PortalHomePage folder need to be added to the URL Set of the trunk, so that they are not blocked by UAG rules. For more information, see Configuring URL rules.

Collapsing the portal tree

The application tree on the left side of the portal can be expanded and collapsed. By default, the tree is displayed in the expanded mode. To display the page with the tree collapsed by default, do the following:

1. Copy the file PortalHomePage\Standard.master to the CustomUpdate folder at PortalHomePage\ CustomUpdate\, and open the file for editing from the CustomUpdate folder.

2. In the file, add a call to the hideTree() function in the body onload event, as follows:
<body onunload="closePopups()" oncontextmenu="return false;" onload="ResizeContent();hideTree() " onresize="ResizeContent()">

Figure3 . The UAG Portal with the application tree collapsed

Toolbar only, please

Is the portal too crowded for you? Do you want more space to view your applications? You can customize the portal to show only the toolbar and application list / selected application, and hide the header, footer and application tree , as follows:

1. Copy the file PortalHomePage\App_Themes\Office\Office.css to the CustomUpdate folder (PortalHomePage\App_Themes\CustomUpdate\Office\Office.css), and open the file for editing from the CustomUpdate folder, as follows:
   • In the file, to hide the header, replace the style of div#topStrip to display:none. Erase the rest of the properties.
   • To hide the tree, replace the style of contentLeftSideBarCell to display:none. Erase the rest of the properties.
   • To hide the footer, replace the style of div#footer to display:none. Erase the rest of the properties.
   • To move the toolbar up and replace the hidden header, in the div#toolbar style, change the value of top to top:0.
   • To move the application list or the displayed application up, in the div#content style, change the value of top to top:40.

Figure 4. The UAG Portal after the customization

That’s it for now. I hope these samples will put you on the right track to fully customizing your UAG Portal.

Just to remind you, remember to always put the customized files in the appropriate CustomUpdate folder to ensure they are replicated to all array nodes.

Ittai Doron

AppWrap (Application Wrapper) is an IAG and UAG XML configuration file that enables manipulating HTTP responses on their way back from the backend web server to the client.

In IAG 2007, approximately 30 such files existed, since each AppWrap file was used for a different type of single-application trunk (for example, one AppWrap file was used for a trunk publishing Outlook Web Access 2003, and another AppWrap file for a trunk publishing Outlook Web Access 2007), as well as for portal trunks.

Since single-application trunks are not used in UAG (with the exception of publishing an Active Directory Federation Server), we are left with one main AppWrap file, which is the one used for portal trunks (two versions of this file exist – for HTTP and HTTPS trunks – but they are very similar).

After removing a large amount of manipulation configurations, the files became much clearer and maintainable, as their size was reduced to about 1/3 of their size on IAG 2007.

Manipulation per application

The AppWrap structure was changed to support manipulation per application:

Each group of <DATA_CHANGE> tags is enclosed within <APPLICATION_TYPE>[APP_TYPE]</APPLICATION_TYPE> tags, where APP_TYPE represents the application ID defined in the top part of WizardDefaultParam.ini and then inside []. For example, [ExchangePub2007].

It is still possible to define an empty APPLICATION_TYPE as follows: <APPLICATION_TYPE></APPLICATION_TYPE>, for any other manipulation for a non-defined application.

This change greatly improved the “search & replace” manipulation mechanism and thus enhanced performance.

Backward compatibility

In order to port IAG-style AppWrap files to the UAG format, some manual changes of the original file are needed: after the <MANIPULATION> tag, add a <MANIPULATION_PER_APPLICATION> tag, immediately followed by an <APPLICATION_TYPE>[APP_TYPE]</APPLICATION_TYPE> tag.

Remember to add a closing </MANIPULATION_PER_APPLICATION> tag after all the <DATA_CHANGE> sections, right before the <HEADER_CHANGE> section begins.

The changes are highlighted below.

<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml">

          <MANIPULATION>

                  <MANIPULATION_PER_APPLICATION>

                          <APPLICATION_TYPE>InternalSite</APPLICATION_TYPE>

                          <DATA_CHANGE>

                                  <URL case_sensitive="false">…</URL>

                                  <SAR>

                                          <SEARCH encoding="base64">…</SEARCH>

                                          <REPLACE encoding="base64" using_variables="true">…</REPLACE>

                                  </SAR>

                        </DATA_CHANGE>

                       …

                       …

                       …

                 </MANIPULATION_PER_APPLICATION>

                 <HEADER_CHANGE>

                 …

                 …

                 …

                </HEADER_CHANGE>

        </MANIPULATION>

</APP_WRAP>

Important: Once you’re done modifying the AppWrap file, save it and then double-click it in order for it to open in Internet Explorer. If it opens without any errors, you can be sure that you did not break the XML file syntax while editing the file, and thus the file can be used by UAG. Otherwise, if the syntax is incorrect, IE will indicate that a problem exists and will usually give you a pretty good tip as to what is broken.

Conditional SAR

Conditional SAR (Search and Replace) is a new capability which enables performing manipulations only when certain conditions related to a UAG session parameter are met.

For example, we may want to remove the ‘Log off’ link from an application, but only when this application is published within the portal frame (where the portal ‘Log off’ button exists and should be used). We use the following SAR tag:
<SAR conditional_variable="UsePortalFrame" conditional_var_value="False">.

For example, hiding the ‘Log off’ button on SharePoint 2007:

<URL case_sensitive="false">.*\.aspx.*</URL>

         <SAR conditional_variable="UsePortalFrame" conditional_var_value="True">

                    <SEARCH encoding="base64">SignOut.aspx';" </SEARCH>

                    <REPLACE encoding="base64">SignOut.aspx';" style='visibility:hidden;'</REPLACE>

        </SAR>

</URL>

This option is also available for HTTP header manipulation.

Session parameters and their respective values can be obtained through the Session Details screen on the UAG Web Monitor.

Out of the box AppWrap main manipulations

Here is a list of the main kinds of manipulations performed by the AppWrap feature:

• Blocking uploads and downloads, according to endpoint policy definitions.
• Adding session timeout and logoff functionality to applications.
• Removing logoff functionality from applications published within portal.
• Fixing application publishing bugs (mismatch of HTTP & HTTPS, accessing wrong frames due to portal structure, etc.)
• Sending the Exchange CAS server the right HTTP request headers to support private/public access, as well as access to OWA Light.

Ron Gilad

Today, I’m just going to be brief for a change, and discuss what we refer to as “Managed Out” scenarios.

I want to thank Pat Telford a consultant in Microsoft, specializing in DirectAccess deployments among other things, for helping with this subject.

Like I mentioned in one of my first posts, one of the big advantages of the DirectAccess technology over traditional VPN service is that DirectAccess clients can be managed anytime they are connected to the Internet. We like to refer to that scenario as “manage out.” This means that the client’s computer is “always managed” – there is an IPsec channel that enables the infrastructure and management servers to have access to the client’s computer, even when a user is not logged on.

There are two ways manage out can be accomplished:

• Client-initiated: Where the DirectAccess client initiates the communication to a server on the intranet, and then “pulls” it down:
• In this case the intranet server can be an IPv4 server, and UAG DirectAccess uses it's NAT64/DNS64 capabilities to compensate for the lack of IPv6 connectivity to the intranet server
• The following are examples of Client-initiated management traffic:
• System Center Configuration Manager
• Windows Server Update Service
• System Center Operation Manager (Most of the time)
• Updating Anti-Virus definitions
• Applying Group Policy Objects
• Intranet -initiated: Where the resource in the intranet initiates the communication to a DirectAccess client on the Internet:
• The host initiating the connection must be able to determine the IP address of the remote DirectAccess client. This means that the Remote DirectAccess client must register its FQDN and IPv6 address in the internal DNS servers.
• The client can register its IPv6 address dynamically, if dynamic DNS updates are enabled, and the DNS server supports AAAA records.
• The DNS server must be reachable from IPv6 DirectAccess clients. If you aren’t routing native IPv6 in your network, you can use an ISATAP generated IPv6 address for the DNS server.
• Using a Windows Server 2008 or Windows Server 2008 R2 based DNS Server is the best option here, since they natively support both of the above.
• The second best option would be to use Windows Server 2003 DNS servers With UAG DirectAccess. The built-in NAT64/DNS64 will still provide connectivity to IPv4 only DNS servers.
• UAG DirectAccess supports using NAT64/DNS64 to register DirectAccess clients on a Windows 2003 Active Directory infrastructure.
• The host initiating the connection must be IPv6 able – Our NAT64 implementation doesn’t translate connections initiated from the intranet.
• The following are examples of traffic that is initiated by resources inside the intranet:
• Protocols that may be used by IT personnel (“Peer to peer”)
• Remote Desktop
• SMB – for reaching out to files on the user’s machine
• Endpoint vulnerability scans

That’s all for today, just remember, if you have protocols that initiate connections to DirectAccess clients, you’ll need the DNS infrastructure to be set correctly for it to work with UAG DirectAccess. In addition, don’t forget to specify relevant management servers in the Management Servers and DCs page in the Forefront UAG DirectAccess Configuration Wizard, if you want managed out communications between the client and the management servers, even when the no one is logged on to the client computer.

Thanks

Ben Bernstein

Applications that are published using UAG can benefit from its built-in load balancing functionality. Multiple backend servers can be configured per application, and Web Farm Load Balancing (WFLB) will take care of distributing traffic across the different servers and maintaining clients’ affinity.

Let’s assume I am publishing Outlook Web App (OWA). There are two Client Access Servers in my Exchange 2010 deployment, EX14-CAS-01 and EX14-CAS-02. My trunk’s public host name is portal.contoso.com, but instead of using that I would like users to access OWA using mail.contoso.com. Considering the published OWA application is consumed by a Web browser, I can improve the experience with cookie-based affinity; distributing traffic across the array in a more evenly manner (avoiding the problem with forward proxies of multiple users behind the same IP address). All of these configuration settings are reflected in Figure 1:

Figure 1 - Exchange Web Farm Configuration

The above illustrates a plain vanilla scenario. In contrast, some farms tend to be pickier on how they are being approached. For instance, they may require the Host: name in the HTTP header request to point to the farm’s name instead of a particular backend server. You can instruct UAG to do that by selecting the Use the farm name in the HTTP check box and specifying the designated farm name in the Server farm host name edit box. UAG also replaces backend farm links that match the content of this edit box with the public host name. Figure 2 illustrates how to bake all of this into WFLB configuration settings.

Figure 2 – Advanced Farm Configuration

With the above settings, UAG HTTP requests to backend farm servers look as follows:

• GET / HTTP/1.1
• Host: partners.contoso.com (instead of Host: EN-RWS-01 or EN-RWS-02)

Content from backend servers that contains references with EN-RWS-01 will be modified, as UAG will replace them with partners.contoso.com. Effectively, end-users will not be exposed to the internal hosts’ names but to the public host name only.

Michel Biton