faisals notes

Windows Mobile Phone 7 Office Hub

Faisal Hussain — Thu, 07 Feb 2013 13:54:00 GMT

There is a feature in Windows Phone 7 hidden in Office settings called "office hub". this feature allows user to connect to corporate SharePoint server externally through UAG 2010. I noticed that its not been documented well as how to set this up and what's required.

Windows Mobile Phone site has documented few steps about setting up the Office hub for external users but it doesn't tell you anything more that that. You can review this here:

http://www.windowsphone.com/en-us/how-to/wp7/office/use-office-sharepoint-workspace-mobile

However in terms of setting up things on the UAG side of things , what you need to do it is setup typical SharePoint publishing app or use your existing one and ensure that on SharePoint 2010 server you do setup correct AAM configuration to consume the zones that user through UAG when using external URL will hit and SharePoint should be redirected to the correct site. I am not going to document all this as there is a lot fo resource now available but from old days three blog posts on setting up AAM on SharePoint and configuring UAG server with correct host name are still my favourite that were written by my colleague Meir in the days of IAG. its a three part tutorial that is a great reference to sort AAM configuration and setting up DNS and UAG SharePoint settings. Please review the following blog posts for this :

Part 1:

http://blogs.technet.com/b/edgeaccessblog/archive/2008/10/12/publishing-sharepoint-with-iag-2007-part-1-what-is-sharepoint-aam-and-why-do-we-need-it.aspx

Part 2:

http://blogs.technet.com/b/edgeaccessblog/archive/2008/10/13/publishing-sharepoint-with-iag-2007-part-2-common-questions.aspx

Part 3:

http://blogs.technet.com/b/edgeaccessblog/archive/2008/10/13/publishing-sharepoint-with-iag-2007-part-3-sharepoint-topologies.aspx

and finally TechNet UAG SharePoint publishing guide should you need more details:

http://technet.microsoft.com/en-us/library/dd857299

Once External user is now able to access SharePoint correctly from Mobile Phone browser and you are able to launch the office document hosted on SharePoint office library , it means SharePoint AAM and UAG SharePoint application is configured correctly.

Now moving forward we intend to open the office document directly from Windows Mobile 7 Office hub feature. In Windows Phone 7 in Office hub --> click the UAG tab and put the SharePoint portal AAM name that you have setup on UAG <documentation link provided above> .

On the backend ensure that SharePoint 2010 is setup for Forms based authentication.

Please review SharePoint 2010 documentation on how to do this:

First go through this article just to understand as what you are about to do on SharePoint side of things :

http://blogs.technet.com/b/mahesm/archive/2010/04/07/configure-forms-based-authentication-fba-with-sharepoint-2010.aspx

Now the better way of achieving this is:

http://blogs.msdn.com/b/sridhara/archive/2010/01/07/setting-up-fba-claims-in-sharepoint-2010-with-active-directory-membership-provider.aspx

Once SharePoint is setup correctly with FBA , Office hub will work correctly through UAG 2010.

IOS and Windows Phone devices merging mailboxes for Active Sync Users via UAG when device has multiple profiles

Faisal Hussain — Tue, 27 Nov 2012 11:36:00 GMT

Hi, its me again, got busy working on some other access stuff , didn't get much time to share interesting scenarios with you guys in a while. Anyhow I am back and here is one scenario that came up few times and I think its probably causing some deployment concerns around having IOS or windows phone devices having ability to create multiple profiles on the device itself for same user when he wants to access his two separate mailboxes (Exchange Active Sync) via UAG.

The challenge is if user is having multiple profiles on his mobile device while synchronizing his inbox , it is possible that user might come across inbox of other profile that he is not supposed to view...!. Users might notice different behaviours , some times users see inbox of the second profile while phone is synchronizing using Exchange active sync , at times users have experienced that once synchronization is done they start getting view of the correct inbox but question is why this is happening ?.

This problem is down to the behaviour of session cookie handling by UAG. It depends on various factors as well for instance if there is a load balancer sitting in front of UAG , it could fiddle with session cookies. I have also seen issues when load balancer configured to do "connection pooling" causes funny behaviours , so better test Connection Pooling before enabling it when LB is siting in front of UAG.

Anyways in UAG SP2 release we fixed the session cookie behaviour to make each session unique. For this specific scenario explained above and with UAG SP2 installed you need to make a registry tweak as shown below , that will allow users having multiple profiles on the same mobile device (IOS or Windows phone ) synchronize to there respective mailbox without any session overlap problems for Exchange Active Sync.

The fix is as follows:

1. On the UAG server, please create a new DWORD registry value, as follows:

// This should cause UAG to not base its session management on the UAG session cookie ("NLSession…"), for ExchangeActiveSync.

SOFTWARE\WhaleCom\e-Gap\Von\UrlFilter\SuppressEASSessionCookie

2. Assign it a value of ‘1’

3. Activate the UAG configuration

Once this registry is in place on top of UAG SP2 the above scenario will work.

KB2649422 is available for RDG "maximum allowed connections" issue on UAG

Faisal Hussain — Thu, 12 Jan 2012 14:18:00 GMT

I came across an issue on UAG Remote Desktop Gateway hitting connection limit to MAX few months ago. End users were not able to access the Remote Desktop becase UAG was disconecting them with an error message :

"Your computer can't connect to the remote computer because the Remote Desktop Gateway server reached its maximum allowed connections. Try reconnecting later or contact your network administrator for assistance."

I started dubgging this and ended up working with Remote Desktop Gateway support in Microsoft and we found a bug in this features implementation. The great news is we have a hotfix available now and KB2649422 is available to install on UAG server if you run in to the above mentioned issue.

For more details please review the Knowledge base article:

http://support.microsoft.com/kb/2649422

hope this helps.

Remote desktop or RemoteApps break when Session broker is behind UAG Server

Faisal Hussain — Tue, 13 Sep 2011 16:24:00 GMT

For quite sometime I saw this question poping up on forums and cases as why UAG breaks the RDP traffic if Session broker or connection broker is sitting behind it to loadbalance the farm. I started investigating and took me some to establish foot print of this problem. UAG 2010 SP1 will fail to connect to backend RDP farm using Remote Desktop or Remote Apps if Session Broker is sitting behind the UAG (RDG gateway). You will see the following error on UAG Server event logs:

The following error is logged on the UAG server:

Description:
The user "Alfa\uagservice", on client computer "127.0.0.1", did not meet resource
authorization policy requirements and was therefore not authorized to resource
"10.1.2.194". The following error occurred: "23002".

I took some ETL tracing on Windows 2008 R2 and then based on it I took a memory dump and debugged this when this configuration was in action in memory of the server and set break point when policy function was called. I worked with Remote Desktop Escalation Engineer in Microsoft support (a colleague basically) to help through RD part of the code and noticed RAP function call made to RDG was expecting a policy to be applied using the IP address. When I looked at UAG configuration, I realized that due to not having this documented we are all just giving in FQDN of the RD Farm servers.

Remote Access Policy failure will occur if Session Broker is sitting behind the UAG (RDG) because RAP needs the IP address to communicate to the farm.

To resolve this issue here is the configuration change thats required:

When you publish RemoteApps / RemoteDesktop please add RD Connection broker on UAG server wizard or under Server Settings tab on the application (RemoteApp or RemoteDesktop), you need to add Connection broker name on top of the list and then session hosts FQDN plus their IP addresses as well in this stage of the wizard or Server tab of the applications.

<<Screenshot below>>

With this configuration in place UAG 2010/SP1 should be able to work across RD Farm if session broker is sitting behind the UAG (which is also the RDP Gateway).

Hope this helps.

Citirx XenApp WI 5.4 loops with 302 redirect through UAG

Faisal Hussain — Mon, 20 Jun 2011 15:25:00 GMT

I came across quite few scnerio's recently where I have seen WI 5.4 loops in 302 redirect issue through reverse proxies and in my case its UAG. I debugged the HTTP stream to understand the Citirx WI 5.4 behaviour and to me it looked bit different in flow as compared to previous WI 5.x builds. I tried to tweak the same fix that I provided previously for WI 5.x through UAG but this time it wasnt helping {Grrr..}. After investing some time in lab it all came down to authentication flow thats changed in WI 5.4.

In simple previously Citirx was first installing the Citirx web client and then authenitcating the end user accessing XenApp landing page, now with WI 5.4 they first do authN and then install the client component, which makes sense from WI point fo view as they do have security reservations.

Debugging showed that we are getting in 302 redirect loop at "/Citrix/.*/auth/silentDetection.aspx. I reversed the flow and narrowed down to problem where certain cookies that are signed by UAG are not being interpreted by XenApp. So what I had to do is to write a custom SRA file as follows:

