Skip to main content

Outlook Web Access (OWA) implementation in mixed Exchange 2007 and Exchange 2000/2003 environment

Microsoft documentation about transition to Exchange 2007 suggests that you should install HUB Transport and Client Access (CAS) roles first and than mailbox server role. Exchange 2007 installation order in transition should look like this:

  • Client Access server role
  • Hub Transport server role
  • Mailbox server role
  • Unified Messaging server role

Exchange 2007 CAS role enables users to gain access to their mailboxes through web browser (OWA), ActiveSync or Outlook Anywhere (fromerly known as RPC over HTTPS). It is actually "replacement" for Exchange Front-End server known from previous versions.

Microsoft suggests that you should replace Front-end servers with Exchange 2007 CAS (I think it would be best to say redirect users to new Exchange CAS. Redirection process can be done on FW or just as a change in DNS, but this depends on your network configuration) prior mailbox move from Exchange 2000/2003 to Exchange 2007 mailbox server.

Since new Exchange 2007 OWA is using /owa( as virtual directory name, redirection is done automatically if you open in your web browser.

Choice whether you will be redirected to Exchange 2007 OWA or Exchange 2000/2003 OWA is based on your mailbox storage location. This means that if your mailbox resides on Exchange 2003 server you will see Exchange 2003 OWA look-and-feel, and if your mailbox resides on Exchange 2007 mailbox server you will see Exchange 2007 OWA look-and-feel. This process is done automatically and the only request is that primary point for OWA is Exchange 2007 CAS server.

So if you access

... OWA 2007 screen will be shown on the page and if your mailbox store is on Exchange 2003 server.... will see Exchange 2003 look-and-feel.

Don't forget to import SSL certificate from your Exchange 2000/2003 server to your new Exchange 2007 Client Access Server (or servers).

Related articles:


Popular posts from this blog

Netscaler vs Exchange 2019 "time out during ssl handshake stage

If you are using Citrix Netscaler as load balancer in front of Exchange 2019 server you must know this: Microsoft Exchange 2019 is secured by default and allows only TLS 1.2. Therefore default schannel settings are as follows (using IISCrypto tool from Nartac Software): While Citrix Netscaler offers following Cipher Suites: TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA TLS_DH_anon_WITH_AES_256_CBC_SHA TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA Now, you will fi

Reason: [{LED=250 2.1.5 RESOLVER.GRP.Expanded; distribution list expanded};{MSG=};{FQDN=};{IP=};{LRT=}]

 If you got this error checking the mail flow for a distribution group, it means the distribution group is closed and only internal senders can send e-mail to this group. When outside user sends e-mail to this group you get  Reason: [{LED=250 2.1.5 RESOLVER.GRP.Expanded; distribution list expanded};{MSG=};{FQDN=};{IP=};{LRT=}] Set Delivery for this group to internal and external users and your problem will be solved. 

Ports that need to be open on Firewall for Edge Transport servers

Ports that need to be open on firewall for Edge Server subscription with Hub Server to function properly: For Inbound traffic: SMTP - TCP port 25 (from Internet) SMTP - TCP port 25 (from Edge server to Hub server on internal network) For Outbound traffic: SMTP - TCP/UDP port 25 (from Edge to Internet) SMTP - TCP/UDP port 25 (from Hub to Edge server) LDAP for EdgeSync - TCP port 50389 (from Hub to Edge server) Secure LDAP for EdgeSync - TCP port 50636 (from Hub to Edge server) Since Edge server needs to communicate with Hub server it is important that it can resolve Hub transport servers by FQDN and Hub transport servers must be able to resolve Edge servers by its FQDNs. To accomplish this you need to either open 53 (DNS) port and configure internal network adapter to use internal DNS but as a security precaution I would suggest to enter DNS records for Edge servers on local DNS manually and to fill hosts file on Edge servers with FQDNs for Hub transport servers.