Bulk Create Exchange 2010 Databases

By:Rik Hoffelder

---

Here's a handy script I wrote to bulk create mailbox databases to follow a strict naming convention and consistent configuration. It was designed to work with Exchange 2010, however it works just as well with 2007. The intent is to help organizations maintain consistency using a simple process that can be performed by less skilled administrators.


Script itself uses several command line parameters to create the variables needed for the scripts. The following provides the script usage:


.\createdbs.ps1 2010Server NumberOfDatabases DatabaseStartNumber DatabaseDrive LogDrive WarningQuota SendQuota SendReceiveQuota DeletedItemRetention MailboxRetention Oab PfDb

The following is an example of proper usage:

.\CreateDbs.PS1 EX2010 4 1 E D 450MB 500MB Unlimited 30 14 "\Default Offline Address List" "Public Folder Database 1"

In the above example 4 databases are created on server EX2010 with the following names:

EX2010-DB01-0500
EX2010-DB02-0500
EX2010-DB03-0500
EX2010-DB04-0500

The database are created on drive E, with the log files on drive D. The mailbox store is set to issue size limit warnings at 450MB, prohibit send at 500MB, and prohibit send/receive is set to unlimited. Next deleted items are retained for 30 days, while deleted mailboxes are retained for 14. Finally the Offline Address book is set along with the public folder database used by each mailbox store.

So let's suppose we need to create 3 more databases, but this time on drive G, with the logs on drive H. Let's also set the mailbox size limit to 1GB. You would run the following:

.\CreateDbs.PS1 EX2010 3 5 G H 900MB 1GB 2GB 10 7 "\North America OAB" "Public Folder Database 2"

This would have created databases EX2010-DB05-1000, EX2010-DB06-1000, and EX2010-DB07-1000 with 10 day deleted item retention, 7 day delete mailbox retention, a warning limit of 900MB, prohibit send at 1GB and prohibit send/receive at 2 GB. The OAB would be set to North America OAB and use Public Folder Database 2.

Notice how the DBxx value began with DB05 and the last four digits are now 1000.
The DbStartNum parameter determine the beginning of the numbering scheme in the DBxx portion. The -XXXX at the end uses the ProhibitSend value to represent the mailbox send size limit, making it easy for administrators to identify where to place mailboxes by the database name. A size limit of 125MB would produce a name SERVER-DBXX-0125 and so forth.

It's simple and flexible. To run it simply copy it to a PS1 file then lanuch it from Exchange Management Shell.

CreateDatabases.PS1

### BEGIN SCRIPT ###
Param(
[string] $2010Server = "",
[decimal] $NumDatabases = "",
[decimal] $DbStartNum = "",
[string] $DbDrive = "",
[string] $LogDrive = "",
[string] $WarnQuota = "",
[string] $SendQuota = "",
[string] $SendReceiveQuota = "",
[string] $DeletedItemRetention = "",
[string] $MailboxRetention = "",
[string] $OAB = "",
[string] $PfDb = ""
)

# This function validates the scripts parameters
function ValidateParams
{
$validInputs = $true
$errorString = ""
if ($2010Server -eq "")
{
$validInputs = $false
$errorString += "`nMissing parameter: The 2010Server parameter is required. Please enter the name of the Exchange 2010 server to configure. Example KCCEX2010"
}
if ($NumDatabases -eq "")
{
$validInputs = $false
$errorString += "`nMissing parameter: The NumDatabases parameter is required. Please enter the number of mailbox databases that will be created on this Exchange 2010 server. Example 8."
}
if ($DbStartNum -eq "")
{
$validInputs = $false
$errorString += "`nMissing parameter: The DbStartNum parameter is required. Please enter the starting database number. Example 5."
}
if ($DbDrive -eq "")
{
$validInputs = $false
$errorString += "`nMissing parameter: The DbDrive parameter is required. Please enter the drive letter on which you will create mailbox databases. Example: E"
}
if ($LogDrive -eq "")
{
$validInputs = $false
$errorString += "`nMissing parameter: The LogDrive parameter is required. Please enter the drive letter on which you will create transaction logs. Example: D"
}
if ($WarnQuota -eq "")
{
$validInputs = $false
$errorString += "`nMissing parameter: The WarnQuota parameter is required. Please enter the vaule to issue mailbox size limit warning. Example: 450MB or 1.5GB"
}
if ($SendQuota -eq "")
{
$validInputs = $false
$errorString += "`nMissing parameter: The SendQuota parameter is required. Please enter the vaule to issue mailbox size limit exceeded. Example: 500MB or 1GB"
}
if ($SendReceiveQuota -eq "")
{
$validInputs = $false
$errorString += "`nMissing parameter: The SendReceiveQuota parameter is required. Please enter the vaule at which the mailbox stops accepting mail. Example: Unlimited or 550MB"
}

if ($DeletedItemRetention -eq "")
{
$validInputs = $false
$errorString += "`nMissing parameter: The DeletedItemRetention parameter is required. Please enter the vaule in days. Example: 14"
}
if ($MailboxRetention -eq "")
{
$validInputs = $false
$errorString += "`nMissing parameter: The MailboxRetention parameter is required. Please enter the vaule in days. Example: 30"
}
if ($OAB -eq "")
{
$validInputs = $false
$errorString += "`nMissing parameter: The OAB parameter is required. Please enter the name of the offline address list to be used by this mailbox database in quotes. Example: 'Corporate OAB' "
}
if ($PfDb -eq "")
{
$validInputs = $false
$errorString += "`nMissing parameter: The PfDb parameter is required. Please enter the name of the public folder database in quotes. Example: 'Pub Folders DB 1'"
}

if (!$validInputs)
{
Write-error "$errorString"
}
return $validInputs
}


### Validate the parameters ###
$ifValidParams = ValidateParams;

if (!$ifValidParams) { exit; }

### Define Script variables ###
$2010Server = $2010Server.ToUpper()
$b = $NumDatabases + $DbStartNum
$DeletedItemRetention = $DeletedItemRetention + ".00:00:00"
$MailboxRetention = $MailboxRetention + ".00:00:00"