In SRA file <WhlFiltSecureRemote_HTTPS.xml> under cookie handling tag this is what you need to do:

<?xml version="1.0"?>

<WHLFILTSECUREREMOTE ver="2.2">
<COOKIES_HANDLING>
  <SERVER>
   <SERVER_NAME mask="">.*</SERVER_NAME>
   <Set-Cookie remove="">
    <NAME>WINGSession</NAME>
    <Path remove="true">/Citrix/XenApp</Path>
   </Set-Cookie>
   <Set-Cookie remove="">
    <NAME>WIUser</NAME>
    <Path remove="true">/Citrix/XenApp</Path>
   </Set-Cookie>
   <Set-Cookie remove="">
    <NAME>WIClientInfo</NAME>
    <Path remove="true">/Citrix/XenApp</Path>
   </Set-Cookie>
  </SERVER>
  <SERVER>
                          <SERVER_NAME mask="">.*</SERVER_NAME>
               <Set-Cookie>
                    <NAME>WINGSession</NAME>
                    <Secure remove="true"/>
               </Set-Cookie>
               <Set-Cookie>
                     <NAME>WIUser</NAME>
                     <Secure remove="true"/>
               </Set-Cookie>
                <Set-Cookie>
                     <NAME>WINGDevice</NAME>
                     <Secure remove="true"/>
               </Set-Cookie>
                <Set-Cookie>
                      <NAME>WIAuthId</NAME>
                      <Secure remove="true"/>
               </Set-Cookie>
               <Set-Cookie>
                      <NAME>WIClientInfo</NAME>
                       <Secure remove="true"/>
                </Set-Cookie>
  </SERVER>
</COOKIES_HANDLING>
</WHLFILTSECUREREMOTE>

===============

The above will fix the looping problem of WI 5.4 through UAG.

You need to copy this file to ...\Microsoft Forefront Unified Access Gateway\Von\Conf\Websites\<your trunk name> \Conf\CustomUpdate

PS: Dont copy /Paste this from here as it might break the XML Syntax and to test that out once you write this file just load it in Internet Explorer to see if its healthy and not broken. Also feel free to tweak the files as you would like as its a very generic configuration I am sharing here.

I would also suggest to use the WhiFiltAppWrap_HTTPS.xml to avoid other known Citirx issues in previous WI 5.x builts. You need to copy this file along with the other in same location <...\Microsoft Forefront Unified Access Gateway\Von\Conf\Websites\<your trunk name> \Conf\CustomUpdate> .

===============

<?xml version="1.0"?>

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

<MANIPULATION>
<MANIPULATION_PER_APPLICATION>
    <APPLICATION_TYPE>CitrixXenApp5</APPLICATION_TYPE>
    
    <DATA_CHANGE ee="1">
    <URL case_sensitive="false">/Citrix/.*/auth/silentDetection.aspx</URL>
    
    <SAR>
        <SEARCH encoding="base64">ZnVuY3Rpb24gc2V0SXRlbUluQ29va2llKG5hbWUsIHZhbHVlKQ==</SEARCH>
        <REPLACE encoding="base64">
ICAgICAgICAgICAgICAgICAgICB3aGxJc1NlY3VyZSA9ICJGQUxTRSI7DQogICAgICAgICAgZnVuY3Rpb24gY2hlY2tXSExSV1MoKQ0KICAgICAgICAgIHsNCiAgICAgICAgICB2YXIgd2hsVVJMID0gbG9jYXRpb24uaHJlZjsNCiAgICAgICAgICBpbmRleDEgPSB3aGxVUkwuaW5kZXhPZigiLy8iKTsNCiAgICAgICAgICBpbmRleDIgPSB3aGxVUkwuaW5kZXhPZigiLyIsaW5kZXgxKzIpOw0KICAgICAgICAgIGluZGV4MyA9IHdobFVSTC5pbmRleE9mKCIvIixpbmRleDIrMSk7DQogICAgICAgICAgaW5kZXg0ID0gd2hsVVJMLmluZGV4T2YoIi8iLGluZGV4MysxKTsNCiAgICAgICAgICAvL2dldCB0aGUgd2hsIGluZGljYXRvciBmb3IgYSBzZWN1cmUvIG5vbiBzZWN1cmUgUldTDQogICAgICAgICAgd2hsVVJMID0gd2hsVVJMLnN1YnN0cmluZyhpbmRleDQtMSxpbmRleDQpOw0KICAgICAgICAgIC8vbWVhbnMgdGhlIFJXUyBpcyBzZWN1cmVkDQogICAgICAgICAgaWYgKHdobFVSTCA9PSAiMSIpd2hsSXNTZWN1cmUgPSAiVFJVRSI7DQogICAgICAgICAgfQ0KICAgICAgICAgIGNoZWNrV0hMUldTKCk7DQogICAgICAgICAgZnVuY3Rpb24gc2V0SXRlbUluQ29va2llKG5hbWUsIHZhbHVlKQ==
        </REPLACE>
      </SAR>
      
      <SAR>
        <SEARCH encoding="base64">dmFyIGlzU2VjdXJlID0gKGxvY2F0aW9uLnByb3RvY29sLnRvTG93ZXJDYXNlKCkgPT0gJ2h0dHBzOicpOw==</SEARCH>
        <REPLACE encoding="base64">dmFyIGlzU2VjdXJlID0gd2hsSXNTZWN1cmU7</REPLACE>
      </SAR>
      
      <SAR>
        <SEARCH encoding="base64">aWYgKHdpbmRvdy5sb2NhdGlvbi5wcm90b2NvbC50b0xvd2VyQ2FzZSgpID09ICJodHRwczoiKQ==</SEARCH>
        <REPLACE encoding="base64">aWYgKHdobElzU2VjdXJlPT0iVFJVRSIp</REPLACE>
      </SAR>
      
      
      <SAR>
        <SEARCH encoding="base64">Y29va2llID0gY29va2llICsgIjsgcGF0aD0=</SEARCH>
        <REPLACE encoding="base64">Ly8gY29va2llID0gY29va2llICsgIjsgcGF0aD0=</REPLACE>
      </SAR>
    </DATA_CHANGE>
</MANIPULATION_PER_APPLICATION>
</MANIPULATION>

</APP_WRAP>

==============

Once both the WhlFiltSecureRemote_HTTPS.xml and WhlFiltAppWrap_HTTPS.xml files are in place WI 5.4 should work fine. Please note if you already have custom files in place for other apps on your trunk then carefully merge this in those exisiting files.

PS: Some of the users seeing the Cookie Session error once redirect problem is resolved. So the solution for that one is just adding two more cookies to the above proposed SRA file so here we go:

         <SERVER_NAME mask="">.*</SERVER_NAME>
               <Set-Cookie>
                    <NAME>WINGSession</NAME>
                    <Secure remove="true"/>
               </Set-Cookie>
               <Set-Cookie>
                     <NAME>WIUser</NAME>
                     <Secure remove="true"/>
               </Set-Cookie>
                <Set-Cookie>
                     <NAME>WINGDevice</NAME>
                     <Secure remove="true"/>
               </Set-Cookie>
                <Set-Cookie>
                      <NAME>WIAuthId</NAME>
                      <Secure remove="true"/>
               </Set-Cookie>
               <Set-Cookie>
                      <NAME>WIClientInfo</NAME>
                       <Secure remove="true"/>
                </Set-Cookie>
</SERVER>
</COOKIES_HANDLING>

Hope this helps.

PS: this post is written considering a very generic and almost XenApp default configuraiton through UAG. Feel free to tweak the XML files as per your requirements.

For custom Paths issue review Ben's blog as he got a nice post up there http://blogs.technet.com/b/ben/archive/2011/10/05/issues-with-citrix-5-4.aspx

How to Configure UAG to Publish Your Private Certificate Revocation List

Faisal Hussain — Fri, 20 May 2011 11:37:13 GMT

Quite a common question and here is a nice article published by my colleagues:

http://blogs.technet.com/b/tomshinder/archive/2010/08/03/how-to-configure-uag-to-publish-your-private-certificate-revocation-list.aspx

UAG Socket Forwarder on Windows 7x64 and RDP Tunnel

Faisal Hussain — Thu, 27 Jan 2011 00:29:00 GMT

I got a case few days ago about UAG SP2 Socket forwarder not working and fails to launch the mstsc on windows 7 x64 bit client. I wasnt sure about it because as we know windows 7 x64 SF support got enabled with UAG update 2 release http://support.microsoft.com/kb/2288900 .

So the problem scenario was as follows:

When you publish RDP tunnel application on UAG portal and on template if you change the Tunnel application setting from port forwarding to Socket forwarding , mstsc fails to launch.

