• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 757
  • Last Modified:

Autodiscover and SSL Warnings during Exchange 2010 Migration.

Hi,

We are in the process of migration of Exchange 2007 to Exchange 2010. Suddenly we are start getting SSL security alert on every client machine.

autodiscover
Since our new servers are still not in production, users should only contact to our old mail server.

But I suspect all three new exchange server are registered in AutoDiscover site scope along with old server.

So I am just looking for way to un-register the new server from auto-discover site scope or the time being and when we ready to move mailboxes we will re-register them.

alert
All are register under same site scope, or is there any other temp way so that Outlook client does not search for these server right now.
0
ozzietek
Asked:
ozzietek
1 Solution
 
Miguel Angel Perez MuñozCommented:
Check if you are using self signed certificates on your new 2010 Exchange servers. Import on your Exchange 2010 servers your current certificate or buy one new.
0
 
Exchange_GeekCommented:
which box is your RPCClientAccessServer pointing to?

Get-MailboxDatabase | FT Name,RPC*

Regards,
Exchange_Geek
0
 
Satya PathakLead Technical ConsultantCommented:
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
tigermattCommented:
If this is indeed an Autodiscover SCP issue which is causing the certificate fault (I suspect so), then all you need to do is modify the service connection point (SCP) on the Exchange 2010 box to temporarily point to another FQDN which will present a valid SSL certificate.

The easiest route around this problem for you would be to update the SCP created for the Autodiscover service on the Exchange 2010 CAS to hand out the URL of one of the Exchange 2007 Autodiscover connection points. Since those are correctly configured with the proper certificates, this will eliminate the certificate issue. You will need to make a note to reverse this configuration when you get a certificate correctly installed on the Exchange 2010 server (not strictly necessary, but cleaner to do so).

To modify the SCP:
Set-ClientAccessServer "Name-of-Exchange-2010-CAS" -AutodiscoverServiceInternalUri https://name-of-a-valid-autodiscover-connection-point.domain.com/Autodiscover/Autodiscover.xml

Open in new window

Your valid autodiscover connection point would typically be autodiscover.company.com, which should be mapped via DNS (using split DNS where necessary) to the Exchange 2007 servers at this time. However, you could specify the internal name of one of the Exchange 2007 servers in that URL provided the internal name is also listed on their SSL certificates.

-Matt
0
 
ozzietekAuthor Commented:
Hi Guys, thanks for your comments, sorry for late reply, actually I had solved the problem on that day, by changing the firewall settings.  

I had set autodiscover URI on all four servers to External URL and point that external URL to my old server.
0
 
ozzietekAuthor Commented:
I've requested that this question be closed as follows:

Accepted answer: 0 points for ozzietek's comment #a38353839

for the following reason:

I resolved the issue on the same day... As i post the quesiton.
0
 
tigermattCommented:
>> I had set autodiscover URI on all four servers to External URL and point that external URL to my old server.

I hate hitting "Object" to these close requests, but with respect, I feel that was what was alluded to in my comment at http:#a38304403:

"...update the SCP created for the Autodiscover service on the Exchange 2010 CAS to hand out the URL of one of the Exchange 2007 Autodiscover connection points..."

"... autodiscover connection point would typically be autodiscover.company.com, which should be mapped via DNS (using split DNS where necessary) to the Exchange 2007 servers at this time..."

As that is ultimately what you did (using your firewall, rather than split DNS - both are just as good methods), I feel I must contest the closure on this occasion.

-Matt
0
 
tigermattCommented:
As per my objection message, I recommend Accept using http:#a38304403.

-Matt
0

Featured Post

Configuration Guide and Best Practices

Read the guide to learn how to orchestrate Data ONTAP, create application-consistent backups and enable fast recovery from NetApp storage snapshots. Version 9.5 also contains performance and scalability enhancements to meet the needs of the largest enterprise environments.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now