ISINTEG for Microsoft Exchange: a Troubleshooting Tool

ISINTEG (Information Store Integrity checker) is a useful and potentially dangerous tool for checking the integrity of an Information Store and fixing it (the potentially hazardous part).

Much like its cousin ESEUTIL you have to run it from the /bin directory of the c:\Program Files\exchsrvr directory as it is not added to the PATH system variable by default.

The easiest and safest option with ISINTEG is -test. Also don't forget to use -s [SERVERNAME] as this will tell ISINTEG what server to run the test on.

There are other flags that ISINTEG can use such as -patch, -verbose, and -l [LogFile]. But the one that you should be especially careful of is -fix. This has been know to kill an Exchange server, so make sure you have a back up of you Information Store before running this, as a bad store is still better than a bad installation of Exchange. You have been warned!

Windows XP Myths

Andrew K over at Optimize Guides has a very good article on some very common Windows XP myths. It is a suggested read for any Microsoft administrator. I have read many of the myths in the past and tried them out on my computers, or my users computers and for many of the "improve performance" settings have never seen any difference.

I learned a bit today after reading all of the myths, and as stated previously don't use anything the myths try to sell you. Most of the time the settings they are telling you to change simply do not get read by Windows XP, and if they do, hopefully they won't harm you system in any way.

ESEUTIL for Microsoft Exchange, Part 1 The Basics

ESEutil (Extensible Storage Engine utility) is the sister EXE to NTDSutil (New Technology Directory Service I believe). There are three sides to this utility that any Microsoft Exchange administrator should know how to use. The harmless checking options, the hairier defragmentation option, and finally the scariest restore options.

On a side note it should be mentioned to any new Microsoft Exchange administrators that ESEUTIL is not a part of the PATH system variable, and as such must be run from the Exchange/bin folder. If you find yourself using ESEUTIL frequently I would suggest adding it to your path as I have.

First there is the mostly harmless options /k, /mh, and /cc. These flags will do various things that Microsoft Exchange will normally do for you, such as re-run log files after you remount a store. The /mh flag will check the store to see if it was properly shut down and along the way will tell you when the last time it was backed up. This is an easy way to start learning how to use ESEUTIL properly.

Example: “eseutil /mh "d:\program files\exchsrvr\mdbdata\priv1.edb" (Assuming Exchange 2003 is installed on the d:\ drive.)”

This command should return “State: Clean Shutdown” within its output. Also you can use /mh to see how many /r commands have been run against it, with anything greater than zero being your number.

There are other simple flags to use such as /ml to check log files, /mm to dump the metadata (not truly useful to most administrators, but interesting to see none the less.), /mk to see information about the checkpoint file (.chk files).

ESEUTIL /k will run a similar function to running a checksum against a file to verify its integrity. It will only VERIFY the database, not repair as that is what /p and /r are for. This is most often used when Microsoft Exchange has been shut down improperly. On another side note it worth mentioning that hundreds of uninitialized pages are normal, but bad checksums or wrong page numbers are bad. Also you can verify log files with /k in the same way you verify stores.

Example: “eseutil /k "d: \program files\exchsrvr\mdbdata\priv1.edb" “

Just as easy to run is ESEUTIL with the /d flag. This will defragment the .edb file and recover lost disk space. This is much akin to running jetpack against the DHCP.mdb file to defragment the DHCP database in Microsoft Windows Server 2003 and not so much like defragmenting you hard drive with Windows built in defragmenter. You must dismount the store in order to run eseutil /d, but you do not need to stop the Information Store service to do so.

The last function of ESEUTIL, and by far the scariest function set is the restore options. The /r and /p flags can really muck up a Microsoft Exchange store quickly. These options will require their own blog entry so stay tuned for more.

A quick over view of all the options for Microsoft Exchange’s ESEUTIL.
Eseutil /cc Performs a hard recovery after a database restore.
Eseutil /d Performs an offline compaction of a database.
Eseutil /g Verifies the integrity of a database.
Eseutil /k Verifies the checksums of a database.
Eseutil /m Generates formatted output of various database file types. e.g. /mh
Eseutil /p Repairs a corrupted or damaged database.
Eseutil /r Performs soft recovery to bring a single database into a consistent or clean shutdown state.
Eseutil /y Copies a database, streaming file, or log file.

Using Webmin to install Software

Today as I was building a new server running Debian that I needed to install ProFTPD. While I was in the Webmin interface poking around I saw this line:
" The ProFTPd package can be automatically installed by Webmin. Click here to have it downloaded and installed using APT."
Unfortunally I found out that I already have an FTP server installed on the box, but I like the forward thinking of the Webmin crew to offer such an easy way to install software!

Password Strength Checker

Today I StumbledUpon a Password Strength Checker. It will tell you just how strong your password it. Now I thought my standard password was pretty strong. It's eight characters with numbers thrown in elite haxor style, but I found out my password is only "Medium".

I did however find out that the current administrative password is strong, which is good news, now I just need to work on getting a stronger base password, and then go trough all of my accounts and make the necessary changes.

How strong is your password?

A simple way to Secure Microsoft Exchange 2003

One of the easiest ways to secure Microsoft Exchange 2003 is to not run Microsoft Exchange 2003 on an Active Directory Domain controller. This way IF your Microsoft Exchange 2003 Server is compramised you will not have to worry about your Active Directory data being compramised as well.

Small Business Server users should take note of this as the default install of Small Business Server has Microsoft Exchange 2003 Server running on your Active Directory Domain Controller with Microsoft SQL Server running as well. Also more than likely this same server is also running your Active Directory DNS server, DHCP server, WINS server and in some cases even your public Web Site running on IIS and an FTP server also running on IIS.

Secure Multi-Purpose Internet Mail Extension also known as S/MIME

S/MIME protects the integrity and confidentiality of e-mail messages. It only protects the message itself, while using SSL is suggested to protect the transmission channel. S/MIME REQUIRES the use of certificates issued through the use of a Public Key Infrastructure (PKI).

Using a Public Key Infrastructure to secure Microsoft Exchange Server 2003

Public Key Infrastructures (PKI from here on out!) use two mathematically related keys, a Public Key, and a Private Key. The public key is as it's name describes public and thus shared with others so they can Verify your Private key (Message Signing) and Encrypt messages to you. You keep the Private Key private and can then decrypt the messages sent to you with your key and sign outgoing messages to prove they came from you & where not tampered with in transit.

For all of this to work you need a client that supports S/MIME such as Outlook, Outlook Web Access, and most 3rd Party POP3 & IMAP4 clients. Also you need to both trust the same Certificate Authority (CA).

PKI's are best used with-in the same Active Directory Domain/Forest with a Windows 2003 Certificate Authority as the CA for the domain. Also Auto Enrollment must be enabled or all certificates would need to be manually approved by a CA administrator.

Using a Front-end / Back-end to secure Microsoft Exchange 2003

One of the best practices often talked about is the "Front-end / Back-end" topology, where by the Front-end server sits outside of the main network separated by a firewall (known as the "internal firewall"), but protected from the Internet by a separate firewall. The Back-end server meanwhile is within the confines of the internal network.

This configuration allows more ports opened on the external firewall and fewer ports opened on the internal firewall. Also, the data and log files that Exchange needs are keep more secure behind two firewall and no direct access from the Internet. The front-end server will then respond to all Internet SMTP requests and then forward them on to the back-end servers for delivery to users mailboxes.

While this method may be a "Best Practice" it requires at least twice as much hardware and software. You now need at least two servers, two firewalls, and two copies of Windows Server 2003 and Exchange server 2003. To allow this setup to withstand even more abuse you should then also Cluster the Exchange back-end server requiring Windows 2003 Enterprise Edition and Exchange Enterprise edition on the two back-end servers.

A heavily suggested setup is to have the Front-end server running Outlook Web Access (OWA) with a widely know Certificate Authority SSL certificate to provide data encryption to the clients over the public Internet. This requires TCP port 443 (for default installs). Also since the whole reason to have Microsoft Exchange is to send and recieve email with other organizations via the Internet you will need SMTP running over TCP port 25, with Anonymous Access allowed. These would then be the only two ports open on the public/external firewall. On the internal firewall you would need to open TCP port 80 to allow OWA access to the back-end servers, TCP/UDP ports 389 for LDAP (Lightweight Directory Access Protocol), TCP port 3268 for LDAPGC (Global Catalog), and all of this is running with in the confines of IPSEC which would need IP Protocol 51 for Authenticating Header, IP Protocol 50 for Encapsulating Security Protocol, UDP port 500 for the key exchange and TCP/UDP port 88 for KERBEROS.

Making the Jump to Vista!

This morning, I finally made the jump to Windows Vista! It was about two hours to upgrade (didn't have the time to do a clean install) and so far everything is working well. I will try to report back any findings I have after I have really used it.