UAG out of box RDP Windows XP/Vista Tunnel application template looks like :

While working with this issue in lab I noticed that when we enable SF on RDP tunnel App the application calls mstsc.exe from %systemRoot%\system32 directory and that is causing a problem. It should be called from %SystemRoot%\SysWoW64 directory as we need to launch 32 bit app .

If you go to %SystemRoot%\system32 and rename mstsc.exe to mstsc.exe.bak or any random extension and then go close the browser and launch this app again after new logon session, it will launch the tunnel successfully because this will now invoke mstsc.exe from SysWoW64 directory.

Note:

To rename the mstsc in system32 you might be prompted for permissions:

Browse to %SystemRoot%\System32

Right click mstsc.exe and choose Properties

Go to the Security tab

Click Advanced

Go to the Owner tab

Click Edit

From the “Change owner to:” list, choose your user name

Click OK

Go to the Permissions tab

Click Change Permissions…

Click Add

Enter your user name and click OK

Tick the box in the Allow column for Full control

Click OK

A Windows Security warning will come up; click Yes to proceed

Click OK

So to me it looks like the two instances of mstsc.exe onWindows 7 x64 , one in %SytemRoot%\system32 and second in %SytemRoot%\sysWoW64 is causing the confusion.

Another approach is to publish a generic enhanced application for 64 bit clients which launches the MSTSC from %SystemRoot%\SysWoW64

UAG SSTP Split Tunnel

Faisal Hussain — Wed, 26 Jan 2011 23:38:10 GMT

Network Connector in IAG used to have two different types of tunneling mode, split tunnel and non split tunnel you can find details here if not familiar with these options http://technet.microsoft.com/en-us/library/dd278013.aspx . When Microsoft shipped UAG , it came up with windows 7 as an endpoint supporting full VPN tunnelling platform, however windows 7 came up with a new type of VPN tunnel called SSTP , here is some good reference to SSTP overview http://blogs.technet.com/b/rrasblog/archive/2007/01/10/how-sstp-based-vpn-connection-works.aspx or visit TechNet centre for details. SSTP architecture is very different from Network Connector VPN type that is still their in UAG but only for backward compatability. With SSTP Windows 7 only allows non split tunnelling by default, which means all VPN traffic goes through corporate gateway.

Being in support I have been asked this question as how to enable split tunneling in windows 7 using SSTP through UAG portal. Ofcourse UAG product group clearly states that SSTP is non split tunnelling bydefault so it means split tunnelling is not possible from UAG portal.Anyhow I got a case few weeks ago where one of our premier customer had this requirement to enable split tunnelling using SSTP. I knew the answer that its not possible and not supported, however I started fiddling with UAG SSTP in my lab environment. Digging through Source code and testing various scenarios I managed to find the way to enable split tunnel. Let me walk you through this failrly simple but unsupported configuration. Let me also set your expectations first, this is a client side solution , its not elegant so you need to have a mechanism of dropping the modified dialer file on all windows 7 machines that would be launching SSTP split tunnel through portal and this is not a supported solution from Microsoft UAG support. if you are happy with all disclaimers then lets proceed further :).

Steps to configure SSTP Split tunneling :

1- Sstp.pbk is part of \InternalSite\Win32ActiveX\WhlClntProxy.cab. so once you deploy UAG client components on Windows 7 endpoint this pbk file gets dropped with them. Now extract the SSTP.pbk file from UAG client components.

2- Click on properties and click the Networking button and select Networking tab:

3- Click TCP/IPV4 and hit properties button:

4- Click the Advance button and under IPSettings tab uncheck the "Use default gateway on remote network" option:

5- now copy this SSTP.pbk file back to UAG client components directory on windows 7 machine.

6- Launch the SSTP application from UAG portal now and check your routing table .

hope this helps ;-)

UAG client components tracing options

Faisal Hussain — Thu, 30 Sep 2010 11:55:10 GMT

If you would like to enable tracing for UAG client side to trace end point detection components bit in case of any problem then here are the options you need to enable on UAG and IAG update 3:

Browse to \Program Files\Microsoft Forefront UAG\EndPoint Components\3.1.0Run trace.hta

Scroll to the bottom of the window. If it says ‘Logging is currently ON’ then click ‘Stop’

Add ticks to all the tickboxes (Error Warn, Info, Func & Noise) for these components:

· CompMgr_BASE

· Detector_BASE

· Security_CheckSite

· SoftToken

· TCPDump

· VistaUtils

· SSLVPN_BASE

· IPC_BASE

· LSP_BASE

· NSP_BASE

Scroll to the bottom of the window and click ‘Go’

Reproduce the problem

Click ‘Stop’ in trace.hta

Send the Forefront_UAG.bin file from c:\windows\debug\ to CSS for troubleshooting.

NOTE: some times due to UAC on Win 7 you might need to launch Trace.hta through elevated cmd under local admin context.

Common issues when publishing RemoteApp and Remote Desktop through UAG

Faisal Hussain — Thu, 15 Jul 2010 16:07:00 GMT

I have started seeing people asking various questions about RemoteApp or Remote Desktop (User defined ) or Remote desktop (Pre-defined) issues. Its quite a complex combo of technologiese through RDG (UAG) and involves various bits and pieces. If you do see a problem in any of the the above scnerios then its important to first isolate where the problem is. Is it RDS (backend TS server), is it session broker , is it DNS Round Robin for RDS farm etc, so first isolate that before you jump to UAG.

If RDS bit looks fine then lets focus on RDG (UAG) and see what we can see there.

Extract the RDP part from the TSPub file and try to run it from the UAG machine. If it doesn’t work it might be that:

There are problems with the TS server

Bad connectivity to this server (TMG, Networking, etc)

If step 1 looks good then:

Check the Remote Desktop Services status in its console:

RDG Common Problems:

· RDG service is down

· It’s certificate is tampered

· It’s IIS binding is removed

Get the screenshot of the error and the OS version , MSTSC client version from where you are testing.

Also ensure that Active X control is not disabled in IE as we need RDS Active X control on end point to initiate the connection.

If After clicking the remoteApp you get the following error:

"This computer can't connect to the remote computer because an error occurred on the remote computer that you want to connect to. Contact your network administrator."

The above error points to RD client not supporting RDP client verion 6.1.7600.

If you get the following error popup:

"Your computer cant connect to the remote computer because no certificate was configured to use at the Remote Desktop Gateway server. Contact your network administrator for assistance".

The above error points to RDG certificate is not valid so open the RDG console and change the certificate.

You also need to ensure that TS settings are not changed after RDG is configured . if you have changed anything on TS then on UAG (RDG) you need to update the corresponding settings. Another reason as why you cant login is due to access policy that you fail to meet.

Please ensure that manual URL replacement setting on UAG is removed so ensure its there.

"/rcp/rpcproxy.dll\?localhost.*" ,<without quotes>

One more common reason I came across is:

When using a certificate (i.e. the site’s certificate), not derived from a trusted CA on the client’s side (e.g. a self-signed certificate or a certificate from internal CRL). The browser warns but permits to continue; the MSTSC just does not accept such a signature. A resolution: the user should update the trusted root CA’s list accordingly.

Bad certificates are the main cause of the failures. You might reach to this stage and when you try to launch the App , you see the following prompt before launch:

Once launched you might the see the following pop up :

"This computer cant verify the identity of RD Gateway www.abc.com. It's not safe to connect to server that cant't be identified. Contact your network administrator for assistance".

So if you come across the above two popups then fix the cert , they indicate bad certificate issue and RemoteApp will never launch.

If you have configured your RemoteApp for single Sign on (SSO) then ensure the end user allows the RemoteApp activeX control else functionality wont work on end point.

this is the interface on UAg server where you set up the RemoteApp for SSO:

Windows XP/Vista might require upgrading the RDP client by visiting the following KB article http://support.microsoft.com/kb/969084 .

If you suspect RD host connectivity the worth trying to verify the TMG settings if rule allows connectivity to RD host. also try accessing from RDG server it sefl to ensure you dont run in to connectiviy problems.

1- Session Monitor will give you details about each session.

2- Event viewer on both client server would be good to look at.

3- there is no client side tracing , you can use fiddler or httpwatch to see the RDP traffic but its windows Native implementation of RDP. UAG doesnt have a code involved on this end so RDP support could help on any RDP issues.

4- On UAG server side you can enable the following tracing for Microsoft support to assist:

Please launch UAG Bits tracing hta file from c:\Program Files\Microsoft Forefront UAG\common\bin\tracing --> launch <trace.hta>

here are the components you probably want to turn tracing on for: UAGRDPSVC, WHLTSGAUTH, WHLTSGCONF, WHLFILT_CORE, WHLFILTSECUREREMOTE_BASE, WHLGENLIB, WHLGENLIB_GENERAL

