5.   What is changing post-Beta2

So, if I understand correctly, in order to get Outlook2007/Exchange
2007 free/busy to work correctly, I need to buy a certificate and
make sure it works?  I just have a test deployment and don’t want
to buy certificates at this time.

Yes, we realize the limitation of this design.  So, with Outlook 2007 B2TR (Technical Refresh for
Beta2), it is possible to use self-signed certificates if you are running Outlook 2007 on domain-
joined machines.  When running on the Intranet, OL2007 will ignore certificate mismatches.

Outlook 2007 depends on being able to find the Autodiscover service to use many new features in
Exchange 2007.  Unfortunately, Autodiscover doesn’t work out-of-box for intranet or Internet
clients.   This means that features that make Exchange2007 shine, like the Availability Service and
OOF++ will not be used by Outlook out-of-box.

To get these working, a successful E12 deployment requires that an Autodiscover service be
locatable in DNS, based on the extracting the domain from an Outlook 2007 user’s e-mail address
– e.g. exchange.microsoft.com or autodiscover.exchange.microsoft.com from
tmyerson@microsoft.com.  Along these lines, customers are familiar with configuring Internet DNS
to get outside mail flowing to their org and exposing their org’s OWA and Server ActiveSync on
the ‘Net.  Reusing or setting up an additional Internet host records for Internet access to
Autodiscover will happen in due course.
 
When a user runs Outlook 2007 on the intranet however, his client will resolve an Internet host
like autodiscover.microsoft.com – and the request for there is a good chance the user will be
prompted for credentials if she is proxied via anything less than ISA Server 2004.  The current
solution to this problem is for administrators to create a Host or Alias record in their internal DNS
that points to the internal IP address or addresses or Client Access Service hosting the
Autodiscover server.  Customers do not generally need to configure internal DNS to get mail
flowing inside their organizations.

The complexity of manual steps required for DNS-based deployment means that customers will
need help to get Autodiscover working – and more help to keep it working.  Each new recipient
domain (microsoft.com, exchange.microsoft.com, windows.microsoft.com) means an additional,
manual DNS change is required.

We’ve been brainstorming ways to eliminate Autodiscover’s dependency on DNS in the intranet,
as it is very unlikely that we will be able to make an intranet DNS-based solution work out of the
box in a large number of customer deployments.   The ongoing maintenance of this solution will
become an administrative burden.
 
Once Outlook is able to connect to the Client Access Server hosting the Autodiscover service as
well as the Availability service – there’s the problem of encrypting the pipe.  In most out-of-the-box
cases, Exchange will configure self-signed certificates to use for SSL and these will cause Outlook
to prompt the user about a misconfigured server.  Users will either be alarmed by or be trained to
ignore the prompt – resulting in many helpdesk and PSS calls.
 
As well, the current DNS-based solution poses problems for Exchange hosting organizations that
have dozens or hundreds of e-mail domains – deploying an SSL certificate for each one of these is
not only cost-prohibitive, but also error prone.

We can make the Autodiscover service work reliably out of the box on our customers’ intranets –
by having clients search the Active Directory (AD) for Autodiscover “Service Connection Points.”
   See the MSDN reference on this topic.  Established precedents for using Service Connection
Points in exactly this way exist – intranet discovery of Microsoft UDDI Registry, SQL Server, AD
Application Mode (ADAM), Internet Authentication Service (IAS), etc. – and confirm the validity
of this option.
  
The change to Autodiscover deployment is as follows:

1.      At CAS setup time, Autodiscover setup must correspondingly look for or create a Service
Connection Point (SCP) object, under the container:


CN=Autodiscover,CN=Protocols,CN=<CAS_SERVER>,CN=Servers,CN=Exchange Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services, [Configuration Naming Context]
where:
a.       objectCategory=Service-Connection-Point
b.       cn=[machine physical FQDN]
c.  serviceClassName=Exchange Autodiscover
d.  Keyword={77378F46-2C66-4aa9-A6A6-3E7A48B19596}
If found, this is the object to update as it contains the forest’s authoritative list of Autodiscover
service URLs.  If not, then the object should be created in this location, with the
serviceBindingInformation attribute set to:
https://[machine physical FQDN]/autodiscover/autodiscover.xml
Where [machine physical FQDN] is the server’s ComputerInformation.
PhysicalFullyQualifiedDomainName value.  This value is the physical DNS name of the machine.
Administrators may at a future time change this value to match the NLB name of the machine.

2.      Ensure before saving the object that the well-known Authenticated Users account has
effective “read” permission to the object or log a warning, as this will mean that not all users will be
able to search for and read the item.

3.      CAS Uninstall must look up and remove the object added, and if no CAS server is left,
delete Autodiscover container.

 Please use the following cmdlet to export your SCP settings to another forest:

export-AutoDiscoverConfig

For example: