asked on
CAS degraded, attempting to migrate mailboxes
I have a unique issue here and I am no understanding autodiscover and outlookanywhere config enough to get around it.
I have 2 sites with 1 Exchange 2013 box with all roles in each as my production environment. It is fully configured and functioning externally and internally.
My box at the primary site(second site is not internet facing) is sitting on a clustered storage space which is degraded and will not rebuild on the replacement disk, backup attempts crash the cluster disk so day by day data is further compromised by the minute.
My only choice was to attempt to install another box in the primary site and move the mailboxes.
I have deployed a new bow (Exchange 2013 CU21 all roles) and moved my mailbox for testing successfully. Internally everything functions fine for my account, externally autodiscover, owa, outlookanywher do not work.
I dont' seem to be visualizing the proxy functionality correctly or have made changes on the new CAS which is breaking the functionality.
Current config is as such:
= Have changed nothing on the degraded primary site server or the remote sites CAS/Mailbox server
- This may be where I screwed up, but it tested fine internally so I thought the changes had no affect due to the proxying
- Changed all web services URL's on the new primary site machine to match the degraded machine in preparation for the cutover after the mail box moves were completed.
- eg. degraded server autodiscover is mail.domain.com and new server is mail,domain.com for both internal and external (I am running split DNS) I am thinking this tested ok internally due to the outlooproviders and this may be the issue
- One other point is the Outlookproviders, when moving from 2007 to 2013 I struggled and probably fat fingered around to get this up. I have noticed in troubleshooting this that the providers have been changed from default setting and are hard coded to the SCP name (mail.domain.com)
Just need some clarification as to how this should actually be set up during this disaster migration phase to get all web services functioning for external users on the new box until the degraded server is decommissioned.
eg.What should the URL's be on the services of the new server (internal and external), does this second server need a public natting during this interim period or will the proxy functionality cover things, I have not nat'd it, was planning on just repointing the existing nat has the final step. Have I caused this issue by changing the outlookproviders…...etc.
Thanks in advance, hung out to dry here and cannot start the migrations until internal and external client functionality is working.
Chuck C
I have 2 sites with 1 Exchange 2013 box with all roles in each as my production environment. It is fully configured and functioning externally and internally.
My box at the primary site(second site is not internet facing) is sitting on a clustered storage space which is degraded and will not rebuild on the replacement disk, backup attempts crash the cluster disk so day by day data is further compromised by the minute.
My only choice was to attempt to install another box in the primary site and move the mailboxes.
I have deployed a new bow (Exchange 2013 CU21 all roles) and moved my mailbox for testing successfully. Internally everything functions fine for my account, externally autodiscover, owa, outlookanywher do not work.
I dont' seem to be visualizing the proxy functionality correctly or have made changes on the new CAS which is breaking the functionality.
Current config is as such:
= Have changed nothing on the degraded primary site server or the remote sites CAS/Mailbox server
- This may be where I screwed up, but it tested fine internally so I thought the changes had no affect due to the proxying
- Changed all web services URL's on the new primary site machine to match the degraded machine in preparation for the cutover after the mail box moves were completed.
- eg. degraded server autodiscover is mail.domain.com and new server is mail,domain.com for both internal and external (I am running split DNS) I am thinking this tested ok internally due to the outlooproviders and this may be the issue
- One other point is the Outlookproviders, when moving from 2007 to 2013 I struggled and probably fat fingered around to get this up. I have noticed in troubleshooting this that the providers have been changed from default setting and are hard coded to the SCP name (mail.domain.com)
Just need some clarification as to how this should actually be set up during this disaster migration phase to get all web services functioning for external users on the new box until the degraded server is decommissioned.
eg.What should the URL's be on the services of the new server (internal and external), does this second server need a public natting during this interim period or will the proxy functionality cover things, I have not nat'd it, was planning on just repointing the existing nat has the final step. Have I caused this issue by changing the outlookproviders…...etc.
Thanks in advance, hung out to dry here and cannot start the migrations until internal and external client functionality is working.
Chuck C
StorageExchangeInstallation
Last Comment
ccroasmun
ASKER
Autodiscover settings on new CAS, domain specific info change and underlined in the post here.
Set-ClientAccessServer –Identity newserverinternalname.domain.com –AutoDiscoverServiceIntern
Set-ClientAccessServer –Identity newserverinternalname.domain.com –AutoDiscoverServiceIntern
Did you created autodiscover and mail records pointing to internal and external IP of new exchange box?
probably you should point your external DNS hostnames (autodiscover and mail) to new exchange box public IP
Set virtual directories on new box (internal url and external URL to point to mail.domain.com
Also same time you could remove DNS records for autodiscover and mail pointing to degraded exchange box from internal and external DNS servers
this will ensure that users will connect to new exchange box and connection will be proxied to degraded server to access mailbox
mean time you can start mailbox migration, migrated users will eventually directly connected to new server only
I hope certificate is installed on new server and already applied to exchange services
probably you should point your external DNS hostnames (autodiscover and mail) to new exchange box public IP
Set virtual directories on new box (internal url and external URL to point to mail.domain.com
Also same time you could remove DNS records for autodiscover and mail pointing to degraded exchange box from internal and external DNS servers
this will ensure that users will connect to new exchange box and connection will be proxied to degraded server to access mailbox
mean time you can start mailbox migration, migrated users will eventually directly connected to new server only
I hope certificate is installed on new server and already applied to exchange services
ASKER
Mahesh,
Thank you very much for your reply. I am being hesitant about the reconfiguration as I do this very seldom (Only when we upgrade). I chose to leave the degraded server as the primary CAS, configured "as is" so if I made mistakes during the reconfiguration I wouldn't be buried in fixing that and be delayed on the mailbox migration.....I had originally considered this, but chose to try to get the moves started ASAP.
I did not create autodiscover and mail records for the new server. I planned on allowing the degraded server to continue it's functioning autodiscover services until mailbox moves are completed, and MX records point to our Symantec gateway so no need there. I have left Symantec relaying to the degraded server for now cause everything is workling.
I left external and internal dns pointing to the degraded server....but, as a test I configured all of the new servers URL's and authentication methods to match the degraded server. I was hoping I could do this to "stage" the config for cutover after moves, I figured this may work as DNS was pointing to the degraded server and these services on the new server wouldn't be hit until DNS was changed. Internal testing worked fine, but external is not working and why I posted.
Where I am stuck is whether the "staging" config I put on the new server, or the details how 2 CAS servers in the same site interact could be causing the issue.
Any clients with their mailboxes on the degraded server still function properly internally and externally. I would hate to break this too trying to move the web services first. I would like to just get the autodiscovery and proxying from the degraded to the new working.
Is there any caveats with having 2 separate non-HA CAS servers in the same site? Also recall how I previously(during the original migration from 2007 - 2013) hard coded the outlookproviders to mail.domain.com. Could that be causing external problems.
I understand having 1 CAS proxying OutlookAnywhere to multiple mailbox servers, but am I missing something with the degraded server having to proxy to another CAS which also hosts the mailboxes?...….
Thanks again!!!!
Thank you very much for your reply. I am being hesitant about the reconfiguration as I do this very seldom (Only when we upgrade). I chose to leave the degraded server as the primary CAS, configured "as is" so if I made mistakes during the reconfiguration I wouldn't be buried in fixing that and be delayed on the mailbox migration.....I had originally considered this, but chose to try to get the moves started ASAP.
I did not create autodiscover and mail records for the new server. I planned on allowing the degraded server to continue it's functioning autodiscover services until mailbox moves are completed, and MX records point to our Symantec gateway so no need there. I have left Symantec relaying to the degraded server for now cause everything is workling.
I left external and internal dns pointing to the degraded server....but, as a test I configured all of the new servers URL's and authentication methods to match the degraded server. I was hoping I could do this to "stage" the config for cutover after moves, I figured this may work as DNS was pointing to the degraded server and these services on the new server wouldn't be hit until DNS was changed. Internal testing worked fine, but external is not working and why I posted.
Where I am stuck is whether the "staging" config I put on the new server, or the details how 2 CAS servers in the same site interact could be causing the issue.
Any clients with their mailboxes on the degraded server still function properly internally and externally. I would hate to break this too trying to move the web services first. I would like to just get the autodiscovery and proxying from the degraded to the new working.
Is there any caveats with having 2 separate non-HA CAS servers in the same site? Also recall how I previously(during the original migration from 2007 - 2013) hard coded the outlookproviders to mail.domain.com. Could that be causing external problems.
I understand having 1 CAS proxying OutlookAnywhere to multiple mailbox servers, but am I missing something with the degraded server having to proxy to another CAS which also hosts the mailboxes?...….
Thanks again!!!!
You can keep dns configuration as you thought, what I suggested is exactly reverse what you are thinking.
I am thinking in view to decommission degraded server in some point of time, but its Ok you can keep all DNS records pointing to degraded server
Note that exchange 2013 CAS connects to mailbox GUIDs no matter mailbox is hosted on which exchange server, so if mailboxes are moved to another server CAS will eventually connect to another mailbox server
I don't se any issues with that
I am thinking in view to decommission degraded server in some point of time, but its Ok you can keep all DNS records pointing to degraded server
I understand having 1 CAS proxying OutlookAnywhere to multiple mailbox servers, but am I missing something with the degraded server having to proxy to another CAS which also hosts the mailboxes?...….
Note that exchange 2013 CAS connects to mailbox GUIDs no matter mailbox is hosted on which exchange server, so if mailboxes are moved to another server CAS will eventually connect to another mailbox server
I don't se any issues with that
ASKER
May I have broken some proxy communications by binding mail.domain.com to the new servers services since that FQDN is still pointing to the degraded box?
make external URL property on new box virtual directories blank and check
Else add one more mail and autodiscover record in dns pointing to new mailbox server in addition to degraded sever
Else add one more mail and autodiscover record in dns pointing to new mailbox server in addition to degraded sever
ASKER
Thanks, I'll give it a try. All clients services on the degraded server are functioning properly. This box as I understand it should have been able to immediately service clients of which had mailboxes on it without any config as I understand it. The web service refinement as I understand it should only be needed when cutting it over. Probably shouldn't have touched it yet??
You've been GREAT I appreciate it, every minute these mailboxes remain on the server worries me.
You've been GREAT I appreciate it, every minute these mailboxes remain on the server worries me.
note that autodiscoverserviceinterna
ASKER
Thanks, that is set in that manner. I am currently clearing the other service url's
ASKER
No luck, researching what impact my changes to the Outlookprovider during my 2007 - 2013 migration may be causing. I had differing reactions from different Outlook versions at the time and was bouncing around tweaking things until I got everything working. The current settings are:
Name Server CertPrincipalName TTL
---- ------ ----------------- ---
EXCH DegradedServerUnqualified msstd:mail.domain.com 1
EXPR DegradedServerUnqualified msstd:mail.domain.com 1
WEB DegradedServerUnqualified msstd:mail.domain.com 1
Name Server CertPrincipalName TTL
---- ------ ----------------- ---
EXCH DegradedServerUnqualified msstd:mail.domain.com 1
EXPR DegradedServerUnqualified msstd:mail.domain.com 1
WEB DegradedServerUnqualified msstd:mail.domain.com 1
ASKER
Also, cert is a multi host SAN with mail.domain.com as the first domain in the cert. I can nat a second IP to the new server and there is a usable domain in the cert, but it has been my understanding autodiscovery doesn't like to be bound to cert domains not at the top of the list.
Eg. I could do:
mail.colind.com to degraded server (as is now)
mail2.domain.com to (New server)………...Add public nat
This is the same cert on each server now, but mail2 entry is not the first in the list on the cert.
Eg. I could do:
mail.colind.com to degraded server (as is now)
mail2.domain.com to (New server)………...Add public nat
This is the same cert on each server now, but mail2 entry is not the first in the list on the cert.
ASKER
Found the issue, unfortunately it was a Kerberos issue caused by an SPN I registered which was in previous documentation I had recorded from my 2007 - 2013 migration. Once that was addressed proxy started working properly.
I need to thank Mahesh again for his attentive help. He was great
I need to thank Mahesh again for his attentive help. He was great
ASKER CERTIFIED SOLUTION
THIS SOLUTION 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.
The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.domain.com:443/Autodiscover/Autodiscover.xml for user ccroasmun@domain.com.
The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
Additional Details
A Web exception occurred because an HTTP 503 - ServiceUnavailable response was received from Unknown.
HTTP Response Headers:
request-id: 0dd484f2-e09f-440b-bd1a-cc
X-CalculatedBETarget: NEWSERVERINTERNALNAME.DOMA
Persistent-Auth: true
X-FEServer: DEGRADEDSERVERINTERNALUNQI
Content-Length: 0
Cache-Control: private
Date: Sat, 12 Jan 2019 17:35:36 GMT
Set-Cookie: ClientId=AFUUKTJRW0ITMDGLV
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Elapsed Time: 6049 ms.