Please enable all levels Error,Warn,Info,Func,Noise for all these components.

Hit the Go button when ready to repro.

Stop the tracing as soon as issue is reproduced.

Give it 30 seconds before you collect the bin file from c:\Windows \debug.

IAG 2007 drops connectivity intermitently due to network pool limit

Faisal Hussain — Wed, 14 Jul 2010 10:47:59 GMT

I came across an interesting case recently on IAG 2007 where symptoms were bit different but the rootcause apperently seems to be the same.

The symptoms I came across are as follows:

In this scnerio the number of users getting connected to IAG server is around 250 plus and IAG seems to be dropping connections intermittently. So the users who connected earlier in the day before we reached the limit of 250 connections , they stay on the server and when it reaches the ~ > 250 users , it starts dropping. This is the experince I have seen on portal trunk.

Another scenario that I came across was on Active Synch trunk where number of users were 1000 and then reaching the ~ >1000 users on this trunk IAG starts dropping random connections and intermittently. Intermittent issues are quite tricky to repro and debug and they are very time consuming to dientify as problem is not there always and you have to wait for the right oppertunity. I looked through different layers of the product to understand as if its a perfomrance limit, network monitor /wireshark doesnt give much information on it, even took ISA level tracing to no avail. Rebooting the server ractifies the issue temporarily but issue bounces back when these trunks reach those numbers.

After some more indepth investigation and taking the debug trace of the IAG filter I noticed the major IAG filter construct throwing the following error:

CExtECBQueue: ERROR: Unable to allocate an additional 1 entities, this would max out the pool. Current status: Total = 501, Available = 0, Used = 501

After doing some debugging around this error and source code reviews I figured out what does this construct is grumbling about.

here is the interface on IAG console that controls this setting:

So now this could explain the number 501 from the pool. My second cusotmer had this to 1000 for his Active Synch trunk and he was crossing the 1000 limit. Interesting bit is on average browser (User -Agent) usually establishes two TCP connections so 250 users mulitply by 2.

To fix this behaviour I changed the value to double the number of users that are expected to connect to this trunk. It could vary depending on the User-Agent. You also need to do Start --. run --> cmd --> iisrest <ENTER> and then apply the change to IAG configuration by hitting the apply button on the console.

to me these sort of issues pop up due to lack of planning and testing before product is deployed. Defaults are never acceptable but such settings should be kept under review always with more traffic influx. in UAG I have noticed this setting has moved from this interface to Advance trunk <Genreal> tab and its set to 10000 by default.

You dont have to accpet the limits I am referring here as they are unique in each environment but if you run in to similar issue ensure you do see the excpetion in filter trace before you tweak the limits I referred as they are very specific.

IAG update roll back and Whale Backup

Faisal Hussain — Thu, 01 Apr 2010 13:10:00 GMT

In case you run in to an regression or instable behavior after upgrading to a new built , then follow these steps to roll back and get on the previous built immediately.

1- Under C:\Whale-Com\e-Gap\patchdb\unistall-last.bat

2- Just run this bat file and it will uninstall the update for instance if you want to uninstall just Update 3.

3- Wait till the installer confirms that its rolled back successfully

4- Reboot.

Also please ensure that you take full back up of IAG server before upgrading it to new built / latest built by using whlbackup utility only and not just Configuration export from whale console.

Its documented on TechNet --> http://technet.microsoft.com/en-us/library/dd278145.aspx

Publishing File access through UAG 2010

Faisal Hussain — Fri, 26 Mar 2010 21:52:00 GMT

Setting up File access through UAG 2010 is pretty straight forward. However I have noticed that when administrator starts configuring File access , he usually gets the following error.

Refer to TechNet article on how to set it up and ensure all services listed in the article are started

http://technet.microsoft.com/en-us/library/dd897168.aspx

No rule on TMG is required as it already has the rule out of box.

Just ensuring that NeBIOS traffic UDP ports 137,138 and 139 is not blocked by any firewall in between your UAG server and DC. And to be on safe side on command prompt type net use * \\machinename\C$ from UAg server to ensure that you can map the share on port 445.

Here is my lab setup:

My hyper-v servers are in same subnet. Here is the UAG server File Access console that I published my win 2008 DC on backend with a test Share.

And here is the screenshot of my lab win XP machine on internet that is accessing file share successfully.

So to recap these are the steps I followed to setup my File Access:

1- I joined my UAG server to Domain (it’s a prereq)

2- Enabled NetBIOS over TCP/IP on UAG , DC internal NICs.

3- Make sure you have Computer Browser , DTC and Workstation service started on UAG and DC.

4- I created Test Share on my windows 2008 DC

5- From my UAG , tested to access the share directly to ensure that no NetBIOS traffic is blocked anywhere. Its working.

6- Then went to UAG File Access menu and configured it (Note: you need to wait as it takes time till File Access populates the server end)

7- Then I published the File Access application on UAG portal.

8- Finally I logged in to portal from Win XP/SP3 client from internet and there you go.

MOSS 2007 and Office docs Authentication handling through IAG

Faisal Hussain — Tue, 22 Dec 2009 10:49:00 GMT

IAG / UAG team blog has detailed articles on publishing MOSS through IAG and different scnerios. From support perspective people come across some interesting scenarios and this is where I get involved. For instance a scenario where a user logs on to IAG portal and then launches the MOSS portal after SSO , clicks on a word 2007 document should be able to launch Office doc without reauthentication. However customers call in and report that instead when user clicks on a word, excel doc on MOSS liberary, end user is presented with IAG login page which is kind of merged inside the word doc (so a kind of distorted UI). Now if SSO is setup ideally this should not happen. Question is why this is happening?

In simple Office launches its User Agent for authentication and is not the same User agent as was your browser. So when end user clicks on the word doc on MOSS portal through IAG portal , she is being challenged again as the exisiting credentials that were presented earlier while logging on to IAG are not used any more. Technically you know what I am saying but its the cookie that is not persistant and it doesnt know whats going on and what this user agent is?. IAg is a reverse proxy so droping a persistant cookie for ever is not a great idea. So to handle this situation product group came up with the following option on advance trunk UI (authentication tab).

On IAG portal advance trunk , under Authenitcation tab there is a check box that resolves this issue.

Enable this option on the trunk and Apply configuration to IAG trunk.

This should give end user SSO experince end to end and technicalities are handled pretty smoothly out of box.

IAG Network Connector Configuration Prerequisites

Faisal Hussain — Wed, 09 Dec 2009 13:39:00 GMT

Network connector configuration is pretty much documented in IAG user guides. I dont want to reinvent the wheel here but have noticed that it tends to take a lot of effort to make the NC work when split tuneling is configured. Apperently the network connector UI explains that what you need to do but at times it doesnt give the desired results. Non Split tunnel setup is straight forward as the traffic is routed through corp gateway but it gets tricky if traffic has to be routed through the client itself (split tunnel). The confusion is only due to lack of documentation for setting this up. I will share with you the steps that are prerequisites in case you are wondering why split tunnel setup is not working though you have followed all the steps as per TechNet documentation.

Infrastructure setup

On ISA the only change needed to make Network Connector work properly is to configure the “Internal” networks in ISA to include the Internal and Whale Network Connector adapters. In Windows, persistent routes need to be created for every internal network or external networks that need to be accessible to clients and or routed via the corporate network. Those persistent routes should have a gateway set to the IAG’s internal network’s gateway. Those changes need to be made manually as IAG doesnt set this up for you. Single NIC configuration of IAG is an unsupported scenario, and will break Network Connector.

There are two types of pools and each type of pool has unique configuration and details.

Corporate IP Address Pool

Corporate IP Address pool are IP addresses that belong to subnet that the network connector adapter binding is configured to (usually the internal network, NEVER the external interface).

For example: if the corporate segment is configured to 192.168.0.0/255.255.248.0, an example of a "corporate pool" would be 192.168.6.2-192.168.6.200. Ensure that you exclude the specified range of IPs from your internal Dynamic Host Configuration Protocol (DHCP) server. IAG cannot use a DHCP server in order to assign IP addresses to remote VPN clients. Persistent routes MUST be configured on IAG of the corporate networks that IAG will communicate with.

Private IP Address Pool

Private IP Address pools are IP addresses that do not belong to the subnet that the network connector adapter binding is configured to.

For example: If the corporate segment is configured to 192.168.0.0/255.255.248.0, "private pool" would be 10.16.16.2-10.16.16.200. Ensure that you exclude the specified range of IPs from your internal Dynamic Host Configuration Protocol (DHCP) server. IAG cannot use a DHCP server in order to assign IP addresses to remote VPN clients.

