Exchange 2007: Renaming the default storage group / mailbox database or deleting and recreating.
This question has seem to come up a lot lately, and since I have an opinion on it I figured it’s time to blog it.
When you run Exchange setup for the first time we will always create a default storage group and default mailbox database (also depending on installation order you may get a second storage group with a public folder database). This default database serves several purposes:
- In order for the information store service to start there must be at least one storage group and one mailbox database defined.
- The system attendant mailbox defined for the server is automatically stored in the first mailbox database created during setup.
- Each storage group has a system mailbox.
Here is a sample dump of a system mailbox showing homeMDB stamped.
Expanding base 'CN=SystemMailbox{00608BD1-A3C2-4F33-8499-AA68EFE80928},CN=Microsoft Exchange System Objects,DC=exchange,DC=msft'...
Getting 1 entries:
Dn: CN=SystemMailbox{00608BD1-A3C2-4F33-8499-AA68EFE80928},CN=Microsoft Exchange System Objects,DC=exchange,DC=msft
cn: SystemMailbox{00608BD1-A3C2-4F33-8499-AA68EFE80928};
deliveryMechanism: 0;
displayName: SystemMailbox{00608BD1-A3C2-4F33-8499-AA68EFE80928};
distinguishedName: CN=SystemMailbox{00608BD1-A3C2-4F33-8499-AA68EFE80928},CN=Microsoft Exchange System Objects,DC=exchange,DC=msft;
dSCorePropagationData: 0x0 = ( );
homeMDB: CN=2008-MBX3-SG1-DB1,CN=2008-MBX3-SG1,CN=InformationStore,CN=2008-MBX3,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Exchange,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=exchange,DC=msft;
instanceType: 0x4 = ( WRITE );
legacyExchangeDN: /o=Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=SystemMailbox{00608BD1-A3C2-4F33-8499-AA68EFE80928};
mail: SystemMailbox{00608BD1-A3C2-4F33-8499-AA68EFE80928}@exchange.msft;
mailNickname: SystemMailbox{00608BD1-A3C2-4F33-8499-AA68EFE80928};
msExchHideFromAddressLists: TRUE;
msExchHomeServerName: /o=Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=2008-MBX3;
msExchMailboxGuid: 4ab4dda2-166e-42c1-9ab7-951919825c39;
msExchMailboxSecurityDescriptor: O:SYG:SYD:(A;CI;CCDCRC;;;SY);
name: SystemMailbox{00608BD1-A3C2-4F33-8499-AA68EFE80928};
objectCategory: CN=ms-Exch-System-Mailbox,CN=Schema,CN=Configuration,DC=exchange,DC=msft;
objectClass (2): top; msExchSystemMailbox;
objectGUID: 4ab4dda2-166e-42c1-9ab7-951919825c39;
proxyAddresses: SMTP:SystemMailbox{00608BD1-A3C2-4F33-8499-AA68EFE80928}@exchange.msft;
uSNChanged: 41160;
uSNCreated: 41159;
whenChanged: 9/16/2008 10:32:19 AM Eastern Daylight Time;
whenCreated: 9/16/2008 10:32:19 AM Eastern Daylight Time;
-----------
Here is a sample LDP dump of the system attendant mailbox showing homeMDB stamped.
Expanding base 'CN=Microsoft System Attendant,CN=2008-MBX1,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Exchange,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=exchange,DC=msft'...
Getting 1 entries:
Dn: CN=Microsoft System Attendant,CN=2008-MBX1,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Exchange,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=exchange,DC=msft
adminDisplayName: System Attendant;
cn: Microsoft System Attendant;
deletedItemFlags: 5;
deliveryMechanism: 0;
delivExtContTypes: <ldp: Binary blob 8 bytes>;
displayName: Microsoft System Attendant;
distinguishedName: CN=Microsoft System Attendant,CN=2008-MBX1,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Exchange,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=exchange,DC=msft;
dSCorePropagationData: 0x0 = ( );
garbageCollPeriod: 0;
homeMDB: CN=2008-MBX1-SG1-DB1,CN=2008-MBX1-SG1,CN=InformationStore,CN=2008-MBX1,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Exchange,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=exchange,DC=msft;
homeMTA: CN=Microsoft MTA,CN=2008-MBX1,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Exchange,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=exchange,DC=msft;
instanceType: 0x4 = ( WRITE );
legacyExchangeDN: /o=Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=2008-MBX1/cn=Microsoft System Attendant;
mail: 2008-MBX1-SA@exchange.msft;
mailNickname: 2008-MBX1-SA;
mDBOverHardQuotaLimit: 100000;
mDBUseDefaults: FALSE;
msExchMailboxSecurityDescriptor: O:LAG:LAD:(A;;CCRC;;;SY);
msExchPoliciesIncluded: {7E47E963-8F11-496A-A63E-34521AB66DFF},{26491CFC-9E50-4857-861B-0CB8DF22B5D7};
name: Microsoft System Attendant;
objectCategory: CN=ms-Exch-Exchange-Admin-Service,CN=Schema,CN=Configuration,DC=exchange,DC=msft;
objectClass (2): top; exchangeAdminService;
objectGUID: d6c9d7c9-c7e9-4990-812b-8a246a4e9d0f;
proxyAddresses: SMTP:2008-MBX1-SA@exchange.msft;
showInAdvancedViewOnly: TRUE;
uSNChanged: 33319;
uSNCreated: 33257;
whenChanged: 9/15/2008 6:16:16 PM Eastern Daylight Time;
whenCreated: 9/15/2008 6:10:15 PM Eastern Daylight Time;
-----------
In terms of my opinion, the second two bullet points are the most important.
When the default mailbox database and/or storage group are removed and recreated, the homeMDB associated with the system mailbox and system attendant mailbox are no longer valid. When a storage group and database are recreated, the system mailbox should be created and the system attendant mailbox rehomed to this store. The issue here is when these operations fail. When any of these operations fail, the following operations may also fail:
- Move mailbox may no longer function.
- OWA free busy publishing may no longer function.
- Event sinks may not function correctly if the system mailbox is absent.
In most cases the rehoming and recreation procedures work without issues, but why chance it?
In many cases this query arises from customers that desire to script installations of Exchange. In my opinion it’s just as easy to script the deletion and recreation of the default storage group and mailbox database as it is is to update the names to your standard naming convention, and move the paths.
In order to change the name of an existing storage group, use the set-storagegroup command.
set-storagegroup –identity <Server\First Storage Group> –name <NewName>
In order to change the name of an existing database, use the set-mailboxdatabase (or set-publicfolderdatabase).
set-mailboxdatabase –identity <Server\Mailbox Database> –name <NewName>
In order to move the paths, use the move commandlets.
move-storagegrouppath –identity <Server\NewName> –logFolderPath <path> –systemFolderPath <path> –configurationOnly:$TRUE
move-databasepath –identity <Server\NewName> –edbFilePath <path\file.edb> –configurationOnly:$True (This is where you’ll want to specify the default naming convention for your edb file).
In each of these commands you will notice that I use the –configurationOnly switch. Using this switch should be a safe operation since the database / storage group being modified should not contain any user mailboxes. By utilizing the configurationOnly switch, I can run the same series of commands regardless of the installation type for Exchange (standalone / single copy cluster / cluster continuous replication).
On a standalone server or single copy cluster installation, when I use the above command with –configurationOnly, I will be prompted to mount a blank database. If a yes is provided to the mount command, a new log stream will be created at the logFolderPath location, a new checkpoint file created at the systemPathLocation, and a new edb file created at the edbFilePath with the edb name specified in the command. No existing files will be moved or retained. If I choose not to run the command with –configurationOnly, the files will be automatically moved to their new paths for me and the existing files preserved.
(Note: If using a single copy cluster installation do not forget to update the database / storage group dependencies to include all lettered volumes and mountpoints where Exchange data resides for that database / storage group.)
On a clustered continuous replication installation, when I use the above command with –configurationOnly, I will be prompted to mount a blank database. If a yes is provided to the mount command, a new log stream will be created at the logFolderPath location, a new checkpoint file created at the systemPathLocation, and a new edb file created at the edbFilePath with the edb name specified in the command. No existin files will be moved or retained. If I choose not to run the command with –configurationOnly, an error will result indcating that moves on CCR members can only be performed with –configurationOnly.
In the case of CCR clusters that have no user data to retain, it is safe to use the –configurationOnly switch and mount the blank database. The replication service will be smart enough to detect the path change, start replicating log files to the passive node, and replay the logs and build the database at it’s new location. If there is user data to retain, the files should be manually moved to their new locations on both nodes prior to mounting the database.
(Note: If standby continuous replication is already enabled on any database, and existing data is preserved either by automatically moving files or manually moving files to their new paths, the same files will need to be manually moved on the SCR target machine. If mounting a blank database into a new log stream, the replication service on SCR is smart enough to detect the path change, being replicating log files, and rebuild the database in their new location.)
If following these steps you should have successfully renamed the default storage group and database to the naming convention of the organization. The log files, checkpoint files, and databases files should be moved to their desired location with the edb file name matching the organizations naming convention. The added bonus comes in the fact that we preserved the homeMDB thereby preventing the need to re-create the system mailbox or rehome the system attendant mailbox.
Good luck and happy renaming!
Comments
Anonymous
January 01, 2003
PingBack from http://exchangereadings.wordpress.com/2009/04/14/exchange-daily-article-apr-14-2009/Anonymous
May 25, 2010
It's very useful for me , I am deploying CCR in our customer's environment, this artical has helped me to prevent confusion operations such as delete the First Storage Group and Database.Anonymous
July 05, 2010
I have a CCR with two storage groups. Both databases are in a dirty shutdown state due to missing log files that were deleted manually (each database has a size of 120 GB). To recover from situation I have to run the eseutil tool. To do this I have to dismount databases and it will take too much time to be accomplished. And even after that, Microosft recommends that I do not use a repaired database for a long period. To avoid this, I am thinking about to create a new databases and move the mailboxes to them. Do you think this will solve the dirty shut down state?. ThanksAnonymous
July 05, 2010
@Yassine: If your CCR copy status was healthy at the time the log files were manually deleted is there any chance they are on the passive node. If CCR was not healthy this is not an option for you. Unfortuantely when log file are removed that are required to recover a database your have essentially two options:
- Restore from last backup and replay up to the current point in time remaining.
- Repair the database. If you have a set of log files remaining that are contiguous, and you do not care about the data in the missing log files, then restoration is your best bet. If you have no backup then this is not an option for you - off to repair. Repairing does take sometime to complete and has three process, the eseutil /p, eseutil /d, and then the isinteg. In some cases the isinteg has to be run more than once. These processes can be time consuming, but unfortuantely are your only options if you want to get these databases mounted. The process must be completely followed. Once it's followed you should have no issues continuing to utilize those databases in production. Mounting blank databases and than moving mailboxes is not an option for you, as it will not help with the dirty shutdown databases. Considering speaking with your Microsoft support about dialtone recovery.