Exchange

One of the things I’ve been doing for as long as I can remember is redirecting requests that don’t go to (or /exchange) to the correct URL. So, if someone goes to or , they get redirected to the correct (secure) URL. Historically I’ve always done this with two components:

• A custom website listening on Port 80 on each CAS server
• A default.aspx file in the root of the Default Web Site redirecting to /owa

This approach no longer works with Exchange 2010 CAS because the PowerShell virtual directory actually operates over Port 80 (authentication is Kerberized). If you try and tinker with this, you’ll start getting errors from Remote PowerShell like this:

VERBOSE: Connecting to cas01.customer.com

If you get the following error when you try to seed a CCR/SCR target node, you may have a Windows Firewall problem.

WARNING: Replication for storage group 'MyCluster\SG01' is still suspended. If needed, you can use the Resume-StorageGroupCopy cmdlet in the Exchange Management Shell to resume replication.

If you take a network trace while this cmdlet is running, you'll find numerous unanswered TCP SYNs from the source node to the target node. Looking in from Sysinternals, you'll find the PowerShell.exe process listening on the port these SYNs are sent to. If you're using the Windows Firewall, you'll need create a rule that permits PowerShell.exe to listen.

I initially assumed these were RPCs so I created a Dynamic RPC rule for PowerShell.exe, but, this didn't work. Thus I just fell back to a rule which permitted TCP connections on any port to PowerShell…

If you've ever had Exchange 2007 setup fail partially, you've probably noticed that some of the components (maybe even the one it failed during) show up as installed, but, if you run the ExBPA (Best Practices Analyzer), it will probably complain that setup failed. With most applications, you can open the Add/Remove Programs (or Programs and Features in WS2008) Control Panel and begin a repair. Unfortunately Exchange does not offer a repair option.

The trick with Exchange is to fix it with the exsetup utility. If, for example, you need to repair a Mailbox server role installation, go to the Exchange installation folder and run "exsetup /role:Mailbox". The utility will resume setup where it left off and clean things up.

I had a question come across my desk the other day about how to enable protocol logging in Exchange 2007 for IMAP and POP. Protocol logging for these protocols generates comma delimited logs similar to HTTP logs (except for IMAP). In Exchange 2003 you enabled these with a couple of . These don't however work in Exchange 2007. Exchange 2007 instead uses a couple of config files on the file system.

To enable the logging for IMAP, you would do this:

1. Browse to C:\Program Files\Microsoft\Exchange Server\ClientAccess\PopImap
2. Open Microsoft.Exchange.Imap4.exe.config with text editor (e.g. Notepad) and scroll to the bottom
3. Modify ProtocolLog from false to true.
4. Modify LogPath as necessary
5. Restart the MsExchangeImap4 service

For POP, simply edit Microsoft.Exchange.Pop3.exe.config instead and restart the MsExcahngePop3 service.

You can use a number of tools to parse the logs, although one tool I would recommend is from Microsoft.

I found another useful script I wrote last year on my hard drive this evening. It's pasted in below. This script will dump quite a bit of useful information about each mailbox on a particular server or set of servers to a CSV file which you can in turn import into Excel and create a spreadsheet from. I typically would import data into a SQL Server table using DTS (Data Transformation Services) if I needed to do alot of computation or data mining. Excel gets very slow when doing tasks that really require an index over a lot of data.

Note: The script uses WMI to get this information so Exchange 2003 is required. Only Exchange View Only level permissions are required in Active Directory, however you will likely need local Administrator privleges on each Exchange server. I don't have an Exchange 2003 server readily available to test and I was running as an Exchange Full Admin when I originally wrote this script.

There are a few properties which I did not export as I did not …

A comment I received on a on sites and subnets in Active Directory was "what benefit(s) does a dedicated Exchange site provide?". There's a couple things to consider here with the advent of Exchange 2007. The first is the great degree of dependency Exchange has on Active Directory data for everything it does. The second, applicable to Exchange 2007 deployments is that Exchange now uses the Active Directory site topology to route email. I'm not familiar enough with this scenario yet to speak to it, but I will speak to the need for fast and reliable global catalog access for Exchange servers.

With Exchange 2000 and 2003, the vast majority of the configuration data for Exchange is stored in Active Directory in the Exchange services container in the configuration partition. All of the configuration data for recipients is stored on top of the objects representing them in Active directory – users for mailboxes, contacts, distribution groups, public folders, etc. More specifically when Exchange n…