Ex2K7 - Certificate errors for internal clients using Outlook 2007

This may be a bit long winded so my apologies in advance!
We have a rather sticky problem with certificates on our new Exchange 2007
Client Access server set up. We are currently in the process of trying to
migrate from Ex2K3 to Ex2K7. We've moved a few test clients over to the new
Ex2K7 server and they are all getting certificate errors when Outlook 2007
starts up on domain joined machines (internal clients). The error states that
the site name that Outlook is looking for is different from what is on the
cert. And it is correct. Here is the whole sorry saga of our certificate
tragedy:
We are a school in the UK. We have a publicly registered domain name that
ends with .sch.uk. Our internal/private AD domain name is nearly identical to
our public domain name and also ends in .sch.uk (don’t ask, this was before
my time) and looks very much like a public domain name. Because of this, we
were unable to find a single commercial certificate provider that would
include our internal FQDNs to any UCC certificate we wanted. In the end, we
ended up purchasing a Digicert UCC cert that had only our external FQDNs for
the CAS server and autodiscover services. We tried to work around this
problem by enabling both our commercial cert as well as the default MS cert
that ships with Ex2K7 which we added all of our internal FQDNs to. The hope
was that the external clients would be able to use the commercial cert, while
the internal clients would be able to use the default simple cert. This
seemed to work for a brief time, but after a few weeks, Outlook 2K7 on the
internal clients began ignoring the internal certificate and started using
the commercial cert which, of course, didn't have any of the internal
information on it and hence they started getting the certificate error on
startup. After much wrestling with this issue, we made the decision to
register our internal domain name so that we could provide Digicert with a
"whois" for it and they would then be happy to add our internal FQDNs to our
commercial cert and we could decommission the MS default cert. However, I
then spoke to Nominet and was told that we could NOT register our internal
domain name because it has the .sch.uk suffix and since we already have one
..sch.uk domain name registered, we can't register another one.
We've been given two options by certificate providers, domain name
registrants and Nominet alike:
1. Rename our external domain name so that it is the same as our internal
domain name
2. Rename our internal domain name to use a suffix like .int or .local
Neither of these options is even slightly appealing to us so we are
desperately trying to find a work-around.
I am now aware that having two active certificates running on the same CAS
server is not supported. Is it possible to have two CAS servers in the same
organisation and to force internal clients to use a specific one for
autodiscover? If so, we could set the two up and just have the Digicert
commercial cert on one for external access and have the MS default cert
enabled on the other for internal access.
Any other thoughts or ideas would be greatly appreciated. Many thanks,
Adam

Is the internal URL WebServices Virtual Directory pointing to your external
registered domain that is included with the SAN Cert?

Get-WebServicesVirtualDirectory | FL


--
John Oliver, Jr
MCSE, MCT, CCNA
Exchange MVP 2009
Microsoft Certified Partner


"Adam" wrote in message
news:9C2006F1-B82A-4D6A-AFA3-31BC9E00279D@microsoft.com...
> This may be a bit long winded so my apologies in advance!
> We have a rather sticky problem with certificates on our new Exchange 2007
> Client Access server set up. We are currently in the process of trying to
> migrate from Ex2K3 to Ex2K7. We've moved a few test clients over to the
> new
> Ex2K7 server and they are all getting certificate errors when Outlook 2007
> starts up on domain joined machines (internal clients). The error states
> that
> the site name that Outlook is looking for is different from what is on the
> cert. And it is correct. Here is the whole sorry saga of our certificate
> tragedy:
> We are a school in the UK. We have a publicly registered domain name that
> ends with .sch.uk. Our internal/private AD domain name is nearly identical
> to
> our public domain name and also ends in .sch.uk (don’t ask, this was
> before
> my time) and looks very much like a public domain name. Because of this,
> we
> were unable to find a single commercial certificate provider that would
> include our internal FQDNs to any UCC certificate we wanted. In the end,
> we
> ended up purchasing a Digicert UCC cert that had only our external FQDNs
> for
> the CAS server and autodiscover services. We tried to work around this
> problem by enabling both our commercial cert as well as the default MS
> cert
> that ships with Ex2K7 which we added all of our internal FQDNs to. The
> hope
> was that the external clients would be able to use the commercial cert,
> while
> the internal clients would be able to use the default simple cert. This
> seemed to work for a brief time, but after a few weeks, Outlook 2K7 on the
> internal clients began ignoring the internal certificate and started using
> the commercial cert which, of course, didn't have any of the internal
> information on it and hence they started getting the certificate error on
> startup. After much wrestling with this issue, we made the decision to
> register our internal domain name so that we could provide Digicert with a
> "whois" for it and they would then be happy to add our internal FQDNs to
> our
> commercial cert and we could decommission the MS default cert. However, I
> then spoke to Nominet and was told that we could NOT register our internal
> domain name because it has the .sch.uk suffix and since we already have
> one
> .sch.uk domain name registered, we can't register another one.
> We've been given two options by certificate providers, domain name
> registrants and Nominet alike:
> 1. Rename our external domain name so that it is the same as our internal
> domain name
> 2. Rename our internal domain name to use a suffix like .int or .local
> Neither of these options is even slightly appealing to us so we are
> desperately trying to find a work-around.
> I am now aware that having two active certificates running on the same CAS
> server is not supported. Is it possible to have two CAS servers in the
> same
> organisation and to force internal clients to use a specific one for
> autodiscover? If so, we could set the two up and just have the Digicert
> commercial cert on one for external access and have the MS default cert
> enabled on the other for internal access.
> Any other thoughts or ideas would be greatly appreciated. Many thanks,
> Adam
>

