none
Outlook Autodiscover forces IMAP RRS feed

  • Question

  • I have Exchange 2007 SP3, two CAS boxes. ExRCA works successfully, in both AutoDiscover and Outlook AnyWhere tests. All tests seem to work internally as well. Internally Outlook configures a Microsoft Exchange (RPC/HTTPs) connection. Externally Outlook configures an IMAP connection. I read somewhere that you can force AutoDiscover to prefer RPC/HTTPs, but I can't find that setting.

    How can I force AutoDiscover to prefer RPC/HTTPs.

    Friday, May 9, 2014 5:23 PM

Answers

  • I have found the catalyst but not the root cause. Instead of doing the redirect, I moved the host header to the main default site. Once I moved the host header "autodiscover.domain.com"; ALL clients selected Exchange. But to answer your questions.

    We installed Exchange as normal, used the EWS and AutoDiscover set commands to set the external URLs to owa.domain.com. During a standard Exchange installation, Exchange is installed to the default (aka main) site. I configured a new site, and provided the host header of autodiscover.domain.com; again because I needed to get data before I turned it on), the main site has a host header of owa.domain.com. I used the IIS7 redirect option with a 301 redirect to redirect autodiscover.domain.com to owa.domain.com (DNS has the appropriate records for both). Autodiscover & OWA .domain.com both exist on the same servers, just different sites (i.e. w3svc1 & w3svc2). All sites are internet facing.

    AGAIN... ExRCA worked as did all non Outlook clients; ONLY Outlook clients failed to get the appropriate reason. But for grins and giggles I removed the 301 redirect and reassigned the host headers to the default site (w3svc1) and lo and behold Outlook started working correctly.

    So the answer was to remove the 301 redirect and go direct to the Exchange virtual directories.

    • Marked as answer by Kennywood Thursday, May 22, 2014 9:37 PM
    Thursday, May 22, 2014 9:37 PM

