We're trying to decide whether we'll name and populate our databases based on site (PDX, SEA, BOI, etc), user function (Staff, Attorney), or just a general database where we randomly drop users. It seems strange to name them, "Mailbox Database 1" and populate it with users from across the corporation (after we consolidate to centralized Exchange), but Microsoft and Dell said this common. So, i've been tasked with asking around to see how others are approaching this issue.

Hi, I normally name the databases after department or location depending on the company. I like to have a pretty good idea about where to find my user if I just look at the AD account and then the databases. It might not make a big difference in performance or message hygine, but it does make it easiere for myself to get around in. i.e a database for City A and database for City B etc. /MartinExchange is a passion not just a collaboration software.

I just use a simple naming convention of a few letters followed by a sequence of numbers, and I don't care which users go in which database except for groups that have different business needs (i.e. where we would need to do maintenance at different times or back things up differently.) The way the 2007 and 2010 consoles are set up, you don't really look at mailboxes on a per database level. You just look at recipients and searching is trivial. You can filter by database if you want but it's not like 2003. If you make a heavily organized structure based on users you might find that some databases end up getting really big while others stay small, complicating your storage planning. Plus you'll spend a lot of time moving mailboxes for no reason when people change jobs within the company. On top of that, a failure of the "Sales" database (for example) will take out the whole department whereas if everybody was mixed up, they could at least ask their neighbor across the hall to send a critical email for them. (If you have DAGs with multiple copies in your design, you might be able consider this a minor risk.) On the other hand, maybe your boss would rather only have to explain to *one* manager why *all* his employees had no email, rather than your boss having to explain to *all* the other managers why *a couple of each of their employees* couldn't work. Who cares about users, they're just mailboxes to us !

I just use a simple naming convention of a few letters followed by a sequence of numbers, and I don't care which users go in which database except for groups that have different business needs (i.e. where we would need to do maintenance at different times or back things up differently.) The way the 2007 and 2010 consoles are set up, you don't really look at mailboxes on a per database level. You just look at recipients and searching is trivial. You can filter by database if you want but it's not like 2003. If you make a heavily organized structure based on users you might find that some databases end up getting really big while others stay small, complicating your storage planning. Plus you'll spend a lot of time moving mailboxes for no reason when people change jobs within the company. Plus, a failure of the "Sales" database (for example) will take out the whole department whereas if everybody was mixed up, they could at least ask their neighbor across the hall to send a critical email for them. (If you have DAGs with multiple copies in your design, you might be able consider this a minor risk.) Other the other hand, maybe your boss would rather only have to explain to *one* manager why *all* his employees had no email, rather than your boss having to explain to *all* the other managers why *a couple of each of their employees* couldn't work. Who cares about users, they're just mailboxes to us !

Nomenclature is one aspect of your design, having a documented Nomenclature helps avoid complexity.and uniquely define a databse Exchange 2010 i would go by this 1 first there letters DOMAIN or YOUR ORG 2.next three location 3.unique part of server name 4. mailbox databse sequence number eg if i was to name databse 10 in a server names exch1v1 located in richardson datacenter and my company domain is AAA the databse name would be AAARDNv1MB10 if it was 2007 or 2003 i would name it like AAARDNv1-SG1-MB10 here first part tells me where the server is identification of server and what storage group mailbox is in i know some of us do not consider this important. however if you were to manage a large environment this is worth paying attention to as things become too complex otherwise Dhruv

I would second cn9 and recommend that you allocate based on the capabilities of the underlying LUN for each database rather than department, therefore ensuring the number of users or mailbox sizes are balanced. Otherwise you may have one very large DB with many users just because they are in department X and a smaller DB for department Y. If people change role then you would also need to move them between DBs, and a DB failure could take out an entire department. You may also need to allocate the underlying storage based on department/section sizes of the business. If you "randomly" allocate the people on the databases then you obviously cannot see the impact of a failed database of database failover quite so easily, but on the other hand you know it is unlikely to take out an entire section of your organization. To balance the number of mailboxes between databases, I've written a powershell script which you may want to consider. SteveSteve Goodman Check out my Blog for more Exchange info or find me on Twitter

Im with the posters who dont agree with splitting up by department or similar constructs. Important things for you are to keep sizes broadly similar and IOPS profiles at manageable levels. You have PowerShell scripts to rebalance based on loading parameters so splitting by department isnt going to last very long. There are obviously going to be exceptions but thats not the same as keeping everybody rigidly within alphabetically assigned stores, or departments or geos. "stormwriter" wrote in message news:08a196d5-8cf1-47c2-84f0-40c5231e1128... We're trying to decide whether we'll name and populate our databases based on site (PDX, SEA, BOI, etc), user function (Staff, Attorney), or just a general database where we randomly drop users. It seems strange to name them, "Mailbox Database 1" and populate it with users from across the corporation (after we consolidate to centralized Exchange), but Microsoft and Dell said this common. So, i've been tasked with asking around to see how others are approaching this issue. Mark Arnold, Exchange MVP.

One thing with 2010 though is that I wouldn't name the databases based on the server name. If you use DAGs or ever plan to in the future (because you can add it later without rebuilding your existing servers) you'll see that databases are not necessarily tied to a particular server. Maybe you want to put the "DAG name" in there instead though. Similarly, "location" can become cumbersome if you ever deploy site resilience.

So, no one sees any potential pitfalls from having a database populated with users in different local and remote locations, with different WAN speeds? We're hoping to get all remote site links to 100mb before the consolidation starts.

As you're centralising and they will all be on the same server(s) then no, it shouldn't make any difference.Steve Goodman Check out my Blog for more Exchange info or find me on Twitter