Exchange 2010: Outlook Anywhere Related To EWS,OAB,OOF

Answered Exchange 2010: Outlook Anywhere Related To EWS,OAB,OOF

  • Friday, June 22, 2012 7:26 PM
     
     

    Currently I have hit a wall, bare with me as I pull my hair out.

    I have been circling around the same posts with no resolve to my issue.

    SAN cert in place through external provider with the principle names as follows:

    DNS Name= us.corp.com

    DNS Name= autodiscover.us.corp.com

    DNS Name: Domain.local

    DNS Name=server.domain.local

    DNS Name=autodiscover.domain.local

    SAN Cert Applied to IIS SMTP (and too a 3rd i cant remember atm i believe CAS or Exchange)

    Back story, Migration from Exchange 2k3 to 2010 on an environment that forwards from main site to offsite location, Main site: corp.com ; Our site: us.corp.com

    so all users on local site us.corp.com function as corp.com. roll users from 2k3 to 2010 mailbox move successful. all local users no issue with oab/oof. 

    NEWLY ADDED hosting via outlook anywhere to other United States affiliates that DO NOT RUN ON OUR LOCAL DOMAIN. Only connection they are able to make is to Outlook Anywhere and OWA. No Direct Domain Auth. 

    Clients Local Outlook 2007, Clients for Affiliates Outlook 2010(via outlook anywhere)

    Now here is my issue: outlook client is able to connect via outlook anywhere once pre-configured through more settings->connection->outlook anywhere-> exchange proxy settings with SSL required pointing to https://us.corp.com -> finish wizard -> open outlook -> Prompt for credentials -> add account -> domain\username -> password -> remember cred. ( Note: again these users function on a separate domain.) 

    From Outlook Anywhere Connection: OAB fails error 0x8004010F, oof error Your out of office settings cannot be displayed, because the server is currently unavailable. Try again later.

    I have added the externalurl to OAB, and EWS.

    Published Via Autodiscover from client I read:

    Autoconfigureation has started, this may take up to a minute

    Autoconfiguraion found the following settings:

    Display Name: First Lastname

    Protocol: Exchange RPC

    Server: Server.Domain.Local

    Login Name: First.Lastname (correct naming convention)

    Availability Service URL: Https://server.domain.local/EWS/Exchange.asmx

    OOF URL: Https://Server.Domain.Local/EWS/Exchange.asmx

    OAB URL: Https://Server.Domain.Local/OAB/hash-hash-hash-hash-hash/

    Unified Message Service URL: Https://server.domain.local/EWS/UM2007Legacy.asmx

    Auth Package: Unspecified

    Protocol: Exchange HTTP

    Server: us.corp.com

    Login Name: First.Lastname ( again correct naming convention ) 

    SSL: Yes

    Mutual Authentication: Yes

    Availability Service URL: Https://us.corp.com/EWS/Exchange.asmx ( Note: when authenticated via IE offers https://us.corp.com/ews/Services.wsdl )

    OOF URL: Https://us.corp.com/EWS/Exchange.asmx

    OAB URL: Https://us.corp.com/oab/hash-hash-hash-hash-hash/    ( Note: when authenticated via IE 403 when you append oab.xml page loads once authenticated.)

    Unified Message Service URL: https://us.corp.com/EWS/UM2007Legacy.asmx

    Auth Package: NTLM

    Certificate Principal Name: msstd:us.corp.com

    With all of this, I have hit a wall. Outlook functions flawlessly on local machines, yet with the these externalurl's in place outlook anywhere will not function to its fullest potential. Currently have users changing password, and settings oof through OWA. Yet that is a very short term fix to a long term problem. OAB is a major concern, as the only way to update is to my knowledge re-setup the remote account ( speculation ).

    I have almost narrowed it down to a few things or i could be missing the picture entirely.

    1) access rights on IIS

    2) authentication methods on IIS

    3) firewall corrupting transmission before it hits exchange. all 433,25,80 straight through to exchange ( possibly TCP only / unsure of UDP on same port)

    4) external DNS for autodiscover.us.corp.com is not established. ( even though it pulls the autodiscover correctly from us.corp.com/autodiscover/autodiscover.xml

    5) I have offended the IT god's, and this is their wraith.


All Replies

  • Saturday, June 23, 2012 12:19 AM
     
     

    I have found a few articles which describes outlooks local functionality in OOF and OAB calls, which basically states that that outlook will use the primary address domain no matter the setting on autoconfiguration. in my case even though the mail hosting site is: us.corp.com , the primary address on the mailbox is corp.com. (we do this to unify us and corp.) 

    OAB ^^

    I have yet to try this though, this will be testing next week. also instead of applying a public DNS entry to autodiscover.corp.com to point to autodiscover.us.corp.com ( which has the high chance of crippling corp.com{if can setup at all because it is already registered}) setting up local host file with autodiscover.corp.com to point to my external ip. Feels promising, tests through testexchangeconnectivity on user@us.corp.com all green.

    Will update when more information is known.



  • Saturday, June 23, 2012 9:02 PM
     
     Answered

    Hosts File Works pointing corp.com to us.corp.com functions as believed above, only issue is SAN cert does not have corp.com as a alternate, functional when removing ssl requirement from autodiscover and oab only. will have to add to SAN cert and integrate and phase out old cert to be able to use ssl for autodiscover and oab.... will also have to setup GPO for the push, and communicate with the aforementioned external entities.

    Hope this helps some people in the future marking as answer reference my other posts for all answers.

  • Sunday, June 24, 2012 5:00 PM
     
     
    This is correct. you could add autodiscover.corp.comto the SAN cert.