If the Internet access level, defined in the Access Control tab, is set to Split Tunneling or No Internet Access, in order to enable access to the corporate network, you must add the corporate network as an additional network on the Additional Networks tab. If you do not add the corporate network, remote clients are granted access only to other clients and cannot access the corporate network.

Some router on the corporate network MUST be configured to route the private pool's subnet to the IP address that the network connector adapter binding is configured to usually this is the internal network adapter’s IP. In addition, if your corporate firewall (not the ISA firewall on IAG) filters traffic on its internal interface, configure the firewall to allow bi-directional traffic between the private pool subnet and the corporate subnet defined in the Network Segment tab. In order to enable access to the wide area network (WAN) or Internet, configure the firewall to allow bidirectional traffic between the private pool subnet and the WAN, and define the private pool permissions. In addition, if you are using Network Address Translation (NAT) in order to enable access to the WAN or Internet, define the subnet of the private pool as an additional internal interface.

NOTE: IAG assigns the first IP address from the defined pool to the IAG NC interface, so ensure that the defined IP address pool is sufficient for your needs and consists of enough IP addresses for remote VPN clients. Additionally, IP addresses ending with zero or 255 are not used for IP assignment. For example: if you define the pool 192.168.0.0-192.168.0.9, the network connector server will be able to support up to eight concurrent clients, since 192.168.0.0 will not be used, and 192.168.0.1 will be used by the server itself.

so to recap what I said above , please ensure in order to setup Split tunneling you need to have some basic routing infrastructure ready before you do anyting on IAG interface and these steps are not documented in the guides.

1- ensure that all static routes are setup on IAG server so traffic could route to correct subnets.

2- Traceroute should work and show all the hops.

3- any hop that blocks the traffic including a router / Firewall should allow bi-directional traffic to static routes defined.

4- Once routing is setup correctly, then load ISA server console on IAG appliance.

5- On ISA console --> Configuration --> networks --> Internal --> double click --> Edit --> Addresses tab --> add Whale Internal Adapter to this network.

6- On IAG NC server , setup the IP pool that belongs to Corporate pool.

Select Split tunneling on Access Control Tab in IAG NC server since you want traffic to be routed through client.

Then verified IP range of the subnets in additional Networks.

Closed the NC config.

7- Finally load the IAG console , edit the NC application that is published --> select the Server Settings --> Argument option and change the IP as follows:

Change Frm for example :

-srv %localip%:%localport% -egap 192.168.66.22

To:

-srv %localip%:%localport% -egap NATed IP

Windows 7, IE 8 and 64 bit client side support

Faisal Hussain — Thu, 19 Nov 2009 13:00:00 GMT

As I understand based on information I have about windows 7 support would be fully available for UAG (Unified Application Gateway) only. There are two Win7 clients, 32bits and 64bits and the answers are different per platform:

For 32 bit clients: SSL Network Tunneling (Network Connector) won’t work (Win7 + UAG offers instead SSTP) and Terminal Services (RDP) won’t work (TSG will). Please also note that SSL Application Tunneling will only work in socket forwarding (no port forwarding is supported).

For 64 bit clients: in addition to the above, SSL Application Tunneling and Socket Forwarding won’t work, TSG will only work on 32bit IE that supports ActiveX.

As far as I know for IAG there would only be support for 32 bit clients and is expected with update 3 that will be released end of Jan. IE 8 is fully supported with IAG 3.7 SP2 Update 2 only.

For more clarification please refer to UAG forum:

http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/9a4c45fe-a780-4e07-85a9-93b9aa6cf651

Publishing Terminal Services for MAC OS X clients through IAG

Faisal Hussain — Thu, 29 Oct 2009 11:53:00 GMT

Mac clients accessing the terminal services through IAG is possible and IAG does have in built support for publishing MAC OSX apps. I think the best approach here is to publish using a Generic Mac OS X Carbon App. Alternatively, you can simply tunnel port 3389 using a Generic Client App and instruct the end user to launch the local RDP app after the tunnel is up.

PS: Please note only MAC OS 10.3 and later, JRE version 1.5 onwards and Safari version 3 and later is supported through IAG 3.7 Sp2 Update 2.

First try with Generic Mac OS X Carbon App:

On your trunk à select the Generic Mac OS X Carbon App wizard.

Generic Mac OS X Carbon App

Server Settings:

Generic Mac OS X Carbon App (hosts required)

Note

This application is supported on Mac OS X operating systems.

So on the wizard when you click next à

Use this screen to configure the application server.

Server Hostname

Hostname of the application server. Use the effective hostname as defined in the DNS.

Port

Port number of the application server.

Executable

Executable that runs the application.

Note

If the installation path of the application is not a default path, you have to add the path in this field. For example: /Applications/MSRDP/Remote Desktop Connection.

Arguments

Address of the remote server, for applications that receive the address as an argument in the command line.

Tip

Use variables in this field.

Launch Automatically on Start

When this check box is selected, if a user is authorized to access the application, the application is automatically launched when the user accesses the portal.

This should launch the terminal services for MAC OS X clients.

If the above doesn’t help then you can take a different approach and use Generic Client type Application wizard and just publish the port 3389.

Generic Client type Application

Server Settings:

Generic Client App

Note

This application is supported on Microsoft Windows, Mac OS X, and Linux operating systems.

When you click next in the wizard à

Use this screen to configure the application server.

Server

Define the server, using a hostname or an IP address. If you use a hostname, use the effective hostname as defined in the DNS.

Note

To enable multi-platform support and support on endpoint computers where the Socket Forwarding component is not installed, enter a hostname in this field, and not an IP address.

Port

Port number of the application server.

Launch Automatically on Start

When this check box is selected, if a user is authorized to access the application, the application is automatically launched when the user accesses the portal.

PS: the idea is to launch the tunnel first before user launches the TS.

JRE Client side detection troubleshooting

Faisal Hussain — Tue, 20 Oct 2009 13:38:00 GMT

IAG 3.7 SP2 supports JRE compliant browsers and non windows machines to be scanned for complaince by IAG server when end user access the IAG portal. To enable client side detection IAG uses the JRE and certain extention to current client side detection model but utilizing the Java Applet.

IAG supports after SP2 the following non-windows operating systems as well. Supported OS includes:

RPM Based Linux Distributions (RedHat Enterprise 4 and 5, Fedora Core 5 and up)
Debian Linux Distributions (Debian 4 and up, Ubuntu 6.10 and up)

Mac OS X version 10.3 and later

On the browser side IAG also supports following browsers inaddition to Internet Explorer:

Firefox version 2 and later on Windows, Linux and Mac
Safari version 3 and later on Windows and Mac

Java engine has to be JRE 1.5.* and later

At times when using any of the above browsers the end user could get in to a situation where you do see that end point detection is failing. Now to understand what could be a potential problem , as a starter first ensure that you do run the supported version of the OS and browser as per the list provided above. If you do then dump the JRE console logs output to a text file to ensure that you do have to ensure that JRE is correct and error free setup. If you are not sure on how to dump the JRE log, its the Jave icon on the lower right hand side of the task bar showing that JRE is avaialble and running for the client. If you double click on it then you do get the JRE console and that should give you some information like this:

Java Plug-in 1.6.0_16
Using JRE version 1.6.0_16-b01 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\Marc
----------------------------------------------------
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
l:   dump classloader list
m:   print memory usage
o:   trigger logging
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
x:   clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------

JavaDetectorApplet: checking Java version
JavaDetectorApplet: reported version is 1.6.0_16
JavaDetectorApplet: version is accepted
Opening log at C:\Documents and Settings\Marc\IAG Remote Access Agent/abccontosocom/abc1\log\applet_10-10-2009.Log
********* Applet started. *********
Version: 3.7.261.0
Reading all input args
Starting...
OS detected: Windows 2003 : Setting Report Server: https://abc.contoso.com/InternalSite/SetPolicy.asp?site_name=abc&secure=1
Setting cookie:
<<cookie removed>>
Cookie set.
init
Exec type: INIT started
Installing agent files
Installing file C:\Documents and Settings\Marc\IAG Remote Access Agent/abccontosocom/abc1\agent_win_helper.jar
File already exists, checking server cache.
Date on local file is: 28-08-2009 19:02:36
Server sent response code: 200
1157415 bytes copied ...
Verifying agent signature.
Extracting...
extractJar( C:\Documents and Settings\Marc\IAG Remote Access Agent/abccontosocom/abc1\agent_win_helper.jar , C:\Documents and Settings\Marc\IAG Remote Access Agent/abccontosocom/abc1\ )
Checking for proxy on route to: https://abc.contoso.com/InternalSite/SetPolicy.asp?site_name=abc&secure=1
Proxy test: proxy detected proxy:80
Checking if proxy requires authentication
Running AW: C:\Documents and Settings\Marc\IAG Remote Access Agent/abccontosocom/abc1\AttachmentWiper.exe -x https://abc.contoso.com/InternalSite/Conf/abc1AWDirs.ini -r proxy:80 na -o
Exit value: -1
Checking to see if we should remove old log files.
Launching Proxy with "C:\Documents and Settings\Marc\IAG Remote Access Agent/abccontosocom/abc1\ProxyProcess_Win.exe" init "IAG Remote Access Agent/abccontosocom/abc1" -a " -d abc.contoso.com -c https://abc.contoso.com/InternalSite/Conf/abc1AWDirs.ini -t 1 -1" -e /InternalSite/CustomUpdate/ABCDomainCheck.vbs;/InternalSite/CustomUpdate/Mac_Check.vbs;/InternalSite/WhaleDetection.vbs -p "C:\Documents and Settings\Marc\IAG Remote Access Agent/abccontosocom/abc1\log\" -j 1.6.0_16 -m abc.contoso.com -o proxy:80 na

This console should give a lot of information as why could the dection is being failed. Next step is to ensure that the brwoser is enabled for Jave and Java applets to execute. Most of the time I have seen custom scrip is being introduced and that fails only, so the rational approach is to get rid of the custom scrip first and ensure that end point detection works fine without any script as default.

Webmonitor is always a friend and it could show you the failing URLs and policies or possible detection falure causes.

If your OS is windoes but browser is non IE then just for troublshooting you can load IE and confirm if it works with IE or not, if it works with IE then you know its just a broswer side problem and then you should look around broswer related aspect. At times for Java client detection the %userprofile%\IAG Remote Access Agent\<hostname_without_dots>\<trunk_name>\log is useful to point towards any problem. So basically you would get hold of three logs , Attahment Wiper log , if you are running into AW issue. Then you have the applet log if its java applet issue and finally you would see the proxy log , if any proxy is fiddling inthe middle for applet execution.

Last but not least if you still dont understand whats going on then only for testing disable the IAG InternalSite builtin rule for .jar files check on the advance trunk --> rule set tab to see if things work without the rule. if the rule is breaking it then the issue is narrowed down to the rule.

AD type repository gives a unexpected errors for GC search

Faisal Hussain — Fri, 16 Oct 2009 09:38:00 GMT

I came across a very strange issue few days ago with a customer. They deployed IAG appliances at a site with identical configuration but one of the appliance started showing weird issues. Few users were able to logon to the portal and once number of session reached a certain level then they started seeing the following symptoms:

1- IAG portal login works fine for few users and when the number of sessions increases, they do see the error message from /InternalSite/ “Web Site too busy”. this error was presneted to the end user.

2- Then you will start getting all kind of weird unrelated error messages from Trunk, authentication, sessions, Global catalogue errors etc.

3- Network stack will show too much traffic back and forth from AD.

4- You could see GC is found correctly but tracings will show various failures to identify GC on the network.

5- It has nothing to do with permissions as I have found.

6- The major indication for the problem is when you open your AD type repository and click OK to accept the configuration you have done for it, you should see the following error:

So what we found is if NetBIOS over TCP/IP is enabled on the Internal NIC of IAG is then you will start seeing all of the above.

Disable the NetBIOS over TCP/IP from the Internal NIC of IAG and things will get back to normal.

SWF Flash Content type rewrite via IAG

Faisal Hussain — Sun, 11 Oct 2009 08:42:00 GMT

I have seen this question being asked several times that if its possible to rewrite the SWF/ Flash content type via IAG?. Now the question is whats so different with SWF / Flash content type ?. Lets first understand what is the issue. IAG cannot rewrtie the absolute URL's within the swf / flash content type because its a complied bytecode. IAG doesnt know how to handle these SWF URL's and therefore you cant tell the IAG engine to HAT the URL's if you are publishing a flash based application via IAG.

Important concept to understand is about the URLs within the Flash app. If the URL is just an absolute path the WhlHAT cookie should take care of it without any issues or if you think its not rewriting the URL path then you can use the "manual reroute" to handle under advance trunk --> application access portal tab on IAG console and that will rewrite the signed part of the HAT URL.

However if within Flash app there are full URL's and they are pointing to internal servers then IAG cannot rewrite these URL's. to handle this situation there is another solution via IAG called Hat via Proxy. “HAT via Proxy” solution is implemented by publishing a dedicated application that you add to the portal --> the Enhanced HAT application in the Wizard when you setup the application.

So when you publish the application HAT via Proxy its pretty much tunneling the SSL traffic but "enhanced HAT" (aka Hat Via Proxy) instead of actually fully processing the request over the tunnel and all subsequent clicks/link that are not HATed, sends back a redirect and asks the browser to re-request the link in a signed format (IAG HAT format), and hence not needing the generic tunnel except for that first request.This is how swf/ flash embeded URL's are actually rewritten by IAG by intercepting the complied byte code and SWF based flash URLs work as expected.

Publishing Java Applet Enabled Applications through IAG

Faisal Hussain — Sun, 11 Oct 2009 08:12:00 GMT

Most of the times I have been asked on how to publish a Java applet enabled application through IAG. Now IAG is an application proxy that intercepts the traffic to and from the backend webserver , now if you invoke an applet within your web application then considering Java applets compiled byte code and its own sandbox , IAG cant intercept applet communication to its dedicated java servlet. So the java applet web app isnt handled by IAG filter easily and it cannot rewrites the URL as expected . Now if you run in this kind of a situation then IAG does have a type of application wizard called "Generic Client Application - multiple server type" its pretty staright forward to handle the scenario as long as both the servers (webserver and the applet servlet) are on your network. If servlet is on internet then the story is bit more complicated.

here are the steps that should work to publish the Java applet:

Isolate the Java applet publishing from the web application using a GCA (Generic ClientApplication).
Verify the servlet URL and Port on the JRE console on your desktop.
Publish the applet using GCA (multi server) template wizard as a seperate application.
Ensure the Java applet works as expected via the tunnel.
After the Java applet is functional, create a web-based application (main app i.e Java applet depenedant) in the IAG portal that will allow the URL to be auto-launched on the client, for both IE and Firefox browsers.

PS: Servlet URL need to be bypassing the proxy or put it on exception list. If you want to ensure that proxy is not fiddling gthen on the client ping to servlet URL and you should see its resolving to 127.0.0.x.

So the entire flow goes like this:

servlet is launched with GCA tunnel and by passes the proxy and since its the prerequsite of the main web application when you publish the application as a web app, it will launch successfully. Any Java applet control within the app should work seemlessly.

From security perspective its important to understand that Java applets run in their own sandbox so its your responsibility to ensure that you verify that the serlet is what this applet should be communicating with and basically using IAG we are simply tunneling it and not rewriting anything in the sandbox.

Unicode or double Byte calendar breaks via IAG

Faisal Hussain — Mon, 10 Aug 2009 15:28:00 GMT

When you publish German or any Double Byte language Exchange through IAG , you might see the following error when accessing the OWA Calender page:

<snip>

Webpage error details

Message: Access is denied to: https://ac.cdf.local/whalecom81249048fa132e49dd8c0987588586c1e640607057125a3787b/whalecom1/exchweb/6.5.6944.0/controls/ctrl_message.ht

Line: 0

Char: 0

Code: 0

URI: https://xy2.bcd.at/whalecom81249048fa132e49dd8c0987588586c1e640607057125a3787b/whalecom1/exchange/Administrator/Kalender/?Cmd=new&mm=7&dd=29&yy=2009

Message: Access is denied to: https://ac.cdf.local/whalecom81249048fa132e49dd8c0987588586c1e640607057125a3787/whalecom1/exchweb/6.5.6944.0/controls/ctrl_datepicker.htc

Line: 0

Char: 0

Code: 0

URI: https://xy2.bcd.at/whalecom81249048fa132e49dd8c0987588586c1e640607057125a3787/whalecom1/exchange/Administrator/Kalender/?Cmd=new&mm=7&dd=29&yy=2009

Message: Object doesn't support this property or method

Line: 268

Char: 2

Code: 0

URI: https://xy2.bcd.at/whalecom81249048fa132e49dd8c0987588586c1e640607057125a3787/whalecom1/exchweb/6.5.6944.0/controls/ctrl_message.js

</snip>

After investigating the following workaround has been found to resolve this error and it actually works fine. But the correct way is not to modify the actual WhlFiltSecureRemote_HTTPS.xml but create a CustomUpdateable file. Anyways just to give you an idea here is it how the above error is fixed:

C:\Whale-Com\e-Gap\von\conf\SRATemplates\WhlFiltSecureRemote_HTTPS.xml