John,
No, the internal URL for the WebServices directory contains the internal
FQDN of our client access server.

As a side note, I've been able to stop the security warnings regarding the
site name mismatch on internal Outlook clients by running the
"set-clientaccessserver" command to change the servicebindinginformation
attribute of the SCP object so that it matches what is listed on our UC
certificate which is the external FQDN of our CAS server. However, because
all of the internal URLs still list the internal FQDN of our client access
server, the autodiscover service fails on internal Outlook 2007 clients. This
doesn't seem to be having any negative impact on their functionality as of
yet but it isn't ideal. According to MS KB article 940726, in order to change
these internal URLs so that they match the external FQDN of the CAS server,
we'd need to add a host record for that external FQDN to our DNS that
resolves to the internal IP address of the CAS server. The only way I can
think of achieving this is via a spilt DNS configuration which simply
wouldn't work in our environment. I may just try testing this by changing
those internal URLs to match our external FQDN and see of the DNS host record
is really necessary. Thanks for you time and do let me know if you have any
other thoughts on this.
Adam

"John Oliver, Jr. [MVP]" wrote:

> Is the internal URL WebServices Virtual Directory pointing to your external
> registered domain that is included with the SAN Cert?
>
> Get-WebServicesVirtualDirectory | FL
>
>
> --
> John Oliver, Jr
> MCSE, MCT, CCNA
> Exchange MVP 2009
> Microsoft Certified Partner
>
>
> "Adam" wrote in message
> news:9C2006F1-B82A-4D6A-AFA3-31BC9E00279D@microsoft.com...
> > This may be a bit long winded so my apologies in advance!
> > We have a rather sticky problem with certificates on our new Exchange 2007
> > Client Access server set up. We are currently in the process of trying to
> > migrate from Ex2K3 to Ex2K7. We've moved a few test clients over to the
> > new
> > Ex2K7 server and they are all getting certificate errors when Outlook 2007
> > starts up on domain joined machines (internal clients). The error states
> > that
> > the site name that Outlook is looking for is different from what is on the
> > cert. And it is correct. Here is the whole sorry saga of our certificate
> > tragedy:
> > We are a school in the UK. We have a publicly registered domain name that
> > ends with .sch.uk. Our internal/private AD domain name is nearly identical
> > to
> > our public domain name and also ends in .sch.uk (don’t ask, this was
> > before
> > my time) and looks very much like a public domain name. Because of this,
> > we
> > were unable to find a single commercial certificate provider that would
> > include our internal FQDNs to any UCC certificate we wanted. In the end,
> > we
> > ended up purchasing a Digicert UCC cert that had only our external FQDNs
> > for
> > the CAS server and autodiscover services. We tried to work around this
> > problem by enabling both our commercial cert as well as the default MS
> > cert
> > that ships with Ex2K7 which we added all of our internal FQDNs to. The
> > hope
> > was that the external clients would be able to use the commercial cert,
> > while
> > the internal clients would be able to use the default simple cert. This
> > seemed to work for a brief time, but after a few weeks, Outlook 2K7 on the
> > internal clients began ignoring the internal certificate and started using
> > the commercial cert which, of course, didn't have any of the internal
> > information on it and hence they started getting the certificate error on
> > startup. After much wrestling with this issue, we made the decision to
> > register our internal domain name so that we could provide Digicert with a
> > "whois" for it and they would then be happy to add our internal FQDNs to
> > our
> > commercial cert and we could decommission the MS default cert. However, I
> > then spoke to Nominet and was told that we could NOT register our internal
> > domain name because it has the .sch.uk suffix and since we already have
> > one
> > .sch.uk domain name registered, we can't register another one.
> > We've been given two options by certificate providers, domain name
> > registrants and Nominet alike:
> > 1. Rename our external domain name so that it is the same as our internal
> > domain name
> > 2. Rename our internal domain name to use a suffix like .int or .local
> > Neither of these options is even slightly appealing to us so we are
> > desperately trying to find a work-around.
> > I am now aware that having two active certificates running on the same CAS
> > server is not supported. Is it possible to have two CAS servers in the
> > same
> > organisation and to force internal clients to use a specific one for
> > autodiscover? If so, we could set the two up and just have the Digicert
> > commercial cert on one for external access and have the MS default cert
> > enabled on the other for internal access.
> > Any other thoughts or ideas would be greatly appreciated. Many thanks,
> > Adam
> >

Would it be possible to set up separate URLs for exteral and internal access?
In other words, have a set of internal URLs for external access that have the
external FQDNs and another set for internal access that contain the CAS
server's internal FQDNs?

"Adam" wrote:

> John,
> No, the internal URL for the WebServices directory contains the internal
> FQDN of our client access server.
>
> As a side note, I've been able to stop the security warnings regarding the
> site name mismatch on internal Outlook clients by running the
> "set-clientaccessserver" command to change the servicebindinginformation
> attribute of the SCP object so that it matches what is listed on our UC
> certificate which is the external FQDN of our CAS server. However, because
> all of the internal URLs still list the internal FQDN of our client access
> server, the autodiscover service fails on internal Outlook 2007 clients. This
> doesn't seem to be having any negative impact on their functionality as of
> yet but it isn't ideal. According to MS KB article 940726, in order to change
> these internal URLs so that they match the external FQDN of the CAS server,
> we'd need to add a host record for that external FQDN to our DNS that
> resolves to the internal IP address of the CAS server. The only way I can
> think of achieving this is via a spilt DNS configuration which simply
> wouldn't work in our environment. I may just try testing this by changing
> those internal URLs to match our external FQDN and see of the DNS host record
> is really necessary. Thanks for you time and do let me know if you have any
> other thoughts on this.
> Adam
>
> "John Oliver, Jr. [MVP]" wrote:
>
> > Is the internal URL WebServices Virtual Directory pointing to your external
> > registered domain that is included with the SAN Cert?
> >
> > Get-WebServicesVirtualDirectory | FL
> >
> >
> > --
> > John Oliver, Jr
> > MCSE, MCT, CCNA
> > Exchange MVP 2009
> > Microsoft Certified Partner
> >
> >
> > "Adam" wrote in message
> > news:9C2006F1-B82A-4D6A-AFA3-31BC9E00279D@microsoft.com...
> > > This may be a bit long winded so my apologies in advance!
> > > We have a rather sticky problem with certificates on our new Exchange 2007
> > > Client Access server set up. We are currently in the process of trying to
> > > migrate from Ex2K3 to Ex2K7. We've moved a few test clients over to the
> > > new
> > > Ex2K7 server and they are all getting certificate errors when Outlook 2007
> > > starts up on domain joined machines (internal clients). The error states
> > > that
> > > the site name that Outlook is looking for is different from what is on the
> > > cert. And it is correct. Here is the whole sorry saga of our certificate
> > > tragedy:
> > > We are a school in the UK. We have a publicly registered domain name that
> > > ends with .sch.uk. Our internal/private AD domain name is nearly identical
> > > to
> > > our public domain name and also ends in .sch.uk (don’t ask, this was
> > > before
> > > my time) and looks very much like a public domain name. Because of this,
> > > we
> > > were unable to find a single commercial certificate provider that would
> > > include our internal FQDNs to any UCC certificate we wanted. In the end,
> > > we
> > > ended up purchasing a Digicert UCC cert that had only our external FQDNs
> > > for
> > > the CAS server and autodiscover services. We tried to work around this
> > > problem by enabling both our commercial cert as well as the default MS
> > > cert
> > > that ships with Ex2K7 which we added all of our internal FQDNs to. The
> > > hope
> > > was that the external clients would be able to use the commercial cert,
> > > while
> > > the internal clients would be able to use the default simple cert. This
> > > seemed to work for a brief time, but after a few weeks, Outlook 2K7 on the
> > > internal clients began ignoring the internal certificate and started using
> > > the commercial cert which, of course, didn't have any of the internal
> > > information on it and hence they started getting the certificate error on
> > > startup. After much wrestling with this issue, we made the decision to
> > > register our internal domain name so that we could provide Digicert with a
> > > "whois" for it and they would then be happy to add our internal FQDNs to
> > > our
> > > commercial cert and we could decommission the MS default cert. However, I
> > > then spoke to Nominet and was told that we could NOT register our internal
> > > domain name because it has the .sch.uk suffix and since we already have
> > > one
> > > .sch.uk domain name registered, we can't register another one.
> > > We've been given two options by certificate providers, domain name
> > > registrants and Nominet alike:
> > > 1. Rename our external domain name so that it is the same as our internal
> > > domain name
> > > 2. Rename our internal domain name to use a suffix like .int or .local
> > > Neither of these options is even slightly appealing to us so we are
> > > desperately trying to find a work-around.
> > > I am now aware that having two active certificates running on the same CAS
> > > server is not supported. Is it possible to have two CAS servers in the
> > > same
> > > organisation and to force internal clients to use a specific one for
> > > autodiscover? If so, we could set the two up and just have the Digicert
> > > commercial cert on one for external access and have the MS default cert
> > > enabled on the other for internal access.
> > > Any other thoughts or ideas would be greatly appreciated. Many thanks,
> > > Adam
> > >

You would be better served to keep them the same. You would not need a
split DNS to achieve this, you can create a Forward Lookup Zone in DNS to
match your internal/external url, mail.sch.uk for example. Create Host
record of the internal IP of your Exchange Server. Now test internally from
command prompt that mail.shc.uk resolves to this IP. No need for split DNS
if you follow this route.

--
John Oliver, Jr
MCSE, MCT, CCNA
Exchange MVP 2009
Microsoft Certified Partner


