A Microsoft Technologies Blog

Tag Archives: Exchange 2007

If you don’t want to hear the back story, go ahead and skip down to ‘Rubber, Meet Road’ section, I tend to be windy. Is it even called windy when you type incessantly? I digress….

So, we’re in the middle of an Exchange migration. As most of you know, sometimes these migrations can be painfully slow, suffer setbacks, delays, etc. So, to that end, we had to move mailboxes off of server A and over to server B due to disk storage issues. Sadly, server A doesn’t have enough room on the drive to do an offline defrag after moving the email to server B. Needless to say, the drive is REALLY low on space, I’m talking under 1GB out of 600GB low. I monitored the disk carefully for a while, making sure that the almost 400GB of whitespace in the databases I have freed up is doing the trick keeping the drive from filling up. After a week or two, things are looking good with no substantial decrease in disk space, which was what I expected. Alas, a month later (yes, the migration was only supposed to be delayed by a few weeks, but again, we all know how that goes) I get more disk space alerts, and about 100 more MB of space had been chewed up. I filter the event log for event ID 1221 which tells me that I have ample whitespace remaining in the two databases…. So what is taking up my space? Following best practices, log files are on a different drive, so I know that isn’t the culprit. So, as you likely already figured out from the title, it was in fact the Exchange CatalogData-<GUID> folder(s). There were two folders, one for each database, and their total size was 15GB. Now, that is a lot of index for only 300GB of mail. I knew that even 10GB would likely buy me the space I needed to ride this migration delay out and not have to perform any unnecessary maintenance and downtime.

In Exchange 2007 the CatalogData-<GUID> folder is located in the same folder as the mailbox database by default. I had initially set out to move the CatalogData-<GUID> folders as I have some other drives on that server with some space. One of the first few links returned on my search sent me to this article by Vidad Cosonok. Vidad’s article was a quick ‘how to’ on freeing up space in short order on a filled up drive to buy some time. I read through it, and it looked easy enough, and it also didn’t look like it was going to cause any downtime so I gave it a go. Right around 5 p.m. (to be on the safe side) just like the article said, I stopped the Microsoft Exchange Search Indexer service, deleted two CatalogData-<GUID> folders with a hard delete (shift-delete) and restarted the service. Bing Bang, just like that, I had 15GB of free space on the drive, no errors, and the service had re-created the folders and was re-indexing the two databases. It is important to point out, that if a user tries to run a search on their email while the index is being rebuilt, it will take an extremely long time and may return a “No Items Found” when the item is actually there (false negative). It might behoove you to do this after hours, and depending on your user tolerance, you might consider doing it over a weekend as it will tax the server during the rebuilding of the index. The next morning, I checked the CatalogData folders and their combined size was 1.5GB. How about that! This leads me to believe that Microsoft Exchange 2007 does zero maintenance on catalog files, and an administrator should probably add it to their best practices and list of yearly maintenance tasks to rebuild the indexes. I would also encourage you to do this shortly after a migration on the source server, as is the case in this scenario, assuming you need the space. I monitored the index over the next couple of days and found the CatalogData-<GUID> folder did not increase much, which suggests to me that it is done with the initial indexing pass on the database and is simply keeping up with new email.

It is important to point out, that if a user tries to run a search on their email while the initial re-index is occurring, it will take an extremely long time and may return a “No Items Found” when the item is actually there (false negative). It might behoove you to do this after hours, and depending on your user tolerance, you might consider doing it over a weekend.

One more quick disclaimer, I bugged my Exchange Guru colleague Robert Durkin and asked about the application of this situation to Exchange 2010, and he said that while there are some differences with the distribution of the catalog when a 2010 mailbox database is in a DAG, in general the process should be the same in 2010 as mentioned by the article I linked above by Vidad Cosonok. I did not test this on 2010 and cannot speak to its applicability, so as always I’d recommend testing first.

A common problem I’ve read about, and personally experienced, is deleting a user and their mailbox, only to find out later that they had a recurring calendar meeting in a conference room, or they were an administrative assistant, or something like that. This will cause orphaned calendar items that can be a pain to clean up. When I recently ran into this problem, I noodled around trying to find an answer. I found forums on Microsoft’s site, Experts-Exchange, etc. with nothing that was really helpful. Finally, I hit up a peer of mine, Robert Durkin. Robert sent me this link of a post by Dominic Savio that got me going in the right direction.

Dominic’s post covered the basics and had the information I needed, but it still required some playing to get what I needed. So, I ended up with three commands to clean up old orphaned calendar items:

This command will delete all calendar appointments originating from the deleted user in a single target mailbox using that deleted user’s email address. This will ensure that only calendar appointments from that user will be deleted since we’re A) using a unique string to identify the appointments and B) specifying the Calendar folder. Be careful if you’ve added the departed user’s email as an alias to another account because I didn’t test that and I am not sure what those results would be.

I borrowed the filter portion of my last post in this command to delete the appointments originating from the deleted user in every mailbox whose Custom Attribute 14 is set to ResourceMB. I went ahead and entered this custom attribute for every conference room, projector, and video cart we have so that I can clean them all up with one command.

You can also use the –TargetMailbox parameter to redirect items to a separate mailbox instead of delete them in the event of a disaster. The full list of parameters for TargetMailbox is located here.

Quick note. I ran into a scenario where the user’s account was already deleted, so when I would run the command, it didn’t do any clean up. When I checked the appointment, I saw that the user had ‘No e-mail address exists for this person’ in the properties in Outlook. Since this was the case, the command using the email address obviously didn’t work. I replaced the email address with the displayed user name in the appointment and it worked like a champ. The modified command looked something like this:

We were getting slim on storage on our Exchange server so I had to knock out some cleanup today. I saw that there were several service accounts with 40K messages or so apiece in them. Not sure how common these mailboxes are, but some are dumping grounds for NDRs, network/service alerts, or in our case, mail flow monitoring accounts. So, I composed this simple command to clean out the inbox of those service accounts. This script is for 2007, not 100% how different the script would be in 2010 since I know they made some significant changes to the 2010 Export-Mailbox command, but this worked like a dream in 2007:

Export-Mailbox -Identity ‘service-mailbox’ –DeleteContent

This quick script will delete all messages from the mailbox with no backup. Of course, you have to replace ‘service-mailbox’ with the alias of your service mailbox.

Now, I took it one step further. In order to repeat this process on a semi-regular basis, I added an ‘svc’ value to Custom Attribute 15. I then wrote this command to select these accounts and clean them out: