wolfstar76
asked on
Unable to synch a PPC-6700 with Exchange
Hello Experts,
I saw a couple questions similar to my own, but haven't been able to get a working solution yet. Here's a rundown of what's going on.
I recently (a month ago) purchased a Sprint PPC-6700 Windows Mobile 5.0 device. I was able to get it up and running synchronizing with my Exchange server over the web (since the PDA/Phone gets Internet access). The web address I was using was webmail.companyname.com, and everything was just fine.
Because we were having issues with Outlook 2003 not being able to connect via RPC over HTTP, my co-worker eventually found that we needed to install a new certificate to the mail server, because the current certificate installed was using the server's internal name (mailserv.companyname.net)
However, I lost my ability to synch my PDA. The error I'm getting is that my server's certificate is invalid.
Elsewhere on this site I saw a solution that, if I understood it correctly, referenced installing the CA's certificate. Since our certificate here is home-brew, I'm assuming that might also be the case for me, but I don't know enough about Windows Mobile 5.0 to figure out how to import our internal CA as a root server - or, in fact, if that's even the "fix" for me.
Looking for some pointers here, and much appreciate any help I can get.
I saw a couple questions similar to my own, but haven't been able to get a working solution yet. Here's a rundown of what's going on.
I recently (a month ago) purchased a Sprint PPC-6700 Windows Mobile 5.0 device. I was able to get it up and running synchronizing with my Exchange server over the web (since the PDA/Phone gets Internet access). The web address I was using was webmail.companyname.com, and everything was just fine.
Because we were having issues with Outlook 2003 not being able to connect via RPC over HTTP, my co-worker eventually found that we needed to install a new certificate to the mail server, because the current certificate installed was using the server's internal name (mailserv.companyname.net)
However, I lost my ability to synch my PDA. The error I'm getting is that my server's certificate is invalid.
Elsewhere on this site I saw a solution that, if I understood it correctly, referenced installing the CA's certificate. Since our certificate here is home-brew, I'm assuming that might also be the case for me, but I don't know enough about Windows Mobile 5.0 to figure out how to import our internal CA as a root server - or, in fact, if that's even the "fix" for me.
Looking for some pointers here, and much appreciate any help I can get.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
If you browse to the OMA directory, do you get a certificate prompt?
https://servername.domain.com/oma
Simon.
https://servername.domain.com/oma
Simon.
ASKER
Negative, but after being prompted to login, I get the following error:
A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.
A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.
If OMA isn't working, then I would be surprised is EAS works. They use the same backend structure. Usually if you can get OMA to work, then EAS will work as well.
Lets try the standard stuff first...
Authentication, application pools and SSL settings...
All done in IIS Manager...
The correct authentication settings for the Exchange virtual directories are:
/exchange - basic and integrated ONLY
/exchweb - anonymous ONLY
/exadmin - integrated ONLY
/public - basic and integrated ONLY
/oma - basic ONLY
/Exchange-Server-ActiveSyn
Application Pools
/exchange - ExchangeApplicationPool*
/exchweb - ExchangeApplicationPool*
/exadmin - ExchangeApplicationPool*
/public - ExchangeApplicationPool*
/oma - ExchangeMobileBrowseApplic
/Exchange-Server-ActiveSyn
* will probably show ExchangeApplicationPool but greyed out.
Ensure that the /exchange virtual directory does NOT have require SSL enabled. That can break both applications.
Also ensure that .net framework 1.1 is enabled, not version 2.0
Finally, in ESM, ensure that under mobile services in Global Settings, that every option has been enabled.
Simon.
Lets try the standard stuff first...
Authentication, application pools and SSL settings...
All done in IIS Manager...
The correct authentication settings for the Exchange virtual directories are:
/exchange - basic and integrated ONLY
/exchweb - anonymous ONLY
/exadmin - integrated ONLY
/public - basic and integrated ONLY
/oma - basic ONLY
/Exchange-Server-ActiveSyn
Application Pools
/exchange - ExchangeApplicationPool*
/exchweb - ExchangeApplicationPool*
/exadmin - ExchangeApplicationPool*
/public - ExchangeApplicationPool*
/oma - ExchangeMobileBrowseApplic
/Exchange-Server-ActiveSyn
* will probably show ExchangeApplicationPool but greyed out.
Ensure that the /exchange virtual directory does NOT have require SSL enabled. That can break both applications.
Also ensure that .net framework 1.1 is enabled, not version 2.0
Finally, in ESM, ensure that under mobile services in Global Settings, that every option has been enabled.
Simon.
ASKER
Sorry it's taken so long to reply, was tinkering with this until quitting time last night, and this morning brought the usual "morning rush" of people needing this, that, and the other thing.
I took a look at the items listed above, and set authentication as you listed. I'm not very knowledgeable about IIS, however, and I'm not sure about my application pools. It would appear that my listing for ActiveSynch is part of the ExchangeApplicationPool and not the ExchangeMobileBrowseApplic
On the upside, the OMA is no longer giving me the error from before, however, its now telling me and my coworker that our accounts have not been enabled for wireless access. When I check out accounts, however, we're both listed as being enabled for all the mobile services.
Lastly, my PDA is still giving me the same 0x80072F0D invalid certificate error as before.
Your continued assistance is greatly appreciated. I wish I had more points to share.
I took a look at the items listed above, and set authentication as you listed. I'm not very knowledgeable about IIS, however, and I'm not sure about my application pools. It would appear that my listing for ActiveSynch is part of the ExchangeApplicationPool and not the ExchangeMobileBrowseApplic
On the upside, the OMA is no longer giving me the error from before, however, its now telling me and my coworker that our accounts have not been enabled for wireless access. When I check out accounts, however, we're both listed as being enabled for all the mobile services.
Lastly, my PDA is still giving me the same 0x80072F0D invalid certificate error as before.
Your continued assistance is greatly appreciated. I wish I had more points to share.
ASKER
I found and corrected OMA's configuration, and can now use that, however I'm still stuck with the certificate error for my PDA.
As for the certificate error on the PDA, try removing the certificate from the device completely and see whether you get the SAME certificate error.
Also ensure that you don't have client certificates enabled on the /Microsoft-Server-ActiveSy
Simon.
Also ensure that you don't have client certificates enabled on the /Microsoft-Server-ActiveSy
Simon.
ASKER
Removing the cert from my PDA gives the same error (re-adding it also made no difference).
The Microsoft-Server-ActiveSyn
The only thing that I can think of at this point would be the naming convention between the server and the certificate.
Internally the server is known as hermes.faysharpe.net. Externally it's webmail.faysharpe.com.
When the certificate was assigned to hermes.faysharpe.net - my PDA synched just fine. However, we couldn't connect external laptops and the like running 2k3 via HTTP. My co-worker managed to deduce that it was the disparate naming of our external connection and the server/certificate name. On Friday, around 3:00 he replaced the certificate with one that instead read "webmail.faysharpe.com" - and our laptops (and my home computer) were able to connect up again - but that's when I lost the ability to connect my PDA (mysterious indeed).
Since the PDA is reporting an issue with the certificate, I wonder if there's some happy middle ground I can find here? Is it possible that my PDA is connecting via the "webmail" address, and then negotiating with the server to discover the "hermes" name and freaking out when the cert doesn't match that way? If so, can/should I add a second certificate?
I know you said you're not a fan of homebrew certs outside a lab, but I don't have a lab to test these things out on (don't get me started about my budget), but I can play with the homebrew stuff 'til the cows come home, as needed.
Thoughts? Suggestions?
The Microsoft-Server-ActiveSyn
The only thing that I can think of at this point would be the naming convention between the server and the certificate.
Internally the server is known as hermes.faysharpe.net. Externally it's webmail.faysharpe.com.
When the certificate was assigned to hermes.faysharpe.net - my PDA synched just fine. However, we couldn't connect external laptops and the like running 2k3 via HTTP. My co-worker managed to deduce that it was the disparate naming of our external connection and the server/certificate name. On Friday, around 3:00 he replaced the certificate with one that instead read "webmail.faysharpe.com" - and our laptops (and my home computer) were able to connect up again - but that's when I lost the ability to connect my PDA (mysterious indeed).
Since the PDA is reporting an issue with the certificate, I wonder if there's some happy middle ground I can find here? Is it possible that my PDA is connecting via the "webmail" address, and then negotiating with the server to discover the "hermes" name and freaking out when the cert doesn't match that way? If so, can/should I add a second certificate?
I know you said you're not a fan of homebrew certs outside a lab, but I don't have a lab to test these things out on (don't get me started about my budget), but I can play with the homebrew stuff 'til the cows come home, as needed.
Thoughts? Suggestions?
The certificate name mismatch should have no effect on the deployment of this feature. I have deployed loads of SSL certificates where the name on the certificate and the name inside are totally different. My home domain (with a purchased certificate) is set in this way. I therefore think that is a red herring.
All you have to ensure is that the name resolution is correct - ie that the name on the certificate and the name entered in to EAS match and resolve to the correct location.
You can add as many certificates as you like. When you hit a site with a certificate protection the device looks through its certificates to see if one matches - so if you have to add in additional certificates then that is fine.
I presume that you are trying this over the mobile phone network all the time? You haven't tried it inside to see if it works there? I am not familiar with the exact spec of the Treo 700W as they aren't available on this side of the pond, so I don't know if it can connect to the LAN as well.
If you don't have LAN access then I would be tempted to get hold of the Windows Mobile 5 emulator and see what happens without the certificate internally. I am hesitant to suggest trying it from outside the LAN without the SSL certificate, as that would mean opening port 80 and all the security risks that brings.
Simon.
All you have to ensure is that the name resolution is correct - ie that the name on the certificate and the name entered in to EAS match and resolve to the correct location.
You can add as many certificates as you like. When you hit a site with a certificate protection the device looks through its certificates to see if one matches - so if you have to add in additional certificates then that is fine.
I presume that you are trying this over the mobile phone network all the time? You haven't tried it inside to see if it works there? I am not familiar with the exact spec of the Treo 700W as they aren't available on this side of the pond, so I don't know if it can connect to the LAN as well.
If you don't have LAN access then I would be tempted to get hold of the Windows Mobile 5 emulator and see what happens without the certificate internally. I am hesitant to suggest trying it from outside the LAN without the SSL certificate, as that would mean opening port 80 and all the security risks that brings.
Simon.
ASKER
I have attempted to use it internally as well, with the same results I'm afraid. Not that it really matters, but it's a Sprint PPC-6700, not a Treo, but I imagine the issue would be the same.
I suppose I could attempt replacing the certificate one more time. I can't help but wonder - you mention making sure the certificate resolves correctly. I *assume* you mean the cert-path back up the CA, but just in case, would it be possible that my cretificate might be resolving to the internal IP and not my external IP, again causing confusion?
It would be REALLY nice if the PDA let me see the "invalid" certificate, but such is simply not meant to be I guess.
I suppose I could attempt replacing the certificate one more time. I can't help but wonder - you mention making sure the certificate resolves correctly. I *assume* you mean the cert-path back up the CA, but just in case, would it be possible that my cretificate might be resolving to the internal IP and not my external IP, again causing confusion?
It would be REALLY nice if the PDA let me see the "invalid" certificate, but such is simply not meant to be I guess.
Sorry about the treo comment. I am working on two EAS questions at the moment - one is Treo and one is this one. I defiantly will not have seen the Sprint device as we don't have that network over here.
By certificate resolving I mean that the name on the certificates resolves. If the certificate is issued to mail.domain.com then the PDA needs to be able to resolve mail.domain.com
It can resolve to the internal name if you are on the internal network. That is what I meant by resolution - ensure that whether inside or outside the name resolves to the correct place - ultimately the Exchange server.
However EAS is very dependant on the mobile phone network - the push technology doesn't work over anything other than the mobile phone network.
EAS is much like RPC over HTTPS with the certificates. You cannot see the certificate or the error, it either works or it doesn't. That is why when testing we tell people to browse to certain directories to see if there is a certificate prompt. If you get a prompt then the feature will not work.
Simon.
By certificate resolving I mean that the name on the certificates resolves. If the certificate is issued to mail.domain.com then the PDA needs to be able to resolve mail.domain.com
It can resolve to the internal name if you are on the internal network. That is what I meant by resolution - ensure that whether inside or outside the name resolves to the correct place - ultimately the Exchange server.
However EAS is very dependant on the mobile phone network - the push technology doesn't work over anything other than the mobile phone network.
EAS is much like RPC over HTTPS with the certificates. You cannot see the certificate or the error, it either works or it doesn't. That is why when testing we tell people to browse to certain directories to see if there is a certificate prompt. If you get a prompt then the feature will not work.
Simon.
ASKER
Yeah, see, that's what has me baffled.
It *all* worked, without any effort, until we renamed the cert. Oddly, we renamed the cert *correctly* and that's when it broke.
I haven't been reliant on just the mobile network either. Trying to connect over the Internet using my wi-fi connection at home ALSO gives me a certificate error.
It *all* worked, without any effort, until we renamed the cert. Oddly, we renamed the cert *correctly* and that's when it broke.
I haven't been reliant on just the mobile network either. Trying to connect over the Internet using my wi-fi connection at home ALSO gives me a certificate error.
The certificate has to be the problem then. Look at the method for creating the certificate.
Otherwise go to RapidSSL and get one of their 30 day trial certificates and see whether that works. Their certificates don't work natively with the Windows Mobile Devices, but importing the root is easy enough.
Simon.
Otherwise go to RapidSSL and get one of their 30 day trial certificates and see whether that works. Their certificates don't work natively with the Windows Mobile Devices, but importing the root is easy enough.
Simon.
ASKER
I finally figured it out, and it was, indeed, a matter of not trusting the in-house certificate server.
It seems that in my hurry the certificate I had been importing was (absent-mindedly) the exchange server's cert, and not the CA's root cert. I just installed that root cert, and now that my PDA trusts our CA, it trusts the cert for our webmail as well. I'm finally back in business.
Thanks for your persistant assistance in troublshooting this issue, Sembee.
It seems that in my hurry the certificate I had been importing was (absent-mindedly) the exchange server's cert, and not the CA's root cert. I just installed that root cert, and now that my PDA trusts our CA, it trusts the cert for our webmail as well. I'm finally back in business.
Thanks for your persistant assistance in troublshooting this issue, Sembee.
ASKER