((MXECHO))

It is rather common for people to experience problems after their mailbox has been moved between Exchange Servers. This is usually due to something else playing a part in the move, for example maybe Anti_Virus on the server has not been configured properly (http://support.microsoft.com/kb/823166 and http://www.msexchange.org/articles/Properly-Configure-file-system-antivirus-Exchange.html) or maybe something else is hooked into the mailbox when trying to move, 3rd party archiver or indexer…whatever. What can you do to help verify that your mailbox moves will go as planned? Well of course you can test on a small subset prior to your whole org, but you can also turn up diagnostic logging on the Exchange Server to get more information about the mailbox moves during the move, so should something go wrong you can go back and review.

In Exchange 2003 – Navigate in Exchange System Manager to the Exchange Server, right-click and choose Properties, open the Diagnostic Logging tab and choose MSExchangeIS\System\Move Mailbox – turn this up to Maximum. This will generate a lot of events in the application log on your server (so be mindful of space) but will also give you much more information about how the procedure went and if there were any errors in the process.

In Exchange 2007 you will use the Management Shell

set-eventloglevel –id “MSExchangeIS\9002 System\Move Mailbox” –level expert

and to turn it back down

set-eventloglevel –id “MSExchangeIS\9002 System\Move Mailbox” –level lowest

Hope this helps in troubleshooting Move Mailbox operations.

If you ever find your self in a position where you need to run a hard repair against an Exchange database, it is important you understand the entire procedure. First I should say that running the /p against your database should never be your first choice, it is always your last resort. You have no backup, and no other options.

So here is your procedure

1. eseutil /p <path to edb>
   1. this process will take a long time, usually deleting the unicode table takes the longest and you should be careful not to click in the black command prompt window, this can pause eseutil. If you do pause, you can resume by clicking the top cmd promt title bar and pressing F5. This procedure will take a while.
   2. this process deletes data that is corrupt or incomplete so the database can be brought back to a consistent state.
2. eseutil /d <path to edb>
   1. this process will defrag the repaired database and must be run after the /p.
   2. you must have at least 110% free space, relative to the database size in order to run this command. You can redirect to another temp location using the /t switch (eseutil /d <full path to edb> /tX:\tempdfg.edb)
   3. again do not click the command prompt screen, it may pause eseutil
3. isinteg –fix <servername> –test alltests
   1. Before you can run isinteg –fix you will have to mount and dismount the database. To do this,
      1. move all logs from the original storage group location, stop smtp so no new mail is delivered to the database, mount the DB and then dismount, you can then restart SMTP.
   2. isinteg will create a log file named isinteg.pri, check this log when finished, at the bottom of the log you will see how many errors and fixes were encountered. Run this test until you see 0 errors and 0 fixes. You may need to run this 2 or 3 times.

Once you have run EACH of the steps above you can then mount your Database and allow your clients to connect. Each is very important to the stability of your database in the future. It is even recommended that you eventually move all your mailboxes from this database to a new database in the future.

The process of using eseutil /p can get you out of a bad situation but it is never something you want to use unless you are out of options. This will take a LONG time and you will lose data from your DB.

recap – process is

eseutil /p

eseutil /d

mount / dismount

isinteg –fix –s <servername> –test alltests

I ran across a situation the other day that I thought could use some additional explanation. In this case when users would open a Public Folder for the first time through Outlook the Outlook client would lock up or become unresponsive. If the user closed (end task) Outlook and went back into the same Public Folder then it opened quickly. If they waited (not ending task) then the Outlook client would “hang” for 40 seconds to 2 or 3 minutes – depending on how many items were in the Public Folder, but the folder would eventually open. The more items, the longer the wait time. As testing the Admin, created new profiles, and even restarted the computer several times to test. The issue ONLY occurs the first time they open the folder, after the first long pause, the folder opens fast each and every time. These clients were online clients. To clarify, this was for each folder in the Public Folder hierarchy. 

When we open a Public Folder in Outlook online mode the server creates the view for your client based on the view requested by the client. On most clients the view is standard, meaning they have not added any additional columns or modifications. In this standard scenario, the server has the general view already created as a table and can provide this view to the client quickly. However if your client is requesting a different view, then the server must create this view as a table in the store in order to present the view to the client. Once the view is created it is kept for a given amount of time (varies depending on Exchange version, but at least days) and is reused the next time it is requested. This is why the users would see the data quickly after the initial delay.

Do you have any control over these views or workarounds for the initial delay? There are two attributes on the public folder store that can control how many cached views are held and how long they are held for, msexchmaxcachedviews and msexchagingkeeptime. The biggest impact you can have on this initial delay is lowering the item count for the folders you are trying to access. The more items in the folder, the longer it will take to present the new view to your client. The other option you have is to reset your clients views back to default. You may  not even realize that you are using a view that is not common. The Outlook switch /cleanviews will reset your clients views back to default. This will NOT clear any views from the server, just the settings on the client.

This same type of behavior can be seen in mail folders as well, not just Public Folders. In fact many people may see this after a mailbox move as the views associated with the mailbox will needs to be recreated. Once the view is created, as long as it is accessed frequently enough the view will not be deleted from the server and the clients performance will remain quick. If the user goes on vacation….and doesn’t access their custom view for a given amount of time, then when they return they will also more than likely see some initial delays while those views are being created.

For additional information on this behavior see this TechNet article http://technet.microsoft.com/en-us/library/cc535025.aspx

If you have ever wanted to have a look at the Performance of your Exchange Server, any version, then this is the post for you

Using PerfWiz you can easily configure a Performance Monitor counter to take a snapshot of your server over a given period of time, the best part is it uses a wizard to capture the counters that mean the most to a Windows Server/Exchange Server so you do not have to be a PerfMon genius. Then using the PAL tool you can analyze the .blg file that the PefWiz counter creates and get a nice report with graphs to review and diagnose or build baselines of your Exchange Server. The report even explains what the counters mean and what you should be looking for. You install the PerfWiz on your Exchange Server (quick and easy install, no reboot required) and PAL on any workstation, there are some pre-reqs for the PAL tool so make sure to read through them on the site below.

Keeping an eye on performance trends can be invaluable when trying to justify hardware upgrades or for better tuning of your servers. I am sure you will find this tool combination useful.

PerfWiz - http://www.microsoft.com/downloads/details.aspx?FamilyID=31FCCD98-C3A1-4644-9622-FAA046D69214&displaylang=en

PerfWiz - (Exchange 2007) - http://blogs.technet.com/mikelag/archive/2008/05/02/perfwiz-replacement-for-exchange-2007.aspx

PAL - http://pal.codeplex.com/

Recently I ran across a scenario where a company had migrated from Exchange 2003 to Exchange 2007 and noticed that their Search functionality was behaving differently. They, like most, used their email as a major component of their business. Work orders would come into their mailboxes and they would use Search to find and manage the flood of inbound emails. Each email would have a subject pattern that was somewhat predictable based on their work ordering numbering scheme. When they would search they would search for their portion of the code. This portion was not always the first portion of the string of characters. When using Exchange 2003 this worked great. Once they moved to Exchange 2007, they got inconsistent results. Why? Answer

Before I explain the difference before the clean and dirty states of an Exchange database we should explain how

I have noticed a lot of questions come up regarding the severity of the 8275 error on an Exchange 2003 Server.

Event Type: Error
Event Source: MSExchangeFBPublish
Event Category: General
Event ID: 8275
Date: <date>
Time: <time>
User: N/A
Computer: <server>
Description:
SchedulePlusFreeBusy folder could not be opened for duplicate message deletion on virtual machine <server name>. The error number is 0×80040115.
For more information, click http://www.microsoft.com/contentredirect.asp.

This error normally can be resolved by restarting the System Attendant, if this error is being logged on a cluster failing over to the other node (and then back if desired) would also resolve the error.

Keep in mind that restarting the SA will restart your Information Store service as well so you should schedule this during a maintenance window.

When you look up another users Free Busy you may see ////// hash marks. Many Administrators know these hash marks, they can sometimes be frustrating. But, before immediately thinking you have a problem with Free Busy, it is important to know some, valid reasons for seeing these hash marks //////

For example, lets say there is a free busy message in the public folder but no meetings are scheduled in the calendar. You may see hash marks, not just a blank schedule when looking up the user. Below are the different mailbox/client scenarios and what they produce in this type of situation.

Free Busy message exists in Public Folder, but no meetings are scheduled during the clients publishing period (generally 2 months)

MB = Mailbox, CL = Client

MB Exchange 2003 with CL Outlook 2003 or 2007 = ////////////

MB Exchange 2007 with CL Outlook 2007 = <nothing>

MB Exchane 2007 with Outlook 2003 = /////////////

So you can see the only time we will actually see a blank calendar when there are no appointments or meetings scheduled in the users calendar is when we are using Outlook 2007 and Exchange 2007. Otherwise if the users calendar is blank for the entire publishing period we would see hash marks.

So, easy test. Next time you are fighting a ////// Free Busy battle, see if posting a meeting to the users calendar has any affect. Remember to give the entry time to publish and replicate if using multiple Public Folder Shed + Free Busy replicas.

Mail store will not mount, in Exchange System Manager you see an Internal Processing error with error ID c1041724. You also notice an error in the application log, 9518 with error code 0xfffffddc.

How do you find out what is wrong?

First, you need to make sense of the error codes. If you have not used err.exe before, this is a perfect time to become familiar. Download this tool from Microsoft

I don