Hi All My Exchange environment is Exchange 2007 SP 2, with dedicated mailbox, hub, edge and client access servers. Some of my internal Outlook 2007 users are having problems with, 1. Autodiscover service 2. Availability service 3. Offline Address book 4. Out of Office assistant External Outlook Anywhere users running Outlook 2007 do not have any problems, and my legacy Outlook 2003 users (internal and external) are also fine. My internal domain users should use SCP for locating the autodiscover service but I have noticed for those users that cannot access the above mentioned services the SCP lookup fails and a DNS lookup for autodiscover.<domain name> is attempted. I know I can setup up SRV records in DNS or create an A records for autodiscover but I do not want to do this because of Web proxy and split DNS complications, and basically because SCP should work for all internal users. Is anyone able to explain why SCP lookup may work for some users but not others, even when logging into the same laptop, on the same network, authenticating to the same domain controller. One other thing to note is that I use SAN certificates will all required names from a trusted CA on the Client Access servers. Regards Richard

On Fri, 17 Dec 2010 12:32:51 +0000, Richard B Redman wrote: > > >Hi All > >My Exchange environment is Exchange 2007 SP 2, with dedicated mailbox, hub, edge and client access servers. Some of my internal Outlook 2007 users are having problems with, > >1. Autodiscover service > >2. Availability service > >3. Offline Address book > >4. Out of Office assistant > >External Outlook Anywhere users running Outlook 2007 do not have any problems, and my legacy Outlook 2003 users (internal and external) are also fine. > >My internal domain users should use SCP for locating the autodiscover service but I have noticed for those users that cannot access the above mentioned services the SCP lookup fails and a DNS lookup for autodiscover.<domain name> is attempted. > >I know I can setup up SRV records in DNS or create an A records for autodiscover but I do not want to do this because of Web proxy and split DNS complications, and basically because SCP should work for all internal users. > >Is anyone able to explain why SCP lookup may work for some users but not others, even when logging into the same laptop, on the same network, authenticating to the same domain controller. The search for the SCPs is just a LDAP query to a GC. Do the Outlook profiles of the people who fail use a specific GC? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Hi Rich The users with issues are spread across the organisation. We have some 60 sites with approx 100 DC's. The site I work in has two DC's and both are GC's. How do I determine which GC I'm querying? FYI - I have used ADSI Edit to confirm the SCP records exist in the AD for the two DC's in my site. Is is possible that the issue could be permissions related on the actual SCP AD object? Regards Richard

On Mon, 20 Dec 2010 09:49:37 +0000, Richard B Redman wrote: >The users with issues are spread across the organisation. We have some 60 sites with approx 100 DC's. Are there Exchange servers in each of those sites? >The site I work in has two DC's and both are GC's. How do I determine which GC I'm querying? For the SCP? Good question. I'd expect that the information in DNS about the _tcp.<sitename>._sites.<domain>.<tld> would be used to find the GCs, but after that you could be connected to any of them in the site. A network trace would show you which IP address you're talking too, but the data's encrypted. >FYI - I have used ADSI Edit to confirm the SCP records exist in the AD for the two DC's in my site. You want the SCP objects that have DNs like this: CN=<SERVERNAME>,CN=Autodiscover,CN=Protocols,CN=<SERVERNAME>,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=<ORGNAME>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<TLD> You should be able to find them with LDP and a query that looks just for objects with the "keywords" attribute set to "site=yoursitename". With 60 AD sites, which SCP will be selected by Outlook is something like play three card monte -- you chances of finding the "right" one is pretty dicey. You might want to look into the use of the AutoDiscoverSiteScope to get those clients to the right CAS. This is a pretty good explanation of how to use that, and DNS, to prevent everything in your organization from using the same CAS server. :-) http://www.shudnow.net/2008/08/24/configuring-exchange2007-autodiscover-site-affinity/ >Is is possible that the issue could be permissions related on the actual SCP AD object? No, I doubt that's the problem. If you have just two GCs in your local site you should find the same set of SCPs in both of them. You can use LDP (or ADSIEDIT if you like to do things the hard way) to verify their existence. There really should be no reason for them to fail to find a SCP in the AD. There *may* be a problem with them connecting to the server in the SCP if they pick one that's not accessible, though. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks for the replies. I'm pleased to say I have resoved the issue now. Turns out the problem was with Outlook 2007 registry settings and nothing to do with the AD or Exchange infrastructure. Under the following key there are a number of registry values relating to how Autodiscover works, [HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover] "PreferLocalXML"=dword:00000001 "ExcludeHttpRedirect"=dword:00000001 "ExcludeHttpsAutodiscoverDomain"=dword:00000000 "ExcludeHttpsRootDomain"=dword:00000000 "ExcludeScpLookup"=dword:00000000 "ExcludeSrvLookup"=dword:00000000 "ExcludeSrvRecord"=dword:00000000 I have no idea how these have been added to the registry (because they do not appear as part of a standard install of Office 2007) so it must relate to how our 3rd Party builds and configures our laptops before shipping them to us. If anyone encouters Autodiscover issues, I would recommend taking a look at these registry settings on the client first. All that's left for me to do now is create some custom ADM files that set the correct registry settings across the domain. Regards Richard