Microsoft Exchange ActiveSync Event ID: 3005 ... how to resolve?

Those instructions you followed were for an SBS system - the rules are slightly different with a frontend/backend. As such, this will not be the end all solution question because most people don't run frontend/backend scenarios.

The articles on forms based authentication and EAS don't apply to you - because you are on FE/BE.

Does OMA work? EAS uses the OMA infrastructure to connect and it is easier to diagnose.
Is the frontend server working correctly? If you connect to OWA does the URL stay the same or does it redirect you to the backend server?

Simon.

Hi Simon-

Does OMA work?
-->OMA works on a PC and works on the mobile we are trying to configure (Tmobile MDA)

If you connect to OWA does the URL stay the same or does it redirect you to the backend server?
-->When we type http://weboutlook.website.com/exchange , it transfers us to https://weboutlook.website.com/exchweb/bin/auth/owalogon.asp?url=https://weboutlook.website.com/exchange/&reason=1 for the FBA login page. After logging it, it goes back to https://weboutlook.website.com/exchange . We have it force to HTTPS and FBA for OWA.

Thank you,
Kit

You need to remove the require SSL. That breaks EAS.

What I was more interested in was whether the URL did something like...

https://webmail.domain.com
http://server1.domain.com

ie redirected to a different server altogether. That is an indication that the frontend feature isn't' working.

Simon.

Simon-

Not sure why I would remove the SSL for? What does EAS stand for? SSL is on OWA for PC user access and that has been working fine.

ie redirected to a different server altogether. That is an indication that the frontend feature isn't' working.
-->This is not happening. When it gets into the mailbox from the front-end server, the URL stays as https://weboutlook.website.com/exchange (no server name)

Kit

EAS = Exchange Active Sync

There is a quirk with EAS. It makes an internal communication over http to the /exchange virtual folder. Forcing SSL on the /exchange virtual folder breaks EAS. It is buried in this article: http://support.microsoft.com/default.aspx?kbid=817379

I am not asking you to remove SSL, just remove the setting that REQUIRES SSL on that virtual folder.

Simon.

I see Simon

