What is Exchange 2010 automatic mailbox distribution?

[The_Exchange_Team]

Have you ever wondered why, in Exchange 2010, you can create a new mailbox and you don't have to tell Exchange in what mailbox database it should be created? Or had an administrator in one department create a mailbox, and the mailbox is created in a database that their department isn't assigned? If you've answered 'yes' to either of those questions, you'll want to check out a new article that was just posted today.

Where Did That New Exchange 2010 Mailbox Go? introduces you to automatic mailbox distribution, which is a new feature added to Exchange 2010. The article talks about how automatic mailbox distribution works, steps you through the selection process, and shows you how you can control it using exclusions, Active Directory sites, and (in Exchange 2010 SP1) database scopes.

Take a look at the article and let us know what you think of this new feature.

David Strome

[#2]

Don't understand the benefit of this feature since its choosing the DB randomly.
Already have a PS script that chooses the BEST DB taking into account Number of user, Space on disk....

Improve it, make it more intelligent and I think this will be a very nice feature.
Right now imho is not.

[#3]

I'd actually like this to be revamped a bit to be more like Dynamic Distribution Lists... let me set parameters on the database that will automatically instruct the new mailbox wizard to assign the mailbox to a corresponding database. For example, let me set it so that anytime a user has a specific department it goes to the database for that department.

[#4]

Doesn't this fight against the previous Large Mailbox articles? The idea of creating a database/organization relationship was because of Single Instance Storage. Now that SIS is gone I think it's actually bad to put everyone on the same team on the same database. You want to spread your users out. That way if a database does go down, at least everyone else on the team still gets their mail. Plus people change teams, or certain teams might jump in email usage, causing the database to bloat unproportionatly.
Now I can see goodness if the New-Mailbox cmdelt had a -DatabaseAvailabilityGroup parameter, so the admin could point the new mailbox to a target Dag and Exchange can workout which database in the Dag to use. But that should be the extent of the scoping.

[#5]

This is very nice.  Like others have said it would be good if it could take database size into account.  I know there are existing scripts but still.

As for scoping it, I agree that you don't always want to put everyone who works together on the same database or servers (although if you do your DAGs right and have some mature operations procedures this shouldn't matter much.) But the scoping here is based on the abilities of the IT admin.  In large orgs with decentralized IT, you as the master messaging admin may want to give certain departments their own databases or servers so that manage it without affecting the rest, and of course so they can be responsible for their own storage and server costs. Depends on the org.  

[#6]

Thanks!  This was on my list of things to figure out.  I didn't see any preivious documentation to the effect.

[#7]

Just finished reading.  I agree with edvin's comments.  This has the potential to be really cool if it were smarter.  I can spin the wheel and pick a random database myself if that's all it's doing.

I do have one question.  Whats the difference between IsExcludedFromProvisioning   and IsSuspendedFromProvisioning?  Aren't they really the same thing?  Is it that one can be undone and the other cannot?

[#8]

New-ManagementScope -Name MyScope -RecipientRestrictionFilter {(RecipientType -eq 'UserMailbox' -and Database -eq '**DEPT MAILBOX DATABASE DISTINGUISHED NAME**') -or (RecipientType -eq 'MailUser') -or (RecipientType -eq 'MailContact') }

ShahinBasheer.AT.hotmail.com

[#9]

Agree on comments, nice but needs more customization.  Through planning tools, you're able to determine how many mbx's each database "should" support.  Simply allowing us to specify max mbx's per db would help.  We also have this fully scripted, along w/other criteria.  Would be great if we could eliminate these and use Exchange or ILM to provision mbx's.

[#10]

agree that you don't always want to put everyone who works together on the same database or servers (although if you do your DAGs right and have some mature operations procedures this shouldn't matter much.) But the scoping here is based on the abilities of the IT admin.  In large orgs with decentralized IT, you as the master messaging admin may want to give certain departments their own databases or servers so that manage it without affecting the rest, and of course so they can be responsible for their own storage and server costs. Depends on the org.