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 <ServerFirst Storage Group> –name <NewName>
In order to change the name of an existing database, use the set-mailboxdatabase (or set-publicfolderdatabase).
set-mailboxdatabase –identity <ServerMailbox Database> –name <NewName>
In order to move the paths, use the move commandlets.
move-storagegrouppath –identity <ServerNewName> –logFolderPath <path> –systemFolderPath <path> –configurationOnly:$TRUE
move-databasepath –identity <ServerNewName> –edbFilePath <pathfile.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!
