Have you ever wondered why Exchange 2010’s default databases are always named something along the lines of “Mailbox Database 1419556758”? What’s the secret is behind that seemingly very significant number? Have you tried to convert it to something magical, much the way FYDIBOHF23SPDLT translates to EXCHANGE12ROCKS?
Well, I hate to disappoint, but there’s no secret cabal of Exchange engineers encoding secret messages in your database naming. No prize for decrypting the numbers. It’s just a string that should be unique in your Exchange organization. And that string sucks. No, really, it’s just fine when you are using the Exchange Management Console, and if you rarely have to drop to the command prompt it is usable in the Exchange Management Shell, but if you have to do CLI work frequently, you will soon learn to hate that bloody name, both for the spaces (quote enclose!) and for the string of numbers you can never type right the first time. Or is that just me?
The truth is, you can rename those databases, and more to the point, you should rename those databases, as soon as you build an Exchange server. As you create more databases on your existing Exchange servers, naming will be very important, so here are some best practices for naming Exchange databases.
- Establish a database naming standard
Whatever your naming, make sure it follows a standard, and that this standard is used organization-wide. You don’t want different groups (or different admins) doing their own thing, otherwise it isn’t really a standard.
- Include something that indicates the server hosting the database in the name
Yes, when you view the databases in the EMC you can see what server hosts them. But when you do a get-mailboxdatabase you don’t unless you view more details, such as when you use | fl. Having something to indicate which server you are dealing with will make quick EMC tasks that much easier.
- Use only letters and numbers
Stick to using only alphanumeric characters. This keeps things easy, and minimizes the likelihood you will run into any issues down the road. You might use a hyphen (see tip 5 below) to help designate special databases, but other than that, stick to the 36 characters we all know and love.
- Avoid special characters like spaces, parentheses, colons, etc.
Even though Exchange will let you use them, admins have encountered problems in the past when special (non-alphanumeric) characters were in a database name. As recently as Exchange 2010 SP2, there was a bug that caused the AppPool to crash when a user tried to access their mailbox on a database that contained parens or a colon. KiSS is the rule of the day here. And remember, CLI and scripting both hate spaces, so unless you just really love to quote enclose everything, concatenate it all together.
- Reserve certain character combinations to indicate significant features of the database.
Recovery databases, DAG members, archive databases, and “special purpose” databases should all have something to indicate what they are. Again, a standard is critical here. I like to add –rec, -dag, -arc, -fast, etc. to any special databases. It’s easy to remember and makes it clear what is what.
Following these best practices will not only make your command line management and scripting easier, it will make it much less of a chore to figure out which database is on which server, or to remember whether that is a recovery database, an archive database, etc. The larger your Exchange org grows and the more servers you deploy, the more you will appreciate these tips. I hope you find them as useful as I do!