Publishing Microsoft ActiveSync through IAG 2007 – Part 2 of 2

Publishing Microsoft ActiveSync through IAG 2007 – Part 2 of 2

  • Comments 4
  • Likes

1. Introduction

 

We published the first part of this article, which had step by step details of how to configure Microsoft ActiveSync through IAG 2007. In this second part, we will cover troubleshooting the most common issues that we’ve encountered while publishing ActiveSync through IAG 2007.

 

2. Gathering Data

 

One of the most important areas that you need to be aware of in troubleshooting ActiveSync, is what data you need to collect.  As a rule of thumb the following logs should be enabled for this scenario:

 

2.1. IAG Trace logs

 

Follow the steps below to enable this log:

 

1. Browse to C:\Whale-Com\e-Gap\von\InternalSite\inc\trace.inc

2. Modify trace_on = false to trace_on = true and save the file

3. Browse to C:\Whale-Com\e-Gap\common\conf\trace.ini

4. Go to the last line of the file and add the following lines:

[Trace\WhlFilter]

*=xheavy

[Trace\UserMgrCom]

*=xheavy

 

5. Save the file

 

Tracing will now start for both WhlFilter and UserMgrCom,. These logs will be located in \whale-com\e-gap\logs and should be named *.usermgrcom*.log and *.whlfilter.*.log

 

2.2. Filter log

 

Follow the steps below to enable this log:

 

1. Run regedit

2. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\e-Gap\von\UrlFilter

3. Locate the LogFlag DWORD

4. Modify the value from HEX 0 to HEX 4

 

In about 30 seconds logging will start and the log will be located in \whale-com\e-gap\von\conf\websites\[TrunkName]\Logs\*WhlFilter.log

 

Note: These logs are very verbose and fill up disk space quickly. Therefore enable these logs only for troubleshooting purposes. After you’re done gathering the data you need, it is strongly recommended to disable all of them.

 

3. Troubleshooting Scenarios

 

The environment used for this troubleshooting guide is the following one:

 

Figure 1 – Basic diagram.

 

3.1. After completing the IAG configuration by following part 1, I’m getting an error when I try to synchronize my mobile device. I enabled the logs but there is nothing in there.

 

If this is the first attempt to synchronize after enabling the ActiveSync Trunk and the logs are empty, most likely you are running into a certificate issue. If you enable Netmon trace on the external NIC of the IAG server you will notice the following:

 

TCP Handshake on port 443

192.168.0.185     192.168.0.181     TCP   TCP:Flags=......S., SrcPort=1032, DstPort=HTTPS(443), PayloadLen=0, Seq=337408, Ack=0, Win=32768 (scale factor 0) = 32768

 

192.168.0.181     192.168.0.185     TCP   TCP:Flags=...A..S., SrcPort=HTTPS(443), DstPort=1032, PayloadLen=0, Seq=2541104422, Ack=337409, Win=16384 (scale factor 0) = 16384

 

192.168.0.185     192.168.0.181     TCP   TCP:Flags=...A...., SrcPort=1032, DstPort=HTTPS(443), PayloadLen=0, Seq=337409, Ack=2541104423, Win=33580 (scale factor 0) = 33580

 

SSL Handshake

192.168.0.185     192.168.0.181     SSL   SSL:  Client Hello.

 

192.168.0.181     192.168.0.185     SSL   SSL:  Server Hello. Certificate. Server Hello Done.v