"Adam" wrote in message
news:7652B225-F7D8-4609-8FF9-89094426FE64@microsoft.com...
> Would it be possible to set up separate URLs for exteral and internal
> access?
> In other words, have a set of internal URLs for external access that have
> the
> external FQDNs and another set for internal access that contain the CAS
> server's internal FQDNs?
>
> "Adam" wrote:
>
>> John,
>> No, the internal URL for the WebServices directory contains the internal
>> FQDN of our client access server.
>>
>> As a side note, I've been able to stop the security warnings regarding
>> the
>> site name mismatch on internal Outlook clients by running the
>> "set-clientaccessserver" command to change the servicebindinginformation
>> attribute of the SCP object so that it matches what is listed on our UC
>> certificate which is the external FQDN of our CAS server. However,
>> because
>> all of the internal URLs still list the internal FQDN of our client
>> access
>> server, the autodiscover service fails on internal Outlook 2007 clients.
>> This
>> doesn't seem to be having any negative impact on their functionality as
>> of
>> yet but it isn't ideal. According to MS KB article 940726, in order to
>> change
>> these internal URLs so that they match the external FQDN of the CAS
>> server,
>> we'd need to add a host record for that external FQDN to our DNS that
>> resolves to the internal IP address of the CAS server. The only way I can
>> think of achieving this is via a spilt DNS configuration which simply
>> wouldn't work in our environment. I may just try testing this by changing
>> those internal URLs to match our external FQDN and see of the DNS host
>> record
>> is really necessary. Thanks for you time and do let me know if you have
>> any
>> other thoughts on this.
>> Adam
>>
>> "John Oliver, Jr. [MVP]" wrote:
>>
>> > Is the internal URL WebServices Virtual Directory pointing to your
>> > external
>> > registered domain that is included with the SAN Cert?
>> >
>> > Get-WebServicesVirtualDirectory | FL
>> >
>> >
>> > --
>> > John Oliver, Jr
>> > MCSE, MCT, CCNA
>> > Exchange MVP 2009
>> > Microsoft Certified Partner
>> >
>> >
>> > "Adam" wrote in message
>> > news:9C2006F1-B82A-4D6A-AFA3-31BC9E00279D@microsoft.com...
>> > > This may be a bit long winded so my apologies in advance!
>> > > We have a rather sticky problem with certificates on our new Exchange
>> > > 2007
>> > > Client Access server set up. We are currently in the process of
>> > > trying to
>> > > migrate from Ex2K3 to Ex2K7. We've moved a few test clients over to
>> > > the
>> > > new
>> > > Ex2K7 server and they are all getting certificate errors when Outlook
>> > > 2007
>> > > starts up on domain joined machines (internal clients). The error
>> > > states
>> > > that
>> > > the site name that Outlook is looking for is different from what is
>> > > on the
>> > > cert. And it is correct. Here is the whole sorry saga of our
>> > > certificate
>> > > tragedy:
>> > > We are a school in the UK. We have a publicly registered domain name
>> > > that
>> > > ends with .sch.uk. Our internal/private AD domain name is nearly
>> > > identical
>> > > to
>> > > our public domain name and also ends in .sch.uk (don’t ask, this was
>> > > before
>> > > my time) and looks very much like a public domain name. Because of
>> > > this,
>> > > we
>> > > were unable to find a single commercial certificate provider that
>> > > would
>> > > include our internal FQDNs to any UCC certificate we wanted. In the
>> > > end,
>> > > we
>> > > ended up purchasing a Digicert UCC cert that had only our external
>> > > FQDNs
>> > > for
>> > > the CAS server and autodiscover services. We tried to work around
>> > > this
>> > > problem by enabling both our commercial cert as well as the default
>> > > MS
>> > > cert
>> > > that ships with Ex2K7 which we added all of our internal FQDNs to.
>> > > The
>> > > hope
>> > > was that the external clients would be able to use the commercial
>> > > cert,
>> > > while
>> > > the internal clients would be able to use the default simple cert.
>> > > This
>> > > seemed to work for a brief time, but after a few weeks, Outlook 2K7
>> > > on the
>> > > internal clients began ignoring the internal certificate and started
>> > > using
>> > > the commercial cert which, of course, didn't have any of the internal
>> > > information on it and hence they started getting the certificate
>> > > error on
>> > > startup. After much wrestling with this issue, we made the decision
>> > > to
>> > > register our internal domain name so that we could provide Digicert
>> > > with a
>> > > "whois" for it and they would then be happy to add our internal FQDNs
>> > > to
>> > > our
>> > > commercial cert and we could decommission the MS default cert.
>> > > However, I
>> > > then spoke to Nominet and was told that we could NOT register our
>> > > internal
>> > > domain name because it has the .sch.uk suffix and since we already
>> > > have
>> > > one
>> > > .sch.uk domain name registered, we can't register another one.
>> > > We've been given two options by certificate providers, domain name
>> > > registrants and Nominet alike:
>> > > 1. Rename our external domain name so that it is the same as our
>> > > internal
>> > > domain name
>> > > 2. Rename our internal domain name to use a suffix like .int or
>> > > .local
>> > > Neither of these options is even slightly appealing to us so we are
>> > > desperately trying to find a work-around.
>> > > I am now aware that having two active certificates running on the
>> > > same CAS
>> > > server is not supported. Is it possible to have two CAS servers in
>> > > the
>> > > same
>> > > organisation and to force internal clients to use a specific one for
>> > > autodiscover? If so, we could set the two up and just have the
>> > > Digicert
>> > > commercial cert on one for external access and have the MS default
>> > > cert
>> > > enabled on the other for internal access.
>> > > Any other thoughts or ideas would be greatly appreciated. Many
>> > > thanks,
>> > > Adam
>> > >

John,
That sounds very sensible and oddly enough, another colleague of mine was
just discussing something very similar to that yesterday. I will talk it over
with the team and see if they'll agree to let me test this. If they do and if
this resolves the issue, I'll post it here.Thanks again for your time,
Adam

"John Oliver, Jr. [MVP]" wrote:

