locked
2010 OWA and 2003 OWA Coexistantize problem passing credentials RRS feed

  • Question

  • We've recently deployed our Exchange 2010 CAS and we're trying to getting the Exchange 2010 OWA to coexist with mailboxes still on the existing 2003 server.  If we try and log in via the Exchange 2010 OWA with a Exchange 2003 user, it sucessfully reroutes to the Exchange 2003 OWA's path, but the credentials are not being passed or understood correctly.  The error message we receive:

    You could not be logged on to Outlook Web Access. Make sure your domain\user name and password are correct, and then try again.

    If we resupply the same credentials in the same format (doman\<username>) it logs right in with no problem, it just is not seemless with a single point of entry.  I know it should pass credentials, but obviously it is not.

    What we've done already:

    • Applied new certificate (to both boxes) with both the existing OWA name, the new name for legacy, etc. (Although we are NOT testing using the final web address, we just get the certificate warning message and bypass it going into the 2010 OWA box, it will have the public name ones migrated, the final address for the 2003 OWA is in place and working)
    • Ran the set virtual directory command in EMS
    • Forms based Auth enabled for both sides, disabled on Back End 2003 servers

     

    Thanks for you help in advance.

    Friday, May 27, 2011 2:48 PM

All replies

  • When you run Get-OwaVirtualDirectory | fl on the Exchange 2010 OWA virtual directory, what do you show for the Exchange2003Url, LogonFormat and DefaultDomain properties? Does that Exchange2003Url go straight to the Exchange 2003 Server?  Do you have all the required SANs in the certificates, and do you have the primary OWA name as the CA in each certificate?  The Exchange 2010 certificate doesn't need the legacy (Exchange2003Url) in its SANs since that name shouldn't direct to that server, but it shouldn't hurt anything if it does.

    If you provide more specifics, you'll get better help.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Friday, May 27, 2011 3:19 PM
  • Exchange2003Url = https://owa2003.<external domain name>.com/exchange   (Which is correct, we have the DNS records created and I can browse directly to it)

    LogonFormat= FullDomain

    DefaultDomain= <blank>

     

    Yes, that web address browses directly to the Exchange 2003 FE server.

    Yes, both certs have the existing external production address name and legacy address name included.

    I don't understand that 3rd question, CA = Cert Authority or Client Access?

     

    I have found some additional information.  The attempt to pass creds is semi-working.  On the 2003 FE server in the IIS Logs I get the following:

    OST /exchweb/bin/auth/owaauth.dll - 443 - ********** Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.1;+WOW64;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0;+MDDR;+InfoPath.3;+.NET4.0C;+.NET4.0E) 302 0 0

    As you can see its a 302 error code, which is "Object Moved"?

     

    Then in the Security logs at the same time:

     

    Event ID 529
    
    Logon Failure:
       Reason:    Unknown user name or bad password
       User Name:  <test user name>
       Domain:    <AD Domain>
       Logon Type:  8
       Logon Process:  Advapi 
       Authentication Package:  Negotiate
       Workstation Name:  <2003 FE Server Name>
       Caller User Name:  <2003 FE Server Name>$
       Caller Domain:  <AD Domain>
       Caller Logon ID:  (0x0,0x3E7)
       Caller Process ID:  5088
       Transited Services:  -
       Source Network Address:  <Test Client IP>
       Source Port:  62135




    For more information, see Help and Support Center at

     

    Friday, May 27, 2011 4:07 PM
  • Sorry, that CA was a typo.  I meant CN (Common Name).

    Make sure the Exchange 2010 servers are in the "Exchange Servers" group.

    Make sure the Exchange 2003 servers are in the "Exchange Domain Servers" group, that group is a member of the "Exchange Enterprise Servers" group, and both groups are in the root Users container in AD.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Friday, May 27, 2011 9:59 PM
  • Hello Sean,

     

    What you have done are completely correct for deploying the redirection from Exchange 2010 to Exchange 2003 OWA.

     

    I just would like to ask, have you restart the IIS services on both Exchange 2010 and 2003 server after doing the configuration such as, setting Exchange2003URL, configuring the FBA. If not, please reset the IIS service by “IISreset” to refresh the settings.

     

    If it still does not work, can we directly access the exchange 2003 owa url and log in it successfully?

     

    You can also check the IIS log on the Exchange 2003 server to see if there are any related error code and post it for us if possible.

     

    Thanks,

    Simon

    Monday, May 30, 2011 8:22 AM
    Moderator
  • Ed:

    Yes the common name for the cert is our primary web address for the OWA.  I will confirm that the Exchange computer accounts do exist in those groups first thing tomorrow (Tuesday).

     

    Simon:

    I have restarted IIS on all of the 2003 server I know for sure.  I can't recall if I have restarted IIS on the 2010 server, I will do that tomorrow as well just so I know it has been done.

    In the previous post I have the information you requested, I can log on directly to the 2003 FE server as it is still our Production OWA server, additionally I can log on to it via the new "legacy" url.  Also in that previous post there is a exert from the IIS Logs from the 2003 FE server mentioning a "302" error code.  Let me know if that does not answer your question.

     

    Thanks for the help thus far.

    Monday, May 30, 2011 7:56 PM
  • Ed: Sorry I thought I replied but hadn't.  Each of the servers are in the correct groups.
    Thursday, June 2, 2011 10:52 PM
  • Is the Exchange 2003 server a front-end server configured to use forms-based authentication?


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Friday, June 3, 2011 4:20 AM
  • It is configured for Forms-Based.
    Friday, June 3, 2011 11:30 AM
  • Have you had a chance to look over this any more?
    Wednesday, June 8, 2011 12:09 PM
  • Have you had a chance to look over this any more?
    Wednesday, June 8, 2011 12:09 PM
  • Are you using any reverse proxy in front isa,tmg\uag? If so FBA is typically enabled on the reverse proxy and basic set on the FE\CAS otherwise you will get double prompted. If not did you already try recreating your 2003 OWA virtual directories? I'm thinking your permissions are not correct somewhere within your IIS virtual directories.
    James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
    Wednesday, June 8, 2011 3:38 PM
  • There is no proxy in front of either server.  I have not tried recreating the virtual directories since it is up and running, and working in every regard with the expection of this, ie it has been working perfectly for 5+ years.

    Without recreating, is there a way to check/confirm the permissions?

    Thursday, June 9, 2011 1:18 PM
  • Have you rebooted your 2003 FE's since you impemented the coexistence? If not reboot first. If that doesn't work disable forms based on your FE, renable and test again.
    James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
    Thursday, June 9, 2011 6:12 PM
  • I have rebooted a couple times already, I have also tried disabling and re-enabling forms based already.  Since this unit is still in production I am unable to do this again during the day.

    Do you have any other suggestions I can try in the mean time?

    Thursday, June 9, 2011 8:10 PM
  • Since no solution was found we had no other choice but to migrate our entire organization at one single time.  Consequently all the mailboxes are running on the new 2010 OWA and are working as expected.
    Sunday, June 12, 2011 1:39 PM