Repairing the Information Store

1. Open a command prompt.
2. Navigate to the folder where your databases are. You can check this by looking at the Database tab in Mailbox Store properties in Exchange Manager. In my case I would navigate to E:\Exchange\MDBDATA\ where E:\ was the drive letter of that big IDE drive we installed Exchange to.
3. Type "E:\Program Files\exchsrvr\BIN\eseutil.exe" /p priv1.edb where priv1.edb is your private (aka- mailbox) store. Use search to find eseutil.exe if you're having trouble finding it, and enter the full path to execute it.
4. You should get a warning message- simply click OK.
5. ESEUtil will notify you that is "Initiating REPAIR Mode" and it will begin scanning and repairing the private store. This can take a long time, and you will need roughly at least 50% free disk space on this drive.
6. When has successfully repaired the private store it is time to repair the public store.
7. Type "E:\Program Files\exchsrvr\BIN\eseutil.exe" /p pub1.edb where pub1.edb is your public (aka- public folders) store.
8. You should get a warning message- simply click OK.
9. ESEUtil will notify you that is "Initiating REPAIR Mode" and it will begin scanning and repairing the private store. This can take a long time, and you will need roughly at least 50% free disk space on this drive. Do not close the command prompt when it is done.
10. Now open the Services MMC, and restart the Microsoft Exchange Information Store Service.
11. In the Exchange Manager find the databases. Mount and then promptly dismount each one.
12. Next, shut the Information Store service down again in the Services MMC.
13. Back at the command prompt, type "E:\Program Files\exchsrvr\BIN\eseutil.exe" /d priv1.edb to defragment the private information store database.
14. When that completes type "E:\Program Files\exchsrvr\BIN\eseutil.exe" /d pub1.edb to defragment the private information store database. (Figure 6)
15. Now open the Services MMC, and restart the Microsoft Exchange Information Store Service.
16. When that completes type "E:\Program Files\exchsrvr\BIN\isinteg.exe" -s servername -fix -test alltests to run integrity checking and repairs on the databases.
17. Your databases will all need to be offline for this to work. If they are not listed as offline go into the Exchange Manager and dismount them. Type the number corresponding to your mailbox store and hit Enter. (Figure 7)
18. Type Y and hit Enter. The tests will begin.
19. These tests will be much quicker than any of the other commands you've run so far. On my private store the process only took about an hour.
20. When that completes type "E:\Program Files\exchsrvr\BIN\isinteg.exe" -s servername -fix -test alltests to run integrity checking and repairs on the other database.

Figure 6

Figure 7

Once these steps are complete you should be able to mount your information stores, and have a fully functioning Exchange server populated with real data from your production environment. Of course as time goes on it will become increasingly inconsistent with your production environment, but you can periodically refresh the lab with a new backup from production following the steps above. The important thing is that should the need arise to test deploying a new Exchange Server on new hardware you have real mailboxes representative of your production environment to move to the new server. This will give you a good idea of how long the process will take, and what problems you might encounter. In any case, open the Services MMC and restart the Information Store service, and then open the Exchange Manager and remount both databases.

Imaging Our Lab Desktops

All that is left is to apply your desktop image to your desktop computers. After all the heavy lifting you've done up to this point this is a cake walk. Just make a new Ghost boot disk to create a drive mapping appropriate for your lab environment, fdisk the desktops, and then image them with Ghost. Then bring each one online and run through the minimal setup required. Once they are joined to the domain and running smoothly, you're pretty much done.

Our lab is now running at 100%. One suggestion I would make at this point is that you now save an image of your 3 main machines- LABDC1, LABDC2, and EMAIL. Those required a lot of work to get set up correctly and you want to avoid redoing it if you can. Update these images periodically. The frequency with which you refresh the images really depends on how active you are in the lab, but always keep that first image you made and then just keep a most recent image that you update maybe once every 3-9 months depending on how often you make configuration changes.

Documenting the Lab

Documentation is the single most important piece of any technical project you undertake. This project is no exception. As you can see I developed a healthy tome documenting my little lab, and it paid off because there were not really any surprises or big questions going into the project. Please take this, and use it as a guideline for developing your own documentation on this project. Another point I want to make about documentation though is that the lab is now a living, breathing thing. You are going to make changes to the lab, and test how they work. You should be documenting the changes you make, and the results they produce in a formal way. When you think you've got a clever GPO setting to make, but it causes all user accounts to not be able to run any software you should have this written down somewhere. It's not enough that you tested it out and avoided a headache in production. You want to make sure someone else doesn't make the same mistake testing the same setting in the future, or that you even do it again having forgotten about the first time.

Also, you may make a change that seems harmless at first. Three new changes later and you have a problem. It will be nice to step backwards through your log of the most recent changes to see what combination of things may be causing the issue. And lastly, if you are working with other people in your department on the lab, all of the work going on in the lab needs to be transparent to everyone. When you change the router ACLs and someone else starts seeing a problem with their videoconferencing apps they're testing out, they ought to be able to quickly look through the change log to see what the issues might be.

Now, instead of spouting righteous idealism at you I'm going to offer a quick suggestion as to how to make this a reality. I may provide a detailed guide separately in the future, but for now it will suffice to give general suggestion. Setup a Linux or *BSD box on some spare hardware. Install Apache, PHP, and MySQL, and some sort of content management system. I'm preferential to Joomla myself. Add users for anyone who will be working in the lab so that each one can record their own updates, and you can track each to an individual. There are some Linux distributions which require less setup effort than Windows, and Joomla is a cakewalk. So you ought to have this up and running quicker than you got your domain controllers together. In fact you could do this while waiting for those endless Exchange commands to run.

As for how to use your Joomla to your advantage, that is mostly up to you. It is versatile and easy-to-use software, which is often found running news sites or blogs. So come up with your own formal submission guidelines for your lab. Like each change must be submitted with a description of why the change was made (the desired result), and any appropriate links to knowledgebase articles or security bulletins. Joomla will display the name of the person who submitted the "article" and the time and date it was submitted. Have each person go back and update their submissions with reports of how the changes worked. IOW, did they have the desired effect? Start each update with a time and date mark to denote the portion of the submission that is updated. Finally, update it again with a note that the changes were pushed to production, and if there are any unforeseen issues with this roll out post yet another update to the "article." If there are indeed problems with the roll out in production you should have a good body of evidence to start with when you go into your analysis in postmortem meetings.

In any case, I won't go into too much more detail than that. This article is long enough already.