> You would be better served to keep them the same. You would not need a
> split DNS to achieve this, you can create a Forward Lookup Zone in DNS to
> match your internal/external url, mail.sch.uk for example. Create Host
> record of the internal IP of your Exchange Server. Now test internally from
> command prompt that mail.shc.uk resolves to this IP. No need for split DNS
> if you follow this route.
>
> --
> John Oliver, Jr
> MCSE, MCT, CCNA
> Exchange MVP 2009
> Microsoft Certified Partner
>
>
> "Adam" wrote in message
> news:7652B225-F7D8-4609-8FF9-89094426FE64@microsoft.com...
> > Would it be possible to set up separate URLs for exteral and internal
> > access?
> > In other words, have a set of internal URLs for external access that have
> > the
> > external FQDNs and another set for internal access that contain the CAS
> > server's internal FQDNs?
> >
> > "Adam" wrote:
> >
> >> John,
> >> No, the internal URL for the WebServices directory contains the internal
> >> FQDN of our client access server.
> >>
> >> As a side note, I've been able to stop the security warnings regarding
> >> the
> >> site name mismatch on internal Outlook clients by running the
> >> "set-clientaccessserver" command to change the servicebindinginformation
> >> attribute of the SCP object so that it matches what is listed on our UC
> >> certificate which is the external FQDN of our CAS server. However,
> >> because
> >> all of the internal URLs still list the internal FQDN of our client
> >> access
> >> server, the autodiscover service fails on internal Outlook 2007 clients.
> >> This
> >> doesn't seem to be having any negative impact on their functionality as
> >> of
> >> yet but it isn't ideal. According to MS KB article 940726, in order to
> >> change
> >> these internal URLs so that they match the external FQDN of the CAS
> >> server,
> >> we'd need to add a host record for that external FQDN to our DNS that
> >> resolves to the internal IP address of the CAS server. The only way I can
> >> think of achieving this is via a spilt DNS configuration which simply
> >> wouldn't work in our environment. I may just try testing this by changing
> >> those internal URLs to match our external FQDN and see of the DNS host
> >> record
> >> is really necessary. Thanks for you time and do let me know if you have
> >> any
> >> other thoughts on this.
> >> Adam
> >>
> >> "John Oliver, Jr. [MVP]" wrote:
> >>
> >> > Is the internal URL WebServices Virtual Directory pointing to your
> >> > external
> >> > registered domain that is included with the SAN Cert?
> >> >
> >> > Get-WebServicesVirtualDirectory | FL
> >> >
> >> >
> >> > --
> >> > John Oliver, Jr
> >> > MCSE, MCT, CCNA
> >> > Exchange MVP 2009
> >> > Microsoft Certified Partner
> >> >
> >> >
> >> > "Adam" wrote in message
> >> > news:9C2006F1-B82A-4D6A-AFA3-31BC9E00279D@microsoft.com...
> >> > > This may be a bit long winded so my apologies in advance!
> >> > > We have a rather sticky problem with certificates on our new Exchange
> >> > > 2007
> >> > > Client Access server set up. We are currently in the process of
> >> > > trying to
> >> > > migrate from Ex2K3 to Ex2K7. We've moved a few test clients over to
> >> > > the
> >> > > new
> >> > > Ex2K7 server and they are all getting certificate errors when Outlook
> >> > > 2007
> >> > > starts up on domain joined machines (internal clients). The error
> >> > > states
> >> > > that
> >> > > the site name that Outlook is looking for is different from what is
> >> > > on the
> >> > > cert. And it is correct. Here is the whole sorry saga of our
> >> > > certificate
> >> > > tragedy:
> >> > > We are a school in the UK. We have a publicly registered domain name
> >> > > that
> >> > > ends with .sch.uk. Our internal/private AD domain name is nearly
> >> > > identical
> >> > > to
> >> > > our public domain name and also ends in .sch.uk (don’t ask, this was
> >> > > before
> >> > > my time) and looks very much like a public domain name. Because of
> >> > > this,
> >> > > we
> >> > > were unable to find a single commercial certificate provider that
> >> > > would
> >> > > include our internal FQDNs to any UCC certificate we wanted. In the
> >> > > end,
> >> > > we
> >> > > ended up purchasing a Digicert UCC cert that had only our external
> >> > > FQDNs
> >> > > for
> >> > > the CAS server and autodiscover services. We tried to work around
> >> > > this
> >> > > problem by enabling both our commercial cert as well as the default
> >> > > MS
> >> > > cert
> >> > > that ships with Ex2K7 which we added all of our internal FQDNs to.
> >> > > The
> >> > > hope
> >> > > was that the external clients would be able to use the commercial
> >> > > cert,
> >> > > while
> >> > > the internal clients would be able to use the default simple cert.
> >> > > This
> >> > > seemed to work for a brief time, but after a few weeks, Outlook 2K7
> >> > > on the
> >> > > internal clients began ignoring the internal certificate and started
> >> > > using
> >> > > the commercial cert which, of course, didn't have any of the internal
> >> > > information on it and hence they started getting the certificate
> >> > > error on
> >> > > startup. After much wrestling with this issue, we made the decision
> >> > > to
> >> > > register our internal domain name so that we could provide Digicert
> >> > > with a
> >> > > "whois" for it and they would then be happy to add our internal FQDNs
> >> > > to
> >> > > our
> >> > > commercial cert and we could decommission the MS default cert.
> >> > > However, I
> >> > > then spoke to Nominet and was told that we could NOT register our
> >> > > internal
> >> > > domain name because it has the .sch.uk suffix and since we already
> >> > > have
> >> > > one
> >> > > .sch.uk domain name registered, we can't register another one.
> >> > > We've been given two options by certificate providers, domain name
> >> > > registrants and Nominet alike:
> >> > > 1. Rename our external domain name so that it is the same as our
> >> > > internal
> >> > > domain name
> >> > > 2. Rename our internal domain name to use a suffix like .int or
> >> > > .local
> >> > > Neither of these options is even slightly appealing to us so we are
> >> > > desperately trying to find a work-around.
> >> > > I am now aware that having two active certificates running on the
> >> > > same CAS
> >> > > server is not supported. Is it possible to have two CAS servers in
> >> > > the
> >> > > same
> >> > > organisation and to force internal clients to use a specific one for
> >> > > autodiscover? If so, we could set the two up and just have the
> >> > > Digicert
> >> > > commercial cert on one for external access and have the MS default
> >> > > cert
> >> > > enabled on the other for internal access.
> >> > > Any other thoughts or ideas would be greatly appreciated. Many
> >> > > thanks,
> >> > > Adam
> >> > >

John,
Your solution was spot on. I created a new forward lookup zone in DNS for
our external domain name, then populated it with a single host record for our
external CAS server name and resolved it to the internal IP address of the
CAS server. Tested that I could ping it...all good. I then changed all of the
relevant internal URLs to match the external FQDN on our UC cert (i.e. -
https://ourserver.ourexternaldomain....todiscover.xml).
Then tested that I could get to that address in a browser...was asked for my
credentials, put them in and got the expected web page result. Finally,
tested autodiscover on Outlook and we are golden! Thanks so much for your
help.
Adam

"John Oliver, Jr. [MVP]" wrote:

> You would be better served to keep them the same. You would not need a
> split DNS to achieve this, you can create a Forward Lookup Zone in DNS to
> match your internal/external url, mail.sch.uk for example. Create Host
> record of the internal IP of your Exchange Server. Now test internally from
> command prompt that mail.shc.uk resolves to this IP. No need for split DNS
> if you follow this route.
>
> --
> John Oliver, Jr
> MCSE, MCT, CCNA
> Exchange MVP 2009
> Microsoft Certified Partner
>
>
> "Adam" wrote in message
> news:7652B225-F7D8-4609-8FF9-89094426FE64@microsoft.com...
> > Would it be possible to set up separate URLs for exteral and internal
> > access?
> > In other words, have a set of internal URLs for external access that have
> > the
> > external FQDNs and another set for internal access that contain the CAS
> > server's internal FQDNs?
> >
> > "Adam" wrote:
> >
> >> John,
> >> No, the internal URL for the WebServices directory contains the internal
> >> FQDN of our client access server.
> >>
> >> As a side note, I've been able to stop the security warnings regarding
> >> the
> >> site name mismatch on internal Outlook clients by running the
> >> "set-clientaccessserver" command to change the servicebindinginformation
> >> attribute of the SCP object so that it matches what is listed on our UC
> >> certificate which is the external FQDN of our CAS server. However,
> >> because
> >> all of the internal URLs still list the internal FQDN of our client
> >> access
> >> server, the autodiscover service fails on internal Outlook 2007 clients.
> >> This
> >> doesn't seem to be having any negative impact on their functionality as
> >> of
> >> yet but it isn't ideal. According to MS KB article 940726, in order to
> >> change
> >> these internal URLs so that they match the external FQDN of the CAS
> >> server,
> >> we'd need to add a host record for that external FQDN to our DNS that
> >> resolves to the internal IP address of the CAS server. The only way I can
> >> think of achieving this is via a spilt DNS configuration which simply
> >> wouldn't work in our environment. I may just try testing this by changing
> >> those internal URLs to match our external FQDN and see of the DNS host
> >> record
> >> is really necessary. Thanks for you time and do let me know if you have
> >> any
> >> other thoughts on this.
> >> Adam
> >>
> >> "John Oliver, Jr. [MVP]" wrote:
> >>
> >> > Is the internal URL WebServices Virtual Directory pointing to your
> >> > external
> >> > registered domain that is included with the SAN Cert?
> >> >
> >> > Get-WebServicesVirtualDirectory | FL
> >> >
> >> >
> >> > --
> >> > John Oliver, Jr
> >> > MCSE, MCT, CCNA
> >> > Exchange MVP 2009
> >> > Microsoft Certified Partner
> >> >
> >> >
> >> > "Adam" wrote in message
> >> > news:9C2006F1-B82A-4D6A-AFA3-31BC9E00279D@microsoft.com...
> >> > > This may be a bit long winded so my apologies in advance!
> >> > > We have a rather sticky problem with certificates on our new Exchange
> >> > > 2007
> >> > > Client Access server set up. We are currently in the process of
> >> > > trying to
> >> > > migrate from Ex2K3 to Ex2K7. We've moved a few test clients over to
> >> > > the
> >> > > new
> >> > > Ex2K7 server and they are all getting certificate errors when Outlook
> >> > > 2007
> >> > > starts up on domain joined machines (internal clients). The error
> >> > > states
> >> > > that
> >> > > the site name that Outlook is looking for is different from what is
> >> > > on the
> >> > > cert. And it is correct. Here is the whole sorry saga of our
> >> > > certificate
> >> > > tragedy:
> >> > > We are a school in the UK. We have a publicly registered domain name
> >> > > that
> >> > > ends with .sch.uk. Our internal/private AD domain name is nearly
> >> > > identical
> >> > > to
> >> > > our public domain name and also ends in .sch.uk (don’t ask, this was
> >> > > before
> >> > > my time) and looks very much like a public domain name. Because of
> >> > > this,
> >> > > we
> >> > > were unable to find a single commercial certificate provider that
> >> > > would
> >> > > include our internal FQDNs to any UCC certificate we wanted. In the
> >> > > end,
> >> > > we
> >> > > ended up purchasing a Digicert UCC cert that had only our external
> >> > > FQDNs
> >> > > for
> >> > > the CAS server and autodiscover services. We tried to work around
> >> > > this
> >> > > problem by enabling both our commercial cert as well as the default
> >> > > MS
> >> > > cert
> >> > > that ships with Ex2K7 which we added all of our internal FQDNs to.
> >> > > The
> >> > > hope
> >> > > was that the external clients would be able to use the commercial
> >> > > cert,
> >> > > while
> >> > > the internal clients would be able to use the default simple cert.
> >> > > This
> >> > > seemed to work for a brief time, but after a few weeks, Outlook 2K7
> >> > > on the
> >> > > internal clients began ignoring the internal certificate and started
> >> > > using
> >> > > the commercial cert which, of course, didn't have any of the internal
> >> > > information on it and hence they started getting the certificate
> >> > > error on
> >> > > startup. After much wrestling with this issue, we made the decision
> >> > > to
> >> > > register our internal domain name so that we could provide Digicert
> >> > > with a
> >> > > "whois" for it and they would then be happy to add our internal FQDNs
> >> > > to
> >> > > our
> >> > > commercial cert and we could decommission the MS default cert.
> >> > > However, I
> >> > > then spoke to Nominet and was told that we could NOT register our
> >> > > internal
> >> > > domain name because it has the .sch.uk suffix and since we already
> >> > > have
> >> > > one
> >> > > .sch.uk domain name registered, we can't register another one.
> >> > > We've been given two options by certificate providers, domain name
> >> > > registrants and Nominet alike:
> >> > > 1. Rename our external domain name so that it is the same as our
> >> > > internal
> >> > > domain name
> >> > > 2. Rename our internal domain name to use a suffix like .int or
> >> > > .local
> >> > > Neither of these options is even slightly appealing to us so we are
> >> > > desperately trying to find a work-around.
> >> > > I am now aware that having two active certificates running on the
> >> > > same CAS
> >> > > server is not supported. Is it possible to have two CAS servers in
> >> > > the
> >> > > same
> >> > > organisation and to force internal clients to use a specific one for
> >> > > autodiscover? If so, we could set the two up and just have the
> >> > > Digicert
> >> > > commercial cert on one for external access and have the MS default
> >> > > cert
> >> > > enabled on the other for internal access.
> >> > > Any other thoughts or ideas would be greatly appreciated. Many
> >> > > thanks,
> >> > > Adam
> >> > >

Your welcome!

--
John Oliver, Jr
MCSE, MCT, CCNA
Exchange MVP 2009
Microsoft Certified Partner


"Adam" wrote in message
news:2B77208D-5379-47E5-A9E7-5600425C4B81@microsoft.com...
> John,
> Your solution was spot on. I created a new forward lookup zone in DNS for
> our external domain name, then populated it with a single host record for
> our
> external CAS server name and resolved it to the internal IP address of the
> CAS server. Tested that I could ping it...all good. I then changed all of
> the
> relevant internal URLs to match the external FQDN on our UC cert (i.e. -
> https://ourserver.ourexternaldomain....todiscover.xml).
> Then tested that I could get to that address in a browser...was asked for
> my
> credentials, put them in and got the expected web page result. Finally,
> tested autodiscover on Outlook and we are golden! Thanks so much for your
> help.
> Adam
>
> "John Oliver, Jr. [MVP]" wrote:
>
>> You would be better served to keep them the same. You would not need a
>> split DNS to achieve this, you can create a Forward Lookup Zone in DNS to
>> match your internal/external url, mail.sch.uk for example. Create Host
>> record of the internal IP of your Exchange Server. Now test internally
>> from
>> command prompt that mail.shc.uk resolves to this IP. No need for split
>> DNS
>> if you follow this route.
>>
>> --
>> John Oliver, Jr
>> MCSE, MCT, CCNA
>> Exchange MVP 2009
>> Microsoft Certified Partner
>>
>>
>> "Adam" wrote in message
>> news:7652B225-F7D8-4609-8FF9-89094426FE64@microsoft.com...
>> > Would it be possible to set up separate URLs for exteral and internal
>> > access?
>> > In other words, have a set of internal URLs for external access that
>> > have
>> > the
>> > external FQDNs and another set for internal access that contain the CAS
>> > server's internal FQDNs?
>> >
>> > "Adam" wrote:
>> >
>> >> John,
>> >> No, the internal URL for the WebServices directory contains the
>> >> internal
>> >> FQDN of our client access server.
>> >>
>> >> As a side note, I've been able to stop the security warnings regarding
>> >> the
>> >> site name mismatch on internal Outlook clients by running the
>> >> "set-clientaccessserver" command to change the
>> >> servicebindinginformation
>> >> attribute of the SCP object so that it matches what is listed on our
>> >> UC
>> >> certificate which is the external FQDN of our CAS server. However,
>> >> because
>> >> all of the internal URLs still list the internal FQDN of our client
>> >> access
>> >> server, the autodiscover service fails on internal Outlook 2007
>> >> clients.
>> >> This
>> >> doesn't seem to be having any negative impact on their functionality
>> >> as
>> >> of
>> >> yet but it isn't ideal. According to MS KB article 940726, in order to
>> >> change
>> >> these internal URLs so that they match the external FQDN of the CAS
>> >> server,
>> >> we'd need to add a host record for that external FQDN to our DNS that
>> >> resolves to the internal IP address of the CAS server. The only way I
>> >> can
>> >> think of achieving this is via a spilt DNS configuration which simply
>> >> wouldn't work in our environment. I may just try testing this by
>> >> changing
>> >> those internal URLs to match our external FQDN and see of the DNS host
>> >> record
>> >> is really necessary. Thanks for you time and do let me know if you
>> >> have
>> >> any
>> >> other thoughts on this.
>> >> Adam
>> >>
>> >> "John Oliver, Jr. [MVP]" wrote:
>> >>
>> >> > Is the internal URL WebServices Virtual Directory pointing to your
>> >> > external
>> >> > registered domain that is included with the SAN Cert?
>> >> >
>> >> > Get-WebServicesVirtualDirectory | FL
>> >> >
>> >> >
>> >> > --
>> >> > John Oliver, Jr
>> >> > MCSE, MCT, CCNA
>> >> > Exchange MVP 2009
>> >> > Microsoft Certified Partner
>> >> >
>> >> >
>> >> > "Adam" wrote in message
>> >> > news:9C2006F1-B82A-4D6A-AFA3-31BC9E00279D@microsoft.com...
>> >> > > This may be a bit long winded so my apologies in advance!
>> >> > > We have a rather sticky problem with certificates on our new
>> >> > > Exchange
>> >> > > 2007
>> >> > > Client Access server set up. We are currently in the process of
>> >> > > trying to
>> >> > > migrate from Ex2K3 to Ex2K7. We've moved a few test clients over
>> >> > > to
>> >> > > the
>> >> > > new
>> >> > > Ex2K7 server and they are all getting certificate errors when
>> >> > > Outlook
>> >> > > 2007
>> >> > > starts up on domain joined machines (internal clients). The error
>> >> > > states
>> >> > > that
>> >> > > the site name that Outlook is looking for is different from what
>> >> > > is
>> >> > > on the
>> >> > > cert. And it is correct. Here is the whole sorry saga of our
>> >> > > certificate
>> >> > > tragedy:
>> >> > > We are a school in the UK. We have a publicly registered domain
>> >> > > name
>> >> > > that
>> >> > > ends with .sch.uk. Our internal/private AD domain name is nearly
>> >> > > identical
>> >> > > to
>> >> > > our public domain name and also ends in .sch.uk (don’t ask, this
>> >> > > was
>> >> > > before
>> >> > > my time) and looks very much like a public domain name. Because of
>> >> > > this,
>> >> > > we
>> >> > > were unable to find a single commercial certificate provider that
>> >> > > would
>> >> > > include our internal FQDNs to any UCC certificate we wanted. In
>> >> > > the
>> >> > > end,
>> >> > > we
>> >> > > ended up purchasing a Digicert UCC cert that had only our external
>> >> > > FQDNs
>> >> > > for
>> >> > > the CAS server and autodiscover services. We tried to work around
>> >> > > this
>> >> > > problem by enabling both our commercial cert as well as the
>> >> > > default
>> >> > > MS
>> >> > > cert
>> >> > > that ships with Ex2K7 which we added all of our internal FQDNs to.
>> >> > > The
>> >> > > hope
>> >> > > was that the external clients would be able to use the commercial
>> >> > > cert,
>> >> > > while
>> >> > > the internal clients would be able to use the default simple cert.
>> >> > > This
>> >> > > seemed to work for a brief time, but after a few weeks, Outlook
>> >> > > 2K7
>> >> > > on the
>> >> > > internal clients began ignoring the internal certificate and
>> >> > > started
>> >> > > using
>> >> > > the commercial cert which, of course, didn't have any of the
>> >> > > internal
>> >> > > information on it and hence they started getting the certificate
>> >> > > error on
>> >> > > startup. After much wrestling with this issue, we made the
>> >> > > decision
>> >> > > to
>> >> > > register our internal domain name so that we could provide
>> >> > > Digicert
>> >> > > with a
>> >> > > "whois" for it and they would then be happy to add our internal
>> >> > > FQDNs
>> >> > > to
>> >> > > our
>> >> > > commercial cert and we could decommission the MS default cert.
>> >> > > However, I
>> >> > > then spoke to Nominet and was told that we could NOT register our
>> >> > > internal
>> >> > > domain name because it has the .sch.uk suffix and since we already
>> >> > > have
>> >> > > one
>> >> > > .sch.uk domain name registered, we can't register another one.
>> >> > > We've been given two options by certificate providers, domain name
>> >> > > registrants and Nominet alike:
>> >> > > 1. Rename our external domain name so that it is the same as our
>> >> > > internal
>> >> > > domain name
>> >> > > 2. Rename our internal domain name to use a suffix like .int or
>> >> > > .local
>> >> > > Neither of these options is even slightly appealing to us so we
>> >> > > are
>> >> > > desperately trying to find a work-around.
>> >> > > I am now aware that having two active certificates running on the
>> >> > > same CAS
>> >> > > server is not supported. Is it possible to have two CAS servers in
>> >> > > the
>> >> > > same
>> >> > > organisation and to force internal clients to use a specific one
>> >> > > for
>> >> > > autodiscover? If so, we could set the two up and just have the
>> >> > > Digicert
>> >> > > commercial cert on one for external access and have the MS default
>> >> > > cert
>> >> > > enabled on the other for internal access.
>> >> > > Any other thoughts or ideas would be greatly appreciated. Many
>> >> > > thanks,
>> >> > > Adam
>> >> > >