Faisal Hussain CISSP

Thursday, October 29, 2009 12:53 PM

Publishing Terminal Services for MAC OS X clients through IAG

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.

Posted by faisalh | 0 Comments

Tuesday, October 20, 2009 2:38 PM

JRE Client side detection troubleshooting

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.

Posted by faisalh | 0 Comments

Friday, October 16, 2009 10:38 AM

AD type repository gives a strange errors for GC search

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:

<<

The Server Access Credentials settings are invalid. Error message: Failed to connect to the domain's global catalog server. If You continue, authentication and authorization using this server might not fucntion properly.

Do you wish to continue?

YES or NO

>>

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.

Posted by faisalh | 0 Comments

Sunday, October 11, 2009 6:42 AM

SWF Flash Content type rewrite via IAG

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.

Posted by faisalh | 0 Comments

Sunday, October 11, 2009 6:12 AM

Publishing Java Applet Enabled Applications through IAG

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.

Posted by faisalh | 0 Comments

Monday, August 10, 2009 4:28 PM

Unicode or double Byte calendar breaks via IAG

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>

to

<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.

Posted by faisalh | 0 Comments

Tuesday, June 16, 2009 4:27 PM

IAG ActiveSynch Trunk troubleshooting

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.

Posted by faisalh | 0 Comments

Thursday, June 11, 2009 5:40 PM

IAG client components uninstallation failure from desktop

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- kindly 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- Kindly perform this troubleshooting also booting Windows in Safe Mode.

4- Please 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 entries 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.

Posted by faisalh | 0 Comments

Monday, June 01, 2009 9:53 PM

IAG Client components troubleshooting using CTRACE.exe

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.

Posted by faisalh | 0 Comments

Saturday, May 30, 2009 1:32 AM