asked on
Exchange 2007 Autodiscover
I have recently completed a successful migration of multiple Exchange 2007 databases across to a new server in the same Exchange Organisation, the new server has the same roles installed as the original, which are as follows:-
- Hub Transport
- Client Access
- Mailbox
Everything is working fine, however when I run the test AutoConfiguration tool from Outlook I'm still receiving references to the old server, even though I have manually changed the paths using PowerShell. Here is the output:-
Internal OWA URL: https://internal_FQDN/owa - CORRECT
External OWA URL: https://external_FQDN/owa - CORRECT
Availability Service URL: https://old_server.domain.suffix/EWS/Exchange.asmx - INCORRECT
OOF URL: https://old_server.domain.suffix/EWS/Exchange.asmx - INCORRECT
OAB URL: https://external_FQDN/oab/<string> - CORRECT
I have set the new paths using the following commands:-
- Set-WebServicesVirtualDire
- Set-OwaVirtualDirectory
- Set-ClientAccessServer
- Set-OabvirtualDirectory
Some extra information which may be helpful, publicly available namespace for DNS, we own the domain. I have also imported a third-party SSL cert for the FQDN of our CAS server, however I now realise I probably should have included a SAN for Autodiscover but haven't done do.
- Hub Transport
- Client Access
- Mailbox
Everything is working fine, however when I run the test AutoConfiguration tool from Outlook I'm still receiving references to the old server, even though I have manually changed the paths using PowerShell. Here is the output:-
Internal OWA URL: https://internal_FQDN/owa - CORRECT
External OWA URL: https://external_FQDN/owa - CORRECT
Availability Service URL: https://old_server.domain.suffix/EWS/Exchange.asmx - INCORRECT
OOF URL: https://old_server.domain.suffix/EWS/Exchange.asmx - INCORRECT
OAB URL: https://external_FQDN/oab/<string> - CORRECT
I have set the new paths using the following commands:-
- Set-WebServicesVirtualDire
- Set-OwaVirtualDirectory
- Set-ClientAccessServer
- Set-OabvirtualDirectory
Some extra information which may be helpful, publicly available namespace for DNS, we own the domain. I have also imported a third-party SSL cert for the FQDN of our CAS server, however I now realise I probably should have included a SAN for Autodiscover but haven't done do.
Exchange
Last Comment
Peter Jones
ASKER CERTIFIED SOLUTION
Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
Also, are you doing a Server 2007 to Server 2007 move or are you moving to a newer version? The availability service only exists in Server 2007 (It was replaced in 2010, but is available for backwards compatibility). You'll also want to make sure you run IISreset after making changes to the web service URLs. In addition, the OOF and Availability URLs will depend on where your mailbox is. If your mailbox is located on the old server, it will return the old server's URL.
small correction. The script above should be -internalserviceuri not -autodiscoverserviceuri
ASKER
Thanks for the reply.
I have already issued this command, however the changes don't seem to be taking effect as it's still pointing to the old server. The database migration was a simple Exchange 2007 > Exchange 2007.
Just out of curiosity, the old Exchange server completely died, hence the migration, therefore it's currently offline. Will the SCP update with the old box offline? I can bring it back online temporarily if need be, however my plan is to decommission the box properly over the weekend. When I run
I already have the SRV record in place, however my external DNS changes don't seem to have taken effect as of yet. The SRV re-direct method seems like an absolute ball-ache, I'm wondering whether I should re-issue SSL with autodiscover.FQDN as a SAN? Any thoughts?
I have already issued this command, however the changes don't seem to be taking effect as it's still pointing to the old server. The database migration was a simple Exchange 2007 > Exchange 2007.
Just out of curiosity, the old Exchange server completely died, hence the migration, therefore it's currently offline. Will the SCP update with the old box offline? I can bring it back online temporarily if need be, however my plan is to decommission the box properly over the weekend. When I run
get-clientaccessserver
I already have the SRV record in place, however my external DNS changes don't seem to have taken effect as of yet. The SRV re-direct method seems like an absolute ball-ache, I'm wondering whether I should re-issue SSL with autodiscover.FQDN as a SAN? Any thoughts?
Experts Exchange has (a) saved my job multiple times, (b) saved me hours, days, and even weeks of work, and often (c) makes me look like a superhero! This place is MAGIC!
Walt Forbes
SOLUTION
Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a questionASKER
Looks like patience was the winner in the end.
An IISRESET and the allowance of my public SRV DNS record to publish was the key. Both Exchange connectivity analyser & Autoconfiguration tests now pass.
An IISRESET and the allowance of my public SRV DNS record to publish was the key. Both Exchange connectivity analyser & Autoconfiguration tests now pass.