Defragging Exchange in 4 easy steps!

It’s easy enough to search the web for various instructions on how to do an offline defrag of your Exchange database. With SBS, an online defrag occurs every morning. However, that does not actually reduce the size of the .edb/.stm files. Performing an offline defrag is recommended, for example, after you have finished deleting a lot of old emails or purging old mailboxes.

Here are the four basic steps I follow:

1. Backup
You can never have enough backups. I will first use NTBackup to create a full backup of the Exchange database. I will usually do the backup to a file rather than tape, and put it on a separate partition that where my Exchange database is located.

2. Dismount
Go into ESM and dismount your Exchange partitions. Drill down ESM > Servers > Your Server > First Storage Group. Right click on the Mailbox store, and click Dismount Store. Then right click on the Public Store, and click Dismount Store.

3. Defrag
Open up a command window (Start > Run > Cmd). Assuming your Exchange partition is located on your C: drive, type the following commands:

Step 1.  cd \Program Files\Exchsrvr\mdbdata
Step 2.  dir priv1* pub1*
Step 3.  ..\bin\eseutil /d pub1.edb
Step 4.  ..\bin\eseutil /d priv1.edb
Step 5.  dir priv1* pub1*

Step 1 simply points you to the subdirectory where the priv1* and pub1* files exist,  Step 2 lists the sizes of your files. Write these down to compare with the size afterwards. Step 3 & 4 performs your actual inplace defrag of your public and private stores. I generally do the public store first, just because I have less to lose if I screw up my public store. Also, since the public store is usually smaller, it takes less time. The private store, could very well take up to an hour for every 5GB of the priv1 store.
Step 5 lets you compare your new file sizes to your old sizes.

4. Remount & Backup
Now go back to ESM and remount your public and private stores! Most best practices suggest doing another full backup immediately. Most of the time, I wait until my scheduled backup runs. But that’s your call.

Term Server and the Remote App

The following situation was recently posted to the NG. Les Connor’s reply, as usual, nailed the solution perfectly!

First SBS2003 installation, one reception workstation and 2 business partners with laptops who would be in and out of the office. The problem is the line-of-business applications these people use. I was amazed at how limited the configuration options are for these apps. They mostly seem to have derived from old DOS apps to which have been retrofitted for some multi user capabilities. They all expect the binaries and data to be in a single folder hierarchy with no configuration options to separate the data to a different folder/drive/share. The trouble with these types of apps is that you cannot install the executables/binaries/read only bits on the local machine (eg laptop) and have them access data on a network share. So all binaries have to be loaded over the wire (or wireless) with consequential performance hits.

When I got RWW up and running and the partners discovered Remote Desktop Connection they were really impressed. However now we have only one permanently wired in workstation (reception) which is available (only after hours) for RDC.

So finally I get to my question. If we were to set up a Terminal Server could it be used via RWW and RDC to access the business apps (with just screen updates/keyboard/mouse going over the wire)? I note that in RWW only administrators can remote connect to servers – does Terminal Server appear as a server in RWW or are there other options?

And the answer is … (thanks, Les):

Hi John, So long as the LOB apps will run on a TS, this is a great approach.

With the limited amount of users in the current environment, and subject to your hardware being up to the task … Install Virtual Server on the SBS. Install your TS as a virtual machine, join it to the domain. A new link to ‘Connect to my Company’s Application Server’ will magically appear in Remote Web Workplace :-).

Now this is sweet. From anywhere you have an internet connection, and without installing any software, anywhere, your mobile users have access to the LOB apps, as well as the rest of the domain/network resources 🙂

Les Connor [SBS Community Member – SBS MVP]
SBS Rocks !

SBS and the Triple Crown

In horse racing, they talk about winning the Triple Crown — one horse winning the Kentucky Derby, the Belmont and the Preakness in the same year. Likewise, in baseball, they talk about a batter wining the Triple Crown — one person who, at the end of the season, leads the league in most home runs, the hightest batting average, and the most runs batted in (RBI’s).

In many ways, three (3) is a lucky number. In the Small Business Server (SBS) world, we often recommend to SBS newbies to take the time and go through the process of installing SBS a minimum of three times.

Why is that?

  • First of all, nothing replaces experience. Practice makes perfect. And with SBS, you want to have the experience under your belt before you put that server into production mode.
  • Second, once you put that server into production, you can’t just walk in and say to the customer one day, “Whoops! Guess what? I renamed the SBS server incorrectly, and I’m going to need to reformat your entire server right now!”
  • Third, and most importantly, SBS is not just one server — it’s like having ten (10) servers in one.

Let’s count them: We have … 1) W2K3 Server, 2) Term Server, 3) Exchange, 4) DHCP, 5) DNS, 6) IIS, 7) Sharepoint/Intranet, 8) Remote Web Workplace. And if your using SBS Premium, throw in 9) ISA and 10) SQL.

Microsoft, to some degree, went against its own best practices by putting things like Exchange and ISA on the same server. And that just drives some Windows Server purists crazy.

The fact is that not only did Microsoft accomplish what could have been considered a near impossibility, they did it in a grand and successful way. The SBS Dev team has created wizards and front end interfeaces (can you say RWW?), that the rest of the Windows Server world can only dream about.

So, here’s a summary of what I recommend to new SBS administrators, integrators and consultants:

1. Install SBS the first time to learn the process.

If you bought an OEM SBS server, blow it away! While you are installing it the first, take notes of your questions. In fact, have a computer setup and connected to the SBS newsgroup and ask your questions real time. Hook up one workstation and learn what’s required to add a user and add a computer.

Some questions you may want to make sure you get answered during this process:
– How should I partition my disk drives?
– I already have a public domain name for my email. Do I use that fort my SBS server name?
– Should I override the default locations for installing Exchange / Sharepoint / etc.?
– One NIC or two? Why?
– Can I host my public website on the SBS server?

2. After getting answere to these and other questions, reformat and reload SBS a second time. Your goal this second time is to make sure you record (in writing) every prompt, every selection, every option you choose. You want to make sure you understand how and why you selected to put Exchange in its own partition, or what ports you need to open up to make email and Internet access work.

If you did this successfully, you may still have some questions. Perhaps its how to customize and map shared folders to drive letters for all users. Or how to backup and restore a sharepoint database. Or how to do an offline Exchange defrag. Get answer to those questions. Make sure you know where all your 3rd party drivers are located. Make sure you know how to access and use the RAID interface utility.

3. When ready, reformat and reinstall a third time. Your goal this time is to make sure that all your documentation is correct, that you understand it, and you understand how to recover from some unexpected events.

I remember listening to Jeff Middleton back in Sept 2005 as he discussed disaster recovery in the aftermath of Hurricane Katrina. He said that one of the things he learned was that you may know a particular command (like ‘Net Route’) like the back of your hand. But when you are under pressure, and have not slept for 24 or 48 hours, even the simplest commands suddenly become like foreign words to you. They don’t make sense and you’re scrambling for your notes! 

Having your notes written down will help in the event something does happens, and under immense pressure you don’t even know the answer to something as simple as: What’s your Internal NIC IP address?

I hope this helps!


Tired of all those "Success Audit" event entries?

[Editor’s note] I have received several private responses on this post, many saying that deleting successful events may not be a good thing. Here’s one of the best examples why: 

Let’s say you saw 10 unsuccessful events of someone trying to logon as Administrator, followed by a successful event of an Administraot logging on. What’s your conclusion? You would conclude that someone just hacked in on the 11th attempt.

However, if you were filtering out or deleting all of the successful events, you would miss the fact that this hacker was eventually successful.

Nonetheless, many people continually ask how to eliminate the successful events. I will leave this post up, if for no other reason than to encourage people to become familiar with using the Group Policy Editor for tweaking and customizing your SBS server]

Come on — raise your hand if you really enjoy opening up the event viewer on your SBS server and seeing 18,000 success audit entries!  No hands? I didn’t think so.

Kudos to Super Gumby who pointed me toward the true path (the light at the end of tunnel) on how to properly disable those success audits. (As an aside, I’m not recommending that you do this. But if you want to learn … keep reading).

1. Open up your Server Mgmt Console, and drill down as follows:
-Advanced Management
   -Group Policy Management
      -Forest (your server)
            -(Your Server)
               -Domain Controllers

2. Right click on ‘Small Business Server Auditing Policy’ and then click Edit.

3. The Group Policy Editor displays. Drill down as follows:
-Computer Configuration
   -Windows Settings
      -Security Settings
         -Local Policies
            -Audit Policy

4. On the right panel you will see that ‘Audit logon events’ is set to record both Success & Failure events.

5. Double click on ‘Audit logon events’ and uncheck ‘Success’. Click Apply > OK, close the GP Editor and you’re done!

Good luck!

Backing up/moving your POP3 connector settings

None of my SBS sites use the POP3 connector any longer, having migrated them to SMTP even before SBS2003 was released. However, there are still a lot of sites that continue to use it. What surprised me was that I always thought that you were pressing the POP3 connector service once you had more than 10-15 POP3 mailboxes. But I was recently told of sites with 40 to 50 POP3 mailboxes!

So, the question came up: if you are migrating your SBS2003 server over to new hardware, can you copy and migrate over your POP3 connector user info? And the answer is …. Yes! Thanks to Merv Porter and Frank McCallister for providing this information:

If this is a swing from SBS 2003 to SBS 2003 (just new hardware, same server/domain/user account names), I think you can just copy the POP3 Connector .dat and maybe the .bak files (IMBData.dat and IMBData.bak) from the old server to the new and the accounts will then appear in the POP3 Connector on the new server:


C:\Program Files\Microsoft Windows Small Business Server\Networking\POP3\IMBData.dat

C:\Program Files\Microsoft Windows Small Business Server\Networking\POP3\IMBData.bak


I just tried this on a virgin SBS 2003 VPC image.  Copied the .dat and .bak files from a client’s SBS 2003 server to this SBS 2003 VPC.  If I open the POP3 Manager on the SBS 2003 VPC, all my client’s POP3 account info is now there. 


Still trying to reach you, Mr. Gaskin!

I have been trying to contact either Mr. Gaskin and the editors at Network World ever since they received my initial response to Mr. Gatskin’s review of the SBS 2003 R2.

In what could be categorized as “truth is stranger than fiction”, my repeated attempts to contact therm have fallen null and void. That is, until my latest attempt on Friday evening. Lo and behold, on Saturday evening I find this in my inbox:

This message was created automatically by mail delivery software. A message that you sent has not yet been delivered to one or more of its recipients after more than 24 hours on the queue.


The message identifier is:     1GBi6k-0004Im-3B

The subject of the message is: FW: FW: Feedback

The date of the message is:    Fri, 11 Aug 2006 21:16:16 -0400


The address to which the message has not yet been delivered is:


No action is required on your part. Delivery attempts will continue for some time, and this warning may be repeated at intervals if the message remains undelivered. Eventually the mail delivery software will give up, and when that happens, the message will be returned to you.

Hopefully, Mr. Gaskin will be able to resolve his email problems. Or, perhaps he would consider installing SBS2003!

Why use SBS Swing Migration?

In the SBS 2003 Public Newsgroup, and probably most other newsgroups, we often walk a thin line when it comes to recommending 3rd party solutions and products. There are those who love Trend, and those who hate it. Same goes for anything Symantec, or Dell, or HP, or any other HW/SW vendor.

One of the solutions that is constantly recommended is Jeff Middleton’s SBS Swing Migration. His process is perfect whether you are on SBS2003 and need to migrate to new hardware, or if you are on an older version of SBS, and wants to upgrade to SBS 2003 and implement new server hardware at the same time.

Sometimes our love for his solution and methodology may come across as being a paid advertisement. But I can assure you that it’s not. Speaking personally, I paid full price for Jeff’s Swing Migration kit, because (1) it works, (2) he deserves to be paid for his efforts, and (3) did I say it works really well? I receive  no kickbacks or anything of the kind from the sale of Jeff’s product. What I do get is the satisfaction in knowing that Jeff’s expertise has helped you.

So, I decided I would post my own reasons for recommending Jeff’s Swing Migration product. If I missed anything, please add your own comments!

1. With Jeff’s approach, the current server is initially taken offline for just a few minutes while you backup the AD. You then put the current server back on line and the customer continues working and using it.

2. Meanwhile, you are now free to load, install, configure, test your new server — all to your hearts content — and even do it offsite, away from the office.

3. Then when you are ready to convert, you take down the old system, migrate settings, migrate data and exchange files, and bring the server back up. Voila! you’re done.

4. But, the best news of all … with Jeff’s approach, you do NOT have to go and reconfigure every workstation and redo settings, profiles, etc. Nope! Once the new server is up, you turn on the  workstations, and the chances are good (outisde of maytbe a printer issue here or there), the users won’t even know you made a change!!

Now that’s how I spell relief!

Kevin Weilbacher [SBS-MVP]
“The days pass by so quickly now, the nights are seldom long”


Response to the James Gaskin’s "Challenge"

Author James Gaskin published a review of SBS 2003 R2  in Network World on 7/31/2006.

I thought the article was quite favorable, highlighting many of the important features in R2. I responded to him privately, first, with my comments and suggestions, and subsequently posted on my blog:

Primarily, I took exception to his repeated assertions that SBS could not be kept secured by neophyte SBS admins, nor could they install or maintain it without help from consultants. I also suggested that he could have done his readers a service by directing them to the SBS Specialist Community and the public SBS newsgreoup, if help was required.

Well, he did receive my comments, because he sent me back a challenge privately.

I appreciate your comments, and will mention them soon on the SMB page. So you’re willing to bet that 100 percent, or even 90 percent, of your SBS customers have an up to date, secured installation with all appropriate patches and security alerts under control without much outside help? If that’s true, I’ll do a story on just you guys and how your customers are more secure than most.


James E. Gaskin

Well, I responded to his challenge the same day (with two NW editors copied on the email). He claims he did not receive my response. But rather than the courtesy of trying to contact me again to see if I received his challenge, he went ahead and made presumptions based on not hearing back from me – Microsoft Fans Don’t Respond

This evening, I resent my response to his challenge, and have posted it below. Tell me what you think!

James, I hope I’m not naïve enough to claim that every SBS site is up to date on their security patches! Some intervention, even with R2, is required. But R2 makes the whole process so much easier, and that was the (positive) point I was trying to make.

Microsoft’s SBS Dev team has done a fantastic job in designing a new front end interface to WSUS in R2. They’ve simplified the whole process of reviewing new patches, and scheduling them for download and implementation. I say this from personal experience. I tried installing standard WSUS on several systems in the past year, and was frustrated with the learning curve and process. But, with R2 I would not be hesitant in training selected users at a customer site to be responsible for reviewing/scheduling security patches.


Saying that, most customers that I know still prefer that their SBS consultant continue to manage and schedule implementation of security patches. In those cases, the combination of Remote Web Workplace and WSUS in SBS R2 makes this a very easy process for the SBS consultant to do remotely.


Now, if you can get me an SBS R2/WSUS console that allows me to monitor multiple customer sites on one screen, then we would be rocking!


Finally, I’d be happy to touch base with my counterparts, if that’s OK with you, to see if any of them would like to take you up on their offer!



Kevin Weilbacher


Protect yourself when updating your server remotely

At our local Tampa Bay SBS user group meeting, we were talking about what to do when you lose remote connection to your server, and the server needs to be rebooted. The common situation would be that you are using RWW to apply updates to your server, and one of the updates automatically restarts IIS. Say bye-bye to your RWW connection to your server.

So one suggestion, which I really like, is that just prior to starting your update process, go to the command line of your server, and use the ‘at’ (scheduling) command and schedule a forced reboot for some 20 or 30 minutes from now.

For example, you could enter: at 18:30 “shutdown /r” — which will schedule a one time shutdown and restart of your server at 6:30pm.

Here’s the full ‘at’ command syntaxs:

C:\Documents and Settings\Administrator>at /?
The AT command schedules commands and programs to run on a computer at
a specified time and date. The Schedule service must be running to use
the AT command.

AT [\\computername] [ [id] [/DELETE] | /DELETE [/YES]]
AT [\\computername] time [/INTERACTIVE]
    [ /EVERY:date[,…] | /NEXT:date[,…]] “command”

\\computername     Specifies a remote computer. Commands are scheduled on the
                   local computer if this parameter is omitted.
id                 Is an identification number assigned to a scheduled
/delete            Cancels a scheduled command. If id is omitted, all the
                   scheduled commands on the computer are canceled.
/yes               Used with cancel all jobs command when no further
                   confirmation is desired.
time               Specifies the time when command is to run.
/interactive       Allows the job to interact with the desktop of the user
                   who is logged on at the time the job runs.
/every:date[,…]  Runs the command on each specified day(s) of the week or
                   month. If date is omitted, the current day of the month
                   is assumed.
/next:date[,…]   Runs the specified command on the next occurrence of the
                   day (for example, next Thursday).  If date is omitted, the
                   current day of the month is assumed.
“command”          Is the Windows NT command, or batch program to be run.