Publishing IMAP/IMAPS on Microsoft UAG 2010 – UAG Support Boundary

Recently several users with BlackBerry phones approached me seeking to access their corporate email on their phones. Microsoft UAG doesn’t support Blackberry service however a workaround to this is using the IMAP to access and download their emails on their Blackberry phones.

Microsoft Highly recommend and Advice all UAG administrators to leave the TMG configuration (Installed by default on the UAG box) untouched. The TMG rules and configuration is controlled and configured by the UAG. The administrators should not use the TMG for publishing applications and other stuff. However there are some exceptions to this strict recommendation and its published in the UAG support Boundaries document. I also checked with Microsoft Support team and they confirmed the IMAP publishing based on this document.

UAG Support boundaries:  http://technet.microsoft.com/en-us/library/ee522953.aspx

As per the above mentioned document, Forefront TMG can be used to publish IMAP/IMAPS. Attached below is the section dealing with supported configuration on the TMG as per the above document.

Accordingly IMAP/IMAPS can be published normally from the TMG server (On UAG Box). This will be a simple Server Publishing Rule with the following settings:

1. Action - Allow
2. Traffic - IMAPS Server
3. From - Anywhere
4. To - Type You Exchange Server IP
5. Networks - External or DMZ (As per your setting)
6. Schedule  - Always

Its Highly recommended to use the IMAPS over the IMAP to ensure the traffic is encrypted.

Read More

Windows 7 Direct Access Client Troubleshooting – Part 1 – Client Transition Technologies

During the past few months I was heavily engaged with different DirectAccess implementations and passed by several interesting issues/problems. The Direct Access Wizard is so simple and normally things get working from the first time however sometimes things can go wrong.

In this article series I will try to go through several troubleshooting items moving from the basic commands to more advanced issues.
First of all we need to ensure that the Direct Access components on the Windows 7 client are running and functioning normally. The basic steps are as follows:

1. From the Start Menu - Right Click Computer Object – Properties – Device Manager – View (Show Hidden Devices) – Expand Network Adapters – Ensure the “IPHTTPSinterface” and “Teredo Tunneling Pseudo-Interface” are enabled.
2. From the Services, Check the “IP Helper” service startup type is Automatic and the status is up and running.
3. IPconfig /all to check which interfaces are up and which interfaces have IPV6 address.
4. Ensure the Machine is located outside the Corporate Network by running the following command:

          Netsh dnsclient show state

Which Transition Technology is my DA client using?

1.       If the Direct Access client has a public IPV4 address (Assigned to its Ethernet or Wireless NIC) and the IP Protocol 41 is allowed on Company Corporate Firewall/UAG/TMG then the client will connect using the 6to4 Transition Technology

            The Three main Netsh Commands that should be used for Troubleshooting are:

·         Netsh interface 6to4 show state (The State should be Default or Enabled, Disabled means the DA client will never bring 6to4 Interface up)

·         Netsh interface 6to4 show relay (This should list the First Consecutive public IPV4 address configured on the DA server)

·         Netsh interface 6to4 show interface (Displays the Configuration Information)

·         For detailed 6to4 Troubleshooting  http://technet.microsoft.com/en-us/library/ee844172(v=ws.10).aspx

2.       If the 6to4 Interface didn’t come up (For DA clients with public IPV4 Addresses) then the DA client will automatically fall back to IPHTTPS Interface connection.

                  The main Netsh command for IPHTTPS is:

·         Netsh interface httpstunnel show interfaces (This will list the IPHTTPS URL and the status were active means the Interface is up and running, deactivated mostly means the DA client is connected using other transition technology)

·         For detailed Direct access HTTPS troubleshooting  http://technet.microsoft.com/en-us/library/ee844126(v=ws.10).aspx

3.       If the DA client is behind a NAT device then it should connect using Teredo provided that Port 3544 (UDP) is enabled and allowed all the way to the DA Server

                  The main Netsh command used with Teredo is:

·         Netsh Interface Teredo show state (If the state is qualified then Teredo is functioning normally, otherwise there will be a problem mostly with the UDP port blocked)

·         For Detailed Teredo Troubleshooting  http://technet.microsoft.com/en-us/library/ee844188(v=ws.10).aspx

4.       If the Teredo didn’t work (Clients behind NAT) then the DA client will fall Automatically to the IPHTTPS option (Step 2)

Read More

Troubleshooting Direct Access Teredo connectivity on Forefront UAG 2010

I encountered a problem on one of my installations for DirectAccess where all the clients were able to connect to DirectAccess using HTTPS only. After several investigations and with the help of senior Microsoft Engineers we noticed that the Teredo IPV6 route is missing on the server. When the server is trying to respond to Teredo requests, it uses the default Route (6to4) instead of the server Teredo Adapter due to the following route entry:

To fix this issue you need to manually add the Teredo route as follows:

1. We need to obtain the Teredo Adapter interface index (IDX) from running the following elevated command on the UAG server “netsh int ipv6 show int”
2. Add the route manually (using the obtained IDX from the earlier step) as follows:

Read More

Certificate CRL and Delta CRL are not copied automatically to the HTTP Path

