In this scenario when have a single Exchange 2003 standard server installed and installed a new server with Exchange 2007 standard with CAS/HUB/MBX role (multi-role server).
Our problem was that we had too many users that used OWA and ActiveSync so we couldn’t be without this function.
I this case we had 3 different solutions to choose between.
1. Use two different IP addresses; one for the Exchange 2003 OWA/AS and one for the Exchange 2007 OWA/AS
2. Use a front-end firewall like ISA server or something else to publish the correct server
3. Install a new server that act as Exchange 2007 CAS server.
Option 1 was not a good choice because we don’t want to change anything on the end-user’s side like webmail address or ActiveSync settings.
Option 2 was a good idea but the customer didn’t want that type of solution and didn’t got the license for ISA.
Option 3 was the best choice in our solution, with this one we didn’t need to change the DNS record or any settings on the end-users. The only thing to change was the firewall rules.
When we had the Exchange 2003 (2003 Standard) and Exchange 2007 (2007 Standard) in place we did a decision to install a third Exchange server to act as the traditional “Front-end” server, with Exchange 2007 it’s called Client Access Server (CAS).
We imported a 3rd part certificate for IIS service thru PowerShell and configured the OWA to answer on the correct inside and outside web address.
Then we thought it was just to go… But it wasn’t!
We had 2 test users, let’s call them testuser1 and testuser2. They we’re located at different servers to check so everything worked well.
It was checked against the internal webmail address: https://hostname.domain.local/owa (can only be used if the mailbox is located at the 2007 server) so we used instead https://hostname.domain.local/exchange (this should be used if the mailbox CAN be located at the 2003 server). If the mailbox is not located on the 2003 server it will redirect the end-user to the 2007 OWA instead.
After a couple of retries, it didn’t work so well…
I searched the MS newsgroups and other resources like teamblog and google of course :-)
Almost without any luck!
Until I found out what was the problem, thanks to a colleague of mine that found an article on google on it.
If the original 2007 server was installed with “all” roles CAS, HUB, MBX after an uninstallation of the CAS role the server is not in correct state to support the coexistence.
The solution: In our case was to just disable the ‘Require SSL’ on the Default Web Site on the HUB, MBX server after removing the CAS role and restarted the WWW services ‘iisreset’.
On the link I found they were also running some PowerShell commands, but I didn’t need that.
We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.
In this scenario when have a single Exchange 2003 standard server installed and installed a new server with Exchange 2007 standard with CAS/HUB/MBX role (multi-role server).
Our problem was that we had too many users that used OWA and ActiveSync so we couldn’t be without this function.
I this case we had 3 different solutions to choose between.
1. Use two different IP addresses; one for the Exchange 2003 OWA/AS and one for the Exchange 2007 OWA/AS
2. Use a front-end firewall like ISA server or something else to publish the correct server
3. Install a new server that act as Exchange 2007 CAS server.
Option 1 was not a good choice because we don’t want to change anything on the end-user’s side like webmail address or ActiveSync settings.
Option 2 was a good idea but the customer didn’t want that type of solution and didn’t got the license for ISA.
Option 3 was the best choice in our solution, with this one we didn’t need to change the DNS record or any settings on the end-users. The only thing to change was the firewall rules.
When we had the Exchange 2003 (2003 Standard) and Exchange 2007 (2007 Standard) in place we did a decision to install a third Exchange server to act as the traditional “Front-end” server, with Exchange 2007 it’s called Client Access Server (CAS).
We imported a 3rd part certificate for IIS service thru PowerShell and configured the OWA to answer on the correct inside and outside web address.
Then we thought it was just to go… But it wasn’t!
We had 2 test users, let’s call them testuser1 and testuser2. They we’re located at different servers to check so everything worked well.
It was checked against the internal webmail address: https://hostname.domain.local/owa (can only be used if the mailbox is located at the 2007 server) so we used instead https://hostname.domain.local/exchange (this should be used if the mailbox CAN be located at the 2003 server). If the mailbox is not located on the 2003 server it will redirect the end-user to the 2007 OWA instead.
After a couple of retries, it didn’t work so well…
I searched the MS newsgroups and other resources like teamblog and google of course :-)
Almost without any luck!
Until I found out what was the problem, thanks to a colleague of mine that found an article on google on it.
If the original 2007 server was installed with “all” roles CAS, HUB, MBX after an uninstallation of the CAS role the server is not in correct state to support the coexistence.
The solution: In our case was to just disable the ‘Require SSL’ on the Default Web Site on the HUB, MBX server after removing the CAS role and restarted the WWW services ‘iisreset’.
On the link I found they were also running some PowerShell commands, but I didn’t need that.
I will include them to:
Get-OwaVirtualDirectory -server ServerName | Remove-OwaVirtualDirectory
New-OwaVirtualDirectory -Name “Exchange” -owaversion Exchange2003or2000
-VirtualDirectoryType Mailboxes -WebSiteName “Default Web Site”
New-OwaVirtualDirectory -Name “exadmin” -owaversion Exchange2003or2000
-VirtualDirectoryType exadmin -WebSiteName “Default Web Site”
New-OwaVirtualDirectory -Name “public” -owaversion Exchange2003or2000
-VirtualDirectoryType PublicFolders -WebSiteName “Default Web Site”
After this the redirection started to work as it should.
I completed the mission with a redirection in IIS so that the request to the server/site goes straight to /exchange.
Share this post
Link to post
Share on other sites