All replies

  • Post the result of Connection Status and Test E-Mail AutoConfiguration

    Cheers,

    Gulab Prasad

    Technology Consultant

    Blog: http://www.exchangeranger.com    Twitter:   LinkedIn:
       Check out CodeTwo’s tools for Exchange admins

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, May 9, 2014 5:52 PM
  • My situation is before Outlook is configured.

    Create a new profile, fill in Name, Username, Password and let the AutoDiscover process go. If the workstation is inside my network/domain joined, then Outlook will choose an Exchange Connection type. If the workstation is outside of my network (not domain joined) then Outlook chooses an IMAP Connection type.

    I want Outlook to always choose the Exchange Connection type.

    Friday, May 9, 2014 7:10 PM
  • From the Internet, visit this page and run the Autodiscover and Outlook Anywhere tests:

    https://testconnectivity.microsoft.com/


    --- Rich Matheisen MCSE&I, Exchange MVP

    Monday, May 12, 2014 9:43 PM
  • As I mentioned in my first post; I have run both of these tests. ExRCA.com is the same site, just a shorter FQDN to type.
    Monday, May 12, 2014 10:05 PM
  • Hi,

    As far as I know, in Exchange 2007 environment, domain-joined Outlook clients use MAPI(RPC) while external      Outlook clients use RPC over HTTP(Outlook Anywhere).

    According to your description, you want to force Autodiscover to use RPC over HTTP. Based on my experience, we can depend the Outlook feature to achieve this:

    Select the following options: “On fast networks, connect using HTTP..."  and "On slow networks, connect using HTTP..."

    And here is the path: file>account settings>Exchange account>more settings>connection>Exchange proxy settings

    Please note that the above method only applies to one account configured on one Outlook.

    If I misunderstand your meaning, please feel free to let me know.

    Thanks,


    Angela Shi
    TechNet Community Support

    Tuesday, May 13, 2014 8:55 AM
    Moderator
  • Thanks, that is not quite what I am getting at. You are talking about manually configuring the Outlook client, I am talking about AutoDiscover configuring the Outlook client.

    AutoDiscover is automatically configuring my non domain joined systems for IMAP4 (please note IMAP is not MAPI), I want AutoDiscover to configure for an Exchange Connection, regardless of whether or not the computer is domain joined.

    I have researched configuring autodiscover.xml (http://technet.microsoft.com/en-us/library/cc511507(v=office.14).aspx), but the 'Protocol' list does not include MAPI/RPC. DAV is an Exchange 2003 communication method, which is deprecating so I presume that it is not the option to use. There is also no EWS option. I also presume that since Outlook chooses MAPI internally, the XML is not my issue.

    Tuesday, May 13, 2014 4:00 PM
  • So you did. My bad.

    Considering that exrca.com works, have you read through this?

    http://support.microsoft.com/kb/2212902/en-us


    --- Rich Matheisen MCSE&I, Exchange MVP

    Tuesday, May 13, 2014 7:42 PM
  • Yes; again AutoDiscover works, it just chooses IMAP instead of an Exchange connection. I want to force AutoDiscover to ONLY select an "Exchange" connection.

    Tuesday, May 13, 2014 10:57 PM
  • Hi,

    As far as I know, to choose method of connecting to Exchange server, Autodiscover service depends on the XML request from Outlook client:

    “The XML request contains the necessary information for this to happen, such as the SMTP address and which client (MAPI client or Outlook Anywhere) made the request so the Autodiscover service can easily identify the provider the request needs to be forwarded to.”

    http://blogs.technet.com/b/exchange/archive/2008/09/26/3406344.aspx

    According to your description, your external client use IMAP. Thus, I’d like to confirm if all external users use IMAP. How about recreating profiles ?

    Thanks,


    Angela Shi
    TechNet Community Support

    Wednesday, May 14, 2014 2:48 AM
    Moderator
  • All mailboxes are configured to allow MAPI, IMAP, and POP3. Again there is no profile to recreate, it is the creation process that I am talking about. The repro steps are as follows:

    Outlook 2010 installed with NO profile created.

    Open Outlook

    Enter E-mail address, username, and password.

    With the SAME mailbox; Outlook on a domain joined computer chooses an Exchange connection, but on a non domain joined computer chooses an IMAP connection.

    This is when AutoDiscover is creating the profile new. My goal is to use AutoDiscover as it was intended for new clients.

    I've referenced the XML request in previous posts here, and given the fact that the two different clients access the same AutoDiscover service, grabbing the same AutoDiscover.XML, I doubt the XML is the issue here.

    Wednesday, May 14, 2014 3:26 AM
  • Yes; again AutoDiscover works, it just chooses IMAP instead of an Exchange connection. I want to force AutoDiscover to ONLY select an "Exchange" connection.


    Hi,

    I don't thinkt there is a way to tell Outlook not to use Guessmart to query the DNS for common names for IMAP/POP/SMTP, like imap.domain.com, pop.domain.com and smtp.domain.com.

    It is not Exchange giving away those IMAP Settings in the Autodicover response - It is Outlook asking for it with Guesssmart and the only workaround that I can think of is to not have those names (imap.domain.com etc) available in the external DNS.


    Martina Miskovic

    Wednesday, May 14, 2014 5:04 AM
  • Those names don't explicitly exist in my environment, but wildcard records do. That being said, I run into the same scenario, the configuration internally and externally is exactly the same; same Exchange, same mailbox, same DNS settings, same Outlook. The ONLY difference I can see is internal vs. external. Internally, Outlook chooses an Exchange connection; Externally, Outlook chooses an IMAP connection. There is reference to setting up a preference for telling Outlook to use the Exchange type of connection. Then when you add onto this, those that use Office 365; in certain configurations they won't be domain joined, but yet Outlook will choose an Exchange connection. This all indicates it is possible, I simply can't find an AutoDiscover.XML that shows a preference for RPC/HTTPs, or any true indicator of WHERE I can set this priority.

    Does Microsoft CSS no longer monitor the forum threads? Is there anyone from Exchange support that can provide some insight into how to force AutoDiscover to choose an Exchange connection?

    Wednesday, May 14, 2014 5:18 AM
  • Hi,

    IMAP is not pushed by Autodiscover service. This issue would occur if Autodiscover is not working from external clients. Please make sure the following conditions are true:

    • There is public IP for Autodiscover.domain.com
    • autodiscover.domain.com is included in the certificate
    • Autodiscover URLs can be accessed from external clients.

    Since we have run RCA test for Autodiscover and Outlook Anywhere, the test result is OK, the basic settings could be correct. I'd like to confirm that if we have ISA server or any other firewall or proxy server between the external clients and Exchange servers. If there is, check the settings on these servers.

    Meanwhile, please access the Autodiscover URLs in IE on one affected external machine (please replace the domain.com with your own domain), post the result, thanks!

    https://autodiscover.domain.com/autodiscover/autodiscover.xml

    https://domain.com/autodiscover/autodiscover.xml

    Thanks,

    Jessie

    Thursday, May 15, 2014 7:09 AM
  • With all due respect, AutoDiscover DOES "push" IMAP; check here for the functionality to not only tell your clients to use IMAP, but to prefer IMAP - http://technet.microsoft.com/en-us/library/cc511507(v=office.14).aspx. Please note this documentation shows nothing on RPC or MAPI (I have a theory on what is correct, but I was hoping someone might actually know).

    As for the rest, yes ExRCA shows a successful AutoDiscover test (see below). This alone should answer all of your questions, but...

    There is no ISA or layer 7 firewall between the clients and the Exchange server.

    We use a wildcard certificate.

    domain.com/autodiscover does not work on purpose.

    autodiscover.domain.com gets the standard base XML response:

      <?xml
    version="1.0" encoding="utf-8"
    ?>
    - <Autodiscover
    xmlns
    ="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    - <Response>
    - <Error Time="08:29:07.3790481"
    Id
    ="2797652423">
      <ErrorCode>600</ErrorCode>
      <Message>Invalid Request</Message>
      <DebugData />
      </Error>
      </Response>

     </Autodiscover>

    ExRCA response:

    Autodiscover Account Settings
    XML response:
    <?xml version="1.0"?>
    <Autodiscover xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
     <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
     <User>
     <DisplayName>The User</DisplayName>
     <LegacyDN>/o=ExchangeOrg/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=myuser</LegacyDN>
     <DeploymentId>44e14b0f-16c1-4138-b049-347991a74b9e</DeploymentId>
     </User>
     <Account>
     <AccountType>email</AccountType>
     <Action>settings</Action>
     <Protocol>
     <Type>EXCH</Type>
     <Server>myserver.domain.net</Server>
     <ServerDN>/o=ExchangeOrg/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MAILCORP</ServerDN>
     <ServerVersion>72038053</ServerVersion>
     <MdbDN>/o=ExchangeOrg/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MAILCORP/cn=Microsoft Private MDB</MdbDN>
     <ASUrl>https://owa.mydomain.com/ews/Exchange.asmx</ASUrl>
     <OOFUrl>https://owa.mydomain.com/ews/Exchange.asmx</OOFUrl>
     <OABUrl>http://cas.domain.net/OAB/5c45110d-c9d1-4cb8-9ba6-28fa3d6c6cc1/</OABUrl>
     <UMUrl>https://cas.domain.net/UnifiedMessaging/Service.asmx</UMUrl>
     <Port>0</Port>
     <DirectoryPort>0</DirectoryPort>
     <ReferralPort>0</ReferralPort>
     <PublicFolderServer>myserver.domain.net</PublicFolderServer>
     <AD>AD.domain.net</AD>
     <EwsUrl>https://owa.mydomain.com/ews/Exchange.asmx</EwsUrl>
     </Protocol>
     <Protocol>
     <Type>EXPR</Type>
     <Server>owa.mydomain.com</Server>
     <ASUrl>https://owa.mydomain.com/EWS/Exchange.asmx</ASUrl>
     <OOFUrl>https://owa.mydomain.com/EWS/Exchange.asmx</OOFUrl>
     <OABUrl>https://owa.mydomain.com/OAB/5c45110d-c9d1-4cb8-9ba6-28fa3d6c6cc1/</OABUrl>
     <Port>0</Port>
     <DirectoryPort>0</DirectoryPort>
     <ReferralPort>0</ReferralPort>
     <SSL>On</SSL>
     <AuthPackage>Ntlm</AuthPackage>
     <CertPrincipalName>msstd:*.mydomain.com</CertPrincipalName>
     <EwsUrl>https://owa.mydomain.com/EWS/Exchange.asmx</EwsUrl>
     </Protocol>
     <Protocol>
     <Type>WEB</Type>
     <Port>0</Port>
     <DirectoryPort>0</DirectoryPort>
     <ReferralPort>0</ReferralPort>
     <External>
     <OWAUrl AuthenticationMethod="Fba">https://owa.mydomain.com/owa</OWAUrl>
     <Protocol>
     <Type>EXPR</Type>
     <ASUrl>https://owa.mydomain.com/EWS/Exchange.asmx</ASUrl>
     </Protocol>
     </External>
     <Internal>
     <OWAUrl AuthenticationMethod="Basic, Fba">https://cas.domain.net/owa</OWAUrl>
     <OWAUrl AuthenticationMethod="Basic, Fba">https://cas.domain.net/owa</OWAUrl>
     <Protocol>
     <Type>EXCH</Type>
     <ASUrl>https://owa.mydomain.com/ews/Exchange.asmx</ASUrl>
     </Protocol>
     </Internal>
     </Protocol>
     </Account>
     </Response>
    </Autodiscover>

    HTTP Response Headers:
    Pragma: no-cache
    Persistent-Auth: true
    Content-Length: 2849
    Cache-Control: no-cache
    Content-Type: text/html; charset=utf-8
    Date: Thu, 15 May 2014 15:28:48 GMT
    Expires: -1
    Server: Microsoft-IIS/7.5
    X-AspNet-Version: 2.0.50727
    X-Powered-By: ASP.NET


    Elapsed Time: 118 ms.

    Thursday, May 15, 2014 3:39 PM
  • What does the autodiscover XML look like when you use the "Test E-Mail Autodiscover" (with the two Gessmart boxes unchecked) from a machine running Outlook out on the Internet? What about the contents of the :Log" tab, to?

    --- Rich Matheisen MCSE&I, Exchange MVP

    Thursday, May 15, 2014 8:55 PM
  • The point is I'm not even getting to that area. In order to use what you ask a profile needs to ALREADY be created. I am talking about going into the mail applet in control panel and creating a new profile. This new profile is created as an IMAP profile by Outlook USING AutoDiscover. My current AutoDiscover.XML file on the server is the default blank XML file.

    The question is WHY does Outlook for a non domain joined computer choose IMAP when a domain joined computer chooses Exchange, and what can I do to force the non domain joined computer to choose Exchange (both computers are on the SAME network)?

    To make this more fun Outlook 2007 chooses POP3, Outlook 2010 chooses IMAP. Again the ONLY differences are whether or not the computer is domain joined (virtual systems built on the same host, using the same bits - I've gone so far as to join/disjoin to the domain, and as I have explained Outlook (now physically being the SAME computer) changes its behavior. ALL DNS records are the same, as the IP information has not changed, just the fact that I disjoin or join the domain.

    But to answer your question the test comes back and shows me either POP3 or IMAP4 depending on the Outlook version used, and the LOG states AutoDiscover fails with an 0x80040005 (yet every computer tested, including the ones failing this test ALL provide the AutoDiscover 600 Error (Invalid Request) when I go directly to the URL). Oddly enough I noticed that the test shows that there is a 301 redirect (which is true), but the non domain joined computer does NOT redirect. It stays on autodiscover.domain.com when the redirected URL should be owa.domain.com.

    Thursday, May 15, 2014 10:06 PM
  • Hi,

    The Autodiscover you mentioned is the local Autodiscover xml. Only when the Exchange Autodisocver service failed, Outlook tries to contact the Autodiscover through the local Autodiscover XML file. It is represented in the TechNet article you posted:

    If the previous step fails, try local XML discovery and use the XML found on the local computer, if applicable.

    HTTP code 600 when accessing Autodiscover URL is expected. It means the Autodiscover configuration is correct and the Autodiscover URL could be contacted from the external clients. I noticed the Exchange Autodiscover failed on an external client. To the redirection when internal clients try to contact Autodiscover service, it would happen if we have mutiple CAS servers in the environment. But to external clients, generally, they try to contact Autodiscover service via http://autodiscover.domain.com/autodiscover/autodiscover.xml. It is not recommended to enable redirection for Autodiscover service, particularly if we have no firewall or proxy server. Do you mean that the rediretion is configured for Autodiscover service but it does not function?

    Besides, please make sure the autodiscover.domain.com is resolved to the Internet Facing Exchange 2010 server.

    Thanks,

    Jessie

    Friday, May 16, 2014 9:26 AM
  • I read the part you are referring to, but if you take a look at this section:

    ISP with POP3 and SMTP service

    The following XML file would be configured as a custom 405 error response at either  https://contoso.com/autodiscover/autodiscover.xml or https://autodiscover.contoso.com/autodiscover/autodiscover.xml.

    You note that I can create a 405 error response (on the server) to force my preferences and options.

    Please note, there have been a lot of statements in this thread, but some are very important.

    1. Our Autodiscover is actually configured at owa.domain.com 

    2. Autodiscover works and redirects correctly via ExRCA (from autodiscover.domain.com to owa.domain.com).

    3. With the exact same computer, in the exact same network, I can duplicate this issue by simply disjoining the domain. When joined to the domain Outlook chooses Exchange, when disjoined to the domain Outlook chooses a lesser protocol. The same DNS servers are used, the same SRV records are an option, but Outlook is choosing its behavior SOLELY on its domain membership.

    4. Outlook on a non domain joined computer, when running Test E-mail Autoconfiguration, both get to the same point (Testing https://autodiscover.domain.com) but the non domain joined computer does not redirect properly to owa.domain.com, while the domain joined instance (again disjoining and rejoining the domain just to prove the point) does correctly utilize the 301 redirect.

    5. Non Outlook clients don't experience the same issue (i.e. ALL mobile devices correctly find and utilize an Exchange connection.

    6. I have NO control over these Outlook machines (think community college in which I have to provide e-mail but cannot admin their computers, but yet remove strain off the helpdesk via AutoDiscover).

    So now we get back to the same question, how do I get Exchange to push an Exchange connection in AutoDiscover? Jessie, your tagline says Microsoft, can you ask a Tech Lead on this?

    Friday, May 16, 2014 2:40 PM
  • Hi Kenny,

    Currently, only the non-domain joined clients are affected. That means the Autodiscover configuration on Exchange server could be correct. Only when the clients are unable to contacts the Exchange autodiscover services, it tried to contact the local Autodiscover.  The current issue could be that Exchange Autodiscover service does not work on non-domain joined client issue. You also noticed it on a client when it disjoined to the domain. 

    The external clients follow the predefined order to contact the Autodiscover service.  You may also refer to "White Paper: Understanding the Exchange 2010 Autodiscover Service".

    As you stated that you configured the Autodiscover as owa.domain.com, could you please let us know how and where you configured it?

    Thanks,

    Jessie

    Saturday, May 17, 2014 3:38 AM
  • Autodiscover uses HTTP(S), so put Fiddler (http://fiddler2.com) on one of those clients and fire it up before you start Outlook. You'll see the interaction between the client and whatever it's talking to (CAS, TMG, etc.). Does the client ever get the XML data from the CAS?

    Fiddler is to HTTP/S what Wireshark is to network monitoring. It's an invaluable tool that everyone should be using to debug web interactions.

    And, speaking of Wireshark, it might be a good idea to put that on the same machine. Use a display filter of "DNS" and see if those non-domain-joined clients are able to resolve the name "domain.com" and/or "autodiscover.domain.com".

    Since the MS web application (ExRCA) works properly (it's not a domain-joined client!) what is it with YOUR machines that's different?

    The domain-joined machines are using the SCP data (the name of the source should be you CAS servers), so they work fine. But when the non-domain-joined machines ask for the Autodiscover do they ever resolve any of the names?

    Does a domain-joined machine, when connecting from the Internet without a VPN work okay?


    --- Rich Matheisen MCSE&I, Exchange MVP

    Sunday, May 18, 2014 9:51 PM
  • #4: Why not just use a CNAME, or an A record in your DNS? Why got to all the trouble of redirection?

    autodiscover IN MX owa.domain.com.

    or

    autodiscover IN A 1.2.3.4


    --- Rich Matheisen MCSE&I, Exchange MVP

    Sunday, May 18, 2014 9:56 PM
  • Hi,

    Do you have any update about this issue?  If you have any questions about the information we provided, please feel free to let us know.

    Thanks,

    Jessie

    Wednesday, May 21, 2014 11:27 AM
  • I don't know if anyone suggested it, but it'd be interesting to see how it copes if you disable IMAP at the server end. Maybe temporarily, if you do have clients that use it.

    OWA For SmartPhone

    Wednesday, May 21, 2014 12:57 PM
  • Fiddler shows nothing other than the https attempt to autodiscover.domain.com and the response that the XML can be found at owa.domain.com (and provides a link). A domain joined computer not connected to the VPN experiences the same issue, so it does appear as if a lack of querying for an SCP record could be the issue. Remember that I have taken a domain joined computer and disjoined the domain, while leaving it on the SAME network (accessing the exact same DNS servers), produces the same result.

    As for why the redirect, because I was running other tests before I fully released autodiscover, had to fully control the autodiscover feature because I was migrating from an E2k3 forest to a new E2k7 forest. And I did not want to add the secondary host headers to my production site (no good reason, just did not want to).

    This still leaves me with my question, what is done special to get external/non domain joined Outlook clients to choose an Exchange connection?

    Wednesday, May 21, 2014 5:07 PM
  • Cannot disable IMAP, all protocols must be available.
    Wednesday, May 21, 2014 5:07 PM
  • Answered above. But... DNS already has an A record for AutoDiscover; that is how I get to my site. I presume you mean why not go direct to the main site, as opposed to a 301 redirect (have not tried a 302).

    Also, as an FYI, the first record is an MX record, wouldn't help here.

    Wednesday, May 21, 2014 5:13 PM
  • Hi,

    SCP is not available for external clients. It is expected. Currently, the issue is about Exchange Autodiscover not working for external clients. Even if you configure the local Autodisocver XML, some other Exchange services may still encounter problems.

    I'd appreciate if you could let us know the following details:

    • Where do you configure the Autodiscover as owa.domain.com?
    • Where do you configure the Autodiscover redirection?
    • How to you configure the Autodiscover redirection?
    • We already have an A record for Autodiscover, which server is the autodiscover resolved to?
    • What do you mean the "my site" and the "main site"? Which site is Internet facing?

    Please also post the snapshot of Test-Autoconfiguration on an external client which has an existing Outlook profile. Thanks for your help!

    Thanks,

    Jessie


    • Edited by Jessie Yuan Thursday, May 22, 2014 8:44 AM mistake input
    Thursday, May 22, 2014 8:43 AM
  • I have found the catalyst but not the root cause. Instead of doing the redirect, I moved the host header to the main default site. Once I moved the host header "autodiscover.domain.com"; ALL clients selected Exchange. But to answer your questions.

    We installed Exchange as normal, used the EWS and AutoDiscover set commands to set the external URLs to owa.domain.com. During a standard Exchange installation, Exchange is installed to the default (aka main) site. I configured a new site, and provided the host header of autodiscover.domain.com; again because I needed to get data before I turned it on), the main site has a host header of owa.domain.com. I used the IIS7 redirect option with a 301 redirect to redirect autodiscover.domain.com to owa.domain.com (DNS has the appropriate records for both). Autodiscover & OWA .domain.com both exist on the same servers, just different sites (i.e. w3svc1 & w3svc2). All sites are internet facing.

    AGAIN... ExRCA worked as did all non Outlook clients; ONLY Outlook clients failed to get the appropriate reason. But for grins and giggles I removed the 301 redirect and reassigned the host headers to the default site (w3svc1) and lo and behold Outlook started working correctly.

    So the answer was to remove the 301 redirect and go direct to the Exchange virtual directories.

    • Marked as answer by Kennywood Thursday, May 22, 2014 9:37 PM
    Thursday, May 22, 2014 9:37 PM
  • Yeah. Sorry about the MX. I think it's something automatic now, after all these years. It should have been CNAME.

    And, yes, why not go to wherever the "main site" is.


    --- Rich Matheisen MCSE&I, Exchange MVP

    Friday, May 23, 2014 1:38 AM