A common problem noted on several implementations of Active Directory Certificate Services is the CRL and Delta CRL copies to the HTTP Path.  By default Microsoft Enterprise CA only publishes CRL automatically to LDAP path defined in the CRL Distribution Point (CDP). Normally CA administrators could define CDP in many locations as LDAP and HTTP (Inetpub Folder). Since it’s only copied to LDAP, the HTTP location gets expired and the user would encounter this error.

The certificate will try to retrieve the CRL and Delta CRL from each defined location (LDAP and HTTP) when system check the revocation status of certificate. If it can get the CRL from one and only one of these locations then it will pass the revocation process and function normally even if the CRL is not copied to the HTTP location. However it will give the above Expired Status for CRL and Delta CRL HTTP Location.

To solve this issue you have two options:

1. Copy them manually from the CERTSRV folder to the Inetpub folder
2. Create a batch file to copy them automatically and add this batch file to the daily scheduled tasks.

The Batch file should be something like this

Xcopy c:\windows\system32\certsrv\CertEnroll\*.crl  C:\Intetpub\

Read More

Manual Install of UAG 2010/Remote App and RDS Portal Components

Microsoft UAG 2010 main functions are Application Publishing and Enhanced DirectAccess deployment. The Application publishing allows you to publish several applications on either HTTP or HTTPS trunk. Application publishing includes Web applications, Non-Web applications, Remote Desktop Services (RDS), RemoteApps and VPN services.

When accessing the UAG portal for the first time from your computer using one of the supported browsers (Please check the Client requirements and Supported browsers in http://technet.microsoft.com/en-us/library/dd920232.aspx) the user will be prompted to download and install the UAG endpoint components, these components are used in many things among them checking device (Endpoint detection), SSL tunneling……………etc. This installation is done once per computer.

Some clients have restricted Internet Explorer settings (Using Group Policies) that prevent them from installing MSI or EXE files from the Internet and they need to install the Endpoint components manually.

There are two types of clients that you need to install manually to fully utilize the UAG portal.

1.    UAG Client Components, these are available on the UAG server under

 C:\Program Files\Microsoft Forefront Unified Access Gateway\von\PortalHomePage

 

Several files are available under this location for each component or you can just take the WhlClientSetup-all.msi from this location and have your users install it manually (Of course they need to have admin rights on their computer). Make sure you are running the latest UAG version on your server. The current latest version is 4.0.1773.10110 http://support.microsoft.com/kb/2647899

 

When manually installing the WhlClientSetup-all.msi, the users will be given the choice for Typical installation or Custom Installation to pick specific components as per the below screenshot.

 

2.    Remote Desktop Services (RDS) and RemoteApp need the latest Remote Desktop Connection 7.0 client update for Remote Desktop Services (RDS) for Windows XP SP3, Windows Vista SP1/SP2 which can be downloaded from the following site  http://support.microsoft.com/kb/969084  

This RDC 7.0 client is already installed by default on Windows 7 systems. If you using Network Level Authentication (NLA) on the RDS servers then you need to check this article http://support.microsoft.com/kb/951608 since the NLA is disabled on XP service pack 3.

 

Once both components (UAG and RDS) are installed manually, the user will be prompted to approve running the ActiveX and adding the portal site to the browser trusted sites.

Read More

DNS64 Not Healthy after Applying UAG SP1 Update 1 Rollup 1

After applying the latest Rollup 1 for UAG SP1 Update 1 released on Jan 12, 2012 I noticed that the DNS64 is unhealthy under the Direct Access Monitor/Current status as shown in the below figure.

I did a reboot to the UAG/Direct Access server (although it’s not required by the fix) however the DNS64 component still showed unhealthy. I disabled/enabled direct access as follows:

1.     Disabled Direct Access

2.     Saved/Activated the configuration

3.     Enabled Direct Access

4.     GPupdate /force on the UAG Server

5.     Applied the policy

6.     Activated the configuration

After that it all worked fine. I am not sure about the reason (Will try to check with Microsoft Team) however that workaround fixed my problem.

Read More

Publishing Direct Access Web Monitor on UAG Portal

Recently I tried publishing the UAG Web Monitor on my External HTTPS Web Portal, the UAG web monitor is very useful monitoring and reporting web application which gives you the ability to view different UAG sessions, applications, Direct Access and the UAG event viewer.

When the UAG Web Monitor is published on the UAG Portal Trunk everything works fine except the Direct Access section (Current Status and Active Sessions). When you try to open the Current Status or Active Sessions you get the below error screen.

This issue looks like a bug with the UAG and I opened a support case with Microsoft and they are considering a permanent fix. Currently to fix this issue you need to add 5 rules as follows:

1. Go to the Trunk Configuration - Configure Trunk Settings - Configure - URL set.
2. Copy any Web Monitor default rule and paste it 5 times
3. Modify/Add the URL in the 5 rules as follows:
1. /damonitor\.asp
2. /damonitorcurrentstatus\.asp
3. /damonitorcurrentstatusrefresh\.asp
4. /damonitoractivesessions\.asp
5. /damonitoractivesessionsrefresh\.asp
4. Save- Activate and this should fix the issue.

Here is a Screen shot of how these rules should be added and modified.



Read More