From what I can see, on the front-end server, it has /exchange, /exchange-oma (the virtual server created of an offspring of /exchange.
/exchange has Basic Authentication, SSL
/exchange-oma Integrated and Basic Authentation, No SSL

The back-end server has the same virtual folders: /exchange /exchange-oma.
/exchange has Integrated and Basic Authentication, No SSL
/exchange-oma has Integrtated and Basic Authentication, No SSL

My Mobile user says now there is a 409 error on his page. He gets an error when he deletes an email on his pda and then does a send/receive....

Feeling we are getting close, but not close enough

Is my settings correct Simon?

By SSL what do you mean?
Do you mean that the there is a requirement for SSL to be used to connect?

Simon.

WHen I say "SSL", i meant that the checkbox in IIS Properities of /exchange, Directory Security, Secure Communications, Edit "Require Secure channel (SSL)" is checked.

I changed 1 setting and my PDA user to sync and his error code changed from 409 to 400.

The change I made was in the front-end server /exchange. I checked the "Integrated Authentication" which changed his error from 409 to 400...

Ok - that needs to be removed on the /exchange virtual directory.
It causes problems with EAS when it is enabled.

The site will still use SSL for communications.
To give you an idea - I usually refuse to open port 80 to production sites, including my home Exchange server. However with the requirement for SSL off, but only port 443 open, everything works correctly.

Simon.

Changed exchange on the front-end back to not having it be Integrated Authentication

On our firewall, weboutlook.website.com is open to 80 and 443... what now?

ActiveSync over the air works fine (meaning it updates the device and exchange server) but then throws the 3005 error (Http 400)... on the device and on the front-end server.

Just a clarification here. No error is thrown on the device, only on the front-end exchange server. Initiating a sync wirelessly on the device works fine (things are updated) but then the event error is thrown.
Also, no DirectPush works. Just the 15 minute normal over the air activesync (with event error).
We tried the same process with a newer exchange user and had the same results, although interestingly, we had a 409 error then followed by the usual 400 errors.

With the direct push, do you have a device that has that feature enabled? If so, I suspect that direct push is not working because the connection is being dropped by the error. Direct push works by maintaining a connection between your server and the handheld.

The latest issue I have heard is with multiple homed or multiple IP addresses on the machine.
Something about the Active Sync process having to find the server itself to connect correctly. This would tally up with the requirement to ensure that Require SSL connection is not enabled on certain folders that would appear at first glance not to have anything to do with the sync process.

Simon.

The feature on the MDA is enabled. The CommManager has the Microsoft DirectPush button. We are still getting errors from the BE server (the HTTP 400 error - event 3005). We tried some other items and that killed OWA and we had to roll back. Any more advice?

Update. We did have 2 IP addresses on the single NIC. We deleted one and still get the same issue.

Also, something interesting. If I turn OFF the DirectPush, and initiate an over the air sync or a send and receive on the device, we do NOT get the 3005 error.

If I turn ON the DirectPush on the device, we DO get the error. In fact, we get it as soon as the DirectPush button is clicked.

Grrrrrr!

Does the sync actually complete successfully with Direct Push disabled?

If so, then it might be a problem with the Direct Sync mechanism and your firewall.
I have heard that some firewalls cannot cope with the extended length of the packet that is used for Direct Sync. If the firewall has any kind of http inspection facility enabled it may cause a problem.

As you can probably appreciate it is early days with this technology, and troubleshooting is a challenge.

Simon.

yes. with directpush disabled there is no problem doing an ota sync and no entry in the event log. I will have IT check about the firewall. thanks for your help!

THank you for your help thus far Simon-

As for our firewall, we are using a cisco firewall and the we set the UDP timeout to be 15 mins. (I'm assuming Direct Push Technology is using this protocol).

It is standard http packets, so should be TCP not UDP.
There isn't much from Microsoft on the firewall configuration.
So far this is all we have to go on (that I can share with you anyway) http://support.microsoft.com/default.aspx?kbid=905013

Simon.

Hi Simon,

We have a good update, but are ever so close to solving this situation. After finding an article (http://groups.google.com/group/microsoft.public.pocketpc.activesync/browse_frm/thread/96a012d52673c49b/22bdad20f97e9745?lnk=st&q=activesync+3005+http+400&rnum=1#22bdad20f97e9745) that said that described our HTTP400 problem, we at least resolved the error, but it now the DirectPushTechnolgoy is not working.

We had to do this on our end
1) Edit a host file at c:\windows\system32\drivers\etc\hosts with an entry for the public IP address of the weboutlook, but with the Windows name + Domain as a DNS entry.
2) Added local DNS for the weboutlook and back-end exchange servers with their FQDN and internal IP address

These two changes have resolved the problem, but when I send an email to my co-worker, the emails are still not "directly pushed" like you would expect a BlackBerry to be like.  Although we are not getting any errors, he has to wait 5 mins for send/receive or manual sync in order to get the email.

I believe you have a point in that they are standard HTTP packets. Running Ethereal on the WebOutlook Server, we noticed that they are https packets using TCP, rather than UDP.  In our case, we have a CIsco 515 Pix but it's not clear how to change the timeout to not timeout so quickly with https. We believe that is the issue at this moment.

Maybe you ran into something this week that could shed some more light on this situation. Thanks and hope to hear from you soon.

Kit

Thanks Simon for all your help,

Well, it seems like we have resolved the issue.. my co-worker was out of office last week so we could not test it since his GSM network lacked coverage..

We last left off at the heartbeat situation, and this morning, he mentioned that there was the Event ID: 3033 error. Googling lead to the MS article (http://support.microsoft.com/Default.aspx?kbid=905013) so I looked at the 4 registry hacks...

The Outlook server had the MaxhearbeatInterval set as 2700 (secs) while the Back End Exchange Server was only set to 900 (secs). Changing the BE-ES to 2700 secs. Restarted IIS and then my co-worker informed me that it just started to work. Sending an email to him, it pushed out in less than 10 secs to him.

Great! I am estatic this finally worked out...

For those that want to read what we did, please read this entire thread and it should work.

Cheers,
Kit