In continuation of my last post, Exchange Recipients, I brought this one to kind of complement a bit more and go deep on the troubleshoot side. Besides that will try to show differences or what we have new since Exchange Server 2003 to Exchange Server 2007.
Mailbox Management Tasks
We can split these ones between the functionalities that we brought from Exchange Server 2003 (even these ones having now Exchange Management Shell cmdlets) and the new ones that we got with Exchange Server 2007.
With this one you can use the New Mailbox wizard in the Exchange Management Console or use the New-Mailbox Exchange Management Console cmdlet. To be able to create accounts you must be delegated Exchange Recipient Administrator role and Account Operator role for the applicable Active Directory containers. Administrators can create a new mailbox by creating a new user and mail or mailbox enabling it in one step, or by mail or mailbox enabling an existing user (in this last bit if using Exchange Management Console you use New Mailbox task, if using Exchange Management Shell you should use Enable-Mailbox cmdlet).
You can move mailboxes across mailbox databases, servers, domains, sites, and forests. You can also move mailboxes among different versions of Exchange Server 200x. To move mailboxes, you can use either the Move Mailbox wizard in the Exchange Management Console or use the Move-Mailbox Exchange Management Console command. To the specific scenario of moving mailboxes between forests you need to use the Exchange Management Shell.
With this task the Exchange Management Shell cmdlet Remove-Mailbox will delete the user account (however if we use the Exchange Management Shell cmdlet Disable-Mailbox will remove the Exchange attributes between the user account and the mailbox - but at the end any of the cmdlets which can be performed through the Exchange Management Console too make the mailbox account orphan during the retention period, unless you use the Exchange Management cmdlet Remove-Mailbox -Permanent).
The properties of a mailbox can be modified from the Exchange Mailbox Console or using the Exchange Management Console cmdlet Set-Mailbox.
The new mailbox management tasks that we got with Exchange Server 2007 have a more statistical focus than the operational one found in the above tasks. These tasks can only be performed through Exchange Management Shell.
With this task you can get the open item counts which tell us about the number of messaging operations, progress operations, table operations, transfer operations, total operations and successful Remote Procedure Calls operations. Besides that you can get the number of open attachments, folders and messages and names and identities associated with the database such as server, storage group, and full mailbox directory names. Last but not least you still can get other information such as latency, client version, client address and logon times.
This task can show you the size of the mailbox, number of messages it contains and last time it was accessed.
Finally this one brings you information about the folders in a specified mailbox, including the number and size of items in the folder, the folder name and other information.
Mailbox Access Troubleshoot
We can troubleshoot a mailbox access issue in many ways, some of them known from the past, others not that much such as cmdlets from the Exchange Management Shell. Here are a few examples.
This Exchange Management Shell cmdlet serves you basically to verify server functionality. It will log on to the mailbox that you specify (using the credentials of the account with which you are logged on to the local computer), or to the system mailbox if you do not specify the -Identity parameter, and retrieve a list of items in the Inbox. Logging on to the mailbox tests two critical protocols that are used when a client connects to a mailbox server: MAPI and LDAP. During authentication, the command indirectly verifies if the MAPI server, Exchange Store, and Directory Service Access are working. After a successful authentication, the command accesses the mailbox to verify that the database is working. If a successful connection to a mailbox is made, the command also determines the time that the logon attempt occurred. You have three levels of granularity here that it can be used through parameters: -Database: will take a database identity and tests the ability to log on to the system mailbox on the specified database; -Identity: will take a mailbox identity and tests the ability to log on to a specific mailbox; and finally -Server: which will take a server identity and tests the ability to log on to each system mailbox on the specified server.
Outlook logging can be enabled on the client side from the Outlook client or through the registry. By default the file is created in “\Documents and Settings\<username>\Local Settings\Temp”. The following article explains how to enable this logging: http://support.microsoft.com/kb/831053/en-us.
It is a good idea to reproduce the issue (try to logon from a local computer and see if the problem can be reproduced) while you monitor network traffic, on both the client and the server, at the same time. When you analyze the data, look for retransmits. A retransmit occurs when the client or the server has to send the same packet of information again, typically because the packets are being dropped between the client and the server. Therefore, when you analyze network captures, determine if the client request is actually getting to the server or if the server is responding but the response is lost before the client receives it.
As said before, but it is always great to remember you can move mailboxes across mailbox databases, servers, domains, sites, and forests. You can also move mailboxes among different versions of Exchange Server 200x. To move mailboxes, you can use either the Move Mailbox wizard in the Exchange Management Console or use the Move-Mailbox Exchange Management Console command. To the specific scenario of moving mailboxes between forests you need to use the Exchange Management Shell.
One good thing that Exchange Server 2007 Move Mailbox task brings you is what is called the Pre Validation. Basically Move Mailbox task will perform a series of checks before actually trying to move the mailbox in a way it saves time by identifying errors right away, rather than waiting until they happen during the move process. Those tests will be user existence verification, source and target credential (done by connecting to the server), mailbox size limit against target database, system mailbox moves blocking, failure if source user does not have a mailbox and finally verification if the target mailbox is mounted.
Administrators can run the validation directly from the Exchange Management Shell cmdlet Move-Mailbox -ValidateOnly. In addition, validation is always executed before a “real” move, i.e. even when running moves using the Exchange Management Console Move Mailbox wizard, a Pre-Validation will be performed and any errors will be reported right away.
Some other advanced options you can use with this Exchange Management Shell cmdlet are:
Exchange Server 2007 Move Mailbox task improves on the existing Exchange Server 2003 logging functionality (event logs and XML report) and adds one new log feature, i.e. the troubleshooting log. All logs are enabled by default and are saved into this path: “<Exchange Install Root>\Logging\MigrationLogs\”.
Move Mailbox Troubleshoot
Email Address Enforcement
If you move a mailbox from Exchange Server 2003 or Exchange Server 2000 to Exchange Server 2007, and the mailbox is part of an e-mail address policy, the e-mail addresses for that mailbox will be automatically updated based on the configuration of the e-mail address policy. If the mailbox had a primary Simple Mail Transfer Protocol (SMTP) address that differs from the e-mail address enforced by the e-mail address policy, that SMTP address will become a secondary SMTP address and the e-mail address generated by the e-mail address policy will become the primary SMTP address. This behaviour is different from what used to happen before when mailboxes were moved to Exchange Server 2003 or Exchange Server 2000. In Exchange Server 2003 or Exchange Server 2000, the e-mail address policy is not applied to a mailbox when it is moved. To prevent accidentally changing the primary SMTP address of a mailbox in an Exchange Server 2007 environment, you must configure the mailbox so that is does not automatically update e-mail addresses based on e-mail address policy. To configure Exchange Server 2003 or Exchange Server 2000 mailboxes, in Active Directory Users and Computers, right-click the recipient, and then select Properties. On the E-mail Addresses tab, clear the Automatically update e-mail addresses based on e-mail address policy check box.
You can specify this parameter to avoid the Outlook 32 Kb rules limit. By default, the Move-Mailbox cmdlet will move rules, both in single forest and cross-forest moves. Using this Exchange Management Shell cmdle you will allow Exchange Server 2007 mailboxes that exceed this limit to be moved back to Exchange Server 2003 successfully. If this option is used the mailbox will be moved without rules.
Damaged or Corrupted Messages
If you are willing to lose the corrupted message, you can skip it when you rerun the Move Mailbox operation using the Exchange Management Console wizard or the Move-Mailbox cmdlet in Exchange Management Shell. In the Move Mailbox wizard, under Move options, you can decide to skip the corrupted message while with the Move-Mailbox cmdlet you can use the -BadItemLimit parameter. Other way of trying to troubleshoot this would be running the ISInteg to check for and fix the corrupted messages. A useful tip would be to you to verify if the antivirus software is not scanning the database where the mailbox you are trying to move at that moment is. Last but not least you can always use MFCMAPI to delete the corrupted message.
There are a few reasons we can point why is ExMerge not being shipped with Exchange Server 2007. Being separate code from the Exchange Server 2007 is one of them. One of the goals for Exchange Server 2007 is to reduce the number of separate tools and code bases supported for migration operations. ExMerge has always been completely separate from all shared Exchange migration code, as so this has caused several technical problems like the need to support an independent PST file provider and so on. These issues have caused delays in updates, limited functionality and extra support costs for customers and Microsoft as well. Besides that being an independent tool didn't help either. The fact that ExMerge is an independent tool has caused a lot of unintended consequences regarding the scenarios where it is used. Every time a tool is used for something it was not designed for, the risk of unintended consequences and bugs increase. Also, over use of the Exmerge tool works as an incentive to under use our other migration tools where they are better suited. This adds extra cost to the management of Exchange.
Obviously if we didn't ship ExMerge with Exchange Server 2007 we still needed to provide some replacement to our customers in the areas that out tools from previous versions of Exchange would not cover what ExMerge could cover. Regarding that the export and import PST files options in the Exchange Management Shell are another way in which we are investing in PowerShell as a scripting platform for Exchange Server 2007. The good news with the replacements is that Administrators can bypass Outlook when attempting to restore and backup a mailbox directly from a PST file and it will support Unicode PST files.
In practical terms those replacements, or in more appropriate words, those Exchange Management Shell cmdlets will be the following ones:
Is a task developed by the migration team to allow Administrators to export content from active mailboxes to a folder inside other active mailboxes. The initial idea for this task was to be a complete replacement for ExMerge. The implementation of some of this functionalities was problematic and it required more time than initially planned. It deletes content from source mailbox after exporting it to target mailbox and also automatically exports dumpster items as regular messages in the target mailbox. Messages from the dumpster are converted to regular items in the folder or .pst file to which you export data. If you want to export from a PST file you need to run this cmdlet from a 32 bits box.
To import data from a PST file to a mailbox, you need to run this cmdlet from a 32 bits box. You cannot import data by using the Import-Mailbox Exchange Management Shell cmdlet to a mailbox that is on a server running Exchange 2003 or Exchange 2000. To import data from a PST file to a mailbox on a server that is running Exchange 2003 or Exchange 2000, you must use the ExMerge tool. By default, the Import-Mailbox Exchange Management Shell cmdlet exports all empty folders, special folders, and subfolders to the target location. To specify folders to either include in, or exclude from the export, use the -IncludeFolders or -ExcludeFolders parameter. The Import-Mailbox cmdlet imports all associated folder messages if they exist in the PST file. Associated messages contain hidden data with information about rules, views, and forms. The Import-Mailbox cmdlet imports all message types, including messages, calendar items, contacts, distribution lists, journal entries, tasks, notes, and documents. When data is imported from a PST file, it is merged into the existing mailbox. If a message from the PST file already exists, it will not be imported as a duplicate message.
This Exchange Management Shell cmdlet is used to recover mailbox content from databases in the Recovery Storage Group. It ca only be used to copy data from a disconnected mailbox to an active one.
Posted by Pedro Alves
You may also want to take a look at scriptlogic's exchange management solution that covers exchange security permissions management, exchange reporting and email archiving.
Its covers so much of the exchange management issues we admins deal with.