- Ssl:   Server Hello. Certificate. Server Hello Done.

  - TlsRecordLayer:

     ContentType: HandShake

   - Version: TLS 1.0

      Major: 3 (0x3)

      Minor: 1 (0x1)

     Length: 1426 (0x592)

   - SSLHandshake: SSL HandShake TLS 1.0 Server Hello Done(0x0E)

      HandShakeType: ServerHello(0x02)

      Length: 70 (0x46)

    + ServerHello: 0x1

      HandShakeType: Certificate(0x0B)

      Length: 1344 (0x540)

    - Cert: 0x1

       CertOffset: 1341 (0x53D)

     - Certificates:

        CertificateLength: 1338 (0x53A)

      - X509Cert: Issuer: Denver CA,contoso,com, Subject: *.contoso.com

       + SequenceHeader:

       - TbsCertificate: Issuer: Denver CA,contoso,com, Subject: *.contoso.com

        + SequenceHeader:

        + Tag0:

        + Version: v3 (2)

        + SerialNumber: 0x612021a7000000000007

        + Signature: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)

        + Issuer: Denver CA,contoso,com

        + Validity: From: 09/26/06 22:45:52 UTC To: 10/10/10 09:18:23 UTC

        + Subject: *.contoso.com

        + SubjectPublicKeyInfo: RsaEncryption (1.2.840.113549.1.1.1)

        + Tag3:

        + Extensions:

       + SignatureAlgorithm: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)

       + Signature:

      HandShakeType: Server Hello Done(0x0E)

      Length: 0 (0x0)

 

192.168.0.185     192.168.0.181     SSL   SSL:  Client Key Exchange. Change Cipher Spec. Encrypted Handshake Message.

 

192.168.0.181     192.168.0.185     SSL   SSL:  Change Cipher Spec. Encrypted Handshake Message.

 

192.168.0.185     192.168.0.181     TCP   TCP:Flags=...A...F, SrcPort=1032, DstPort=HTTPS(443), PayloadLen=0, Seq=337659, Ack=2541105897, Win=33580 (scale factor 0) = 33580

 

What happen here is that the *.contoso.com certificate was issued by a CA (the Denver machine) that the client (Windows Mobile) does not trust. To fix this problem follow the instructions from KB915840 to add the root CA certificate to your mobile device.

 

3.2. I have added the root CA certificate to my mobile device and I was able to connect and synchronize just fine. However, after working for a while, I’m now getting the message below when I try to synchronize:

 

Figure 2 – Error trying to synchronize

 

This is a very generic error, so the best approach here is to get a Netmon trace, but this time on the internal interface of the IAG server. Gather also the logs that were enabled in session 1. Let’s see the result:

 

From UserMgrCom log:

 

Authentication Request

** 25.07.08 10:05:52.257 USERMGR_SERVICE:GENERAL T5900

AuthenticateUser got [CAuthenticateUserIn:

m_repository                          = [AD]

m_user                                = [administrator]

m_password                            = [**Confidential**]

m_domain                              = [contoso]

m_param_vec                           = <EmptyField>

m_site_name                           = [activesynctrunk]

m_secure                              = [1]

m_session_id                          = [22B36058-D0B7-4A6E-A8A6-EDD7DF35E325]

m_login_type                          = [2]

m_source_ip                           = [192.168.0.183]

]

 

* at line 334, file "src/UserMgrCore.cpp".

 

** 25.07.08 10:05:52.257 CONFIGMGR_SERVICE:GENERAL T5900

Get the site [activesynctrunk] secure [1] info.

* at line 555, file "src/SiteContainer.cpp".

 

Authentication Succeed:

** 25.07.08 10:05:52.267 USERMGR_SERVICE:GENERAL T5900

Authenticate the user [administrator] domain [contoso] in the ldap server [10.1.1.6] port [389] dn [CN=Users,DC=contoso,DC=com] type [Active Directory]

* at line 320, file "src/Ldap.cpp".

 

** 25.07.08 10:05:52.267 USERMGR_SERVICE:GENERAL T5900

Connect user [administrator] domain [contoso].

* at line 2178, file "src/Ldap.cpp".

 

** 25.07.08 10:05:52.267 USERMGR_SERVICE:GENERAL T5900

Connect with bind auth negotiate.

* at line 2209, file "src/Ldap.cpp".

 

** 25.07.08 10:05:52.288 USERMGR_SERVICE:GENERAL T5900

Connect success

 

After authentication, IAG needs to contact the Exchange Server to access the ActiveSync URL. At this point, IAG attempts to resolve the name of the Exchange server, as specified in step 6 of the previous article. If the name cannot be resolved the connection will fail, as seen below:

 

