Saturday, January 29, 2005

Why does the EDB and STM file never get smaller?

I'm going to start out this database discussion with a question a lot of newer Exchange administrators ask. Users have deleted a lot of e-mail, but the EDB and STM files never get any smaller.

Answer: The EDB and STM files do NOT get any smaller. It is a "feature". :-)

The file will grow, but it never gets smaller. As messages are deleted, the space is reorganized in to "white space" and then the space is reused.

However, if users are not emptying their Deleted Items folder, the space is not reused. The user must empty their deleted items. Once items are emptied from their deleted items, the space goes in to the users deleted item recovery cache. With Exchange 2003, the data remains in that cache (by default) for 7 days. After that, the space is reorganized and re-used.

If you want the file size to shrink, use the ESEUTIL.EXE utility, dismount the store, and perform an offline degrag (the /d option).

Check your event viewer in the application log for event id 1221. If it reports less than 20% available white space (based on the size of the EDB file, then it is probably not worth your time to dismount stores and defragment the database.

Why is my EDB and STM files continually growing?

Why are my Exchange databases growing? I have gotten a couple of e-mails from people running Exchange 2000 and 2003 recently asking this question. I thought of a couple of obvious answers, but it was not until I ran in to it in production in a couple of different ways that I had some new insight.

I'm going to separate these in to separate blog entries and try to break them up so that they read a little more logically.

Stay tuned!

Friday, January 28, 2005

Where's Jim?

I have been a real slackdog when it comes to keeping up with this blog. I promised myself that, if I started one, that I would keep up with it. And it has not been for lack of material, but rather time.

I worked about 50 - 60 hours a week on a project for the Army from June until December. While I had a great time, everything else in my life got neglected (like the hedge from hell in front of my house).

Currently, I'm in South Korea working on project for U.S. Pacific Command. If it were not snowing like crazy outside right now (I'm in Seoul), I'd probably be out exploring and looking for electronic gadgets. So much for my weekend and a Saturday off.

Anyway, I'll try to get a little more caught up. I have some good material!

Saturday, January 22, 2005

Enabling Windows 2003 Remote Desktop Connection remotely

I learned a neat new way to enable the Remote Desktop Connection service on Windows 2003 today. Several times, I have set up a Windows 2003 server, and forgotten to right click on the compter, go to the Remote tab, and enable the Remote Desktop Connection service. I figured this was a simple registry key, but I had never bothered to research it.

I was faced with this yesterday and figured it was time to get a Googling! Or, I was going to have to drive a couple of hours through Seoul traffic to get to the remote server site.

Connect to the W2K3 machine's registry remotely.

Locate the following registry subkey:
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server

Locate the following REG_DWORD value:
fDenyTSConnection

Change the value from a 1 to a 0.

Remote the server (you can use the SHUTDOWN.EXE command to do this remotely.)

Monday, January 03, 2005

Exchange 2003 24seven errata - Page 105

Happy New Years everyone! Thanks to Shawn for pointing out this little faux pas on my part. On page 105 of the Exchange 2003 Server 24seven book, I included a method for renaming the extended attribute names. I had done some research on how to do this back in 2000 when people were asking how to do it because they could do it with Exchange 5.5 and earlier.

This is a really bad idea and you should not do it. And, the really embarrasing part is that I have known this is a bad idea since before the Exchange 2000 book was published! Yes, you read that right, the 2000 book.

While it is possible to rename the attributes, this causes problems for Active Directory Users and Computers.

I originally wrote this piece for the 2000 book, but later tested it and decided I should not include it. Unfortunately, I had already submitted the chapter to the editors and did not get it removed. When I was working on the 2003 book, I had forgotten it was in there. With the goal of using as much as possible of the original book (about 60 - 70 % of the book was re-written from scratch), that piece on page 105 got carried over from the old book. I did not notice it during my reviews of that chapter. My bad.