Microsoft Exchange and Blackberry Server Specialists

SEMblog

Microsoft Exchange Server and
Blackberry Enterprise Server news, views and fixes.

Exchange 2010 Database White Space

With Exchange 2007 and older versions, one of the key elements that an Exchange administrator needed to keep an eye on, and caused confusion for newcomers to Exchange was the amount of white space in the database.
This is reported as free space in the event viewer via event ID 1221 during the night and is the result of content being removed from the database by the online defrag process.

I have written about this event ID and the white space elsewhere:
http://www.amset.info/exchange/event1221.asp

With Exchange 2010, the behaviour of the database has changed.
Instead of doing a online defrag during a fixed time window, it now does it constantly. This means that content that has passed the deleted item retention period, is removed from the database shortly afterwards, rather than waiting for the next online defrag window.

However because the process is running constantly, event ID 1221 isn't written to the event log. Therefore an administrator may not have a clue as to how much of the database is white space, and how much is actual content.

This question can be easily answered, using EMS, as the amount of free space in the database is available via get-mailboxdatabase -Status:

Get-MailboxDatabase -Status | Select Servername, Name, AvailableNewMailboxSpace

This command will show you the name of the Server the database is mounted on, the name of the database (which is unique across the Exchange org with Exchange 2010) and the mount of space available in the database for new content.
The result will be something along the lines of this:

ServerName                     Name                          AvailableNewMailboxSpace
----------                          ----                            ------------------------
SMB-A                             Mailbox Database         27.75 MB (29,097,984 bytes)

The command used -get-mailboxdatabase -status can provide quite a bit of information about the databases in your Exchange org, use the |fl command to see the full list.

RPC Client Access Array

One of the new features with Exchange 2010 is the client access array. When configured correctly, this is quite a useful feature. In my view it is something that should be configured on all Exchange 2010 servers, even on a single server deployment.

Background

The full explanation of the CAS Array feature is available on Technet, but in short, the reason it was introduced was due to the changes in the way connections to the database are now handled. With Exchange 2007 and older, Outlook connected directly to the mailbox server (unless using Outlook Anywhere). With Exchange 2010 all clients now connect to the CAS servers. The CAS servers then manage the connection to the database.
With the Database Availability Group (DAG) meaning that an active mailbox could be moved between servers easily, connecting directly to the mailbox server wasn't really practical.

The simple way to think of a CAS array is like a virtual Exchange server. Clients see this virtual name instead of the actual name of either the CAS server or the mailbox server.

Why you should configure a CAS Array

If you are deploying multiple CAS servers, or a DAG, then a CAS array is pretty much mandatory. However if you are on a single server, or are separating the mailbox and the CAS role on to separate machines, then a CAS array is still of value.
If you have ever done a migration or disaster recovery, one of the key pain points has been getting Outlook to point to the new server in a timely manner. As long as the original server was alive, then Outlook will redirect to the correct server automatically. During a migration though, it may not be possible to get all clients to connect to the old server in a timely manner and the old server has to be removed.

However as the CAS array is simply a DNS entry and a small configuration in Exchange, it is completely under the control of the network administrator. A change to the DNS will make all Outlook clients point to another server.

If there is a possibility at any time in the future of additional Exchange servers being introduced, or the CAS role moved to its own server, the use of the CAS array from the start will become invaluable for easing that transition. All MAPI clients will use it, so as well as Outlook, this can also include things like Blackberry Enterprise Server.

CAS Array Configuration Notes

Ideally the CAS array should be configured before any mailboxes are moved to Exchange 2010. If you don't, then the clients that are moved will use the true name of the CAS server, and even after the CAS array has been configured, they will not change unless the mailbox is moved between servers or the Outlook profile is changed.
If CAS Array is therefore introduced retrospectively, it can produce mixed results if all clients haven't been updated with the new value some how.

You can use the CAS array with Network Load Balancing (NLB), but if the server  has all of the roles and is also a DAG member, then you must use an external load balancer. Using NLB on the same server as the DAG is not supported.

A CAS array cannot go across Active Directory sites. Therefore if you are doing a two host DAG, with the second (passive) host in a data centre or similar, and have separated the AD sites, you will need two CAS arrays. In the event of a full failover, you will need to change both the CAS Array value on the database and the DNS. While this is a manual intervention, it does mean the process remains under your control.

The CAS array host does not have to be in the SSL certificate, simply because Outlook doesn't make any http connections to that host name.
You should not use the same host name for other services, particularly anything that is being accessed externally (like OWA), but you can use the same IP address and therefore NLB virtual IP.
For example, you could use outlook.example.local as the CAS Array host, then mail.example.com for OWA, SMTP, Outlook Anywhere etc.
If your internal and external domain are the same, then ensure the internal name doesn’t resolve, externally so no wildcard in the domain etc. Failure to do so will result in a confused Outlook, and will probably mean Outlook Anywhere has performance issues, if it connects at all.

Finally, on the DNS entry for the CAS array, turn the TTL time down. This will ensure that if you do have to change the host name IP address, it is picked up quickly.

Background and Configuration of the CAS Array: http://technet.microsoft.com/en-us/library/ee332317.aspx

Sent Items Storage for Shared Mailboxes

The default behaviour of Outlook with regards to sent items continues to come up on forums as an issue.

By default, when you send an email using the From field via your Send As permissions, the item you have sent goes in to your own Sent Items folder. This is because you sent it, not the person whose mailbox it was sent from. This can be useful from a tracking point of view (who sent the email).

However it may also be useful for the item to be stored in the Sent Items folder of the Shared Mailbox so that other users or even the mailbox owner can see what was sent.

How you achieve this depends on the version of Outlook that you are running. The version of Exchange doesn't matter.

For Outlook 2003 and 2007, a registry change is required, following the installation of an update. If you are keeping the machines up to date, then further updates should not be required.
These registry changes are outlined in the following articles:

Outlook 2007
http://support.microsoft.com/kb/972148
Requires Outlook 2007 Hotfix: 970944
http://support.microsoft.com/kb/970944/

Outlook 2003
http://support.microsoft.com/kb/953804/
Requires Outlook 2003 Hotfix: 953803
http://support.microsoft.com/kb/953803/


For older versions of Outlook, you will need to look at third party tools. The only one that I am aware of are the tools from Ivasoft: http://www.ivasoft.biz/

For OWA, you will need to use a server side tool, again the third party tools from the above site are the only ones that I am aware of - and support for latest version of Exchange isn't available.

For Outlook 2010, no registry change is required, you just need to add the mailbox in a different way.
Instead of adding the mailbox as an additional mailbox through the Properties of the primary mailbox, add the additional mailbox as an additional Account. That means going through the new Account wizard again. This feature also allows you to have connections to another mailbox in another Exchange forest at the same time - I have used this to migrate public folders (see http://blog.sembee.co.uk/post/Cross-Forest-Public-Folder-Migration.aspx)

However if you are using Outlook 2010, you should also be aware of the issues  in this KB article: http://support.microsoft.com/kb/2297543 (Performance problems when you try to access folders in a secondary mailbox in Outlook 2010).

(Late posting because I forgot to press publish).

After Moving Mailbox, Type is Set to "Linked"

During a recent mass migration from Exchange 2003 to Exchange 2010, I had a large number of mailboxes that appeared on the new server as the type "Linked".

Now while you can change the mailbox type between normal, shared and resource, it isn't supported to change it from Linked. The only fix is to disconnect the mailbox from the user and reconnect it. This of course has other consequences if not done with care, including breaking internal email replies to old messages that user sent.

I therefore went looking for the actual cause.

The most common cause is another account having the permission "Associated External Account". That is an Exchange 2003 permission, which I cannot find the equivalent of in Exchange 2007/2010. Therefore the only way I found to remove that permission was to move the mailbox back to the Exchange 2003 server. This allowed me to look at the mailbox permissions through ADUC and remove the permission. It should only be on the "Self". In this client's case I found it was allocated to a SID, so a broken account.

If you attempt to modify the permission while the mailbox is on Exchange 2007/2010 you will be unable to and will simply get an error message instead. 

After removing the permission, you can move the mailbox back and it shouldn't be linked.

Very occasionally you will get a mailbox where this does not work, when the drop and reconnect method needs to be used, or you might have a large number of mailboxes that are linked where moving them back is impractical. For those occasions, a script may well be more appropriate.

Fellow Exchange MVP Tony Murray has a PowerShell script to automate this, and it is available from this location:

http://www.open-a-socket.com/index.php/2010/08/30/powershell-script-to-bulk-convert-linked-mailboxes/

Cross Forest Public Folder Migration The Easy Way - Use Outlook 2010

Anyone who has done a cross forest public folder migration will almost certainly be reliving their nightmares about it simply from reading the title.
I was just the same.

Extract the content to a PST file, either manually (selecting about 1000 items at a go) or by using a rule, move the PST file to a machine in the new forest, then import.

Slow, mind-numbing dull and therefore not the most fun part of a migration and always the bit that I don't look forward to. 

However a recent migration was done almost completely hands free. I moved almost 9gb of data in an afternoon, while I went to the cinema.

To do this, I took advantage of the new feature of Outlook 2010 that allows it to connect to two different Exchange organisations at the same time.

This allowed me to create a rule to move the content between the two public folders. Once the rule was set, I left it to get on with it. The speed wasn't great, but compared to moving it manually, it was a considerable time saver. After returning from cinema I was able to do more of the migration work, while I waited for the rule to finish.
Furthermore, by using multiple machines, I could move lots of large public folders at once. Once the process was completed, the rule was discarded.
Even before moving the data, when creating the new folders it was easy to setup the permissions as I could compare them side by side.

Where an item was corrupt and couldn't be moved, or the few items that didn't match the rule, I simply moved those items manually or deleted them. In most folders this was only a few hundred items at most.

You still can't copy and paste large numbers of items, as the problem with trying to copy/cut and paste more than about 1500 items is still in Outlook, but a rule effectively moves each item individually, so that isn't a problem.
For the folders with small number of items, a straight copy and paste works well.

I used the same procedure to move a stubborn mailbox which wouldn't move on the regular cross forest move mailbox procedure. Much faster than exporting the mailboxes out to PST file and then importing them. It also allowed me to identify the corrupt items and deal with them.


Even if you aren't deploying Outlook 2010 for your migration, it is worth downloading the trial for this feature alone. Then once the migration is complete, discard the trial software.