Link to home
Start Free TrialLog in
Avatar of fgarufijr
fgarufijrFlag for United States of America

asked on

Outlook gives SSL Warning for Internal Exchange 2007 Users

My internal exchange 2007 users are recieving a SSL Certificate warning each time they try to connect using Outlook 2007. I'm almost positive that the problem is due to have a different internal domain name then my external domain name, and my SSL certificate is using my external domain name ( 3rd Party Geo-Trust Certificate ).

Internal Server Name = Exchange.Domain.ORG
SSL Certificate Name = Webmail.Domain.COM

OWA, POP3, and Outlook Anywhere clients are fine, they dont have this problem. Only internal Outlook 2007 users

I've tried changing the server name in Outlook on the Exchange Account Page on the internal clients to use the external name but upon clicking "Check Name", it immediately reverts back to the internal server name. How can I fix this?
ASKER CERTIFIED SOLUTION
Avatar of ATIG
ATIG
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of fgarufijr

ASKER

Its funny you responded to this... Just prior to posting this message, I actually found your blog and that article from doing an online search. I tried following it and ran into a few issues. I have a couple of questions:

1. I tried doing the Test-OutlookWebServices commandlet and I keep getting a 401 Authentication issue when running it for any user, or just letting it pick the user. Do you know how to fix this?

2. Do I want to set my internal URL and external URL to the same address??? Or should I make the Internal Exchange.Domain.ORG and External Webmail.Domain.COM??

I think I have a few other questions, but if we can get these figured out first, it might make a difference about any other questions I have :)

Thanks for the response and I look forward to your next one :)
Run it from a non CAS server... there is a know bug with that but was trying to find out if it was just in SP1 builds or RTM (guess I have my answer)

2. Depends on your configuration, the url you set to needs to equal the certificate that you have loaded on the box.
In my envrionment I have 2 CAS/Hub in an NLB all in the same site. I then set internal/external to the same since those server have a cert for mail.x.y

What is your configuration?
how many Cas server? all in same site? NLB?
also, work down through the DNS section then run your tests after that..... I just broke things down into pieces
This might sound like a REALLY stupid question, but how do I run it from a "non CAS server"???

I only have 1 Exchange server in my orginization. We migrated from E2k3 to E2k7. The E2k3 has been retired.

Because the URL needs to be equal to the certificate that I hav eloaded on the box, I'm assuming that means that both the Internal and External URL should be set to the same address?? 1 Exchange Server, 1 SSL certificate. Am I right???

Thanks...
Yep set all your urls the same then .....

Let me find out more about the bug in Sp1.... I have seen the 401 in  my envrionment  as well.  The Vm's I used for th blog are running Sp1 code :P

Sounds good....

The only 64 bit server running in my orginization is the Exchange Server. I'm assuming in order to install ESM on another server, I would need to install the 32 bit version??? If thats the case, do I just download the 32 bit version and only install ESM on that server?

Also, one more question... Could you explain to me why AutoDiscover corrects this problem? I was under the impression AutoDiscover was just an added feature to easily configure new Outlook clients without having to go through all the steps needed to do a manual configuration. How exactly does making these changes, change the way my current Outlook Exchange Clients connect and see the correct certificate?

Thanks! :)
Its called EMC now :P but yes there is a 32 bit version to load on clients

Yeah... I thing autodiscover is not clearn enough .

Outlook 2007 and E2k7 require this configuration for a bunch of features to work OL2k7 uses autodiscover to download the OAB, provide availability, Out of Office, etc... there is about 12 features in OL2k7 that need autodiscover to funcation.
Your OL2k7 client was connecting to the server to get access and the urls presented did not match the name it was looking for which is why you saw the cert mismatch. Once you set the url it became seemless.

I also got the answer about the 401

http://support.microsoft.com/?id=896861.
 In this case, I expect that behavior.  Reflexion attack stuff&.  Heres an interesting test method to verify thats what we are dealing with:

On the CAS server try the following URLS using IE on CAS server:

- https://netbiosname/Autodiscover/Autodiscover.xml :
It will prompt for credentials. After prompting a couple of times we get the following error:

Error: Access is Denied.

-  Use https://localhost/Autodiscover/Autodiscover.xml :
It will work fine and give an output.

You CAN turn it off with that DisableLoopbackCheck, but it leaves a hole.  Im looking at the other method, but dont know if it is going to fly.
I'm going to DisableLookBackCheck for testing purposes. Then I'm going to go back and re-do your blog instructions from start to end again and see where this gets me.

You talk about in the blog post about 'Configuring AutoDiscover via DNS", and the first line talks about being an 'alternative way' of setting it up. I'm assuming this to mean that everything before that is what has to be done, but that its isn't necessary to change anything in DNS ( internally or www ) for this to work?!?!?
for internal clients they will check the SCP to pull the autodiscover info... however I did not complete the configuration. I did not set the EWS,OAB etc.... in the SCP section

In the DNS section, I configured the EWS,OWA, ect...

You do not have to do the Autodiscover record in DNS for internal clients  as long as the SCP is set.

External clients would strictly use the DNS or the xml file to find its information. Internal clients will check for the SCP if it fails then they revert to DNS.

some pieces work togethor and some are sepearate.

Since I allow internal and remote then for me I need to set the SCP and do DNS..... everything is always relative to your configuration and needs.

but I dont configure every piece in every section... I just set the SCP with the set-clientaccessserver command and in the DNS section I set the EWS,OAB, etc....
SUCCESS!!!!!!  HAHAHAHA....

Well, atleast 90% success...

My internal Outlook clients are no longer getting a certificate warning message! :)  There is one thing I noticed though when doing the "Test-OutlookWebServices -Identity <user>" I'm getting the following when trying to connect to the OAB:

 1015   Information [EXCH]-The OAB is not configured for this user.

I'm getting this same error for each user I try the Test-OutlookWebServices for. I've used the Get-OabVirtualDirectory | fl Server,Name,InternalUrl,ExternalUrl command to verify that both internal name and external name are set to the address that I have my certificate for. I've also confimed inside the EMC that it has the same values.

My Outlook Anywhere clients also gives an error when doing a manual send/recieve that
Task 'Microsoft Exchange' reported error (0x8004010F) : 'The operation failed. An object cannot be found.' - The error code says that it wasn't able to contact the Offline Address Book.

Any Ideas????
Have you created an OAB?  I believe you said you dont have a PF did you enable webdistrobution?

Did you associate an OAB with the mail dbs
ATIG...

I accepted the solution and THANK YOU VERY MUCH for getting me through this! :)

I'm still having the problem with OAB, but I figure that its a little out of the scope of this question.

I would like to continue working on it though, if your willing to continue helping me... Would you like me to start a new question or continue in this one?
Sure ..... I will help you out :)
Thanks ATIG!!!

The problem now seems to be with ONLY my Outlook Anywhere clients. They are still recieving the : Task 'Microsoft Exchange' reported error (0x8004010F) : 'The operation failed. An object cannot be found.'

Test-OutlookWebServices -Identity <user> now shows it can connect to the OAB just fine. WebDistribution is enabled and it looks like my OAB is associated with my mail db's. I can goto https://webmail.domain.com/oab/<oabgen>/oab.xml ( I think thats the correct location ) from the outside world and upon logging in, I can see the xml file fine.

Any suggestions on why OAB is getting errors when Outlook Anywhere clients are manually doing a send/recieve?

Thanks
start up another question an I will track it down.
C:\Program Files\Microsoft\Exchange Server\ExchangeOAB on the CAS this is the location of your files for web distrobution there should be some folders there with data

Also, you can turn up logging on your OAB to see if its getting generated.  There is a link to a gui tool on my blog for cranking up the services instead of using EMS.

1. You did create an OAB
 -- EMC- org config-- offline address book
2. Do you have a PF?
3. web based distro enabled, include Global is checked
4. EMC-Server config -> mailbox - db properties--clients tab OAB is set