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.

New Mailbox

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).

Move Mailbox

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.

Remove Mailbox

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).

Change Mailbox

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.

Get-LogonStatistics

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.

Get-MailboxStatistics

This task can show you the size of the mailbox, number of messages it contains and last time it was accessed.

Get-MailboxFolderStatistics

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.

Test-MAPIConnectivity

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

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.

Network Trace

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.

Moving Mailbox

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:

• -GlobalCatalog: Sets Global Catalog to be used during migration;
• -DomainController: Sets Domain Catalog to be used during migration;
• -MaxThreads: Number of mailboxes to be moved simultaneously (default is four);
• -ValidateOnly: Only runs validation code as so mailbox is not moved;
• -ReportFile: Used for changing the directory and/or file name for the XML report;
• -IgnoreRuleLimitErrors: Used for migrations from Exchange Server 2007 to Exchange Server 2003. This relates to the 32 Kb limit for rules in Exchange Server 2003, allowing 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.

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\”.

• Event Logs - Besides logging start and end of migrations, we now log all errors, warnings and any change to Active Directory objects, such as deleting source mailboxes for cross organization moves and we also use a more intuitive category name, i.e. "Move Mailbox“.
• Move Mailbox XML Report - This report now provides a lot more information than before, such as Source and Target Global Catalog and Domain Controller, all options used, total of mailboxes moved (including total of warnings and errors), more data about the mailbox being moved (size, primary SMTP, DN, LegacyExchangeDN, identity) and start and end time both for individual moves and for the overall move action for multiple mailboxes. Administrators can also choose a specific directory and file name for this report by using the parameter -ReportFile. If -ReportFile is not defined, the log will be created in the default location and called move-MailboxHHMMSS.xml.
• Troubleshooting Log - This is a new log for Exchange Server 2007 that displays detailed information about the move which can help in diagnosing move failures. It contains all the information of the other logs with additional detail like Active Directory search operations, user matching details, delegation processing, etc. This log will be created as move-MailboxHHMMSS.log.

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.

Move-Mailbox -IgnoreRuleLimitErrors

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.

ExMerge Replacement

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:

Export-Mailbox

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.

Import-Mailbox

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.

Restore-Mailbox

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

Exchange Server 2007 introduces many new and really well defined recipient types. One of them is the one my customer asked me about. The process to create a Shared Mailbox will create a disable Active Directory user as there is no point to have it - that is not the purpose of this recipient. On the old and still actual days of Exchange Server 2003 or older, when we created a Shared Mailbox  we basically created an Active Directory account with an associated mailbox and those credentials would be shared within who needed to use it. What is the issue here? Security! Was never a good idea to more than one individual login with same credentials. Control on it would be inexistent.

So in Exchange Server 2007 what we have is a mailbox with a disabled user and in a way we can give access to users or distributions lists we just add the proper permissions to the mailbox and it is done.

First of all we need to create our Shared Mailbox and to do that we need to use the Exchange Management Shell!

[PS] C:\>New-Mailbox -Name "mailbox" -Database "database" -UserPrincipalName mailbox@domain.com -Shared

At this stage we have our mailbox created and our active directory user disabled...

However now we need to give the right permissions...

Let's start by giving instructions to the shared mailbox that a few users should have Full Access on it, otherwise won't work. Advice here is do this to a Security Group more than to individual users by the same reasons referred above. Let's do it then to the users on the Sales Team!

[PS] C:\>Add-MailboxPermission "mailbox" -User "user" -Access Rights FullAccess

Almost done but a couple more things to do. At this stage the users on the Sales Team can access totally the mailbox however they still can't send e-mails from the shared mailbox. To do that we need to give them some permissions in Active Directory side...

[PS] C:\>Add-ADPermission "mailbox" -User "user" -ExtendedRights Send-As

At this stage the Sales Users are GOD within the Sales Team Shared Mailbox.

With Exchange Server 2007 Service Pack 1 we can actually setup the Full Access and Send As permissions. Basically we just right click on the Shared Mailbox and add the recipients to the desired permission or just select the account, and on the right hand side of the console you will see the same options.

And that's it!

Posted by Pedro Alves

I’m guessing that over the next few months IT managers are going to be pushing their staff really hard to justify any spend.  ..and projects to upgrade to Exchange Server 2007 are not going to be immune. Clearly to have any chance of getting the go ahead for your deployment of Exchange Server 2007 you are going to need to be able to demonstrate significant advantages of its deployment and that’s going to centre around saving cash…  (incidentally it’s no surprise that 3 out of the top 5 ‘Top Ten Reasons to Upgrade to Exchange Server 2007’ are based on saving money.)

So I thought I’d put together a few blogs about areas where you can prove that deploying Exchange Server 2007 will lead to saving your boss’ money.

Part 1 (Fewer Servers supporting More Mailboxes)
“OK so it’s one thing being able to say that you can support more for less but it’s another proving it.  So how do you prove that you actually save money by requiring fewer servers to support the same or more mailboxes?”

Part 2 (Make your backups more cost effective…)
“One area it’s worth focusing on is backups.  ..but I wouldn’t tackle backups on their own – I would tackle them in conjunction with your overall plans for compliance and availability.”

Part 3 (Storage)
“Ah yes that old chestnut…  SAN versus DAS – switch to DAS and save a load of money.  It’s obvious right?  Well I’m not sure. This is still a hot topic but the bottom line is that Exchange 2007 now gives us a lot more options about which storage we choose to support our Exchange data.”

Part 4 (Big Mailboxes)
“OK so the idea of big mailboxes has become a viable option for a lot of organisations since Exchange Server 2007 was released and now that we are seeing real examples of deployments of mailboxes of multiple GBs there is more information around to make it more of a comfortable decision to deploy large mailboxes with Exchange Server.”

Part 5 (the Edge)
“OK so I work for Microsoft but hey it’s worth a try …consider the Edge Transport role server as a replacement to other services in the perimeter.”

Part 6 (A few last ideas…)
“...a few more ideas that are worth exploring...”

Doug Gowans

Let’s leave the “ why would you? ” to one side for the moment but is it actually possible or supported to defrag a continuous replication target database?  Well not surprisingly er ‘No’.  An offline defrag creates a new database with a new signature (“When defragmentation is complete, the original database is deleted or saved to a user-specified location, and the new version is renamed as the original.”) and therefore whilst it will be possible to defrag the database you’ll break replication. So if you know that you have a large amount of whitespace that it is possible to claw back (maybe you have just reorganised your mailboxes across a larger set of mailbox databases?) and you want to run an offline defrag then you need to defrag the active database and reseed a replica… In my experience there aren’t many reasons to perform an offline defrag and so the relative pain of this process should not be one that many administrators have to follow.  And of course if your LUNs and disk set up allows it might be preferable to create a new database, seed it and then move all the mailboxes from the original database to this new one. Try this article on Technet for the steps to see a CCR database; How to Seed a Cluster Continuous Replication Copy...(read more)

Not something I would normally blog about but will be interesting to any of our partners who operate in this space. Guide to Opportunity: Software-plus-Services https://partner.microsoft.com/UK/productssolutions/40099765 This 16-page guide explains how partners can exploit our Software-plus-Services strategy. Microsoft executives and partners explain how Software-plus-Services can create major revenue opportunities for partners; and cost savings for customers, especially in the current economic climate. Business Advisor Podcast series www.microsoft.com/uk/partner/businessadvisor The Business Advisor series is a set of podcasts featuring commentary from Microsoft executives, independent experts and partners discussing topical business issues. Available are podcasts dedicated to providing advice on: how to make cost savings; cost-effective marketing; sales; and business planning....(read more)