Great querstion from this week’s 10233 design of Exchange 2010 class. Our student asks
“in the past a mailbox move didn’t also move dumpster data. You had to recover it prior to the move. Has this changed in 2010?”
After some digging I was able to confirm that it IS now gathered along with everything else. Confirmed HERE found on the MSexchange.org site. Great article Neil!
The move request puts a special system message into the system mailbox on the mailbox database. The Microsoft Exchange Mailbox Replication service checks the contents of the system mailbox on each mailbox database to see if any move requests are waiting and then processes them accordingly. There are many benefits to having the mailbox moves carried out by this service. Here are three main areas that I typically encounter on migration projects that are addressed with move requests:
- Mailboxes can now be moved online whilst the users are logged into them. Admittedly this is only available if the source mailbox is running Exchange 2007 SP2 or later, or Exchange 2010. However, this is a welcome addition to the overall mailbox moving process as it will help negate the need to move mailboxes out of core business hours.
- Items in the dumpster are now moved as part of the process. In previous versions of Exchange, moving a mailbox did not move the items in the dumpster and it was therefore required that the user had to recover any deleted items prior to the mailbox move. It was all too easy to forget to inform the users of this fact and in some cases users who had been moved then proceeded to recover items from their dumpster only to find it completely empty.
- The mailbox contents are no longer processed by the computer running the move process. It was often the case in Exchange 2007 that the Move-Mailbox cmdlet, or associated script, was run on an administrative machine rather than directly on the target Exchange 2007 server. However, in this scenario, the mailbox contents are moved from the source database to the administrative machine and then into the target database. This scenario was mitigated by running the cmdlet or script directly on the target database server. In Exchange 2010 this situation will not be encountered since the mailbox moves are performed by the Microsoft Exchange Mailbox Replication service running on the Client Access Server.
Another great question from mario this week.
I have shared rooms for meeting spaces in 2003, how can I convert them to room mailboxes in 2010?
You can convert the following:
- User mailbox to shared mailbox
- User mailbox to resource mailbox
- Shared mailbox to user mailbox
- Shared mailbox to resource mailbox
- Resource mailbox to user mailbox
- Resource mailbox to shared mailbox
You can’t use this procedure to convert a user mailbox to a linked mailbox or a linked mailbox to a user mailbox. For instructions about how to convert to a linked mailbox, see Convert a Mailbox to a Linked Mailbox.
A scenario in which you may want to convert a mailbox is if you have moved resource mailboxes from Exchange Server 2003 to Exchange Server 2010. In Exchange 2003, you use shared mailboxes to represent resources. When you move these mailboxes to Exchange 2010, they will be Exchange 2010 shared mailboxes. You must convert them from Exchange 2010 shared mailboxes to Exchange 2010 resource mailboxes so that they will have all the properties of Exchange 2010 resource mailboxes.
Regrettably this can only be done via the Exchange Management Shell using the following syntax..
Set-Mailbox ConfRoom1 -Type Room
You can use the following values for the Type parameter:
For detailed syntax and parameter information, see Set-Mailbox
This information was located in the TechNet Exchange library – Convert a Mailbox
Mario from this week’s 10135 exchange 2010 class asked..
“I used to use the Exchange clean up agent in 2003 all the time, is there something equivalent in 2010?”
We sure do! There is a Cmdlet we can run to force a similar process. We can use the Clean-MailboxDatabase to do this same type of process. Let’s consult TechNet on what it actually does..
Taken from http://technet.microsoft.com/en-us/library/bb124076.aspx
Use the Clean-MailboxDatabase cmdlet to scan Active Directory for disconnected mailboxes that aren’t yet marked as disconnected in the Microsoft Exchange store and update the status of those mailboxes in the Exchange store. This cmdlet isn’t able to update the Exchange store unless the Microsoft Exchange Information Store service is running and the database is mounted.
A connected mailbox has two parts: the mailbox object in the Exchange store and the user object with Exchange properties in Active Directory. A disconnected mailbox is the mailbox object in the Exchange store, but it isn’t connected to a user object in Active Directory. To disconnect a mailbox, use the Disable-Mailbox cmdlet. To disconnect a mailbox and remove the user object from Active Directory, use the Remove-Mailbox cmdlet. If you want to permanently remove a mailbox object from the Exchange store, use the Remove-Mailbox cmdlet.
If you want to reconnect a disconnected mailbox to an Active Directory user account, use the Connect-Mailbox cmdlet.
Under normal circumstances, it isn’t necessary to run the Clean-MailboxDatabase cmdlet because a mailbox is marked as disconnected immediately after the Disable-Mailbox or Remove-Mailbox command completes. If you used the Disable-Mailbox cmdlet or the Remove-Mailbox cmdlet while the Microsoft Exchange Information Store service was stopped, or if a mailbox was disabled by an external means other than the Disable-Mailbox cmdlet or Remove-Mailbox cmdlet, you may want to use the Clean-MailboxDatabase cmdlet to scan for disconnected mailboxes.