Outlook 2010 email autoconfigure always pointing to Mailbox Server not the CAS Array name ?

Hi All,

I'm having strange issue with my newly created user in my remote AD site where newly configured PC for existing user, their Outlook is failed to be automatically configured, because the name of the CAS Array where all users in my HQ office is using is replaced by one of the Mailbox Server (in some of the AD sites but not in the Head Quarter office).

The CAS Array: Outlook.domain.com is pingable from the workstation
Workaround: is to manually type the CAS Array FQDN above.

Any idea where to troubleshoot or check please ?
LVL 10
Senior IT System EngineerIT ProfessionalAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Senior IT System EngineerIT ProfessionalAuthor Commented:
Here is my topology layout roughly:

Single AD Domain forest

AD Site DataCenter contains:
Domain Controllers: PRODDC01-VM, PRODDC02-VM, PRODDC03-VM
Exchange Server 2010 SP3 - CAS&HT: PRODMAIL01-VM and PRODMAIL01-VM (Configured with WNLB as outlook.domain.com)
Exchange Server 2010 SP3 - Mailbox: PRODMAILBOX01-VM and PRODMAILBOX01-VM (no DAG is set)

AD Site HQ contains - This site has no issue:
Domain Controllers: HQDC01 and HQDC02
Workstations using Outlook 2010 and 2013

AD Site SiteOffice1 contains - This site has problem:
Domain Controllers: none but the majority of the workstations LOGONSERVER is pointing to PRODDC03-VM
Workstations using Outlook 2010 and 2013
0
MikeIT ManagerCommented:
Sounds like an issue with autodiscovery.  Have you confirmed that your autodiscover URL's are still pointing to your CAS Array?
0
Senior IT System EngineerIT ProfessionalAuthor Commented:
how ?

is it from the CAS array member using Get-AutodiscoverVirtualDirectory | fl ?

there was no changes doneto the Exchange Servers this year.
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Will SzymkowskiSenior Solution ArchitectCommented:
As stated it is likely due to auto-discover. This is the mechanism where the mailbox is mapped to the Outlook session automatically.

From the users machine hold ctrl+right click the Outlook icon in the System Tray and select Test Email Auto Configuration.

Run the Autodiscover test and check the results tab. Look for Autodiscover URL and see where it is pointing to.

Will.
0
Senior IT System EngineerIT ProfessionalAuthor Commented:
Here's the result from the Powershell

[PS] C:\Windows\system32>
Get-AutodiscoverVirtualDirectory | fl

Open in new window



RunspaceId                      : b929d268-4308-42a2-949e-ffc505fb61a9
Name                            : Autodiscover (Default Web Site)
InternalAuthenticationMethods   : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
ExternalAuthenticationMethods   : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
LiveIdSpNegoAuthentication      : False
WSSecurityAuthentication        : True
LiveIdBasicAuthentication       : False
BasicAuthentication             : True
DigestAuthentication            : False
WindowsAuthentication           : True
MetabasePath                    : IIS://PRODMAIL01-VM.domain.com/W3SVC/1/ROOT/Autodiscover
Path                            : C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags         : {}
ExtendedProtectionSPNList       : {}
Server                          : PRODMAIL01-VM
InternalUrl                     :
ExternalUrl                     :
AdminDisplayName                :
ExchangeVersion                 : 0.10 (14.0.100.0)
DistinguishedName               : CN=Autodiscover (Default Web Site),CN=HTTP,CN=Protocols,CN=PRODMAIL01-VM,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Domain,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com
Identity                        : PRODMAIL01-VM\Autodiscover (Default Web Site)
Guid                            : adc66b9a-20ac-44c7-bab5-7f708493e015
ObjectCategory                  : domain.com/Configuration/Schema/ms-Exch-Auto-Discover-Virtual-Directory
ObjectClass                     : {top, msExchVirtualDirectory, msExchAutoDiscoverVirtualDirectory}
WhenChanged                     : 10/11/2012 4:24:06 PM
WhenCreated                     : 17/01/2011 10:29:02 AM
WhenChangedUTC                  : 10/11/2012 5:24:06 AM
WhenCreatedUTC                  : 16/01/2011 11:29:02 PM
OrganizationId                  :
OriginatingServer               : PRODDC03-VM.domain.com
IsValid                         : True