Ø and then try these steps and let me know the results:

Please open this file in notepad (ensure you don’t break it as its xml file> à

C:\Whale-Com\e-Gap\von\conf\SRATemplates\WhlFiltSecureRemote_HTTPS.xml

and and very carefully only change the following :

<APPLICATION_TYPE>OWA2003SP1</APPLICATION_TYPE>

<URL>/exchange/.*/Inbox/.*\.EML\?cmd=preview</URL>

<URL>.*(Calendar|Contacts|Tasks)</URL>

</APPLICATION>

<APPLICATION_TYPE>OWA2003SP1</APPLICATION_TYPE>

<URL>/exchange/.*/Inbox/.*\.EML\?cmd=preview</URL>

<URL>.*(Kalender|Kontakte|Aufgaben)</URL>

<URL>.*(Calendar|Contacts|Tasks)</URL>

</APPLICATION>

// if you notice that I have added English Calendar after German and by doing this you ensure that in multiligual environment if someone has english OWA then that should also work with German or any other european langauges.

IAG ActiveSynch Trunk troubleshooting

Faisal Hussain — Tue, 16 Jun 2009 18:27:00 GMT

Most of the time IAG administrator doesnt know how to proceed and where to look at in order to understand the ActiveSynch issues via IAG. I would encourage to start from the basics and ensure that trunk configuration looks good, then verify the CAS configuration , ensure mobile device is setup properly, ensure no routing or firewall issues are the stumbling blocks in relation to your problems. Always search for an error in event logs on IAG, web monitor , CAS server events on Exhcnage Server and some times you might like to have a look at IIS server on CAS or IAG appliance just in case. However if nothing is helpful from this troubleshooting flow then you might feel like diving deep inside the IAG ActiveSynch trunk. Please note always looking at tracing might not be helpful if you ignore basics, so my approach is always to stick to basics and then start going deep under step by step.

The best approach is to enable tracing on Windows Mobile Device insynch with IAG Active Synch trunk and reproduce the issue. It will show you what and where the problem is coming from. This tracing is not for any specific IAG/Active Synch issue , basically its generic approach for advance troublshooting if you are convinced that the trunk is setup correctly and something is happening in the background.

PS; please disable this tracing the moment you collect data from problem repro.

Step by step instruction to carry out in repro :

1. Create a new Active Sync trunk.

· For any reference Part 1 will help to create trunk http://blogs.technet.com/edgeaccessblog/archive/2008/07/24/publishing-microsoft-activesync-through-iag-2007-part-1-of-2.aspx

2. Verify the repository is set in the InternalSite\ActiveSyncLogin.asp

3. Leave all defaults expect the following:

· Application Properties: Enable learn mode.

4. Advanced Trunk, Session tab:

· Change inactive timeout to 900.

5. Uncheck, Automatic Scheduled Logoff...

6. Activate.

7. Test with a single clean smart phone client.

· NOTE: Please use one smart phone that has been hard / soft reset to test so we maintain the device name is traces and we don’t have any previous cookies on the device.

8. Check Whale Event Monitor.

9. If still a problem.

10. Record the Exchange server layout. How many servers, what are the server names in this test.

11. Enable client side logging (verbose). Log will be on the device under \Windows\ActiveSync

· Please also enable Verbose logging on the mobile device. This can be done within the ActiveSync Configuration by choosing Advanced under the place where the credentials are entered. Once in Advanced, chose Verbose logging from dropdown menu. Upload all of the device logs directly after reproducing the behavior (Do not sync again before uploading the logs). You can copy over the logs on the device by cradling the device and copying the logs from the FileSystem location of <\\Windows\ActiveSync\Logs> directory on the device.

12. Also on IAG enable the following

Enable In synch filter log tracing on IAG appliance to dump the Active Synch trunk traffic.

Browse to C:\Whale-Com\e-Gap\von\InternalSite\inc\trace.inc
Modify trace_on = false to read trace_on = true

Save the file.

Browse to C:\Whale-Com\e-Gap\common\conf\trace.ini
Go to the last line of the file and add the following lines.

[trace\whlfilter\asfilter]

*=xheavy

[trace\whlfilter\internalsite]

*=xheavy

PS: please comment out or remove these lines once repro is finished.

IAG client components uninstallation failure from desktop

Faisal Hussain — Thu, 11 Jun 2009 16:40:00 GMT

I have already written a blog post about IAG client components troubleshooting and my colleague Ben has a nice article that explains fixing installtion issues with IAG client components in a systematic way. However at times when client component setup is not done as per the recommendations and if you try to run multiple setups or try to remove them inconsistently it is possible that you might end up of having them broken and fail to uninstall them completely.

Certainly this blogpost is not suggesting you that these steps will always help but it will point you to possible areas where the issues could be in regards to IAG client componets uninstallation failure. So when you try to unistall IAG client component from Windows Add/ remove programs, it fails or you try to delete Whale Client components directory it fails then try follow the steps in this blogpost and hopefully it helps.

I would suggest you some generic steps that you need to try on desktop one by one and this should fix the uninstallation issue.

PS:

1- ensure that you first take backup as registry modification can cause system to get unstable

2- also ensure that you create Windows XP / Vista restore point before you proceed.

3- perform this troubleshooting also booting Windows in Safe Mode.

4- perform this action plan while you are logged on as local administrator on the machine.

I hope you have already followed the steps in this article:

http://support.microsoft.com/kb/955097

Scenario two is to stop the DMService and then try to unistall and it should work. If the above above suggested step doesn’t help then proceed :

Please ensure that you remove all Whale client component Active X from Internet explorer and I am aware of a good 3rd party tool that can help but feel free to use any tool of your preference:

http://www.softpedia.com/get/Security/Secure-cleaning/Active-XCavator.shtml

try to uninstall client components now . if this doesn’t help then proceed further:

First Approach:

1. Check the following registry key to find the uninstall string: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Whale Communications' Client Components 3.1.0

Usually it has following value:

"DisplayName"="Whale Communications' Client Components v3.7"

"UninstallString"="rundll32.exe C:\WINDOWS\\DOWNLO~1\WhlMgr.dll,UnInstall 3.1.0 63 0 1 3.7"

confirm if it is rundll32.exe C:\WINDOWS\DOWNLO~1\DM.0\WhlMgr.dll,

2. if file WhlMgr.dll is missing from folder C:\WINDOWS\DOWNLO~1\DM.0 copy it from working system and use this uninstall string to uninstall ….if it fails move next

3. Verify that the file WhlMgr.dll is present --> C:\WINDOWS\DOWNLO~1\DM.0 and used this uninstall string to uninstall but it failed with the same error.

4. Verify no ~\Program Files\Whale Communications directory exists. If it exists - delete it.

5. Open regedit and verify no [HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom] key exists. If it exists - delete it.

6. Go to C:\WINDOWS\SYSTEM32 and double click the following files:

WhlLSPBackup_1.reg

WhlNSPBackup_1.reg

Note you may have advanced numbers but double click only the _1 ones.

7. Reboot

8. WhlCompMgr.inf if not present in this client so in registry search the clsid={8D9563A9-8D5F-459B-87F2-BA842255CB9A}

9. Delete all the clsid={8D9563A9-8D5F-459B-87F2-BA842255CB9A} under HKLM and rebooted the box

10. After this use Offline Installer from the server (C:\Whale-Com\e-Gap\von\PortalHomePage\WhlClientSetup-All.exe).. and run the setup.

Second approach:

please delete all files under ~\Program Files\Whale Communications including this folder and also all the references to whale in registry

1. Check the following registry key to find the uninstall string: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Whale Communications' Client Components 3.1.0

Usually it has following value:

"DisplayName"="Whale Communications' Client Components v3.7"

"UninstallString"="rundll32.exe C:\WINDOWS\DOWNLO~1\WhlMgr.dll,UnInstall 3.1.0 63 0 1 3.7"

if it is rundll32.exe C:\WINDOWS\DOWNLO~1\DM.0\WhlMgr.dll,

2. Verify that the file WhlMgr.dll is present --> C:\WINDOWS\\DOWNLO~1\DM.0 and use this uninstall string to uninstall if it fails …move next

3. On IE Options / Programs tab / manager add-ons try to remove the add-on ...

4. Try to delete whlmgr.dll file under C:\Windows \Downloaded program files ... it you cant , .. unregistered the dll.. try again .. if doesn’t help , move nest

5. Reboot the machine and test .

6. Try installing the components again using offline installer from the server (C:\Whale-Com\e-Gap\von\PortalHomePage\WhlClientSetup-All.exe).. if it fails, move next.

7. Find classid in whlcompmgr.inf .. it should be clsid={8D9563A9-8D5F-459B-87F2-BA842255CB9A} …search it in the registry ..delete the keys after taking their backup.

8. Reboot the machine again.

9. Try to delete whlmgr.dll file under C:\Windows \Downloaded program files ....

10. Try uninstalling the dll from IE options ..

11. Try using Offline Installer again.

IAG Client components troubleshooting using CTRACE.exe

Faisal Hussain — Mon, 01 Jun 2009 23:53:00 GMT

IAG extends its ability to end points via its client components. These components are crtical part of IAG in providing security not only for the end points but also reporting back to server . Client components setup is straight forward and with IAG 3.7 SP2 , an msi package is available that has made deployement really handy. Please follow the Technet resource on details about client componets and deployment methods . Client components get installed under C:\Program Files\Whale Communications \Client Components \3.1.0 \ on client computers.

If client compoents are deployed successfully and a particular component is not behaving as expected and you want to see whats going on then in order to debug you need to enable debug tracing on the end point. Please note this debugging will generate a lot of information that might not be user friendly , however you might find it useful in sharing with Microsoft to save time during troubleshooting.

IAG is shipped with a client side debugging utility called CTRACE. This gets installed as a part of client components setup. if you browse to C:\Program Files\Whale Communications \Client Components \3.1.0 \ directory you will find the components there. There you will see CTRACE.exe, this is the debugging utility. There is also a file called CTRACE.xml , if you right click and edit the file in notepad , you will see the following code inside:

<Configuration name="WhlClnt3.exe" debugOutput="False" outputPath="%TEMP%" enabled="False">
         <TraceReporter reporter="SSLVPN" level="xheavy"/>
         <TraceReporter reporter="TCPDump" level="xheavy"/>
         <TraceClass reporter="SSLVPN" class="XPSP2Check" level="medium"/>
   <TraceClass reporter="SSLVPN" class="TunnelLifetime" level="light"/>
        <TraceReporter reporter="Security" level="xheavy"/>
      </Configuration>

<Configuration name="SFHlprUtil.exe" debugOutput="False" outputPath="%TEMP%" enabled="False">
       <TraceReporter reporter="Security" level="xheavy"/>
     </Configuration>

<Configuration name="WhlCach3.exe" debugOutput="False" outputPath="%TEMP%" enabled="False">
         <TraceReporter reporter="AW" level="xheavy"/>
      </Configuration>

<Configuration name="AWCleaner.exe" debugOutput="False" outputPath="%TEMP%" enabled="False">
         <TraceReporter reporter="AW" level="xheavy"/>
      </Configuration>

<Configuration name="WhlWmiDetect.exe" debugOutput="False" outputPath="%TEMP%" enabled="False">
       <TraceReporter reporter="EndpointDetection" level="xheavy"/>
     </Configuration>

<Configuration name="Outlook.exe" debugOutput="False" outputPath="%TEMP%" enabled="False">
         <TraceReporter reporter="NSP" level="xheavy"/>
         <TraceReporter reporter="IPC" level="xheavy"/>
         <TraceReporter reporter="LSP" level="xheavy"/>
         <TraceClass reporter="LSP" class="passthru" level="xheavy"/>
         <TraceClass reporter="LSP" class="SocketsInfo" level="light"/>
         <TraceClass reporter="IPC" class="Terminal Services" level="light"/>
         <TraceClass reporter="NSP" class="Lookups" level="heavy"/>
         <TraceClass reporter="NSP" class="WSP Threadpool" level="medium"/>
      </Configuration>

<Configuration name="MSTSC.exe" debugOutput="False" outputPath="%TEMP%" enabled="False">
         <TraceReporter reporter="NSP" level="xheavy"/>
         <TraceReporter reporter="IPC" level="xheavy"/>
         <TraceReporter reporter="LSP" level="xheavy"/>
         <TraceClass reporter="LSP" class="passthru" level="xheavy"/>
         <TraceClass reporter="LSP" class="SocketsInfo" level="light"/>
         <TraceClass reporter="IPC" class="Terminal Services" level="light"/>
         <TraceClass reporter="NSP" class="Lookups" level="heavy"/>
         <TraceClass reporter="NSP" class="WSP Threadpool" level="medium"/>
      </Configuration>

<Configuration name="Common" debugOutput="False" outputPath="%TEMP%" enabled="False">
         <TraceReporter reporter="NSP" level="xheavy"/>
         <TraceReporter reporter="IPC" level="xheavy"/>
         <TraceReporter reporter="LSP" level="xheavy"/>
         <TraceClass reporter="LSP" class="passthru" level="xheavy"/>
         <TraceClass reporter="LSP" class="SocketsInfo" level="light"/>
         <TraceClass reporter="IPC" class="Terminal Services" level="light"/>
         <TraceClass reporter="NSP" class="Lookups" level="heavy"/>
         <TraceClass reporter="NSP" class="WSP Threadpool" level="medium"/>
      </Configuration>
   </Configurations>

<Reporters>
      <Reporter name="NSP" id="1">
         <Class name="General" id="0"/>
         <Class name="Lookups" id="1"/>
         <Class name="WSP" id="2"/>
         <Class name="WSP Pipes" id="3"/>
         <Class name="WSP ThreadPool" id="4"/>
      </Reporter>
      <Reporter name="IPC" id="2">
         <Class name="Client" id="0"/>
         <Class name="Terminal Services" id="1"/>
         <Class name="Utilities" id="2"/>
      </Reporter>
      <Reporter name="LSP" id="3">
         <Class name="General" id="0"/>
         <Class name="Overlapped" id="1"/>
         <Class name="SPI" id="2"/>
         <Class name="SocketCreation" id="3"/>
         <Class name="AsyncSelect" id="4"/>
         <Class name="EventSelect" id="5"/>
         <Class name="SOCKS" id="6"/>
         <Class name="SocketsInfo" id="7"/>
         <Class name="Access Control" id="8"/>
         <Class name="Passthru" id="9"/>
      </Reporter>
      <Reporter name="SSLVPN" id="4">
         <Class name="General" id="0"/>
         <Class name="XPSP2Check" id="1"/>
   <Class name="TunnelLifetime" id="2"/>
      </Reporter>
      <Reporter name="AW" id="5">
         <Class name="General" id="0"/>
      </Reporter>
      <Reporter name="EndpointDetection" id="6">
         <Class name="General" id="0"/>
         <Class name="DetectionScript" id="1"/>
      </Reporter>
      <Reporter name="ComponentsManager" id="7">
         <Class name="General" id="0"/>
         <Class name="SystemRestore" id="1"/>
         <Class name="ConfigXML" id="2"/>
         <Class name="Service" id="3"/>
      </Reporter>
      <Reporter name="TCPDump" id="8">
         <Class name="General" id="0"/>
      </Reporter>
      <Reporter name="RSASoftToken" id="666">
         <Class name="General" id="0"/>
      </Reporter>
     <Reporter name="Security" id="9">
       <Class name="CheckSite" id="0"/>
     </Reporter>
     <Reporter name="VistaUtils" id="10">
       <Class name="General" id="0"/>
     </Reporter>
   </Reporters>
</ClientTraces>

you need to enable the reporter that you want to trace. For instance If you enable Terminal Services for XP reporter, it will dump quite a lot of information for you in terms of LSP/NSP installed on the WinSock stack.

this is how you enable client-side traces:

1) Edit and create a copy of ctrace.xml on the client.

2) Close all programs and Internet Explorer browser windows

3) Copy edited-ctrace.xml to C:\Program Files\Whale Communications\Client Components\3.1.0.

4) Open a command prompt change to the C:\Program Files\Whale Communications\Client Components\3.1.0 directory

5) Run the following command: “ctrace activate edited-ctrace.xml” to initialize tracing.

6) reproduce the issue for which the reporter is enabled in edited-ctrace.xml.

7) Open a command prompt change to the C:\Program Files\Whale Communications\Client Components\3.1.0 directory

8) Run the following command: “ctrace activate” to disable tracing

9) Select Start - > Run %temp%

10) This will open the user’s temp directory.

Please review the file to understand what it is capable of doing. Once you enable tracing , you should immediately reproduce the problem and then disable the tracing else it will keep dumping a lot of information. Once issue is successfully reproduced , this debug trace will create output files in %Temp% directory on the path.

Try have a look at the output if it helps with any obvious error messages, if it doesnt make sense to you zip these out put directories and send them to Microsoft for analysis. Please note CTRACE output is always unique from each desktop so for troubleshooting if you are facing identical issues on more than one desktop then collect CTRACE output from atleast two sample machines but also this is operating system specific. So an issue on Windows XP could be different from an issue on Windows Vista.

For few more advance client components troubleshooting articles please refer to Ben's blog . You can also refer to KB 955097 for specific client components issue.