Ben Ari's UAG and IAG Blog

Activation completed…Erez Ben Ari logging off

Ben Ari — Tue, 09 Apr 2013 17:58:39 GMT

As you can guess from the title, this is my last post to this blog. A few weeks ago, I was offered a position as a PM (Program Manager) in the IIS team, and tomorrow is my last day with UAG support. I’ve aspired to be a PM for many years, and that dream has finally come true. In my position as a program manager, I will take part in shaping the future of Microsoft’s Web Server platform and help make it better and more successful.

It’s been a bit over 4.5 years since I joined Microsoft’s customer service and support (1688 days!). It was a rough start…I knew next to nothing about IAG (that was in 2008, before UAG was released), and spending 8+ hours a day on the phone trying to figure out a product with little documentation was very trying. Lucky for me, I had colleagues with super-human skills who helped me along the way. Two years later, UAG came out and by that time, I was already making a name for myself, and being quite successful in my role.

As time passed, I realized that this is the best job I ever had. I had two amazing manages (Jeff and Mohit) who supported my efforts to develop and exercise various peripheral skills such as training, writing and developing code. I was also lucky enough to be to mentor to several other engineers and their success and growth gives me tremendous satisfaction and pride.

Letting all of this go isn’t easy. UAG is not just a job or a product for me – it has become a part of me, and I part of it. Working with my colleagues and customers was something to look forward to every morning and I’ll miss it a lot. This blog will remain as-is, and I hope the vast amount of knowledge I poured into it will continue to serve both my colleagues and customers for years to come (as you might have noticed, I posted over 20 items in the past week, cleaning up various in-progress items I was stashing). I’m afraid I won’t have the resources to investigate and help with UAG issues in the future, so I’m removing the “contact me” link from the blog and I won’t be responding to comments on it. Those resourceful enough will figure out a way to get in touch, but I hope everyone will respectfully honor the boundaries.

Farewell, my friends! I wish all of you fun using UAG, and I’m sure our paths will cross in the future again!

Erez Ben Ari

April 2013

UAG SSL Network Tunneling traffic capture

Ben Ari — Thu, 04 Apr 2013 22:31:50 GMT

Occasionally, one may need to troubleshoot the UAG Network Tunnling (a.k.a. “the Network Connector”). Normally, traffic capturing is done using tools such as Microsoft’s Network Monitor, or WireShark. If, however, you try to run a capture like that on a UAG client that is connected with the SSL Network Tunneling, you will discover that the client freezes, as the capture driver conflicts with the tunneling components.

There is, however, another way to capture this sort of traffic, using UAG’s built-in TCPDumper. Here is how to do this:

1. On the UAG client, log-off any existing UAG session, and close the browser.

2. Open the registry editor.

3. Navigate to HKLM\SOFTWARE\WhaleCom\Client\NetworkConnector

4. Create a new DWORD value and name it “log”

5. Set the value to 4

6. Create a new DWORD value and name it “log\sniff”

7. Set the value to 1:

8. Exit the registry editor

9. Launch a browser window, and establish your SSL tunnel, and reproduce the issue you need to investigate.

10. When done, log-off the UAG portal, and close the browser, to make sure the SSL-VPN component shuts down gracefully.

11. Re-open the registry editor, and remove the values you have created, or change to “0” and “-“respectively.

12. Go to the UAG client component folder (c:\program files\Microsoft Forefront UAG\Endpoint Components\3.1.0), where you will find a file called whliocsv.log.lowlevel.dmp. This file is actually a standard CAP file. You can ask Windows to open it with your network capture software, and it will display like any regular capture!

SRA and AppWrap FAQ

Ben Ari — Thu, 04 Apr 2013 22:29:32 GMT

Here are answers to various F.A.Q. I received over the years for SRA and AppWrap:

1) In the SRA config file, is the application type case sensitive?

Answer: No

2) When I make changes to the SRA configuration, do I need to activate?

Answer: You should, but it’s not 100% mandatory. Once you save your changes, UAG picks up the new file, but it will not apply to existing sessions. In such a situation, you can simply restart IIS to make the changes apply. However, activation is still *very* important, because it stores the configuration in TMG. If you don’t, then a restart of the UAG server or its services will re-read the file from TMG storage and overwrite the file on-disk, wiping the changes you made…or even the custom file itself. Another reason for needing to activate is that it also propagates the changes to other UAG array members.

3) In the SRA config file, is the URL case sensitive?

Answer: No

4) When I configure an SRA S&R or Add_signature, does it change ALL instances in a file, or just the 1st?

Answer: All instanced that match are affected

5) When do I need to perform Base64 encoding?

Answer: when the text contains XML forbidden characters < > and &

6) Are the commands in SRA, like ADD_SIGNATURE case sensitive?

Answer: Yes

7) Are the parameters in commands, like "Location" and "after" case sensitive?

Answer: No

8) Does the CustomUpdate XML should be just the ‘delta’ or full XML modified?

Answer: The Custom XML should only be the delta, and contain only changes you want to make, and not the entire default file. In fact, it’s important to NOT copy over the fill default file, as this causes UAG to work harder, processing everything twice. Also, it makes it a lot harder to support, as it may be hard to find, within the modified file, where changes were made.

9) Does Appwrap/xml version that is listed at the top of the file (for example, “<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml">”) matters? Do we need to change that, if we update UAG?

Answer: No – the version or ID are only relevant for administrative purposes.

10) What is the processing order of SRA and AppWrap?

Answer: When UAG delivers a requested page to the client, SRA processes the file first, followed by AppWrap.

How many IP addresses do I need?

Ben Ari — Thu, 04 Apr 2013 22:07:25 GMT

Setting up a UAG server array provides organizations with the ability to provide higher availability, but it also brings up a common question of how many IP addresses does one need. The confusion usually revolves around two topics – internal vs. external IPs, and NLB vs external LB. Let’s try to clear up some misconceptions here.

Terms:

NLB – Load balancing facilitated by Windows, as opposed to regular LB. Also known as “Integrated NLB”

LB – Load Balancing facilitated by a 3^rd party device, such as F5’s BigIP range of load balancing appliances or Citrix’s NetScaler. Also known as “External LB” or “Non-integrated NLB”

DIP – Dedicated IP. An IP address assigned to a resource that is unique to every server, as opposed to a VIP.

VIP – Virtual IP. An IP address shared by several resources, either directly (such as with NLB) or indirectly (such as with external LB)

External Network – The network through which UAG receives client requests, and replies to them. It could be the DMZ network, but is referred to as “External” for clarity.

Internal Network - The network through which UAG forwards requests from clients to internal (corporate) servers, and receives a response. It could be the DMZ network, but is referred to as “Internal” for clarity.

DA – DirectAccess, one of UAG’s two primary deployment scenarios.

Application Publishing – The second of UAG’s two primary deployment scenarios.

APDA Mode – A UAG Server configured for both Application Publishing and DirectAccess simultaneously

Single Server scenario

If you use a single UAG Server, then you need:

1. one IP address for each portal or ADFS trunk

2. If you have redirect trunks (from HTTP to HTTPS), then they use the same IP as their counterpart HTTPS trunk, and there’s no need for additional IPs

3. The Trunk IPs can be either public IP addresses, or NAT IP Addresses*

4. For DA, you need two IP addresses, which must be public and consecutive, to serve the DA component.

5. If you are in APDA mode, you would need at least 3 IPs – 2 for DA, and one for each trunk. Note that in this situation, you should use the lowest IPs available for the DA connection (for example, if you have the IPs 4.1.1.1, 4.1.1.2 and 4.1.1.3, Use the .1 and .2 for DA, and .3 for the trunk).

* If you are using NAT, keep in mind that NAT devices often perform connection optimization, which could cause problems for clients. For example, this might cause a user to be “dropped” into another user’s session, because the NAT device reuses an existing connection to UAG for the 2^nd user’s request. As a precaution, make sure your NAT device is not optimizing connections.

Array scenario, with integrated NLB

In an array with NLB, you need DIPs and VIPs, like this:

1. One Internal DIP for each server in the array (these can be NAT IPs)

2. One external DIP for each server in the array (These must be public IPs)

3. For Application publishing, one external VIP**, used by all array members

4. For DirectAccess, one internal VIP**, used by all array members

5. For DirectAccess, two consecutive external VIPs**, used by all array members

6. If you are in APDA mode, you would need at least 4 VIPs – one internal, two externals for DA, and one external for each trunk. Note that in this situation, you should use the lowest VIPs available for the DA connection (for example, if you have the IPs 4.1.1.1, 4.1.1.2 and 4.1.1.3, Use the .1 and .2 for DA, and .3 for the trunk).

** Note that with NLB, the Virtual IPs are added using UAG’s NLB configuration screen (under Admin/Network Load Balancing). The NLB configuration within TMG or within Windows should NOT be used to configure these under any circumstance.