RunspaceId                      : b929d268-4308-42a2-949e-ffc505fb61a9
Name                            : Autodiscover (Default Web Site)
InternalAuthenticationMethods   : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
ExternalAuthenticationMethods   : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
LiveIdSpNegoAuthentication      : False
WSSecurityAuthentication        : True
LiveIdBasicAuthentication       : False
BasicAuthentication             : True
DigestAuthentication            : False
WindowsAuthentication           : True
MetabasePath                    : IIS://PRODMAIL02-VM.domain.com/W3SVC/1/ROOT/Autodiscover
Path                            : C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags         : {}
ExtendedProtectionSPNList       : {}
Server                          : PRODMAIL02-VM
InternalUrl                     :
ExternalUrl                     :
AdminDisplayName                :
ExchangeVersion                 : 0.10 (14.0.100.0)
DistinguishedName               : CN=Autodiscover (Default Web Site),CN=HTTP,CN=Protocols,CN=PRODMAIL02-VM,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Domain,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com
Identity                        : PRODMAIL02-VM\Autodiscover (Default Web Site)
Guid                            : 66b6e80e-5b15-47d9-b2cf-cb3cfa59411e
ObjectCategory                  : domain.com/Configuration/Schema/ms-Exch-Auto-Discover-Virtual-Directory
ObjectClass                     : {top, msExchVirtualDirectory, msExchAutoDiscoverVirtualDirectory}
WhenChanged                     : 10/11/2012 4:24:06 PM
WhenCreated                     : 19/01/2011 12:22:46 PM
WhenChangedUTC                  : 10/11/2012 5:24:06 AM
WhenCreatedUTC                  : 19/01/2011 1:22:46 AM
OrganizationId                  :
OriginatingServer               : PRODDC03-VM.domain.com
IsValid                         : True
0
Senior IT System EngineerIT ProfessionalAuthor Commented:
@Will & Shadowless: Yeah Ithought so, but this is happening on the existing AD user account with new replaced computer so start from scratch due to PC refresh.
0
MikeIT ManagerCommented:
run this

Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl
0
Senior IT System EngineerIT ProfessionalAuthor Commented:
one thing that I notice, is that you cannot test the Outlook Autodiscover from the Outlook system tray then Right Clcik option because the email profile is not set up yet.
0
Senior IT System EngineerIT ProfessionalAuthor Commented:
Here's the result:

[PS] C:\Windows\system32>Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl


Identity    : PRODMAIL01-VM\EWS (Default Web Site)
InternalUrl : https://PRODMAIL01-VM.domain.com/EWS/Exchange.asmx
ExternalUrl : https://email.domain.com/ews/exchange.asmx

Identity    : PRODMAIL02-VM\EWS (Default Web Site)
InternalUrl : https://PRODMAIL02-VM.domain.com/EWS/Exchange.asmx
ExternalUrl : https://email.domain.com/ews/exchange.asmx

Open in new window

0
MikeIT ManagerCommented:
Here's a thought, completely out of left field, but a thought none the less.

Have you checked what RPC Access Server the database this user is on is set to, using the following:

Get-MailboxDatabase database_name | fl Name, RpcClientAccessServer
0
Senior IT System EngineerIT ProfessionalAuthor Commented:
yes, it is confirmed the affected user was in a mailbox server 01 where database contains her mailbox. Therefore in the textbox filed during the email profile setup was listed PRODMAIL01-VM

The server value is somehow set to the proper mailbox server but it must be set to the WNLB or CAS Array name.
0
MikeIT ManagerCommented:
The RPCClientAccessServer should point to Outlook.Domain.Com, not the server the MB is stored on.
0
Senior IT System EngineerIT ProfessionalAuthor Commented:
@Shadow: yes that's what I mean.

