tp-it-team
asked on
Fixing some client access problems in Exchange 2007
My predecessor ordered an incorrect SSL certificate for our Exchange 2007 server. The problem was that he only included external server name, not the internal, so after installing it, we started getting certificate errors in Outlook.
Please remember that I'm trying my best to guess what he was doing, I have no contact with that person anymore.
So, instead of ordering a correct cert once again, he applied a 'fix', something like this:
http://www.ntweekly.com/?p=94
I would like to take it back to how it all should be, I have a correct certificate installed now.
In order to reverse that 'fix', I deleted the DNS zone created by my predecessor. I'm not sure if its related or not but now the out of office assistant in outlook doesn't work on PC clients and MAC users are reporting that their email is not working. They are using Outlook for MACs. I maybe wrong but I suspect that it maybe something to do with client access settings on my Exchange.
Here is how it looks like now:
Outlook web access:
Internal: https://exchange.internaldomain.co.uk/owa
External: https://mail.externaldomain.co.uk/owa
For active sync I have only external address in internal field:
https://mail.externaldomain.co.uk/Microsoft-Server-Activesync
External field is empty.
Offline address book distribution is the same:
external url in internal url field and external url field empty.
here is what I have for internal auto discovery:
Name : EXCHANGE
AutoDiscoverServiceInterna
iscover.xml
External is just
Name : EXCHANGE
*External* :
I'm not sure IF these settings relate to out of office and mac problem but I guess that config is wrong and was altered so even internal clients are connecting using mail.externaldomain.co.uk as it was the only server name in the certificate. Can you help fixing that mess, please ? Ideally, I would like to get examples of the correct URL's, not just - 'ehh, use internal one in here.'.
Any other ideas or general guidelines on how to rationalize CAS settings will be greatly appreciated.
THANKS
Please remember that I'm trying my best to guess what he was doing, I have no contact with that person anymore.
So, instead of ordering a correct cert once again, he applied a 'fix', something like this:
http://www.ntweekly.com/?p=94
I would like to take it back to how it all should be, I have a correct certificate installed now.
In order to reverse that 'fix', I deleted the DNS zone created by my predecessor. I'm not sure if its related or not but now the out of office assistant in outlook doesn't work on PC clients and MAC users are reporting that their email is not working. They are using Outlook for MACs. I maybe wrong but I suspect that it maybe something to do with client access settings on my Exchange.
Here is how it looks like now:
Outlook web access:
Internal: https://exchange.internaldomain.co.uk/owa
External: https://mail.externaldomain.co.uk/owa
For active sync I have only external address in internal field:
https://mail.externaldomain.co.uk/Microsoft-Server-Activesync
External field is empty.
Offline address book distribution is the same:
external url in internal url field and external url field empty.
here is what I have for internal auto discovery:
Name : EXCHANGE
AutoDiscoverServiceInterna
iscover.xml
External is just
Name : EXCHANGE
*External* :
I'm not sure IF these settings relate to out of office and mac problem but I guess that config is wrong and was altered so even internal clients are connecting using mail.externaldomain.co.uk as it was the only server name in the certificate. Can you help fixing that mess, please ? Ideally, I would like to get examples of the correct URL's, not just - 'ehh, use internal one in here.'.
Any other ideas or general guidelines on how to rationalize CAS settings will be greatly appreciated.
THANKS
Last Comment
ASKER CERTIFIED SOLUTION
THIS SOLUTION IS ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
OK, that sounds fine. Can you confirm:
A) You now have a certificate with 'exchangeserver.internaldo
B) You have run the Exchange Management Shell commandlets to change the internal URLs for the web services to use 'https://exchangeserver.internaldomain.local/blahblahblah'
That's what we're after here.
A) You now have a certificate with 'exchangeserver.internaldo
B) You have run the Exchange Management Shell commandlets to change the internal URLs for the web services to use 'https://exchangeserver.internaldomain.local/blahblahblah'
That's what we're after here.
ASKER
Can you look at the txt file I attached ?
It's the output of test-outlookwebservices command.
test-outlookwebservices.txt
It's the output of test-outlookwebservices command.
test-outlookwebservices.txt
Exchange
Exchange is the server side of a collaborative application product that is part of the Microsoft Server infrastructure. Exchange's major features include email, calendaring, contacts and tasks, support for mobile and web-based access to information, and support for data storage.
213K
Questions
--
Followers
--
Top Experts
Get a personalized solution from industry experts
TRUSTED BY
ASKER
We have a default zone in place and that's fine.
Our cert only had external URL for email server, like mail.domain.com so there was a new dns zone mail.domain.com created with a record pointing at our internal mail server. Then, various CAS settings were changed so using that external url would actually point to internal IP. So far I deleted that zone and changed internal auto discovery to point to internal location, not external url. I hope it all makes sense.