$SendQuotaLen = $SendQuota.Length
$DBSize = $SendQuotaLen - 2
[decimal] $DBSizeNum = $SendQuota.substring(0,$DBSize)

If ($DbSizeNum -le 9) {$DbExName = [string] $DbSizeNum + "000"}
ElseIf ($DbSizeNum -ge 10 -and $DbSizeNum -le 99) {$DbExName = "00" + $DbSizeNum}
ElseIf ($DbSizeNum -ge 100) {$DbExName = "0" + $DbSizeNum}

If ($DbStartNum -gt 9) {$MdbName = $2010Server + "-DB" + $DbStartNum + "-" + $DbExName}
Else {$MdbName = $2010Server + "-DB0" + $DbStartNum + "-" + $DbExName}
$EdbFilePath = $DbDrive + ":\Exchange\Databases\" + $MdbName + "\" + $MdbName + ".EDB"
$LogFolderPath = $LogDrive + ":\Exchange\Logs\" + $MdbName
$MdbID = $2010Server + "\" + $MdbName

### Create Mailbox Databases Loop ###
Do {New-MailboxDatabase -Name $MdbName -Server $2010Server -EdbFilePath $EdbFilePath -LogFolderPath $LogFolderPath -OfflineAddressBook $OAB -PublicFolderDatabase $PfDb
;Mount-Database $MdbName
;Set-MailboxDatabase –Identity $MdbName –IssueWarningQuota $WarnQuota –ProhibitSendQuota $Sendquota –ProhibitSendReceiveQuota $SendReceiveQuota -DeletedItemRetention $DeletedItemRetention -MailboxRetention $MailboxRetention -RetainDeletedItemsUntilBackup $True
;$DbStartNum++
;If ($DbStartNum -gt 9) {$MdbName = $2010Server + "-DB" + $DbStartNum + "-" + $DbExName}
Else {$MdbName = $2010Server + "-DB0" + $DbStartNum + "-" + $DbExName}
;$EdbFilePath = $DbDrive + ":\Exchange\Databases\" + $MdbName + "\" + $MdbName + ".EDB"
;$LogFolderPath = $LogDrive + ":\Exchange\Logs\" + $MdbName
;$MdbID = $2010Server + "\" + $MdbName
}
Until ($DbStartNum -eq $b)
### END SCRIPT ###

More information on Exchange

Read more!

Replicate Public folders Between Exchange 2003 and 2010 Organizations Using the Interorg Replication Tool

By:Rik Hoffelder

---

I wrote in my article, Cross-Forest Migration with Exchange 2010 is a Piece of Cake! that it is possible to synchronize public folder and free/busy data between Exchange 2003 and Exchange 2010 Forests using the free Interorg Replication Tool. Since that time I have received a few questions on how I set that up and got it working. So by popular demand, here are the steps I used along with screenshots to help get you going.


First, a little background on the environment
In my lab, as was the case as the production enviroment, I had Exchange 2003 running in a single domain Windows 2003 forest, set at Windows 2003 Functional Level. Exchange 2010 is running in a single domain forest with Windows 2008 domain controllers, functional levels also set to 2003. A Cross-Forest Trust was established, SIDHistory filter security relaxed with the intent of migrating all domain resources to the new forest, including Exchange 2010. The Active Directory Migration Tool (ADMT 3.2) was used to migrate user accounts, groups etc as noted in Cross-Forest Migration with Exchange 2010 is a Piece of Cake! and mailbox GUIDs updated to prepare for the mailbox migration.

Setting Up Interorg Replication
To preform the steps outlined below I was running version 6.5.7408 of the Interorg Replication Tool from the Exchange 2003 Toolkit, Exchange 2003 SP2, and Exchange 2010 with Rollup 1, though it should work with Rollups 2 or 3.

1. Create a user account and mailbox to be used for the process in the Exchange 2003 organization. This account must be granted Owner rights on every public folder that you plan to replicate. For my purposes I used the EX2003\Administrator account, though not the most reocmmended for security reasons.

2. Create a user account and mailbox to be used for the process in the Exchange 2010 forest. This account must be granted Owner rights on every public folder that you plan to replicate. For my purposes I used the EX2010\Administrator account, though not the most reocmmended for security reasons. (NOTE: The public folder hierarchy must already exist in the Exchange 2010 forest, so you will need to pre-create the folders you will replicate from 2003.)

3. Create a top-level public folder named ExchsyncSecurityFolder in the Exchange 2003 organization. Assign the account created in step 1 Folder Visible rights only. Remove all other access rights for all other accounts.



4. Create a top-level public folder named ExchsyncSecurityFolder in the Exchange 2010 organization. Assign the account created in step 2 Folder Visible rights only. Remove all other access rights for all other accounts.



5. Install the Interorg Replication Tool replication service on the Exchange 2003 public folder server by running EXSSRV.EXE from the toolkit. Click the Create button which will install the service on the server. In my case I used the EX2003\Administrator account as the service account. I had problems when using local system. Administrator is also a local admin and Exchange Full Administrator



6. Open the Interorg Replication Configuration tool by running EXGCFG.EXE. Click File -> New to create a new Exchange Sync Configuration file (.esc). Click Session from the menu bar then click Add - Public Folder Replication.

7. In the Public Folder Session Configuration window enter PF 03 -> 10 in the title field to indicate 2003 public folders replicating to 2010. In the Publisher Organization section enter the Exchange 2003 public folder server and the mailbox name you created in step 1. In the Subscriber Organization section enter the name of the Exchange 2010 public folder server and the mailbox name you created in step 2.



8. Click the Advanced button under Publisher Organization then enter the credentials for the account you created in step 1. Click the Advanced button under Subscriber Organization then enter the credentials for the account you created in step 2.



9. Click the Folder List button. Click the Logon button under Publisher Public Folders and the Logon Button below Subscriber Public Folders. This will allow you to view the available folders in both organizations. Select a top-level folder under Publisher Public Folders and click the Add button. Repeat this for each top-level folder you plan to replicate.




10. Click Session from the menu bar then click Add - Schedule+ Free/Busy Replication. Repeat steps 7 through 9 to replicate free busy from 2003 to 2010.

11. Repeat steps 7 - 9 instead using Exchange 2010 as the Publisher and Exchange 2003 as the Subscriber to allow reverse replication. Do this for both public folders and free/busy. When the process is complete you will have at least 4 sessions in your configuration as shown below:



12. After completing this you can now monitor the process (I have mine running every five minutes in the lab, hourly in production) using the EXGSRV.EXE console.



For additional information on Interorg Replication Tool configuration and implementation I recommend checking out the full TechNet article here.

More information on Exchange

Read more!

Exchange 2010 – What to Know About Mailbox Import/Export

By:Rik Hoffelder

---

Exchange administrators are often asked to transfer e-mail data for various reasons and this usually involves PSTs. EXMERGE was always a great tool for this process; however Exchange 2007 introduced built-in functionality as a sort of replacement for EXMERGE. I say sort of because the Import-Mailbox and Export-Mailbox cmdlets don’t offer all of the same functionality as EXMERGE, specifically a GUI interface and multi-threaded mailbox export/import. That’s about the only downside to the cmdlets as they offer functionality not available to EXMERGE such as removing a message form mailbox and placing it another. Finding and removing messages from mailboxes, such as viruses (remember ISSCAN and ILOVEYOU?). It also works with mailbox recovery when using a recover storage group, not unlike EXMERGE, except I can recover a mailbox when the original user account was deleted, unlike the EXMERGE components of Exchange 2003 recovery.

Exchange 2010 Import-Mailbox and Export-Mailbox offer similar functionality as they did in Exchange 2007 with a few twists. The first big improvement is in security. In previous versions of Exchange an administrator required full mailbox access rights in order to import or export data using EXMERGE or Exchange 2007’s cmdlets. That is no longer the case with Exchange 2010. Among the new roles included with Role Based Access Control (RBAC) is the Mailbox Import Export role. This role is required for anyone who must perform this task, but it is not enabled by default for any user or group including members of Organization Management. As a result attempting to run the Import-Mailbox cmdlet will fail as an unrecognized command until the user is a member of the role group. An administrator can grant membership using the following cmdlet:

New-ManagementRoleAssignment –Role “Mailbox Import Export” –User “Administrator”

After joining the group, you must log off and back on in order to join, just like any other security group in the Windows world.

Next you must install the 64-bit version of Outlook 2010 or later on the mailbox server where you will perform the import. This must be the 64-bit version and it must be installed on the mailbox server role because Microsoft does not offer a 32-bit version of Exchange 2010 management tools. Also note that it is required on the mailbox server, so simply placing it on a 64-bit management workstation will not suffice; it MUST be on the Exchange 2010 server although you can use a 64-bit workstation to run the actual process.

A few items of note are that the Exchange 2010 version of Import-Mailbox and Export-Mailbox will not work against mailboxes hosted on Exchange 2003 or 2007 servers. You can use EXMERGE against both of those versions. And yes, EXMERGE still works against an Exchange 2007 server; you just have to set it up on a 32-bit workstation with Outlook and Exchange 2003 System Administration Console. On the flip side, Exchange 2007 Import/Export will not work against mailboxes hosted on 2010 or 2003 either.

Exchange 2010 RTM at least through Rollup 3 (most recent version at time of writing) has an annoying bug, in my opinion. If you have a typical installation of a multi-role server (Hub, CAS, & Mailbox), as many smaller organizations do, Import-Mailbox will fail with error -2147221219. The only workaround to this is to bring up a mailbox-only server to perform the imports. It will not work otherwise, it is not a security issue, it is a bug (maybe by design?). So for organizations needing this functionality on a regular basis should plan accordingly. I recommend building that as a virtual machine since it doesn’t require much resource when not in use.

Read more!

Cross-Forest Migration with Exchange 2010 is a piece of cake!

By:Rik Hoffelder

---

Overview
It has been a while since I've posted anything new on The Generation V as I have been neck deep in projects. One of them involved a cross-forest Exchange migration as part of a larger AD migration. In this project the customer was migrating Exchange 2003 in Forest A to Exchange 2010 in Forest B and they needed to do it on a budget. In other words, no third party tools if at all possible. As the title suggests, with free tools from Microsoft and built-in features of Exchange 2010, it was remarkably easy.

Over the years Microsoft has added many tools, most free, to assist in numerous management and migration tasks. For this project I used the Active Directory Migration Tool 3.1, Exchange Sync from the Exchange 2003 toolkit, CVSDE, VBScripts, and PowerShell to perform all of the tasks. This saved the customer the many thousands of dollars third party software would have cost and not necessarily made the process any easier.

I will not go into the specifics of the AD migration part of the project, just know that all user and group accounts were migrated using ADMT 3.1. I also did not use ILM 2007 FP1 SP1 to provide GAL sync as this wasn't necessary due to the relatively small size of the project (about 600 mailboxes) and the rarity of account/mailbox additions/changes/deletions in this environment during the co-existence period. Even in that case, creating new accounts or modifying DLs followed a document process I created that eliminated the need for GAL sync. I would suggest ILM for larger organizations and those that make many changes during co-existence.

Prepare Routing

Prior to the Exchange migration, I had to establish a routing method to be used during the co-existence period between Exchange forests. This is necessary because both Exchange forests must be authorative for the primary SMTP namespace of customer.com. To do this I established a proxy address of ex2003.local for Exchange 2003 and ex2010.local for Exchange 2010.

I then added ex2010.local to the Accepted Domain Hub Transport organization configuration and added %m@ex2010.local as a proxy address to each affected E-mail Address Policy. Next I added the %m@ex2003.local proxy address to each Exchange 2003 Recipient Policy and selected the "This organization is responsible for delivery …" checkbox. All recipients were updated with the new policies.

Next I created SMTP connectors in each Exchange forest to forward to the other's proxy address space. For example the Exchange 2003 SMTP connector routes @ex2010.local to the Exchange 2010 forest and vice versa.

Prepare User Accounts

The Active Directory Migration Tool was used to migrate the Forest A user and group accounts into Forest B. (ADMT is also a free tool available from Microsoft's public download site http://microsoft.com/downloads). After the accounts were migrated I exported the displayName, samAccountName, mailNickname, and mail values for all mailbox-enabled users in Forest A using CSVDE as follows:

csvde -l displayName, samAccountName, mailNickname, mail -r "objectclass=user" -f c:\2003_Mailboxes.csv

This was done to use these values to mail-enable each user account in Forest B. By mail-enabling (not mailbox-enable) the Exchange 2003 users now appear in the Exchange 2010 address book allowing migrated users to communicate with unmigrated users seamlessly, thus eliminating part of the need for ILM in this project.

Before mail-enabling the Forest B users I changed the domain portion of each e-mail address to ex2003.local to use as an input value for the bulk mail-enable process. I also renamed the field in the CSV file to match the input values I used in the Exchange Management Shell cmdlet. DisplayName was changed to Name, samAccountName was changed to Identity, mailNickname was changed to Alias, and mail was changed to EmailAddress. I then ran the following cmdlet to complete the update:

Import-CSV C:\2003_Mailboxes.csv ForEach-Object –process {Enable-MailUser –Identity $_.Identity –Alias $_.Alias -EmailAddress $_.EmailAddress}

This would of course need to be manually updated for any new user accounts migrated over from Forest A.

The final step to prepare the users is run the Prepare-MoveRequest.PS1 script against the mail-enabled users. Prepare-MoveRequest.PS1 is a script created by Microsoft that updates the Forest B mail-enabled user with the MsExchMailboxGUID attribute from Forest A. This value will be used by the New-MoveRequest cmdlet to match the source Exchange 2003 mailbox to a target 2010 user. This little free script along with the –RemoteLegacy switch in the New-MoveRequest cmdlet are the new features in Exchange 2010 that help eliminate the need for third party tools in all but the most complex of cross-forest migrations.

I ran the following cmdlets in 2010 EMS, reusing the 2003.Mailboxes.CSV from the previous step:

$UserCredentials = Get-Credential

Import-CSV C:\2003_Mailboxes.csv ForEach-Object –process {Prepare-MoveRequest.ps1 -Identity $_.Identity -RemoteForestDomainController ex03.ex2003.local -RemoteForestCredential $UserCredentials –UseLocalObject}

For those new to PowerShell in general, EMS in particular, the $UserCredentials = Get-Credential cmdlet will open a dialog box requesting to enter the credentials of an account in Forest A with rights to migrate the data from Exchange 2003. Enter the credentials accordingly or the migration will fail with an error message containing 0x80004005, which means access denied in the entire Microsoft world.

Prepare Distribution Groups

Next I had to mail-enable the distribution groups migrated from Forest A. The ADMT will migrate the groups and group members as a group type of Distribution but it will not bring over Exchange attributes. This required two steps, first each migrated group had to be changed to a Universal group, as they were domain local or global groups in Forest A. Distribution Groups in Exchange 2007/2010 are Universal in scope as a result domain local or global groups cannot be mail-enabled. To do this I ran the following cmdlet in Exchange 2010 Management Shell:

Import-CSV C:\groups.csv ForEach-Object –process {Set-Group –Identity &_.Name –Universal}

I then ran the following script to mail-enable the Universal groups.

Import-CSV C:\groups.csv ForEach-Object –process {Enable-DistributionGroup =Identity &_.Name}

Now keep in mind that any new users created in Forest A and added to the Forest A version of this group, will become a member of the Forest B version of the group after the user account is migrated with the "Fix Group Memberships" option selected, thus negating the need for ILM.

Prepare Public Folders & Free/Busy

This migration occurred over a period of several weeks. Users were fully migrated to Forest B, meaning they were accessing Exchange 2003 from Forest B user credentials on workstations operating in the Forest B domain. After all users, groups, and workstations were migrated, I began the mailbox migration process.

This company relies on Public Folder data in several areas to collaborate and share information. As a result I had to maintain both public folder and free/busy synchronization between Exchange forests for a period of time. To do this I used the good old Exchange Inter-Organization Replication Tool. At preset this tool is not designed for use with Exchange 2010, but version 6.5.7408 is supported with Exchange 2007. I thought what the heck there isn't that much difference in public folder functionality between 2007 and 2010 so I gave it a try … in my lab first of course. What do you know, the darn thing worked and it worked very well.

To get it up and running I followed the steps outlined in this article: http://technet.microsoft.com/en-us/library/ee307369(EXCHG.80).aspx. It took a couple hours to get it fully functional in the customer environment, but it did the job very well and cost nothing but billable time! Hey I gotta eat too, right?

Migrating the Mailboxes

This is another area where Exchange 2010 really shines. The New-MoveRequest cmdlet offers a command-line only switch –RemoteLegacy. This switch tells Move Request to migrate a mailbox from a different Exchange 2003 or 2007 forest. It uses the MsExchMailboxGUID to match the source 2003/2007 mailbox in the remote forest with the target mail-enabled user in the Exchange 2010 forest, which was established earlier using Prepare-MoveRequest.PS1.

$UserCredentials = Get-Credential

New-MoveRequest –Identity migtest1 -RemoteLegacy -TargetDatabase "Mailbox Database 1" -RemoteGlobalCatalog 'ex03.ex2003.local' -TargetDeliveryDomain 'ex2010.local' -RemoteCredential $UserCredentials

When the move request completes it converts the target mail-enabled user to a mailbox-enabled user. It then deletes the source mailbox and converts the user to mail-enabled. As part of that process it adds a proxy address of @ex2010.local as the primary SMTP allowing users on the legacy forest to see the migrated mailbox in the global address list.

Finally using a group policy object I created a VB Script based user logon that creates a new Outlook profile by using a PRF file. The script checks for the presence of a specific profile name, if it doesn't find it Outlook is launched with the PRF as follows:

Path\Outlook.EXE Path\Update.PRF

It's quick it's easy and the code I used was readily available through a simple Bing search.

Final Words

I don't exactly recommend this process for large scale migrations, but for those of you operating on a budget and can't afford 10+ USD per mailbox for a one time use tool; this is will get you by. It isn't perfect, but it worked well for this project.

More information on Exchange

Read more!

Mailbox Reporter for Exchange 2007 & 2010

By:Rik Hoffelder

---

Exchange 2007 and 2010 brought about many great new features and functions. However Microsoft forgot about the little guy when it came to getting a quick overview of mailbox statistics via a GUI. It really made quite a few of my customers unhappy. It’s not that Exchange 2007 or 2010 do not provide this information, it is only available on individual mailbox properties in the Exchange Management Console, you cannot view all mailboxes on a given store without using the Get-MailboxStatistics cmdlet then piping the output to a file.

While this is all well and good, most Exchange Admins moving from 2000 or 2003 to 2007 aren’t familiar with PowerShell, let alone Exchange Management Shell. As a result I wrote this handy little script to replace that functionality and view all mailboxes within the organization. It’s run from Exchange Management Shell using the following command:

C:\Scripts> ./MailboxReport.PS1

It then opens the report in a web browser as shown below:



Just copy the code below and paste into a text file named MailboxReport.PS1 then run as described above. It works with Exchange 2007 or Exchange 2010. I hope you find it useful!

#Exchange Mailbox Reporter
$a = "<style>"
$a = $a + "BODY{background-color:white;}"
$a = $a + "TABLE{border-width: 1px;border-style: solid;border-color: black;border-collapse: collapse;}"
$a = $a + "TH{border-width: 1px;padding: 0px;border-style: solid;border-color: black;background-color:LightBlue}"
$a = $a + "TD{border-width: 1px;padding: 0px;border-style: solid;border-color: black;background-color:White}"
$a = $a + "</style>"
$b = "<H2> Mailbox Summary Report </H2>"
$servers = get-mailboxserver
Foreach ($server in $servers) {
Get-MailboxStatistics -server $Server |
Where-Object {$_.DisplayName -NotMatch "^CAS_"} |
Where-Object {$_.DisplayName -NotMatch "^SystemMailbox"} |
Where-Object {$_.DisplayName -NotMatch "^Microsoft System"} |
Select-Object DisplayName, ItemCount, TotalItemSize, StorageLimitStatus, LastLogonTime, LastLogoffTime, LastLoggedOnUserAccount, ServerName, Database |
Sort-Object TotalItemSize -descending |
ConvertTo-HTML -head $a -body $b |
Out-File MailboxReport.htm
}
Invoke-Expression ./MailboxReport.htm

More information on Exchange

Read more!

Backup & Recovery in Exchange 2010

By: Rik Hoffelder

---

In my previous post, Cluster Databases Instead of Servers … Brilliant!, I covered several architecture changes to message store databases in Exchange 2010. Among those I noted that Database Availability Groups or DAGs add a new level of server resilience that can support same datacenter and/or remote site replication. So this begs the question, are backups really necessary? And to be honest I have to wonder that myself.

The answer really depends on the Exchange 2010 architecture you deploy and your requirements. Microsoft recommends that you maintain at least three database copies before considering the elimination of traditional backups. I am going to add that at least one of those three be in a remote datacenter and is configured as Lagged Mailbox Database Copy. This will help ensure that you can recover from database corruption resulting from controller or other such issues.

A lagged mailbox database copy will allow you to remove corrupt transaction logs before activating the copy to ensure that corruption is not replayed into the database. Keep in mind that a non-lagged mailbox database copy will have already played in the corruption also be unusable. It's the nature of the beast, in fact it affect ALL replication technologies which is why third party applications such as Double Take and NeverFail offer some form block rollback as part of their platforms. With Exchange 2010 there is no need to rollback, just remove the corrupt logs before activation.

(NOTE: Public Folder Store databases do not support continuous replication therefore you must either replicate each PF to another Exchange Server or maintain backups)

With this option do I still need backups? Well yes particularly if you budget will not allow you maintain at least three Exchange 2010 servers with at least on server offsite. If your business requires archival backups for legal or other reasons, you will need to continue maintain backups as usual even if you uses DAGs with multiple database copies. So what are my options? Has anything changed from my 2003 or 2007 backup processes? Yes, it has changed a bit. So before you begin the migration process you might want to make sure you are ready.

Streaming backup of message store databases are no longer supported in Exchange 2010. If this is your preferred or only backup method, you'll need to get with your backup software vendor for an upgrade and maybe some other changes. If you use a solution that supports the VSS APIs, you're in luck that's all Exchange 2010 supports. Exchange 2010 also provides integration with Windows 2008 Backup using the same WSBExchange.EXE process as was provided with Exchange 2007 SP2 which is adequate but has its limitations. (See Exchange 2007 SP2 is Here for more information).
Microsoft's System Center Data Protection Manager provides a robust platform to provide the capabilities missing from the Windows 2008 and Exchange 2010 in-box solutions. DPM along with other vendors such as Symantec, EMC, and IBM also allow you the ability to backup the passive copy of the database. This allows you to run backups more often with affecting user experience and server performance on the active copy.
Snapshot backups are also great solutions that have the lightest impact on overall performance. What's more they are extremely fast, usually less than 15 seconds, and several vendors offer value add by incorporating such things as brick-level mailbox restores from snapshot or snapshot replication. Snap Manager for Exchange from NetApp is an excellent example and one I am most familiar with, but that doesn't mean there are other great solutions. Just means I haven't worked with them yet.

The major reason for backing up your databases is so you can recover them in the event of a disaster. Exchange 2010 has a few changes there as well. Exchange 2007 introduced database portability, which allowed you forklift a database and transaction logs from one server to another in the same organization, run a few cmdlets to prepare and mount it, then redirect users to the new location.

Exchange supported what is known as dial-tone recovery for several versions. In fact I have done this in production environments as far back as Exchange 5.5 in 1997. Restoring the data in that situation was no picnic which is why Microsoft introduced the Recovery Storage Group in Exchange 2003. The RSG allowed you to "Dial-tone" and corrupt database (meaning delete it and bring up a blank DB) to get users working again while you restored the database from tape or disk to a recovery copy. At the end of the process, you would use the mailbox tools to merge the data from the recovery database into the production database. It was somewhat time consuming but a darn good process overall. RSGs were also a component of Exchange 2007 with improvements such as being able to recover deleted mailbox after the original user ID was deleted and merging the data into a different mailbox.

Exchange 2010 eliminates the Recovery Storage Group along with Storage Groups in general. This function is replaced by a Recovery Database. A recovery database is very similar in functionality and operation to a recovery storage group in several ways. First mail can't be sent to or from the RDB, it only supports the MAPI protocol and is only assessable by a special set of tools (Restore-Mailbox, Export-Mailbox). A RDB can only be restored to, it cannot be backed up, you can also restore to a RDB when the mailbox database is online. In fact if the mailbox database is mounted, the restore is automatically redirected to the RDB. Unlike Exchange 2003 you may only have one RDB mounted on a server at a time.

I should note that RDB creation and management is entirely Exchange Management Shell based. Unfortunately Microsoft chose to remove the GUI-based tools included in Exchange 2003 or 2007 in the RTM version of Exchange 2010. I hope they bring that back in SP1, this was a handy feature for my less Exchange savvy customers.

Thus far I have primarily focused on mailbox store database, to ensure full recoverability there other roles that must be accounted for. Any Exchange 2010 (2000 or later for that matter) must take Active Directory into account. All Exchange specific configuration data is stored in the Configuration partition of Active Directory. Therefore if you ever need to perform a complete rebuild of your Exchange environment, you must make sure you have a working copy of Active Directory. I specifically recommend backing up the System State at a minimum on at least one or two domain controllers in each domain of the forest at least once a day, every day. Exchange is also very heavily dependent on DNS. If you use Active Directory-integrated DNS simply backing up the System State of a DNS-enabled domain controller will take care of that. If you do not use AD-integrated DNS or a non-Microsoft platform for your DNS, follow the guidelines recommended by the vendor.

The items I would consider for backup on non-mailbox server roles include a full operating system backup, including server System State at least once a month (more than once a week is overkill) and anytime the operating system of applications have been changed, such as after patch Tuesday or when a rollup or service pack is applied to Exchange or other supporting application on the server. Now let's take a roll by roll look at what else to take into consideration.

Client Access Servers do not maintain user data, therefore the only major items to concern yourself with are keeping a backup copy of your certificates. In the event of a total loss of the server you would reset the computer object in Active Directory, then build a fresh operating system. When you install Exchange specify the /RecoverServer switch when running setup. This will read in the original configurations of that server from Active Directory. At this point you just need to import and enable the certificates. This will allow a complete recovery without data loss.

Hub Transport Servers do maintain a certain amount of user data in the form of messages in transit and the transport dumpster. Neither of these items can be backed up directly, but you can recover in-transit messages from a hub transport server provided you can get to the disks. Exchange 2007 and 2010 hub transport servers use an ESE database, as opposed to IIS SMTP queues used in 2000 and 2003. Because of this and database portability you can copy the ESE file and logs to another hub transport server then recover the database using ESEUTIL and deliver the messages. This also holds true for Edge Transport Servers. Much like the Client Access Server recovery, the total loss of a hub transport server requires resetting the computer object, installing a fresh OS, and running Exchange Setup with the /RecoverServer switch. If you have Edge Transport Servers you will also need to reconfigure your Edge Sync policies.

The Edge Transport server behaves much like the hub transport in recovery scenarios. The ability to move the ESE database to redeliver messages is also an option here. You should also make sure you backup the Edge server setting using the ExportEdgeConfig.PS1 script included in the Scripts directory and store the output in a safe place. In the event of a total server loss you would build a new workgroup server, install the Edge Transport role, the run the ImportEdgeConfig.PS1 script to return to a pre-failure state.


More information on Exchange


Read more!

Cluster Databases Instead of Servers … Brilliant!

By:Rik Hoffelder

---

Among the major architectural changes included in Microsoft's Exchange Server 2010 one of my favorites is the Database Availability Group or DAG. What is a DAG? Simply put it is a failover cluster for Exchange 2010 mailbox stores. So? Exchange has supported clustering mailbox servers for years what's different about this? Ah, but there is the answer, it clusters mailbox databases, not mailbox servers.. This allows you support Mailbox, Hub Transport, and Client Access Server roles on the same server reducing hardware requirements, administration, and complexity yet providing high availability and site resiliency for a lot less investment cost. To top that off, you can create the cluster after Exchange 2010 has been installed allowing you to build one server today then add another months later and still cluster the mailbox stores. This is part of a new Exchange design methodology called Incremental Deployment.

To make this possible the Exchange Design Team made significant changes to the database structure and database objects. First the mailbox database structure was flattened to improve performance allowing it to run on cheaper SATA/Tier2 drives. Because of this improvement Exchange 2010 can support up to 100 databases on a single Enterprise Edition server, (Standard Edition still only supports 5) with the right storage design of course. Next Storage Groups were removed from the architecture, thus forcing a 1 to 1 relationship between databases and transaction logs. Exchange 2000, 2003, and 2007 supported multiple mailbox stores in a single storage group, all sharing the same set of transaction logs. Which has presented its fair share of problems in recovery scenarios, but that's a different topic!

The removal of storage groups was a necessity to supporting DAGs. A DAG utilizes a replication technology based on a combination of Continuous Copy Replication (CCR) and Standby Continuous Replication (SCR). CCR is a technology first introduced in Exchange 2007 that allowed you to create a "shared nothing" cluster, meaning no shared storage, then used log shipping to maintain the passive copy of the database. CCR only supported the mailbox server role so SCR was introduced in Exchange 2007 Service Pack 1 to provide replication between servers host mailbox, hub, and CAS roles, however unlike a cluster failover was manual and did not maintain the original server name. SCR could be used in conjunction with CCR to provide site resiliency and used the same log shipping technology. To implement either replication technology you could have only one database per storage group anyway.

The combined CCR/SCR technology, simply named continuous replication, includes some big changes as well. First the elimination of storage groups allows the replication to occur at the database level allowing the database to be replicated to as many as 16 servers. Log shipping no long occurs over a SMB connection; rather it uses an administrator defined TCP port for data transfer that is compressed and encrypted. Unlike Exchange 2007, 2010 uses a push model in logging shipping ensuring all passive copies are kept up to date. Database seeding can also be performed for a passive copy of the mailbox database, eliminating the performance hit on the active copy.

Exchange 2010 does not support continuous replication of public folder databases, but it does allow a separate copy of a public folder to exist on each DAG member with public folder replication enabled. Exchange 2007 CCR only allowed a single public folder database per cluster requiring a separate mailbox server to host public folder replicas to ensure availability. You may have noticed that I didn't mention Local Continuous Replication (LCR) or Single Copy Clusters (SCC). Those features have been removed in Exchange 2010.

Finally the Mailbox and Public folder store objects were moved to the Organization level of the Exchange Forest (Yep, new term in 2010). The database is no longer a subordinate of a server, it is a peer. Because of this and the features of Windows 2008 Failover Cluster service you are able to cluster the databases and cluster them across as many as 16 servers. And just to get a little crazy here, those 16 servers could be in 16 different datacenters! Not exactly a recommended scenario, but it is possible. All 16 members of the DAG maintain the same name so no reconfiguration of legacy Outlook clients is required as was the case in SCR.

In order to provide the greatest level of resiliency changes were made to the hub transport role to help prevent data loss. Exchange 2007 CCR clusters used a feature of the Hub Transport role called the transport dumpster to help backfill missing messages in the event of a lossy failover. A lossy failover means that transaction log data from the primary node had not been shipped to the secondary prior to failure resulting in data loss. To mitigate data loss the transport dumpster could redeliver up to seven days worth of messages thus backfilling the database. Exchange 2010 still supports this but adds some additional protection.

When a hub transport role is on the same server as a DAG it will reroute all messages destined for local mailbox databases in the DAG to another hub transport server within the Active Directory site to ensure a copy is stored in a second transport dumpster. This is done to prevent loss in the event the entire server is lost and a database failover occurs by ensuring another transport dumpster can redeliver the message. The hub transport server also monitors the replication of delivered messages and will remove the message from the dumpster once a copy has been replicated to all mailbox databases within the DAG.

As you can see this really makes building a highly available, high resilient Exchange architecture simple and darn near bulletproof without a lot of cost or complications. From the testing and playing I have done, it is very simple and quick to setup. A lot less hassle and time consuming than the clusters of yore. This makes me want to tell all my customers … DAG - Nab It!

More information on Exchange
Read more!

Is Brick-level Necessary for Exchange?

By:Rik Hoffelder

---

The need for brick-level backup of Exchange mailboxes is often a topic of discussion with customers. This is of particular concern to those with large message stores, short backup windows, and demanding users. In my opinion Exchange provides enough out of the box functionality that brick-level backups are really unnecessary in all but the most crucial of mailboxes. You know the mailbox that belongs to the person who signs your paycheck! In all seriousness I feel brick-level backup is mostly a waste of tape and/or disk.

Let's first take into consideration the deleted items retention configuration on mailbox stores; a feature that has been with Exchange through many generations. This feature marks a deleted message as hidden to the database thus places it in a "dumpster." By deleted message I mean a message that has been purged from the mailbox, not left in the Deleted Items folder. The length of time the message remains in the dumpster is determined by the deleted items retention configuration on the message store. A value greater than zero will keep the message hidden for that many days, after which time the database page(s) are marked for reuse in effect purging the message from the database. However during the time the message is in the dumpster it is recoverable.
Many of you may already be familiar with the Recover Deleted Items function under Outlook's Tools menu. By default this menu option is grayed out unless you have selected the Deleted Items folder. Microsoft has a little known knowledge base article that documents a registry setting allowing the Deleted Items Recovery option to be available to all folders, not just Deleted Items. This setting not only allows recovery from all folders within the mailbox but all public folders as well. The public folder store also has a deleted items retention configuration. (Additional information on this registry setting can be found in How can I recover items that I have "hard deleted" in Outlook? )

Deleted Item Recovery using this method not only has the benefit of being able to recover any message from any folder; you can also recover messages that have been hard deleted when someone uses SHIFT+DELETE. As a result you can recover messages that have been delivered after the last backup, eliminating the data loss a SHIFT+DELETE would present using brick-level restore. Additionally all recovery is done online, you never need to mount a tape so it literally takes seconds to locate and restore messages. But wait there's more; you can configure this for all end users so they can recover their own messages never having to wait hours, even days for recovery. Do you think that can reduce admin overhead and help desk calls for those little uh-ohs?

Yes there are a few gotchas, what did you expect for out-of-the-box? For instance, each mailbox or public folder store is limited to 4 GBs of dumpster space within the database. For large message stores this will reduce the amount of time you can keep deleted items before reaching the limit. If you exceed the 4 GB limit messages are purged on a First In - First Out (FIFO) basis. It has been my experience that a 100GB mailbox store under normal utilization can support up to 14 days worth deleted items comfortably. This obviously varies by environment; fortunately Microsoft took some the guess work out. Exchange 5.5 Server or later include performance counters under the Information Store object that show current dumpster utilization.

So how do I handle a case where the message is past the recovery period? This is where the Recovery Storage Group comes into use. First introduced in Exchange Server 2003 the RSG allows you to perform an online restore of mailbox databases to a separate storage group and mailbox store instance, then merge the data with the on-line mailbox. Again this is not a perfect solution as the active mailbox must reside on the same server that the backup was taken from. In other words if I moved the mailbox to a different store since the backup I wish to restore was taken, I need to move the mailbox back in order to merge the data. This is very well detailed in Microsoft's knowledge base article How to use Recovery Storage Groups in Exchange Server 2003. The other issue is that the original user account must exist in Active Directory, if this has been deleted you cannot use a RSG. However you can follow the steps I outline in my blog posting How to Build an Exchange 2003 Disaster Recovery Server.

More information on Exchange

Read more!

UM in Exchange 2010 ... Cool just got Cooler!

By:Rik Hoffelder

---

With all the feature enhancements in Microsoft's forthcoming Exchange 2010 a couple of the really cool ones are part of the Unified Messaging Role. Exchange 2007 introduced UM as an integrated Exchange solution and brought such cool features as Outlook Voice Access, Play on Phone, and integration with Outlook 2007. Exchange 2010 builds on that by adding two extremely cool features, Message Preview and Voice Mail Routing Rules.

The new message preview feature transcribes the voice message into text and includes that in the e-mail. You now have the option to prescreen your voice mail without ever listening to the message. Of course you still have the option of playing the WAV file or playing the message on the phone, now you can add the ability to read a bit of the e-mail and deal with the message accordingly. Now that's convenience!
Outlook 2010 and OWA 2010 users can also take advantage of the Voice Routing Rules. This allows the end user, yes I said end user, to choose how they want to handle voice mail messages. For example a user can create a routing rule based on the incoming caller then route the call to their mobile phone. Numbers that don't match can then follow an auto-attendant to route the call to an appropriate team member.
Think about, you're on vacation when an important client calls with a giant purchase order burning a hole in their pocket. How cool is it to be able to setup a rule so your customer can locate you and close that important deal? Microsoft offers a live demo on the TechNet Edge site under What's new in Unified Messaging in Exchange 2010?

It's really worth a look.

More information on Exchange


Read more!

Exchange 2010 Archiving is worth a Look

By:Rik Hoffelder

---

Over the years Microsoft's Exchange server has evolved into a more complete solution. For example Exchange 2003 brought us Recovery Storage Groups and Envelop Journaling to help meet recovery and compliance needs. Exchange 2007 brought new high availability features with LCR, SCR, and CCR as well as refined journaling through transport level rules. This has helped companies provide better solutions with out-of-the-box components rather than shoulder the expense of the many third party products. While not as robust as the third party offerings, Exchange offers viable solutions to provide greater value with each release.

Exchange 2010 is no exception. It incorporates e-mail archiving and retention out-of-the-box. While it is not quite as full featured as many of the finer third party products such as Enterprise Vault or Email Xtender, it offers many compelling features that will enable businesses of all sizes to implement an affordable, out-of-the-box solution. Many of the new features are based around the improvements made to Exchange 2010 database architecture and indexing services. In particular the database optimizations in Exchange 2010 allow for high performance from lower cost SATA/Tier2 drives. This enables an organization to increase storage capacity and performance with breaking the bank.

The integrated solution in Exchange 2010 allows an administrator to create a secondary archive mailbox on the user's mailbox properties. The archive mailbox appears as a secondary mailbox in the Outlook 2010 or Outlook Web Access 2010 clients. Note that the new archiving features are only available in Outlook or OWA 2010. For companies that may not want or be able to upgrade Outlook can still utilize OWA to access archived data.

So what are some of the new features of archiving that make this a compelling solution? First an administrator can set a retention policy on the mailbox or individual folders through the new Retention Policy configuration. Also note that all of the configuration options related to archiving are available through the Exchange Management Console GUI making administration simple.

The administrator has the ability to set separate quota limits for the primary and archive mailboxes. Note that the default archive mailbox has a 10 GB size limit, this is configurable. User or administrator defined retention policies can be applied allowing manual or automatic message moves to archive. The retention policies include rules that allow you move messages from primary to archive, delete messages from primary mailbox folders such as deleted items, or move messages to archive then delete from archive when they have expired. Rules can be set on each folder or the full mailbox.

Think of this as a replacement to Outlook's auto-archive to PST. You can eliminate the need for PSTS. Speaking of PSTs, the end user can drag and drop their PSTs into archive. This helps reduce or eliminate the accident waiting to happen for PSTs stored on workstations, such as my laptop. Oops!

How about search capability, is that in there? Yes and it rivals many of the competitors because it allows search across the primary and archive mailboxes simultaneously. It also provides dumpster searches. Search the dumpster … really?? Yes, think of the implications of not having to run EXMERGE to export dumpster items from mailboxes under investigation because the user found out and started to SHIFT+DELETE certain messages. Then you have to manually search or import the PSTs into some third party tool to find what you need.

Now there is a catch, the archive is only available when you are on line. Items stored in the mailbox archive are not synchronized with an OST file. This is part of the benefit of archiving, particularly when dealing with very large mailboxes. As a work around you can move messages from the archive mailbox to the primary mailbox prior to traveling for accessibility. If you have travelers who frequently access older e-mail keep this in mind as you create your retention policies.

Exchange 2010 archiving also works with journaling. Keep in mind archiving and journaling are not exactly one in the same. Journaling is done for legal or regulatory compliance. This is where Exchange 2010 really shines by building on Exchange 2007 journaling. I believe you can create a true compliance solution to meet any entities' need that rivals any solution on the market today for no additional cost.

Exchange 2010 offers a new user role which allows an administrator to delegate the ability to search the archives to a compliance office, human resources, or other interested party. Moving the responsibility of performing searches back where it belong, at the business level. Exchange 2010 provides a new GUI-based tool that allows search across all or selected mailboxes. Results can be stored in a separate compliance mailbox store. Compliance administrators can also define retention policies and place items on legal hold.

Finally, as in it's about time, journaling has the ability to decrypt messages sent by internal users. Messages are stored unencrypted in the journal mailbox, while the original recipient(s) receives an encrypted copy. This new ability allows encrypted messages to be scanned for viruses (isn't it about time?), scan for content, and apply content transport rules to be applied to encrypted content. Even if you use a third party solution, this alone makes it worthwhile to consider upgrading to Exchange 2010 as soon as it is available.

As you can see archiving offers a host of new options for Exchange 2010 deployments. I have really only touched the surface of what archiving can do there are many other facets. Please drop me a comment or a question, I want to know your thoughts.

More information on Exchange

Read more!