the reply above was regarding the Outlook profile in the new workstation.
0
MikeIT ManagerCommented:
Have you tried adding the user's mailbox on another workstation?
0
Guy LidbetterCommented:
Hi There,

First off.. try ping "Autodiscover" - does it get a response...

Outlook when setting up a profile will send an LDAP query to a DC requesting SCP records. AD will reply with a list of In-Site and Out-of-Site locations. Outlook will then try and connect to each of these in sequence.

Failing that it will then try connecting to the predefined URL's in DNS (i.e. https://autodiscover.yourdomain.com/autodiscover/autodiscover.xml) : It gets the domain from the users configured smtp address. Check this is reachable from the site.

If that doesn't work it will try look for an SRV record - check if one exists with this command
nslookup -q=srv _autodiscover._tcp.youtdomain.com

Open in new window


If all of these fail - outlook will not be able to establish a connection and you will see the users msExchangeHomeServer attribute in the server field.

Have a look through these and see if you find an issue...
0
Senior IT System EngineerIT ProfessionalAuthor Commented:
@Guy: sure, so I assume those test must be done through the affected users workstation ?
0
Guy LidbetterCommented:
That's right... we need to establish what it can see on the network.
0
Senior IT System EngineerIT ProfessionalAuthor Commented:
Guy, I can ping the Autodiscover address from the affected new computer in the affected AD site.
0
Guy LidbetterCommented:
Hi There,

Just reading through everything again to re-familiarize myself, and I just noticed something...
your internal URLs' from the code

Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl

Open in new window


InternalUrl : https://PRODMAIL01-VM.domain.com/EWS/Exchange.asmx
InternalUrl : https://PRODMAIL02-VM.domain.com/EWS/Exchange.asmx

These should be configured to your CAS Array URL... not the individual servers.
You said the CAS\HTC boxes are WNLB'ed, so the internal URL should be configured to that VIP in DNS.

i.e. https://mail.domain.com/ews/exchange.asmx

You can change these with
Get-TransportServer | Set-WebServicesVirtualDirectory -InternalUrl "https://mail.domain.com/ews/exchange.asmx"

Open in new window


Check these points in DNS:
Under your Domain.com zone you should have:

A Records:
mail (or email, whatever you have)  :  WNLB VIP

CNAME Records:  
Autodiscover  :   mail.domain.com
(there are arguments this should be and A record.. but I prefer to use an alias unless you have a dedicated Autodiscover box\cluster in a  large environment)

SRV Record: (Not essential but a good idea...)
Service: _autodiscover
Protocol: _tcp
Priority: 0
Weight: 0
Port Number: 443
Host: mail.domain.com

Lastly... make sure you can telnet to the mail url from the affected workstation
telnet mail.domain.com 443

Open in new window

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Senior IT System EngineerIT ProfessionalAuthor Commented:
ok, so in this case to change the InternalURL using the powershell below:

Get-TransportServer | Set-WebServicesVirtualDirectory -InternalUrl "https://mail.domain.com/ews/exchange.asmx"

Open in new window


is there any outage expected or it can be done during the business hours ?
0
Senior IT System EngineerIT ProfessionalAuthor Commented:
ok, so if I move all of my mailboxes to Office 365, does this problem will go away because Office 365 is always perfect with no issue at all ?
0
Guy LidbetterCommented:
Hi There,

Would you like to try one last thing?
I just read through and realised I never mentioned Autodiscover site affinity. What you can do is set one of the CAS mailboxes to advertise in a particular site, e.g.

Set-ClientAccessServer -Identity "ServerName" -AutodiscoverServiceInternalURI "https://mail.domain.com/autodiscover/autodiscover.xml" -AutodiscoverSiteScope "SiteName"

Open in new window


This may resolve the issue. As I mentioned in my comment above, the SCP LDAP request will send a list of IN and OUT of scope CAS services. This will then create an IN scope option.

Otherwise... O365 is a completely different solution, but you may still have the autodiscover advertising issue, then you'd have to enter the IMAP and SMTP connections yourself in the Manual Internet Email setup.
1
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.