In This Section: |
Web connectivity issues can occur in Mobile Access Web Applications, while working with applications that use/require HTTP cookies. This is because some cookies usually forwarded by Microsoft Internet Explorer to a Web server are not forwarded by Mobile Access in the same scenario. To solve this, see sk31636.
Note - This section applies to Outlook Web Access-related issues occurring when working through Mobile Access without SSL Network Extender. |
If you have problems with Outlook Web Access (OWA) after deploying Mobile Access:
The following sections describe steps to take if you are experiencing problems using Outlook Web Access with Mobile Access.
HTTP and/or HTTPS packets must be able to reach Microsoft Exchange servers.
The following OWA features, platforms and product versions are not supported by Mobile Access:
(*) These products and platforms have not been tested with Mobile Access. However, Mobile Access has been successfully integrated in such environments.
Note - According to Microsoft, only the following OWA configuration supports non-IE browsers: OWA 2000 / 2003 running on Microsoft Exchange 2003 using "Outlook Web Access Basic" scheme. |
If you must utilize one of these features, use SSL Network Extender.
These sections describe issues related to browsing to OWA through Mobile Access.
Note - Examine your traffic logs for errors, to pinpoint the problem. |
After users log in to Mobile Access, and attempt to access an OWA application, they are required by OWA to provide authentication credentials.
Outlook Web Access has two authentication schemes: the regular HTTP-based authentication (HBA), which is the default, and Form-Based authentication (FBA). In addition, Mobile Access supports single sign-on (SSO) through HBA and FBA.
If an internal Web Server requests Integrated Windows Authentication (NTLM) or any other HTTP-based authentication, Mobile Access either displays a dialog box requesting login credentials, or tries to use the user's portal credentials, depending on the configuration of the Mobile Access Web application. HBA-related problems may result from the use of IIS web-based password management services.
IIS Web applications (such as Outlook Web Access) can be configured to use IIS Web-based password management services. These services make it possible for users to change their Windows NT passwords via a web server. These services use IIS HTR technology which is known to be vulnerable to attack, and can allow an attacker to run malicious code on the user system. Microsoft has long advocated that customers disable HTR on their Web servers, unless there is a business-critical need for the technology (Microsoft Security Bulletin MS02-028).
In keeping with the Microsoft recommendation, IPS protects against HTR exploits by default. If you wish to allow the use of the HTR mechanism, deactivate the "htr" worm pattern in the IPS General HTTP Worm Catcher protection. Install the Security policy from SmartDashboard after making these changes.
When troubleshooting, eliminate the possibility of Single Sign On problems by removing the OWA user credentials from the credentials list in the Mobile Access user portal.
The authorization mechanisms of Mobile Access allow administrators to grant access to various resources on a per-path, per-host and per-port basis. Mobile Access views Outlook Web Access as a Web application with special properties, connecting to a special Web server.
Authorization-related problems may result from:
User experiences may vary widely. However, most authorization failures will result in the following error message: Error: Access denied. The destination of your request has not been configured , or you do not have authorization access to it. (401).
Possible discrepancies may occur in the configuration of the OWA port, protocol or paths versus the setup of the corresponding Microsoft Exchange server.
OWA Service must be configured in accordance with the Microsoft Exchange server configuration. Otherwise, Mobile Access will not be able to authorize access to the application.
A user launches an OWA application, gets to the Form-Based Authentication (FBA) page and authenticates using his/her credentials. Subsequently, the user gets the "Access denied" page.
Cause: The Microsoft Exchange server side component (IIS or other) is configured to accept both HTTP and HTTPS traffic, whereas the Mobile Access OWA Web application is configured to authorize HTTP traffic only.
Explanation: The Form Based Authentication setting on the Microsoft Exchange server requires clients to use SSL, which means that some server-side component (be it IIS or other) must also accept SSL traffic. The following message is displayed to the Microsoft Exchange administrator upon FBA configuration:
Forms Based Authentication requires clients to use a SSL connection. If SSL encryption is not off-loaded to another source, complete the following steps:
This means that IIS is likely to be configured to work over SSL. However, in complex cases, such as SSL encryption being off-loaded to another source, and the IIS server itself allowing HTTP traffic, the Mobile Access administrator may not be aware of the need to authorize HTTPS traffic. As a result, discrepancies may occur.
Note - When FBA is in use, always set the OWA Web application to allow HTTPS traffic. |
Solution: Make sure that the OWA application configuration on the Mobile Access blade matches the configuration requirements of the Microsoft Exchange server.
Some companies access their OWA applications via intermediary websites. These intermediary websites may reference the OWA server by its IP(s) or host name(s). If, when defining access to the OWA server, the intermediary website is ignored, it can cause an authorization failure in Mobile Access.
User experiences may vary. In some cases the problem may result in a run-time JavaScript error or OWA becomes unresponsive (see Insufficient User Permissions for more information).
To troubleshoot such problems, test OWA operations without using any mediator (such as proxies, gateways or websites).
Mobile Access utilizes many built-in security features that screen inner networks from external threats. In addition, the Mobile Access endpoint security features protect the endpoint devices.
Occasionally, protection mechanisms may interfere with legitimate user activities. To eliminate this possibility, switch off all Web Intelligence protections during troubleshooting and the install the security policy.
User experiences may vary widely so they are not detailed here. Use the following steps to troubleshoot issues with security restrictions.
Performance issues may occur with OWA for the following reasons:
Generations of Debug and Trace logs (that are accessed via the console), and the storage of these log records when they grow too big, may considerably degrade the performance of the machine.
Note - Traffic and event logs (that are accessible using the SmartConsole clients) do not degrade the performance of Mobile Access. |
To get rid of these logs, turn off Debug logs, Trace logs and purge existing Debug logs and Trace logs.
To turn off Debug logs and Trace logs:
$CVPNDIR/conf/httpd.conf as follows:
LogLevel
parameter to emerg
.#
:#CvpnTraceLogMaxByte 10000000
#CvpnWsDebugSubjects ...
cvpnrestart
commandTo purge existing Debug logs and Trace logs:
httpd.log*
files located in $CVPNDIR/log
directorymod_ws.log
file located in $CVPNDIR/log
directorymod_ws_boa.log
file located in $CVPNDIR/log
directory$CVPNDIR/log/trace_log
directoryThe Outlook Web Access service can be configured to work over SSL inside secure networks. This option is normally used if the Microsoft Exchange server is configured to accept SSL-encrypted traffic (HTTPS).
This is the case if OWA is configured to use Form Based Authentication (FBA). Upon enabling FBA, the Exchange administrator is prompted by the IIS to change the Web application to work over SSL.
Configuring OWA to use SSL inside secure networks may cause degradation in performance and browsing experience. This is because, in such a topology, the amount of SSL negotiations grows considerably. SSL negotiations are very CPU-intensive, and therefore may cause performance degradation.
To solve this problem:
Introducing Mobile Access into an OWA topology allows users to connect to enterprise resources from remote locations.
Users connecting from remote locations may be subject to temporary or permanent network problems. The rate of packet loss in those networks can vary widely, as can the throughput.
Mobile Access inspects and modifies all HTTP traffic passing through the gateway. It takes time to process each particular packet of information.
There is therefore a difference in latency between connections passing through Mobile Access and those that do not. The overhead in absolute elapsed time is proportional to the amount of data passed through the network.
Latency and therefore performance problems when working through Mobile Access may be felt in particular by users with large numbers of emails, calendar events, task items and the like.
To solve this problem:
Minimize the latency overhead by increasing the performance of Mobile Access. You can do this by using a stronger machine.
SSL time-out problems can occur with Internet Explorer while working through Mobile Access. They can cause slowness and even temporary or permanent unresponsiveness of the browser.
To solve this problem:
See these Microsoft articles for more information:
To configure Mobile Access to work without keep-alive packets to specific locations:
LocationMatch
directives for each host used by the Web Application in question. All directives go in the $CVPNDIR/conf/includes/Main.virtualhost.conf
file, in the VirtualHost
section.For more information, see: http://httpd.apache.org/docs/2.0/mod/core.html#locationmatch
|
For example:
|
cpstop
and then cpstart
.When trying to save a file attachment with Outlook Web Access (OWA), Mobile Access adds the full path to the file name. For example, the file name appears something like:
|
To solve this, configure the Web Application to use Path Translation or Hostname Translation.
Note - This Citrix troubleshooting section pertains to Citrix-related issues occurring when working through Mobile Access without the use of SSL Network Extender. |
If you have issues with Citrix after the deployment of Mobile Access, see the section on Citrix Services and then try the troubleshooting checklist.
Follow the steps below to pinpoint the issue that may be causing trouble with Citrix.
Connectivity Issues
HTTP and/or HTTPS protocols must be traversable towards Web Interface servers.
ICA protocol must be traversable towards Presentation servers.
Configuration Issues
/etc/resolve.conf
file is configured correctly or change the value of vsxMountWithIPAddress
in $CVPNDIR/conf/cvpnd.C
from false
to true
. The file share will use the host ip for the mount instead of the hostname.To switch between the R77 and R80.10 File Sharing UI:
$CVPNDIR/htdocs/HFS/.include/conf/properties.ini
use.old.design=
Use these values:
Scenario: Push notifications are configured but users do not see push notification in Capsule Workspace.
Use the Push Notification Status Utility and Monitoring Push Notification Usage to troubleshoot Push Notifications with Mobile Access.
Also see sk109039.