Windowmaker's blog

Funny how things turn out. I was visiting today a customer which is undergoing a process of upgrading his Domain Controllers to W2K3 R2 and I was asked to help them get a report of OS version on all the DCs in the forest (multi-domain forest). First I thought to query the AD directly, but it appears that there is no way to distinguish between W2K3 and W2K3 R2 when looking at operatingSystem, operatingSystemVersion and operatingSystemServicePack attributes of the DC's computer account.

Now what is so funny about it ? Well, just yesterday I helped out a guy at the forum I manage to fix a script that was running against a list of servers and was querying the OS and SP version (see the original post here - it's in Hebrew). The script the guy wrote was almost perfect for my case, but I still had to scope it to run only against the DCs. What I came up is a generic batch that you can use to run a set of commands against all the DCs in the forest (including trees and child domains ).

So how do we achieve that ? Here is the logic I used in the script:

1. I use "dsquery server forestroot" command to obtain a list of all the server objects in the forest (this gives us a list of distinguished names of the server objects in the Configuration partition)
2. For each DN in the list, I query the "serverreference" attribute, which is pointing the the distinguished name of the actual DC's computer account ("dsquery * <DN> -attr serverreference". The DN returned will be used in the next step.
3. I use DN from step 2 to query the dnsHostName attribute of the DC.
4. I run a set of commands against each DC using it's DNS name obtained in step 3

The script break-down:

Most-outer loop (step 1):

for /f "usebackq" %%n in (`dsquery server forestroot`) do ( <second loop here> )

Second loop (inside the above loop):

for /f "usebackq delims=" %%s in (`dsquery * %%n -attr serverreference ^| findstr /i DC=`) do ( <third loop here> )

Third loop (again inside the above loop):

for /f "usebackq skip=1 delims=" %%d in (`dsquery * forestroot -filter "distinguishedname=%%s" -attr dNSHostName`) do (     
	for /f "usebackq skip=1" %%a in (`dsquery * forestroot -filter "distinguishedname=%%s" -attr name`) do ( 
    
 		set netbiosname=%%a 
		set tempname=%%d 
 		set dnsname=!tempname:~2,-2! 

 		echo !netbiosname! : !dnsname!     
 	) 
) 

Imagine the following scenario:

1. You perform a full backup of mailbox store on Exchange 2003.
2. You move a mailboxe from the backed-up store to an Exchange 2007 server.
3. You try to leverage the Recovery Storage Group feature on the Exchange 2003 server to restore the contents of the mailbox in question using ExMerge to restore/export the contents of the mailbox from a date before the mailbox was moved.
4. The ExMerge export phase fails with the following error in the exmerge.log:

   Error opening message store (MSEMS). Verify that the Microsoft Exchange Information Store service is running and that you have the correct permissions to log on. (0x8004011d)

Usually you would get this error if the account you run Exmerge with does not have full permissions on the mailbox you are trying to restore, but this case is a bit different. Even if you grant yourself Full Mailbox Access and get rid of the "Send As" and "Receive As" denies (see KB322312 for details), the process still fails with the error message above.

The issue stems from the fact that the mailbox in question has been moved to a different mailbox store from the one it was backed-up from. In order to better understand the problem, lets look at how Recovery Storage Group links a mailbox from RSG to an existing account in AD and what are some of the checks that are performed when you try to export the contents of a mailbox from a database mounted in the RSG:

• msExchMailboxGUID attribute: this is the first test that is being performed. The GUID of the mailbox in the RSG (taken from the database itself in the RSG) must correspond to an existing account in the AD. If Exmerge can not find the GUID of the mailbox you are trying to restore in the AD, it will fail.
  
• msExchOrigMDB attribute: When a database is added to RSG, its msExchOrigMDB attribute is populated with a distinguished name that points to the original database that was backed-up. When Exmerge runs, it checks whether the mailbox we are trying to restore/export exists in the the database the msExchOrigMDB points to. If the mailbox store does not exist or the mailbox has been moved to a different store, the test fails and the following message is logged in the exmerge.log file:
  
  "Error opening message store (MSEMS). Verify that the Microsoft Exchange Information Store service is running and that you have the correct permissions to log on. (0x8004011d)".

Workaround:

1. Obtain the distinguished name of the store where the mailbox currently resides.
   
   There are numerous ways of locating the DN of the database. Here are 2 examples:
   
   Using command line (I find it quickest): query the homeMDB attribute of the user's account whose mailbox we are restoring using dsquery:
   

   C:\>dsquery * -filter "samaccountname=guyt" -attr homemdb 

   Query result:

   homemdb 
           
   CN=Mailbox Store (E2K7MBX01),CN=First Storage Group,CN=InformationStore, CN=E2K7MBX01, CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Administrative Groups, CN=ExchOrgName,CN=Microsoft Exchange,CN=Services, CN=Configuration,DC=company,DC=corp

   
   Using adsiedit.msc: Navigate to the user account whose mailbox you are restoring and copy the value of the homeMDB attribute of the user account:
   
   a. Drill down in the Domain partition to locate the account in question:
   
   
   
   b. Right-click the user account and select "Properties". Locate "homeMDB" attribute and click "Edit":
   
   
   
   c. Copy the value of the homeMDB attribute which would look something like:

   CN=Mailbox Store (E2K7MBX01),CN=First Storage Group,CN=InformationStore, CN=E2K7MBX01,CN=Servers, CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups, CN=<Exch Org Name>, CN=Microsoft Exchange,CN=Services,CN=Configuration, DC=company,DC=corp

2. Edit the msExchOrigMDB attribute of the object representing the restored database in the Recovery Storage Group
   
   a. Open adsiedit.msc and locate the object representing the database you have recovered to the RSG. It will be somewhere under:

   CN=Mailbox Store (E2K3SRV01),CN=Recovery Storage Group,CN=InformationStore,CN=E2K3SRV01,CN=Servers,CN=first administrative group,CN=Administrative Groups,CN=<Exch Org Name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=corp

   
   
   b. Right-click the mailbox store object and select "Properties". Locate the msExchOrigMDB attribute and click "Edit"
   
   
   
   c. Replace the current value with the distinguished name you obtained in Step 1
   
   d. Click OK and wait a bit till the change replicates to other DCs in your environment.
   
   e. Restart the "Microsoft Exchange Information Store" service on the Exchange server hosting the Recovery Storage Group.
   
3. Mount the database in the Recovery Storage Group
   
4. Run Exmerge. This time you should be able to export the contents of the moved mailbox.

Warning:

After you follow the instructions above you, you will not be able to use Exmerge to access any mailboxes that you did not move to a different mailbox store. If you want to access the mailboxes that remain in the original mailbox store, you must change the msExchOrigMDB attribute back to its original value.

• Troubleshooting ExMerge Issues
• How to use Recovery Storage Groups in Exchange Server 2003
• When the Mailbox Merge Program Tries to Open the Message Store, the Operation Is Unsuccessful