Array mode, with external Load Balancer (a.k.a. “non integrated LB”)

With an array, the VIPs are configured on the load balancer, and not on UAG. You still need the virtual IPs, but UAG is not aware of them, so you need to configure DA with the IPs like this:

1. One Internal DIP for each server in the array (these can be NAT IPs)

2. For DA, Two consecutive external DIPs for each server in the array (These must be public IPs)

3. For Application publishing, one additional DIP for each member for each trunk

4. For DA, two consecutive external VIPs, routed to the multiple DIPs

5. For DA, one internal VIP, routed to the multiple internal DIPs

6. For application publishing, one external VIP, routed to the multiple DIPs used by the trunk

7. The VIPs are assigned and configured on the load balancer, and routed to the DIPs configured on the array members, with UAG not being aware of them

When using an array, we recommend load balancing to be configured both on the internal side, and the external side. It’s possible, though, to have DA run without internal load balancing. If that is your plan, be sure to read the documentation for this scenario, to be sure your server meets the required configuration and that the impacted scenarios and features are acceptable to your organization.

How to create a static redirector on a UAG trunk

Ben Ari — Wed, 03 Apr 2013 18:00:52 GMT

Using UAG as a static redirector is a major overkill, but occasionally, it makes better sense to use an existing server than build a special box just for a redirect. While IIS has a simple option to setup a redirector, making such configuration changes on the IIS on a UAG server is unsupported. In order to setup a redirect, you have to customize UAG a little, and there are two ways to do so.

First option: redirect using a custom login page.

The login page is the 1^st customizable page that is loaded upon a user visiting a trunk. By creating a custom login page, you can perform a redirect on it. To do so:

1. Create a custom login page to do the redirect. The redirect can be done using the response.redirect ASP command, or using a client-side meta-refresh. This would like one of the below options:

ASP example	HTML example
<% Response.redirect “http://www.targeturl.com” %>	<META HTTP-EQUIV=Refresh CONTENT="0; URL=http://www.targeturl.com/">

2. Save your custom file in <UAG path>/von/internalsite/CustomUpdate

3. On your trunk, go to Advanced Trunk configuration

4. Switch to the Authentication tab

5. Adjust the path of the logon page to point to your custom file:

6. Optionally, switch to the Session tab and DISABLE component installation and activation.

7. Click OK, and activate the configuration.

Second option: redirect using a custom portal page.

This method is based on setting the trunk to be unauthenticated (anonymous), and creating a custom portal home page to do the redirect. To use this:

1. Open the trunk’s advanced Trunk Config

2. In the Authentication tab, set the trunk to be unauthenticated (uncheck the “require users to authenticate”)

3. Optionally, switch to the Session tab and DISABLE component installation and activation.

4. Click OK.

5. Open the folder <UAG Path>\von\portalhomepage\CustomUpdate

6. Create a file named “<trunk name><0 or 1>default.aspx” there. Use 1 if this is an HTTPS trunk, and 0 if it’s an HTTP trunk.

7. In that file, create the code to do the redirect. As in option 1, you can use ASP or HTML. However, the file has to have the RUNAT code in it (otherwise, the .Net framework will produce an error).

ASP example	HTML example
<head runat="server"> </head> <% Response.redirect “http://www.targeturl.com” %>	<head runat="server"> </head> <META HTTP-EQUIV=Refresh CONTENT="0; URL=http://www.targeturl.com/">

8. Activate the configuration.

How to customize the portal page

Ben Ari — Tue, 02 Apr 2013 23:45:31 GMT

When logging in to UAG, it will display the portal itself, but sometimes, you might want to have your own page. For example, one scenario is when you want to have your own custom links to your applications, or a very customized design that goes beyond what you can achieve with editing the regular standard.master page. The good news is that the UAG portal page supports the standard CustomUpdate customization framework just like most of the pieces on UAG. However, the portal code is written in ASP.NET, which means you need some accommodations to make it work.

To customize the page, follow these steps:

1. Create your custom home page as “default.aspx”, and place it in <UAG Path>/Von/PortalHomePage/CustomUpdate

2. Make sure the page has the basic formatting as below:

<head runat=”server”>
</head>
<%
‘Your custom ASP code***
%>
‘Your custom HTML and/or JavaScript

***You can use any standard HTML, ASP and JavaScript code in there – just make sure the page starts with <head runat=”server”></head>, otherwise it will cause the .Net Framework to error out.***

3. If you want the page to have images, place the image files in /von/PortalHomePage/Images/CustomUpdate, and then, when referring to them in the code, use something like:

4. You don’t have to activate the configuration after each change, as UAG will update immediately (save time when testing and playing around), but do make sure you activate occasionally, so as to store the configuration in TMG storage, and propagate across array members, if you are using an array.

Naturally, you can use any web-page editing software to create your page. You can simply copy the links from the default portal page, and then build your own page around them in any way you like, or create a richer page content with ASP and/or JavaScript. As in any customization, the possibilities are infinite.

Publishing OMA (Outlook Mobile Access) with UAG

Ben Ari — Tue, 02 Apr 2013 20:53:32 GMT

OMA has been a feature of exchange for many years. Unfortunately, UAG does not have a built in template to publish it, and it’s an unsupported scenario. However, if you need to publish it, and don’t mind the risks of being in unsupported territory, here’s how to publish it.

The key to OMA is that you simply append /OMA to your Outlook Web Access (OWA) URL. For example, if you were to access OWA internally (not via UAG!) using the URL http://ExchSrv01/owa/, then to access OMA on the same server you would simply type in http://ExchSrv01/owa/oma into your browser...and you would get your inbox in the OMA format:

When publishing Outlook Web Access with UAG, it simply publishes the /OWA/ virtual directory on the Exchange CAS, so all you have to do is append /oma to the URL, and it takes you to the OMA view. However, one caveat is that UAG is not designed to permit access to the /oma/ URL. A second issue is that you can’t expect all your users to manually edit the URL every time they need OMA.

To solve the 1^st issue, simple edit the URL set on the UAG server. To do so, you need to create an access rule to permit any URL that begins with /owa/oma. Creating a new URL set rule in UAG is simple, but it has to match the same application type that your normal OWA is published with. If this is Exchange 2010, then the rule name has to be “ExchangePub2010_Rule99”. If it’s Exchange 2007, then it would be “ExchangePub2007_Rule99”. Here’s how such a rule would look on the advanced trunk configuration:

The steps:

1. Open the trunk’s advanced trunk configuration

2. Switch to the URL Set tab

3. Click Add Primary

4. Type the rule name as “ExchangePub2010_Rule99” (if it’s Exchange 2010)

5. Change the action to “Accept”

6. Type the URL as “/owa/oma.*”

7. Set the parameters to “ignore”

8. Open the methods drop-down, and click on GET. Hold the CTRL key and click on POST.

9. Click OK

10. The placement of the rule on the list does not matter, so no need to move it up or down.

The next thing is to provide a link on the portal for users to click-on. Since you already have the application published, all we have to do is create a dummy application that doesn’t actually publish any servers, and has a hard-coded “portal link” to the OMA URL. Here are the steps:

1. On the trunk’s main page, click ADD

2. From the application list’s Web group, select “Other Web App(Portal Hostname)”

3. Type the application name, as you would want it to appear on the portal. For example “Outlook Mobile Access”

4. Type some application type. It can be anything, as it won’t be used in any configuration.

5. In step 3, select “configure an application server” and click next

6. In step 4, type a name of some internal server. It will not be used in any way, and can be anything, but it’s advisable to use a real name. If you don’t, the activation will take longer as UAG tries to resolve a non-existing name.

7. In step 5, leave SSO disabled

8. In step 6, change the application URL to the actual public hostname used by your OWA, and append /OMA to it. For example, if your normal external OWA** link is https://uag.contoso.com/owa, type in https://uag.contoso.com/owa/oma

9. Finish the wizard and activate the configuration.

**If you’re not sure what’s your external OWA URL is, simply open the OWA application published on your portal, and go to the Portal Link tab. Copy the “application URL” setting from that, and append /OMA to it.

Sending mail to the administrator with UAG

Ben Ari — Tue, 02 Apr 2013 20:50:56 GMT

On the UAG portal, you can find an envelope that is a link to create a mail to the site’s administrator (presumably…that’s you!).

However, by default, that link is empty and would generate an empty Email. Editing it requires a little bit of customization, and here are the steps:

1. Navigate to the folder

2. Copy the file web.sitemap into the CustomUpdate folder

3. Open the file inside CustomUpdate with the text editor of your choice

4. Go to line 103, which would read:

5. Add your Email after mailto:

6. Save the file, and activate the configuration to store your changes permanently. If you have an array, this would also replicate them to other array members

If you’d like, you can create a link that will also populate the subject and body of the Email, as well as other fields. However, if you want to do this, know that the & symbol is forbidden in XML, and will cause an application error on the portal. To get around that, use & instead. For example:

Other Email link formatting options include:

1. Specifying additional recipients

mailto:me@you.com,he@you.com,she@you.com

2. Adding a CC

mailto:m2&you.com&cc=he@you.com

3. Adding a BCC

mailto:m2&you.com&bcc=he@you.com

4. Multiple BODY lines:

mailto:me@you.com&subject=UAG&body=Regarding%0AUAG

(%0A creates a line break)

The following blog post by Dennis Lee shows additional options related to Email links in UAG:

http://forefrontdennislee.wordpress.com/2010/11/23/the-forgotten-contact-us-button/

Using AutoIT to automate UAG

Ben Ari — Tue, 02 Apr 2013 19:12:10 GMT

A common question comes up from people who need to create a complex configuration in UAG, and are looking for a better way to do it instead of manually entering it. For example, creating multiple applications on the UAG portal, rather than going through the application wizard multiple times.

Unfortunately, editing the UAG configuration directly by editing UAG’s EGF file is not supported. However, this can be done rather easily using various GUI automation tools. There are plenty of these, with some being simpler than others. The one I like the most is AutoIT, which allows you to create a keyboard and mouse automation script very easily. It’s also free!

To use AutoIT, you need to first download the script engine and install it on your UAG server. Download it from http://www.autoitscript.com/site/autoit/downloads/

AutoIT’s script files are text files with the extension AU3. To use it, simple create such a file, and use the various mouse and keyboard commands. For example, the set below is a partial automation for adding a TSPub application to UAG:

Mouseclick (“”,700,400)
Mouseclick (“”,600,620)
Mouseclick (“”,345,422)
Mouseclick (“”,600,620)
Send(“Access”)
Mouseclick (“”,600,620)
Mouseclick (“”,600,620)
Mouseclick (“”,345,260)
Send(“c:\temp\apps.tspub”)
Mouseclick (“”,600,620)

The geometrics of the screen vary by server, and application, of course, so you’ll have to come up with your coordinates to do these things. One easy way to figure out cursor location is by using a graphic application like PAINT.NET. Take a screenshot, and paste into the app, and then move the mouse to where you want. The program will show the coordinates at the bottom-left of the screen. You can also use http://www.freewarefiles.com/Megacows-Mouse-Coordinates-V_program_207.html , which shows this at the bottom of the screen.

Endpoint policies galore

Ben Ari — Tue, 02 Apr 2013 18:40:16 GMT

If you have a freshly installed UAG server in front of you, you might be considering which Endpoint policies to set for your applications. UAG comes with no less than 27 built-in predefined policies just for Windows computers (plus another 34 policies for Mac and Linux), but their naming doesn’t always indicate what they actually do. Technically, it’s quite easy to see it by opening each one and seeing, but I’d like to save you some of that time. Here are all the policies, and their default configuration:

Default Non Web Application Access

Default Privileged Endpoint

Default Session Access

Default Web Application Access

Default Web Application Download

Default Web Application Restricted Zone Access

Default Web Application Upload

Microsoft CRM 4 Upload

Microsoft CRM 4 Download

Microsoft CRM 4 Enhanced Security

Microsoft OWA 2010 Download

Microsoft OWA 2010 Upload

Microsoft Office SharePoint Portal Server 2003 Admin Zones

Microsoft Office SharePoint Portal Server 2003 Download

Microsoft Office SharePoint Portal Server 2003 Enhanced Security

Microsoft Office SharePoint Portal Server 2003 Upload Checkin

Microsoft Office SharePoint Server 2007 Download

Microsoft Office SharePoint Server 2007 Upload CheckIn

Microsoft Office SharePoint Server 2007 Enable Explorer View

Microsoft SharePoint Server 2010 Download

Microsoft SharePoint Server 2010 Upload

OWA Private Computer

Microsoft OWA 2007 Download

Microsoft OWA 2007 Upload

Always

Never

As you can see, most of the default policies do not actually have any requirements. They simply include the text “true”, which means that the policy will evaluate to “pass” no matter what the endpoint parameters are:

If you’re asking yourself what is the purpose of having the many policies, with so many of them having no requirements or being identical, the answer is that the policies come in groups, and every top-level group has to have the full set. For example, the Default Web Application policy has to have the four sub policies of Access, Upload, Download and Restricted zone. Even though the Access and Restricted Zone are identical and have no requirements, we still have to have them to complete the Default Web Application policy.