Thursday, September 20, 2012

How to recover user mailbox data from deleted mailboxes using Recovery Storage Group (RSG) in MS Exchange 2003 via

The Recovery Storage Group (RSG) is a feature of Exchange Server 2003. In certain situations it removes the requirement of building up an additional recovery server in order to recover mailbox data (to recover public folder data, the recovery server is still required). However, when we restore the backup into RSG, we are unable to use the ExMerge utility to extract data from the mailboxes that have been deleted from the original mailbox store.

Overview of the Recovery Storage Group
Prior to Exchange Server 2003, if you wanted to recover some mailbox data from the backup, you needed to set up a separate Active Directory (AD) forest on a recovery server and restore the backup into this recovery computer. With the RSG feature, this additional recovery server is not required to recover data from a mailbox store in scenarios where both the following conditions are true:

• The logical information in AD about the storage group and mailboxes remains intact and same as before the recovery. That's to say, the mailbox you want to recover must not be deleted or purged from the system, or moved to another mailbox store.
• You want to recover data from a single mailbox, a single database, or simultaneously a group of databases within a single storage group. The database added into RSG must be from a server within the same Administrative Group; furthermore, after we add a database into RSG, we can then only add databases from the same Storage Group.

After you create a RSG and add databases to it, you can either restore online backup sets or copy offline database files to the RSG (please note that enough disk space is necessary for the recovered database in RSG). Then you can use the Exchange Server 2003 version of the Microsoft Exchange Mailbox Merge Wizard (Exmerge.exe) utility or the Recover Mailbox Data Wizard to extract data from the recovered databases in the RSG to the mailbox in the original regular storage group.

How a Recovery Storage Group links back to the original regular storage group
The RSG uses the following two AD attributes to link back to the original regular storage group:

• The msExchMailboxGUID attribute (see Figure A). When a mailbox is created, this attribute is generated as a unique value that distinguishes it from all other mailboxes. The value remains the same for the lifetime of the mailbox. The ExMerge utility uses this attribute to match the mailbox in the RSG to the one in the original regular storage group. When you delete a mailbox, the mailbox attributes will be removed from the AD user account; when you purge a mailbox that has been deleted, the mailbox (and its GUID) is removed from the database. In these two scenarios, ExMerge will fail to extract data from this mailbox in the RSG.

Figure A: The msExchMailboxGUID attribute

• The msExchOrigMDB attribute (see Figure B). This attribute is set on a database in the RSG. It specifies the distinguished name of the original database where the RSG was created, and it will verify if the mailbox you want to recover is still located in the original mailbox store. If the mailbox has been moved to another mailbox store, ExMerge will fail to extract data from the mailbox.

Figure 2: The msExchOrigMDB attribute

So, what is the problem?
As described above, you will encounter problems when you try to use ExMerge to extract data from mailboxes in the RSG under the following situations:
• The mailbox has been moved to another mailbox store
• The mailbox has been deleted or purged from the system

You may encounter the following error message when you try to use ExMerge to retrieve a list of mailboxes from a RSG:
An error was encountered with one or more users when retrieving the list of mailboxes homed in the selected databases on server 'ServerName'. Please refer to the log file, 'ExMerge.log', for more information.
And from the ExMerge log, you may see the following error:
[14:13:08] Error! Cannot identify the user with the msExchMailboxGuid C\03\96f\5D\B1\3BD\81\99\1F\91C2\5B7. The legacyExchangeDN is /O=ORGNIZATION/OU=SITE/CN=RECIPIENTS/CN=USER.

Problem Resolution
Depending on the scenario, you can use different methods to recover the data:

Scenario 1: The mailbox has been moved to another database
In this scenario, we can use the following two methods to recover the data from the mailbox.
Resolution: Move the mailbox back to the original database or modify the msExchOrigMDB attribute
The most efficient method in this scenario is to move the mailbox back to the original database where the RSG was created. Then ExMerge should work fine to retrieve the mailbox list and to extract the data from RSG.
If you are unable to move the mailbox back for any reason, you can modify the msExchOrigMDB attribute on the RSG database and point it to the database that you moved the mailbox to.

To do this, please follow the steps below:
1. Start the ADSI Edit utility. This is included in the Windows 2000 and 2003
Support Tools: click Start -> Run, type adsiedit.msc and press Enter.
2. Locate the mailbox store that you moved the mailbox to. To do this, expand the
following the containers:
Configuration Container [YourServerName.YourDomainName.YourTopLevelDomain]
CN=Microsoft Exchange
CN=Administrative Groups
and then click CN=YourStorageGroup.
3. In the right pane, right-click the database object and click Properties.
4. Locate the distinguishedName attribute.
5. Right-click the value that is in the "Value(s)" box and click Copy.
6. Click Cancel.
7. Locate and click the RSG database object in the
CN=Configuration,DC=YourDomainName,DC=YourTopLevelDomain container.
8. In the right pane, right-click the RSG database object and click Properties.
9. Locate the msExchOrigMDB attribute.
10. Click Clear.
11. Right-click an empty area of the Edit Attributes box and click Paste.
12. Click Set and click OK.
13. Quit ADSI Edit.

For more information, refer to the following Microsoft TechNet article:
How to Change the msExchOrigMDB Attribute Using ADSI Edit

