A short while after the release of the 20.7 update, the Exchange Team released another minor update of the Exchange 2010 Server Role Requirements Calculator, bringing the version number to 20.8.
Compared to 20.7, this version contains a fix for secondary CAS CPU calculations.
You can download the calculator here. For more information please consult the changeblog or usage instructions.
The Exchange Team released version 20.7 of the Exchange 2010 Server Role Requirements Calculator, which contains a small bug fix.
Bug Fixes since version 20.6:
You can download the calculator here. For more information please consult the changeblog or usage instructions.
Today the Exchange Team released Rollup 1 for Exchange Server 2010 Service Pack 3 (KB2803727). This update raises Exchange 2010 version number to 14.3.146.0.
Here’s a list of fixes contained in this Rollup:
As of Service Pack 2 Rollup 4, its no longer required to disable/re-enable ForeFront Protection for Exchange using the fscutility to be able to install the Rollup properly. However, if you want to remain in control, you can disable ForeFront before installing the Rollup using fscutility /disable and re-enable it afterwards using fscutility /enable.
If you want to speed up the update process for systems without internet access, you can follow the procedure described here to disable publisher’s certificate revocation checking.
If you got a DAG and want to properly update the DAG members, check the instructions here.
As with any Hotfix, Rollup or Service Pack, I’d recommend to thoroughly test this rollup in a test and acceptance environment first, prior to implementing it in production.
You can download Exchange 2010 SP3 Rollup 1 here.
A quick write up on something which you might encounter when trying to move mailboxes across forests. Often, operators don’t always have full access permissions in both environments and rely on provided accounts or delegated permissions to execute the move.
Suppose you’re in the target environment and are asked to migrate mailboxes cross-forest from a previous version of Exchange to Exchange 2010. One of the first steps would be to run the Prepare-MoveRequest.ps1 script to prepare the target object and populate it with Exchange-related attributes from the source environment.
You then come at a point in such a migration, after running Active Directory Migration Tool – ADMT and perhaps some additional tweaks, when you need to actually move the user’s mailbox. So, you enter for example:
$cred= Get-Credentials
New-MoveRequest –Identity UserX –RemoteLegacy –TargetDatabase DB1 -RemoteGlobalCatalog SourceDC –RemoteCredential $cred –TargetDeliveryDomain maildomain.com
Mailbox move request are being queued but for some mailboxes you may encounter the following error message: “Database xxxxx-xxxx-xxxx-xxxx-xxxxx doesn’t exist”. That error message may get you worrying, but let’s investigate.
We’re in the target environment and the source environment is running a legacy version of Exchange so setting up a remote PowerShell session and using Get-MailboxDatabase <GUID> is not an option. All roads lead to Rome when querying Active Directory, but in this case let’s load up our trusty LDP to look up that GUID; it should map to a database in the source environment.
In LDP, use Connection > Connect and enter the name of a remote domain controller, like the one specified as RemoteGlobalCatalog, in our example RemoteDC. Then, use Bind providing the credentials you used with RemoteCredential.
Next, select View > Tree and use <GUID=xxxxx-xxxx-xxxx-xxxx-xxxxx> as BaseDN (replace those x’s with the GUID reported by the failing New-MoveRequest and make sure you include those less and greater than symbols).
Now, normally the database object with that GUID and its properties will be returned. If not, something is probably wrong with the permissions on the mailbox, directly or indirectly. Depending on whether you’re able to migrate other users from the same database, server up to the organization, you can rule out if it’s a per-mailbox issue, database permission issue etc.
This proves that as always, preparation is everything. Therefor, prior to migration be sure to check or correct effective permissions on mailboxes to prevent any surprises in that area when you’re actually migrating.
Note that the permission ACLs on a mailbox needs to be in a so-called non-canonical order. To fix this, you may find the FixMailboxSD utility helpful. More information on the importance of canonical ordering of mailbox permissions in Exchange here.
With the release of Exchange 2010 SP3, you can now control where sent items are stored when Send-As or Send-on-Behalf permissions are configured and you’re using Outlook Web Access. In Outlook we already had the possibility to control where sent items are stored this using registry keys, but now we can do so from Outlook Web Access or using the Exchange Management Shell. Unlike Outlook, you unfortunately can’t control where deleted items are stored.
As a quick reminder, to configure permissions for user Francis to send e-mail messages as Philip or on behalf of Philip, you would use:
Add-ADPermission Philip -User Francis -Extendedrights "Send As" Set-Mailbox Philip -GrantSendOnBehalfTo Francis
Sent Items Management from Outlook Web Access
To access the Sent Items Management option, use OWA to open the (shared) mailbox and navigate to Settings > Sent Items
You can configure the following options for Send-As or Send-on-Behalf e-mail:
Sent Items Management using EMS
To inspect where sent items are stored, use Get-MailboxSentItemsConfiguration, e.g.
Get-MailboxSentItemsConfiguration Philip
To configure the settings, use Set-MailboxSentItemsConfiguration in conjunction with SendAsItemsCopiedTo or SendOnBehalfOfItemsCopiedTo specifying Sender, From or SenderAndFrom. For example, to configure the items sent as Philip to be stored in the mailbox of both Philip and the actual sender, use the following cmdlet:
Set-MailboxSentItemsConfiguration Philip –SenderAndFrom
It would be nice if Outlook would honor these settings, just like the signatures, so you configure this centrally and have consistent behavior regardless of the client setting. It shouldn’t be difficult, using Exchange Web Services as a vehicle to store and retrieve this information.
Exchange Server 2010 Service Pack 3 (SP3) has been released, raising the Exchange version number to 14.3.123.4.
For those still unaware, the 550 MB file (1.45 GB uncompressed) contains the full set of binaries; you can use it to upgrade existing installations or deploy new Exchange 2010 SP3 installations.
Service Pack 3 introduces the following features:
In addition to fixes that were part of the Exchange 2010 SP2 Rollups 1 to version 6, SP3 adds the following fixes:
Be advised that after installing SP3 on Mailbox servers, the databases are upgraded to the SP3 version database schema. An SP3 database can’t be mounted on pre-SP3 Mailbox servers. Keep this in mind when upgrading your DAG (you will temporarily have limited fail-over/fall-back or switch-over options) or for example when utilizing database portability. Note that upgrading databases can be time consuming, especially with RTM or low SP databases as the database will be upgrade using interim steps, i.e. RTM to SP1, SP1 to SP2 and finally SP2 to SP3.
Also, while Exchange Server 2010 SP3 is supported on Windows Server 2012, that doesn’t mean .NET 4.5 (WMF 3.0, PowerShell 3.0) is supported on Windows Server 2008 or Windows Server 2008 R2; on Windows Server 2012, PowerShell 2.0 will be used. Also, OS upgrades (e.g. WS2008 R2 to WS2012) with Exchange installed aren’t supported.
After preparing your forest for Exchange 2010 SP3, the schema version number will have changed. Check the Schema Versions page for information on the new values for Exchange 2010 SP3.
The proper method to upgrade mailbox servers that are a member of a Database Availability Group is described here.
You can download Exchange 2010 SP3 here.
The UM language packs for SP3 can be downloaded here. Note that you need to uninstall previous UM language packs before you can install the SP3 versions.
Today the Exchange Team released Rollup 6 for Exchange Server 2010 Service Pack 2 (KB2746164). This update raises Exchange 2010 version number to 14.2.342.3.
Here’s the list of changes included in this Rollup:
In addition to these fixes, this Rollup also includes a fix for the security issue described in Microsoft Security Bulletin MS13-012.
As of Rollup 4, its no longer required to disable/re-enable ForeFront Protection for Exchange using the fscutility to be able to install the Rollup properly. However, if you want to remain in control, you can disable ForeFront before installing the Rollup using fscutility /disable and re-enable it afterwards using fscutility /enable.
If you want to speed up the update process for systems without internet access, you can follow the procedure described here to disable publisher’s certificate revocation checking.
If you got a DAG and want to properly update the DAG members, check the instructions here.
Note that Rollups are cumulative, i.e. they contain fixes released in earlier Rollups for the same product level (RTM, SPx). This means you don’t need to install previous Rollups during a fresh installation but can start with the latest Rollup.
As with any Hotfix, Rollup or Service Pack, I’d recommend to thoroughly test this rollup in a test and acceptance environment first, prior to implementing it in production.
You can download Exchange 2010 SP2 Rollup 6 here.
I received a question on if it was possible to decommission a DAG, so that the Exchange 2010 servers would become stand-alone Exchange servers and the databases remain available on one server, freeing up other mailbox servers. I assume the customer has valid reasons for wanting to do so, like downsizing without requirements justifying the DAG. To answer that question: of course that is possible. Now, while many blogs are happy to tell you how to create a DAG there aren’t many on how to dismantle one, so here goes.
For this blog I use a small setup which consists of a single DAG (DAG1) with member servers L14EX1 and L14EX2 hosting two databases, MDB1 and MDB2; both servers host an active copy.
In this example we’re going to decommission DAG1, where in the end the L14EX1 will host both databases and L14EX2 is freed up.
Before we decommission the DAG, we’ll reorganize the active databases so when removing database copies we’re removing passive copies. We’ll start by checking if the health status of the DAG:
Get-MailboxDatabaseCopyStatus *
We see databases are mounted and copies are in a healthy state. Next, we’ll active the copies on the L14EX1, because we’ll be freeing up the L14EX2:
Move-ActiveMailboxDatabase –Server L14EX2 –ActivateOnServer L14EX1 –Confirm:$false
Verify the databases are now properly mounted on the L14EX2:
Next, we’ll be removing the passive copies hosted on the L14EX2. Use Get-MailboxDatabaseCopyStatus instead of Get-MailboxDatabase because Remove-MailboxDatabaseCopy needs the database name specified together with the server name hosting the copy, e.g. “SERVER\DATABASE”. Note that after removing the copy, the files are still present on the file system which you need to clean up manually:
Get-MailboxDatabaseCopyStatus –Server L14EX2 | Remove-MailboxDatabaseCopy –Confirm:$false
With all passive database copies removed, we can now remove the L14EX2 from the DAG. Note that when removing a non-last member server, the node will also be evicted from the cluster and the quorum will be adjusted when necessary.
Remove-DatabaseAvailabilityGroupServer –Identity DAG1 –MailboxServer L14EX2
Next, do the same thing for the remaining node, the L14EX1. Note that this server still hosts (active) database copies which is ok; the cmdlet will detect this is the last member server of the DAG and will also remove the cluster object.
After the last member server has been removed from the DAG, we now have an empty DAG object which we can remove:
Remove-DatabaseAvailabilityGroup –Identity DAG1 –Confirm:$false
Et voila, L14EX1 now hosts both databases and the L14EX2 is freed up and you can uninstall Exchange from that server if required.
Kindly leave your comments if you have any questions.
Depending on your migration scenario, you could be exporting and importing PST files when migrating mailbox contents from one Exchange environment to another. Now folders in PST files are just folders, i.e. Inbox is a folder just like any other folder and well-known folders lose their identification. Because of this, you may end up with unexpected additional folders in your mailbox after importing PST files.
For example, when importing a non-US mailbox PST in a mailbox set to en-US you may end up with well-known folders and their regional counterparts, e.g. “Inbox” and “Postvak In” or “Calendar” and “Agenda”.
It can also happen that you import the PST file before setting the regional settings of the mailbox. In that case the folders with the local names are already present and Exchange will generate sequence number folders, e.g. Inbox1 or Calendar1.
Note that the above behavior goes for all well-known folders, such as Inbox, Calendar, Contacts and Sent Items. Users logging in early, i.e. logging on to their mailbox while they shouldn’t, can also create these situations.
One way to fix this situation is to manually move contents to the proper location using an e-mail client, which is tedious and something you don’t want to trouble end users or admins with. Another way is to set the mailbox’ regional configuration before importing the PST file.
A better way is of course to have an Exchange Management Shell script which talks to Exchange Web Services, essentially doing the same but in an automated kind of fashion. Here’s where the Fix-MailboxFolder.ps1 script comes into play. Using Fix-MailboxFolders.ps1 requires Exchange 2010 SP1 and Exchange Web Services 1.2 (or later), which you can download here. The script hasn’t been tested yet against Exchange 2013.
Since the script will process user mailboxes, it needs to be run by a user with full mailbox permissions or impersonation permissions. Granting full mailbox access can be done on several levels, e.g. mailbox or database. For example, to grant ExAdmin Full Access on a mailbox:
Add-MailboxPermission –Identity User –User ExAdmin –AccessRight FullAccess
However, a more elegant and preferred method is to utilize impersonation through Role-Based Access Control (RBAC). Information on configuring impersonation in your Exchange environment using RBAC is found here. As an example, to grant ExAdmin permissions to impersonate all(!) users in an organization, use the following cmdlets:
New-ManagementRoleAssignment –Name:impersonationAssignmentName –Role:ApplicationImpersonation –User:ExAdmin
After executing this cmdlet, the account ExAdmin can succesfully impersonate mail-enabled users. To limit impersonation to a certain subset of the user population, you could use a write scope; for more information on RBAC and write scopes, check out my past blog on this topic here.
Fix-MailboxFolders.ps1 uses the following syntax:
Fix-MailboxFolders.ps1 [-Mailbox] <String> [[-Language] <String>] [[-FromLanguage] <String>] [[-Server] <String>] [-ScanNumericals] [-Impersonation] [<CommonParameters>]
A quick walk-through on the parameters and switches:
So, for example assume you have a mailbox with en-US folders but also Dutch folders and the proper regional setting is en-US, use the following cmdlet:
.\Fix-MailboxFolders.ps1 –Mailbox Francis -Language nl-NL -FromLanguage us-EN –Impersonation
If you want to fix the folders of multiple mailboxes you can use a CSV file. The CSV needs to contain at least the Mailbox, but can optionally settings for Language and FromLanguage since the script will accept both through the pipe.
A sample of how the csv could look:
Mailbox,Language,FromLanguage francis,en-US,nl-NL philip,en-US,nl-NL
The cmdlet should then be something like:
Import-Csv .\Users.csv | .\Fix-MailboxFolders.ps1 -Language en-US -ScanNumericals -Impersonation –Verbose
Be advised that the script currently only contains en-US and nl-NL settings; you need to add additional language settings to the $LanguageInfo structure. The $LanguageInfo structure contains localized names for each of the well-known folders and has the following format.
"en-US"= @{
"Inbox"="Inbox";
"SentItems"="Sent Items";
"Notes"="Notes";
"Drafts"="Drafts";
"DeletedItems"="Deleted Items";
"Outbox"="Outbox";
"Contacts"="Contacts";
"Calendar"="Calendar";
"Tasks"="Tasks";
"JunkEmail"="Junk E-mail";
"Journal"="Journal";
"DateFormat"="M/d/yyyy";
"TimeFormat"="h:mm tt"
};
To increase readability I’ve created one setting per line in the script; everything could be stored on a single line of course. The values DateFormat and TimeFormat should be provided in a valid format for the related regional setting. Depending on feedback and demand, I can add additional languages to future versions of the script.
I will gladly take feedback on the script in the comments or through the contact form. If you want to start programming against Exchange Web Services yourself, I would highly recommend Glen Scales blog to look for PowerShell sample code.
Special thanks to co-worker Maarten Piederiet (Exchange 2010 MCM) for reviewing the initial version of the script (hence why the initial public version is 1.1).
You can download the script from the Technet Gallery here.
March 29th, 2013: Version 1.2 fixes loop condition when “Top of Information Store” is localized resulting in call depth overflow.
When creating a Database Availability Group (DAG) in Exchange 2010 or Exchange 2013 you leverage Fail-over Clustering from the operating system, e.g. Windows Server 2008 R2.
Behind the scenes Kerberos authentication is used, for which a so called Cluster Name Object (CNO) has to be created in Active Directory. This CNO will be associated with the Cluster Name Resource.
Depending on the situation, like having the ability to create computer accounts in the domain, you may need to create – or pre-stage – the cluster name object as computer account upfront. For Exchange 2013 on Windows Server 2012, pre-staging the CNO is a requirement. This manual task is described here.
However, there may be circumstances where having the ability to automate the process would be more appropriate, like when you want a fully automated setting up a DAG for example. For this purpose I have created a small script, Create-CNO.ps1. The syntax is as follows:
Create-CNO.ps1 [-Identity] <String> [[-Computers] <Array>] [[-OU] <String>
A small explanation of the available parameters:
So, for example assume you want to create a DAG called DAG001 and the first Mailbox Server will be L14Ex1. The computer object for the cluster is to be stored in the OU ou=Temp,dc=litware,dc=com. In that case, you would call the script as follows:
Create-CNO.ps1 –Identity DAG001 –Computers L14EX1 –OU “ou=Temp,dc=litware,dc=com” –Verbose
If you want to grant Exchange Trusted Subsystem permissions as well and let the script look up the CNO name, you can use:
Create-CNO.ps1 –Identity DAG001 –Verbose
You can download the script from the TechNet Gallery here.
