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 lUri : https://mail.externaldomain.co.uk/autodiscover/autod
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
OK, that sounds fine. Can you confirm:
A) You now have a certificate with 'exchangeserver.internaldo main.local ' as a Subject Alternative Name &
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
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.