Article ID: 2288900 - View products that this article applies to.
These release notes address late-breaking issues that are related to Microsoft Forefront Unified Access Gateway (UAG) 2010. Before you install Forefront Unified Access Gateway (UAG), you must read the information that is contained in this document. This article contains the following information about this update:
This article describes Update 2 for Forefront UAG 2010 and provides installation instructions. Update 2 for Forefront UAG 2010 provides the following features:
Introduction to product evaluation that applies to Forefront UAG
Update informationThe following file is available for download from the Microsoft Download Center:
Download the Forefront Unified Access Gateway (UAG) Update 2 package now.
Collapse this imageExpand this image
For more information about how to download Microsoft support files, click the following article number to view the article in the Microsoft Knowledge Base:
119591Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help prevent any unauthorized changes to the file.
(http://support.microsoft.com/kb/119591/ )How to obtain Microsoft support files from online services
PrerequisitesThis update is cumulative and can be applied to appliances, servers, or virtual machines that are running the following versions of UAG 2010:
981323For more information about UAG Update 1 Rollup 1 hotfix package, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/981323/ )Description of Update 1 for Unified Access Gateway 2010
(http://support.microsoft.com/kb/981932/ )Description of the Rollup 1 hotfix package for Unified Access Gateway 2010 Update 1
Installation NotesOrder of installation when a UAG server array is in use
Restart requirementIn non-array scenarios, you do not have to restart the computer after you apply this update package. You must activate the UAG configuration after you install the update package. Please note that performing the UAG activation will terminate any existing SSL Application Tunneling connections to the UAG server.
In array scenarios restart is required. The array installation steps above are required for successful deployment of the update when using an array, failure to follow these steps can cause corruption of the array and loss of the configuration.
Hotfix replacement informationThis hotfix does not replace a previously released hotfix.
Uninstallation informationTo uninstall this update, use one of the following methods:
File informationThe English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time item in Control Panel.
Collapse this tableExpand this table
Fixed issues that are included in this updateThis update fixes the following issues that were not previously documented in a Microsoft Knowledge Base article.
Administrators require granular access control for their Secure Socket Tunneling Protocol (SSTP) virtual private network (VPN) clients. However, configuring SSTP on UAG creates a single access rule that gives VPN client’s access to the whole Internal Network.
According to the following text from http://technet.microsoft.com/en-us/library/ee522953.aspx, it is supported to use the Threat Management Gateway (TMG) console to create rules that enable granular access control for SSTP VPN Access:
"Creating access rules using the Forefront TMG Management console, for the purpose of limiting users, groups, and networks for granular access when deploying Forefront UAG for VPN remote network access."
However, when administrators create access rules to limit user access, these rules are removed or moved to the bottom of the access policy after UAG activation. This means that the default rule takes precedence and the configured granular control is lost.
This issues is caused by a limitation in the design of the integration between UAG and the dynamically generated rules that are deployed to TMG during UAG activation.
Manual modification of TMG rules to support granular access control as described on TechNet is depreciated (and is no longer supported after the installation of UAG Update 2) in favor of explicit support of granular access control in the UAG Management console.
UAG administrators can now explicitly enable access to particular internal network addresses to SSTP VPN users who are members of particular Active Directory groups. UAG administrators should use the new User Groups tab of the SSL Network Tunneling Configuration dialog box to define granular IP VPN access policy which consists of a set of access rules. Every rule defines a set of internal network IP addresses and IP address ranges that members of a particular Active Directory group can access while connected to SSTP VPN.
Microsoft Virtual Desktop Infrastructure (VDI) support in UAG is not fully implemented.
Because of a misleading UAG UI, problematic configurations and an inability to support multi-authorization in different resources during implementation prevent VDI from working correctly.
We have made a design change to update the UAG UI and support the Personal Desktop scenario of VDI with a more robust implementation. The Pooled Desktop scenario of VDI was not implemented and may be implemented in a future update of UAG.
The UAG Client Component for SSL Application Tunneling (Socket Forwarder) is not supported on 64-bit version of Windows 7 and 64-bit version of Windows Vista.
This is the designed behavior of the UAG client components before the release of UAG Update 2.
We have made a design change to address the following scenario:
There are wide set of non-web applications that use UAG Socket Forwarding / Application Tunneling as a publishing method. For example, such applications are Citrix XenApps and Presentation Server 4.5, and they both run as ActiveX applications in browser. Before this update, because of technical limitations, we disallow deployment of those publishing methods on 64-bit version of client operating systems. Therefore, the same published application that uses those methods may be accessed from 32-bit version of client operating systemss instead of from 64-bit operating systems.
The change made for this scenario is to provide a method of deployment for the Socket Forwarding (SF) client components on 64-bit version of Windows client operating systems to enable opening of tunneled applications. The limitations of this implementation are as follows:
You cannot access Citrix XenApps 5.0 that is published with UAG from a client computer that is running a 64-bit version of Windows Vista or Window 7.
This is the designed behavior of the UAG client components before the release of UAG Update 2.
Refer to the “Resolution” section of Issue 3 for detailed information.
When you try to create or edit an endpoint policy, the “McAfee Total Protection” policy appears two times on the list. If you select the second “McAfee Total Protection” policy, you receive an error message that resembles the following:
source line could not be located
This issue occurs because the %UAG installation directory%\von\Conf\PolicyDefinitions.xml file contains two entries that have the same title and ID.
The double entry issue is resolved by removing the second record from the PolicyDefinitions.xml file.
When you access a resource that is published by UAG, clients receive an error "An unknown error occurred while processing the certificate" in the browser. Also, the UAG administrator may see in UAG server debug logs that SEC_I_CONTINUE_NEEDED is returned during the SSL negotiation step "Handshake Confirm State." Following that step the debug logs will show that the /InternalSite/InternalError.asp page is returned to the client together with error code 37. Error Code 37 is the error message "An unknown error occurred while processing the certificate."
The existing SSL mechanism does not correctly handli several scenarios when it performs SSL handshake with a back-end server published through UAG. The streaming nature of SSL creates a complicated scenario with a possibility of receiving either insufficient data or reading too much information during the handshake. In this scenario, InitializeSecurityContext reports that you have passed additional data that must be saved for use in the future (presumably after you read more data across the wire).
The handshake algorithm is extended to support additional streaming cases and scenarios.
When you access a published HTTPS application through UAG, the user receives error 37: "An unknown error occurred while processing the certificate." An administrator who is doing debug logging (that includes the SSLBOX_BASE trace ) while the user is accessing the application will see the following error message:
ERROR:Failed to initialize security context. Returned error: 0x90320.
InitializeSecurityContext return SEC_INCOMPLETE_CREDENTIALS – Schannel requires client certificate credentials
The back-end application server is configured to ask for client certificate credentials during the SSL negotiation stage. Before this update such functionality was not supported. Therefore, the negotiation failed with an error.
There are two possible scenarios where the back-end server is asking for client certificate credentials:
In some rare cases client computers that have UAG Client Components installed on them receive a "uagqecsvc" event ID 85 log message written to the Windows Event logs every minute when that client is communicating with a UAG Server. Although this a false alarm, this fills up the client event logs making it difficult for administrators or the helpdesk from spotting real events in the client’s Windows Event logs. These messages will always be displayed on the client every minute if that client connects to an IAG server.
Event ID: 85
Description: The Microsoft Forefront UAG Quarantine Enforcement Client component cannot initialize the enforcement client callback HRESULT value: 0x8027000E. This issue may occur if security policies do not enable the component.
There may also be another related event in the client event logs.
Although this issue is not directly related to UAG or to UAG deployments, it is possible that with some deployments users who have the UAG client components installed on them will access both IAG and UAG servers.
Event ID: 16
Log Name: Application
Description: The Microsoft Forefront UAG Quarantine Enforcement Client component cannot retrieve the status of the Network Access Protection (NAP) Agent service. System error 1115: A system shutdown is in progress. (0x45b). When the Microsoft Forefront UAG Quarantine Enforcement Client component starts, it attempts to query settings of the NAP agent service.
UAG Client Components have a component service "uagqecsvc" with a display name of "Microsoft Forefront UAG Quarantine Enforcement Client" which queries endpoint health status by using NAP and reports the status back to the NAP module on UAG. In some rare cases this issue will be seen in UAG deployments as the service re-tries repeatedly to bind to the UAG server. The bind will run in loop with a minute time-out until it can connect.
Additionally starting with IAG Service Pack 2 Update 3, the UAG Client Components were ported to IAG. Therefore the uagqecsvc service is also installed on client computers that connect to any IAG server that has Service Pack 2 Update 3 client components. Because NAP endpoint detection functionality does not exist in IAG, the client that has the UAG components installed on them will continue to try to connect to the UAG NAP service every minute, in the process generating the previously mentioned log messaged in the Windows Event logs.
In the earlier versions of the Client Components the default time-out for retries to communicate with the UAG NAP detection agent was set to a minute, it is been changed in UAG Update 2 to one hour. For administrators who want to modify this value a way to manually define the time-out on the client is provided.
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756Computer users or administrators can manually define on any client computer the time-out in milliseconds. To do this, follow these steps:
(http://support.microsoft.com/kb/322756/ )How to back up and restore the registry in Windows
You (UAG administrator) have UAG installed on a server that is running a localized APAC language version of Windows 2008 R2. When you try to create a trunk on UAG, you receive an error message and the creating of trunk is stopped.
For example, blank windows, unexpected error messages, or frequent MMC crashes occur when you try to create a trunk on UAG.
This issue occurs because of incorrect manipulations of system resources. These incorrect manipulations lead to a failure when you run UAG on some non-Western language versions of operating systems (Korean/Japanese/Chinese).
The code that is responsible for accessing these system resources is fixed.
Endpoint Session Cleanup Component does not start to execute after a restart of an endpoint. Additionally, an explorer window opens that points to client components folder after a restart.
Before a restart, Endpoint Session Cleanup Component writes a registry value under the “Run” key. This registry value allows Windows to start Endpoint Session Cleanup Component automatically after a restart. However, this path value of registry key is an executable path that contains spaces. Therefore, a failure occurs.
The path value that points to the Attachment Wiper executable that is written under the “Run” key is now written as a quoted string to prevent any failures.
When you try to access the language setting options in Exchange Server 2007 Outlook Web Application (OWA) that are published via UAG, the following error message will be sent to the client.
You have attempted to access a restricted URL.
This issue occurs because the out of box template for Exchange Server 2007 OWA does not have a RuleSet entry for the URL"/owa/languageselection.aspx". The UAG RuleSet mechanism does not allow the access to any URL that is not in the white list.
A new rule is added for Exchange 2007 OWA publishing to allow the access to this URL resource. In this case, the new rule " ExchangePub2007_Rule36 " allows the access to the URL "/owa/languageselection.aspx ".
When an user tries to access a UAG site, or tries to access a bookmarked path within the application rather than the UAG login path, the user receives a 500 Internal Server error and is unable to access the site.
Note The UAG site uses ADFS for authentication and directly requests a published application.
When UAG is configured to use ADFS for authentication, several redirects occur between the Security Token Service (STS) and the UAG internal site. If the redirectes are not done in the expected manner, UAG returns errors. When a user tries to directly access a published resource instead of the portal site, the re-routing process is broken. Therefore, internal server error occurs.
This issue is fixed in this update.
When an administrator is configuring an ActiveDirectory type authentication repository, the administrator cannot set the group nesting value to "unlimited". According to UAG specification, the value of the group nesting field could be blank. However, when the field is blank and the configuration is saved and activated, the value is set back to "0" unexpectedly.
Note The UAG MMC needs to be closed and re-opened in order to get the value of "0" visible. As UAG specification, "0" means that there is no group nesting. Therefore, group nesting does not work as expected.
This issue occurs because the correct value for the group nesting field cannot be stored in the configuration. Therefore, the correct value cannot be applied to both the GUI and the authentication functions.
The value in the configuration is now properly stored and updated when the group nesting value is deleted from the GUI Additionally, the value is properly applied to the authentication functions.
Note Microsoft recommends setting the value to be the lowest number that is required for the authorization in UAG. You can set the value to higher than 2 levels of nesting due to the potential delay and the required resources. If higher than 2 levels are required for a deployment, you must test the impact of these changes before the system is deployed in production. In extreme cases, these settings can cause both the UAG server and any DCs that are being used for authentication by UAG to crash because of high resource demands.
When you try to close the Network connector (NC) server configuration window after you enable the NC server, you may receive the following error message:
Wrong Network Connector parameters, invalid segment address
The SSL Network Tunneling service can be used only when the physical network adapters have MAC addresses that begin with "00".
The SSL Network Tunneling service can be used even though the physical network adapters have MAC addresses that begin with "00".
UAG was released with only partial support for Citrix XenApp 5.
When you want to publish Citrix without errors, they were obligated to follow the steps that are provided in the following Microsoft website:
Introduction to how to publish Citrix XenApp 5.x with UAG 2010
This issue occurs because the support for Citrix is broken.
The steps that are provided in the above to properly publish Citrix XenApp 5.0 are now included in this update.
The AV product "Trend Micro OfficeScan Anti-Virus" or "Trend Micro PC-Cillin Anti-Virus" is selected from the GUI. In this case, when you create a policy and then apply the policy to an application, you receive the following error message during the activation:
Source Line could not be located
This issue occurs because the policy syntax validation algorithm misses dependencies that are required by these particular policies.
The dependencies that are required by these policies are added to policy syntax validation algorithm after you install this update.
Known issues with Arrays and Network Load Balancing (NLB)
Article ID: 2288900 - Last Review: November 4, 2010 - Revision: 1.0
Contact us for more help