Scenario 2: The mailbox has been deleted from the database, but not yet purged
Resolution: Reconnect the deleted mailbox to the original or a new user account
When a mailbox is deleted but not yet purged, it becomes an orphaned mailbox in the Exchange server database and is available in the Deleted Mailbox Dumpster (before the retention time expires). Under this situation, you can reconnect the deleted mailbox to the original user account and then recover the data.
If you cannot reconnect the mailbox to the original user (for example, you have created another mailbox and associated it with the original user account), you can just create a new user account (with no mailbox enabled) and then reconnect the orphaned mailbox to this newly-created user. This will work because the msExchOrigMDB attribute does not change on the mailbox even if we associate it with a new user account.

Scenario 3: The mailbox has been purged (permanently deleted) from the database
Resolution: Create a new storage group, or modify the msExchMailboxGuid attribute on a user to point to the mailbox we want to recover data from

If you are running Exchange Server 2003 Enterprise Edition, you can create a new regular storage group and copy the recovered database from RSG to this new storage group. You can then directly extract the mailbox data from the new storage group. For more detailed information see the following Microsoft Knowledge Base article:
You receive an error message when you use the Exmerge tool

However, you cannot use this method on an Exchange Server 2003 Standard Edition because you are limited to one storage group in this edition. In this situation, you can directly modify the msExchMailboxGuid attribute on another mailbox to represent the one you want to recover (according to the principle of the msExchMailboxGuid attribute introduced above).

To do this, please follow the steps below:
1. The GUID shown in ExMerge log is in a different format than the actual
msExchMailboxGuid attribute. So first of all, you need to convert this GUID in
the ExMerge log into a format that contains 16 units with each unit having 2
hexadecimal numerals. Let's take C\03\96f\5D\B1\3BD\81\99\1F\91C2\5B7 as an

i. For units like C\ and 03\, only 1 or 2 characters, leave it as is.
ii. For units like 96f\, 3 characters, split into 2 units: 96 and f.
iii.For units like 91C2\, 4 characters, split into 3 units: 91, C and 2.
iv. Following the rule described above, convert the original GUID into:
C 03 96 f 5D B1 3B D 81 99 1F 91 C 2 5B 7.
v. Then, for each single character, replace it with its ASCII code. So the GUID
is: 43 03 96 66 5D B1 3B 44 81 99 1F 91 43 32 5B 37. (You can visit to check the ASCII code.)

2. Start the AD Users and Computers snap-in, and create a new user with the same name and same organizational unit (OU) as referred to in the ExMerge log.
3. Start the ADSI Edit snap-in: click Start menu -> Run, type adsiedit.msc and
press Enter
4. Expand the Domain container, and expand the OU container which stores the new user (for example, CN=Users).
5. Highlight the newly-created user account in step 2 and open its Properties.
6. Locate the msExchMailboxGuid attribute.
7. Click Clear.
8. Copy the converted GUID: 43 03 96 66 5D B1 3B 44 81 99 1F 91 43 32 5B 37.
9. Right-click an empty area of the Edit Attributes box and click Paste to override with "43 03 96 66 5D B1 3B 44 81 99 1F 91 43 32 5B 37" (without quotation marks).
10. Click Set and click OK.
11. Quit ADSI Edit.
12. Run ExMerge again and connect to the RSG. This time we should see the mailbox
we want to recover. Follow the ExMerge wizard to extract the data.

In Exchange Server 2003, there is a feature called Recovery Storage Group (RSG) which helps you to easily recover data (including messages, mailboxes or an entire database) without building up an extra recovery computer. However, due to the working mechanism of RSG, you cannot directly recover a deleted or purged mailbox. The above is some ways to workaround this limitation

Monday, September 10, 2012

Suggested WMI Hotfixes

Microsoft has released a fast publish article to address the numerous WMI issues that has been reported.
WMI issues will have high level symptoms as below and for me, the concerns are towards SCOM and SCCM

  • Loss of functionality with enterprise management/monitoring software for various machines. Software examples: Microsoft SCOM/SMS etc
  • Loss of functionality related to Citrix terminal services load-balancing.
  • Loss of functionality for WMI-based scripts.
  • Slow user logon times on Citrix terminal servers.
  • Slow user logon times on Windows clients where WMI-based group policy filters are in-place

The article is as below

Monday, September 3, 2012

Who Deleted That Active Directory Object?

Have you ever encountered that an AD object be it an user, computer etc is deleted and no one owns up?
In this situation, the usual questions will be when did it happened, where did it happened (Which DC?), who is the culprit.
You can say that you will be able to trace the culprit by pouring over the security logs if you had enabled auditing but picture this, what if you have over 80 domain controllers and you have no idea when did the deletion take place.
The following procedure will help you provide you the means to get the answers

To get the Distinguished Name of the Delete Object

1)  First open up LDP and connect to a server.
2) Next, bind to the DC you are connected to, click connections and then bind again.
(If all the fields are blank, it will bind with the user credentials that you are currently logged on as)
3) Click on Browse and then Search. Make sure that the control to return deleted objects is properly configured so that the deleted objects will be returned
4) Now we will need to search for the deleted objects. If you go to View and then Tree and leave it blank, it will go to the default naming context which by default is the domain naming context. Once this shows up in the left hand side, expand it then go to the deleted objects container , alt click and then choose search. With this, you will just search for that container and we can look for an attribute that we are looking for.
5) Once the object is located, copy the DN and it will be used in the next step

Who, When , Where?
To gather the information to which when and where, repadmin can be used as below

Repadmin /showobjmeta “DN which was copied in step 5 earlier”

You will get the information as below but what we are actually looking for here is in fact the isdeleted attribute.
This will tell you when the object was deleted and from which domain controller

For the who, you may go to the Domain Controller identified earlier to run through the security logs.
The event ID to look for will be Event ID 630