10.1.1.5    10.1.1.6    DNS   DNS:QueryId = 0x8442, QUERY (Standard query), Query  for mail.contoso.com of type Host Addr on class Internet

 

10.1.1.6    10.1.1.5    DNS   DNS:QueryId = 0x8442, QUERY (Standard query), Response - Name Error

 

To fix this problem enable the IAG server to resolve the name that appears in step 6 of the previous article. After fixing this problem, you should see the following traffic on the internal network:

 

10.1.1.5    10.1.1.6    DNS   DNS:QueryId = 0x234E, QUERY (Standard query), Query  for mail.contoso.com of type Host Addr on class Internet

 

10.1.1.6    10.1.1.5    DNS   DNS:QueryId = 0x234E, QUERY (Standard query), Response - Success, 49, 0

 

10.1.1.5    10.1.1.6    TCP   TCP:Flags=......S., SrcPort=1718, DstPort=HTTP(80), PayloadLen=0, Seq=1407512359, Ack=0, Win=32768 (scale factor 0) = 32768

 

10.1.1.6    10.1.1.5    TCP   TCP:Flags=...A..S., SrcPort=HTTP(80), DstPort=1718, PayloadLen=0, Seq=2078452756, Ack=1407512360, Win=16384 (scale factor 0) = 16384

 

10.1.1.5    10.1.1.6    TCP   TCP:Flags=...A...., SrcPort=1718, DstPort=HTTP(80), PayloadLen=0, Seq=1407512360, Ack=2078452757, Win=32768 (scale factor 0) = 32768

 

10.1.1.5    10.1.1.6    HTTP  HTTP:Request, POST /Microsoft-Server-ActiveSync

 

10.1.1.6    10.1.1.5    HTTP  HTTP:Response, HTTP/1.1, Status Code = 401, URL: /Microsoft-Server-ActiveSync

 

10.1.1.6    10.1.1.5    TCP   TCP:[Continuation to #48]Flags=...AP..., SrcPort=HTTP(80), DstPort=1718, PayloadLen=409, Seq=2078454217 - 2078454626, Ack=1407512979, Win=64916 (scale factor 0) = 64916

 

10.1.1.5    10.1.1.6    HTTP  HTTP:HTTP Payload, URL: /Microsoft-Server-ActiveSync

 

10.1.1.6    10.1.1.5    TCP   TCP:Flags=...A...., SrcPort=HTTP(80), DstPort=1718, PayloadLen=0, Seq=2078454626, Ack=1407512992, Win=64903 (scale factor 0) = 64903

 

10.1.1.5    10.1.1.6    HTTP  HTTP:Request, POST /Microsoft-Server-ActiveSync

 

10.1.1.6    10.1.1.5    HTTP  HTTP:Response, HTTP/1.1, Status Code = 100, URL: /Microsoft-Server-ActiveSync

 

 

5. Conclusion

 

This troubleshooting guide covers two common problems that might arise when configuring a Microsoft ActiveSync Trunk on IAG 2007. Although this article does not cover all possible issues and resolutions, it should give you a good overview of the troubleshooting steps, and the approach to gather and analyze data for ActiveSync publishing through IAG 2007.

 

 

Authors

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – Texas

 

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – Washington

 

Technical Reviewer

Ran Dolev

Security Consultant – IAG Team

Microsoft – Israel

 

Comments
  • A great refrence for troubleshooting ActiveSync error codes is: http://blog.flaphead.dns2go.com/archive/2005/11/21/3202.aspx

  • 132 Microsoft Team blogs searched, 59 blogs have new articles in the past 7 days. 122 new articles found

  • Guten Abend,da dieses Problem mich eine ganze Weile beschäftigte (und ebenso den von mir kontaktierten MS Support) hier die unglaublich einfache Lösung:IAG 2007 unterstützt keine NTLM Authentifizierung gegen den Exchange 2007 SP1 mit Update Rollup 5.Lösu

  • With the release of IAG 2007 SP2 (although this behavior can happen with any new update), we have been

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment