Archive for the ‘Windows Server 2008’ Tag

Exchange 2010 – Multiple OWA/ECP Directories Part 1   16 comments


***Edited New-ECPVirtualDirectory cmdlet text – August 12th, 2011***

This document was written to provide step by step instructions for anyone wanting to configure multiple OWA and ECP directories in Exchange 2010. The document will go through a setup and configuration which can provide the baseline for any configuration variation required by an organization needing this type of solution. This document will NOT provide a one stop solution for all scenarios. The solution provided was based on the article by the Exchange Team which can be found here.

Note: The sample configurations shown were done primarily through Exchange Management Shell (EMS). Some of these tasks can be completed through Exchange Management Console (EMC); however, showing them through EMS allows an easily repeatable process through scripting or copy and paste.

Background:

The biggest reason (in my opinion) to have this configuration is in situations where the organization wants to prevent internal Outlook Web App (OWA)/Exchange Control Panel (ECP) traffic in remote sites from coming into the primary site and then back to the remote (via CAS proxy). However, there are 3 common reasons identified by the Exchange Team which calls for this solution, one of which is the reason identified above.

Scenario 1: There is one Active Directory site facing the Internet, and there is a reverse proxy (such as Microsoft Forefront Threat Management Gateway or Unified Access Gateway) in front of Exchange. The reverse proxy is configured to delegate credentials to Exchange, meaning the CAS servers are configured to use Basic or Integrated Windows Authentication (IWA) and not Forms-based Authentication (FBA). The requirement is to provide FBA for all users, internal and external.

Scenario 2: There is a non-Internet facing Active Directory site and your requirement is to provide FBA for all users, internal and external.

In this configuration, in order to provide external users access to OWA or ECP, a CAS in the Internet-facing site must proxy requests to the CAS in the non-Internet-facing site. This requires the CAS in the non-internet-facing site have IWA enabled, thereby disabling FBA.

Scenario 3: There are different users within one organization who require a different OWA experience, such as a different customization of the Form Based login page, or different Public/Private File Access or Segmentation features.

Part 1 of this document will provide the basic setup required for creating multiple sites with different configurations. In part 2 of this document I will show you how to take these basic steps and use them (with some tweaks) to configure a remote site that has two or more CAS servers configured with Windows Network Load Balancing (WNLB).

Prep Work:

In order to get the ground work ready for multiple OWA and ECP virtual directories there are a few things that need to be done.

Step 1: IP Address

Obtain a second IP address and add it to the NIC of your server.

NOTE: If the servers are configured in a Windows NLB cluster please refer to the second part of this document. As there are a few differences that will be required in order for it to work properly.

Above I have shown I have two IP addresses assigned to this NIC. 192.168.50.20 (Primary IP) and .100 for the secondary IP.

Step 2: DNS

Add a DNS entry for that secondary IP address for the name we will want to use in the new FBA OWA web site. I have chosen “testwebmail”. Be sure there is a valid SSL certificate (recommended to have UC or SAN SSL certs) on the server which has the new name “testwebmail” that will be used in the certificate.

NOTE: In order to configure SSL communication during the creation of the new website, a certificate is required. Ensuring it has the correct name, is from a trusted Certificate Authority, and is in the valid date range will avoid certificate errors seen by clients. For more information see this TechNet article.

Step 3: New Web Site

Create a new web site in IIS on the Client Access Server and bind it to the new IP address used in step 1.

To do this open “Internet Information Services” from the Administrative Tools menu. Expand down to “Sites”. You should see the “Default Web Site” listed similar to what’s shown below.

Right click on “Sites” and select “Add Web Site”

Now a box will come up where information will be required to be filled in. I have provided some information for each field that requires input.

 

  1. Site Name – I like to keep mine simple for easy management when in EMS so I named it “FBA”.
  2. Select the physical path where the files will be – I put mine in the inetpub directory under a new folder called FBA.
  3. In the “Type” field, select “https” in the drop down menu.
  4. Enter the IP address that was added from Step 1. This is called the binding.
  5. Select the SSL certificate in the drop down menu.

Once finished you should see this:

Now the ground work is complete and we can move into Exchange and begin our configuration. But wait!…there is someone in my head telling me I should bind the primary IP address to the Default Web Site before moving to Exchange. DON’T LISTEN!!!!! Doing this will actually break powershell. The Exchange Team made a note in their article as well. Good thing I read that article AFTER I already broke it the first few times I tried this. 🙂

Configuring Exchange

Step 4: Adding Exchange Virtual Directories

The web site has been created and bound to the secondary IP address of our server. Also the DNS record that will be used to access the new FBA OWA page was added to DNS. The next step is to go into EMS and begin adding our virtual directories for OWA and ECP.

Login to the Exchange server and open the Exchange Management Shell. Then run Get-OWAVirtualDirectory and Get-ECPVirtualDirectory to see the default OWA and ECP directories.

 

NOTE: Notice the names. In previous steps I mentioned I used a short simple name for the web site I will be adding these new directories to. This is because in EMS the name will always appear as “owa (SiteName)” and “ecp (SiteName)”. With a shorter name it makes it easier to work with in EMS.

Now run the cmdlets to create a new OWA and ECP site.

New-OWAVirtualDirectory –Name FBA –WebSiteName FBA –InternalUrl https://testwebmail.mylab.ad/owa

 

 

New-ECPVirtualDirectory  –WebSiteName FBA –InternalUrl https://testwebmail.mylab.ad/ecp

 

At this point the virtual directories are created with default settings using FBA. Now we have two OWA and two ECP sites both configured to use FBA.

Step 5: Configure the Virtual Directories

To configure the virtual directories we will disable FBA on the Default Web Site OWA and ECP virtual directories.

 

Set-OWAVirtualDirectory –Name “OWA (Default Web Site)” –WindowsAuthentication $true –BasicAuthentication $false –FormsBasedAuthentication $false

 

Set-ECPVirtualDirectory –Name “ECP (Default Web Site)” –WindowsAuthentication $true –BasicAuthentication $false –FormsBasedAuthentication $false

 

NOTE: This sample is configuring the default site with Windows Authentication. This is for scenarios where internal users are not to be prompted or for remote sites that require CAS Proxy functionality to work while allowing local users to access the FBA page locally without going across the WAN. Verify this is needed for the situation and make adjustments to the authentication mechanism as needed.

OPTIONAL:

I like to setup the FBA to not require the domain name as a part of the logon. This prevents less calls to the help desk and end user confusion. Some situations will require the domain name as a part of the logon. For example, in an environment with multiple domains.

To do this simply type the following:

Set-OWAVirtualDirectory –Name “OWA (FBA)” –LogonFormat Username –DefaultDomain mylab.ad

 

Step 6: Verify the Virtual Directory Configuration

Once the virtual directories are configured, verification of the settings can be accomplished with the following cmdlets:

 

Get-OWAVirtualDirectory | FL Name,*Url,*Authentication,LogonFormat,Defaultdomain

 

Get-ECPVirtualDirectory | FL Name,*Url,*Authentication,LogonFormat,Defaultdomain

 

NOTE: “FL” stands for format-list. I don’t want all the output provided by a format-list so I have specified specific parameters I want to see the values of. For more information on how to manipulate the output see this link.

With the above output I can verify that OWA and ECP directories are configured as desired. The directories on the Default Web Site are configured for Windows Authentication and the directories on the FBA web site are configured for FBA with logon format I want.

The final step in the configuration is to run iisreset on the Exchange server to ensure the settings take effect. It is not necessary to open a command prompt. This can be run from EMS.

 

 

NOTE: Because this was a lab environment I did not run iisreset with the /noforce switch. However, if you have active connections to the systems that you do not want to interrupt you should use the /noforce switch.

Conclusion

Now there are two different web sites, each configured with a different authentication mechanism for the OWA and ECP virtual directories. This can allow more flexibility in how clients access OWA/ECP as well as reduce WAN traffic in a remote site scenario where CAS Proxying would normally be used.

The posts are provided “AS-IS” with no warranties, and confers no rights

 

 

Advertisements

Posted February 28, 2011 by Chris Morgan in Exchange/UC

Tagged with , ,

ExPBA – Exchange 2007 CCR Cluster on Windows 2008 false positives   Leave a comment


Want to setup an Exchange 2007 CCR Cluster on Windows 2008!? Of course you do! You want to take advantage of the new clustering capabilities of Windows 2008 coupled with Exchange 2007 CCR clustering glory.

So, you get your clean Windows 2008 install fully patched and configured for the file share witness. Then you install Exchange 2007 SP1 and the latest Update Rollup and get Exchange all configured. Now you are excited because you have this beautiful pristine environment…right!? You wish!

So, as best practice and quality assurance, you open up the Exchange Management Console, go to the toolbox and click on the Best Practices Analyzer. When it opens up you run your Health Check then view the report. Here’s where you enter the twilight zone. You are expecting to see no issues because you don’t mess up. You have a perfect environment here. EXBPA thinks differently however. You open the report to find this little gem.


There is no way you mess up though right? so you drill down in the warnings to click on the “Tell me more about this issue and how to resolve it before someone sees what I did”. Alright, alright, I made that last little bit up. You will see something like this.


When you click on it it will take to the Microsoft page telling you how to fix this. Of course the great thing is their fix isn’t available through the Windows 2008 Cluster Manager. Now what? First you look again because that cant be possible to not have a solution to fix your perfect environment. Then you panic. Then you lean on every IT professionals technical knowledge base…our bible….yes, google! Guess what? You won’t find anything there either. Except maybe a small hand full of blogs such as this one who will tell you the real truth. Come closer….it’s s secret. There is no fix…there is nothing wrong. You are perfect. This is a EXBPA booboo that should be fixed soon but as of this time you will just have to pretend you never saw these two warnings. OR!!!…click the “Do not show me this item again for all instances……EVER”.

I would suggest leaving the warning alone as the fix for this false positive will be coming to an EXBPA definition update soon. This way you can watch in satisfaction as it disappears when you run the update for the tools. You can also set all those non believers straight too. 🙂

The posts are provided “AS-IS” with no warranties, and confers no rights.

Posted November 22, 2008 by Chris Morgan in Exchange/UC

Tagged with ,

%d bloggers like this: