# Exchange 2013 Server Role Requirements Calculator 5.6

Only 10 days after the release of the first public version of the Exchange 2013 Server Role Requirements Calculator, the calculator gets an update. The new version number is 5.6.

Changes since version 5.1:

• Optimized Volume Design Architecture Formula
• Fixed Recommended Min Number of GC Cores (Secondary Datacenter)” calculation to use SDC instead of PDC CAS count.
• Fixed CPU comments and removed erroneous information.
• Fixed multiple conditional formatting bugs.
• Fixed problem where this workbook had to be the active workbook at all times.
• Fixed problem with extra-wide Fail Server button on the distribution worksheet.
• Enabled variable based tracing.
• Resolved VBA Divide by Zero error caused by DiskGroup = 0.
• Fixed problem with lagged copies in conjunction with multiple databases per volume.
• Fixed missing “\” character in path names in MailboxDatabases.csv file.
• Fixed problem with WAN failure simulation.
• Fixed calcNumAMBXServersDC2 to ensure it cannot have more servers that primary site.
• Fixed calculated IO Multiplication factor formulas to take into consideration IOPS override.
• Added condition to validate that there are enough copies for multiple databases/volume scenario.
• Fixed conditional formatting and JBOD storage results when JBOD evaluation is disabled.

# Exchange 2013 Server Role Requirements Calculator v5.1

It’s been long wait since the release of Exchange 2013, but today the Exchange Team finally released the first version of the Exchange 2013 Server Role Requirements Calculator. This initial release is numbered version 5.1.

Some of the highlights over the Exchange 2010 calculator, mostly due to changes in the architecture, are:

• The calculator includes transport sizing (hence the name, I guess);
• Accommodating for Client Access Server role with sizing for multi-role server deployments;
• Support for multiple databases / JBOD volumes;
• Configurable witness server location (primary, secondary or tertiary data center);
• Configurable server names and database prefixes for generated scripts;
• Generated scripts include script for DAG creation;
• Support for single HA, Act/Pas and Act/Act distribution models.

# Exchange 2013 Unattended Installation Script v1.1

Coming back from a nice vacation to the beautiful Brittany in France, I thought it was time to collect and process feedback and suggestions on several scripts, starting with the Exchange 2013 unattended installation script for Windows Server 2012.

Changes in version 1.1 of the script:

• When the script was used to also prepare Active Directory, RSAT-ADDS-Tools was uninstalled as part of the cleanup. Per request, I’ve removed the uninstallation of that feature;
• The script now detects pending reboots after installing the required features. When ran in AutoPilot mode, the script will reboot and restart the phase (preparing Active Directory, which can’t be run with pending reboots because Exchange’s Setup won’t like it). When not running in AutoPilot mode, you need to start the script manually. You can omit providing installation parameters as they are saved, even a pending is detected;
• The Windows feature Server-Media-Foundation will be installed explicitly as it is an UCMA 4.0 requirement;
• The credentials provided for AutoPilot mode will be validated;
• The OS version check is changed to a string which should enable installation on non-US Operating Systems.

You can download the updated version of the script via the original Exchange 2013 Unattended Installation Script page or directly from the Technet Gallery. Enjoy!

# Exchange 2013 CU1 Help File

A quick post as the Exchange 2013 Cumulative Update 1 Help file (.CHM) file for offline usage has been released on the Microsoft Download Center.

The offline help files files are convenient if you’re on the road or in a location (yes, that happens sometimes) without internet connection.

You can download the Exchange 2013 Cumulative Update 1 .CHM Help file dated April 4th, 2013 for On-Premise and Hybrid deployments here.

# Exchange 2013 CU1 ETA: April 2nd

Today the Exchange Team announced postponing the release of Exchange 2013 Cumulative Update 1 for a few more days. Originally, CU1 was scheduled for Q1 2013, but the date has been set now at April 2nd, 2013.

While it may sound disappointing when you’re waiting for Exchange 2013 RTM CU1, it makes sense to postpone it a bit. As the team indicated,the time is used to add functionality required for coexistence scenarios with Exchange Server 2010 which otherwise had to be put in an update for Exchange 2010 Client Access servers. I expect people to be less happy as Exchange 2010 Service Pack 3 was heralded as the Exchange 2010 product level for coexistence support with Exchange 2013 (running CU1).

Also, looking at time frames involved with testing and accepting updates in production environments, I personally applaud this decision as putting that code in Exchange 2013 at the cost of a few days may in the end be faster than adding that code to Exchange Server 2010, requiring customers to initiate test an acceptance tracks for production updates.

So, until further notice we’ll have to wait just a few more additional days to see what Cumulative Update 1 will bring us.

# New-MoveRequest fails with “Database .. doesn’t exist”

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.

# Jetstress 2013

In the list of expected products to accompany Exchange 2013, Microsoft today released JetStress 2013, version 15.0.651.0.

Jetstress is your tool of choice to check the performance and stability of your storage design under load. It simulates Exchange I/O behaviour using Exchange 2013 patterns allowing you to verify dimensioning and validate performance expectations from a database perspective.

To run JetStress 2013 you need:

• .NET Framework 4.5
• ESE.DLL, ESEPerf.dll, ESEPerf.ini, ESEPerf.hxx (copy these from an Exchange 2013 installation source)

Note: The installer currently installs a shortcut named “Exchange JetStress 2010″, but it really is JetStress 2013.

# Exchange 2013 Unattended Installation Script (Updated)

I’m pleased to announce the availability of Install-Exchange2013.ps1, a PowerShell script to perform a fully unattended setup of Exchange Server 2013 RTM or CU1.

The script takes care of:

• Installing required Windows Server 2012 features and optionally prepare Active Directory (phase 1);
• Install Exchange Server 2013 prerequisites (phase 2);
• Optionally install Exchange Server 2013 (phase 3)
• Optionally – depending on phase 3 – perform post-configuration (phase 4, tailor to your own needs);
• When done, the script will perform some cleaning up, like removing the state file and setting the startup of Transport Service to Automatic (phase 5).

Usage
This script version requires a domain-joined Windows Server 2012 system, an account to perform the installation (and optionally prepare Active Directory) and the location where the Exchange Server 2013 installation files are stored (e.g. an UNC path).

The syntax is as follows:

Install-Exchange2013.ps1 [-InstallCAS] [-InstallMailbox] -SourcePath <string> [-Organization <string>] [-MDBName <string>] [-MDBDBPath <string>] [-MDBLogPath <string>] [-InstallPath <string>] [-TargetPath <string>] [-AutoPilot] [-Credentials <pscredential>] [-NoSetup] [<CommonParameters>]

A short description of the parameters:

• Organization (optional): Specifies name of the Exchange organization to create. When omitted, the step to prepare Active Directory (PrepareAD) will be skipped.
• InstallMailbox: Specifies you want to install the Mailbox server role.
• InstallCAS: Specifies you want to install the CAS role.
• MDBName (optional): Specifies name of the initially created database.
• MDBDBPath (optional): Specifies database path of the initially created database (requires MDBName).
• MDBLogPath (optional): Specifies log path of the initially created database (requires MDBName).
• InstallPath (optional): Specifies (temporary) location of where to store prerequisites, transcript and state file. Default location is C:\Install.
• NoSetup (optional): Specifies you don’t want to perform Exchange setup.
• SourcePath: Specifies location of the Exchange 2013 installation files (setup.exe).
• TargetPath: Specifies the location where to install the Exchange 2013.
• AutoPilot (switch): Specifies you want to automatically restart, logon using credentials specified and continue the installation. When not specified, you will need to restart, logon and start the script manually each time (without parameters).
• Credentials (optional): Specifies credentials to use for automatic logon. Use DOMAIN\User or user@domain. When not specified, you will be prompted to enter credentials.

Note that the script uses an XML file to store the (original) parameters used to start the script but also to keep track of the the process. Of course, if required, you can use predefined XML files to run the script without parameters.

Note that when not present, the script will try to download the prerequisites from the internet. When that isn’t possible or to save bandwidth, you can put them in the location defined by InstallPath and the script will detect and use them.

For example, assume we want to start a fully unattended install of an Exchange Server 2013 Client Access server, using a network location for the Exchange Server 2013 source files. After setting the Execution Policy to Unrestricted and storing the script locally, we start the script using:

 .\Install-Exchange2013.ps1 –InstallCAS –SourcePath ‘\\server\share\isos\Microsoft\Exchange2013\mu_exchange_server_2013_x64_dvd_1112105’ –AutoPilot –Verbose

The script will perform some checks and since AutoPilot was specified without using the Credentials parameter, the script will ask for credentials.

After entering the credentials, the required features will be installed. Since OrganizationName wasn’t specified, Active Directory preparation will be skipped.

After rebooting, the system will automatically log on using the credentials specified earlier and start the script (RunOnce registry key is utilized for this purpose). It will read the last known state from the XML file and will continue with the next phase, which is downloading (when not present) and installing the Exchange prerequisites.

Next, after rebooting and the automatic logon, Exchange will be installed from the source location.

When done, the system will perform post configuration and finalization steps including reboots and logons. Note that it may seem like a lot of reboots, but rebooting after installing Windows features and Exchange prerequisites is required anyway so I put reboots after the other milestones as well.

Revision History
1.02: Fixes AD preparation logic and adds checks to see if domain is in native mode. It also fixes a small typo in the post-prepare AD function.
1.03: Tested against Exchange Server 2013 CU1, replaced installing OS features manually by using /InstallWindowsComponents and removed installation of Office Filtering Pack (routines still there because they’re required for the Exchange 2010 SP3 version I’m working on).
1.1: When AD was prepared, RSAT-ADDS-Tools won’t be uninstalled, pending reboot detection (in AutoPilot, script will reboot and restart phase), installs Server-Media-Foundation feature (UCMA 4.0 requirement), validates provided credentials for AutoPilot and checks OS version as string (should accommodate non-US OS).

# Sent Items Management

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:

• From mailbox: The sent item will be stored in the Sent Items folder of the (shared) mailbox;
• Sender and From mailboxes: The sent item will be stored in the Sent Items folder of the (shared) mailbox and actual sender;
• Sender mailbox: The sent item will be stored in the Sent Items folder of the actual sender (default).

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 2013 Cumulative Updates and You

Few days ago, the Exchange Team published their intentions for Exchange 2013 regarding update schemes (or as Microsoft calls it, servicing). While the article describes the policy with a Q&A section at the bottom, there are still some grey areas. In this blog, I’d like emphasize on some elements and point out those grey areas.

As you probably read before, with Exchange 2013 the Rollup packages will be replaced by Cumulative Updates (CU), a name change probably inspired by Lync’s Cumulative Update packages. But it’s more than just a name change and admins or people involved managing releases should become familiar with the new policy as it will have some features that you don’t want to get surprised by.

One of the major changes in my opinion is that there will be one team working on the product; code bases for on-premises Exchange and Exchange Online (Office 365) will brought up to par. A small change is that Microsoft will first implement – or dogfood – the Cumulative Update in their Office 365 environment after while it will be made available for on-premises or hybrid deployments. While this may improve the quality of the Cumulative Update, not all kinds of deployments will be tested so it’s no warranty. However, looking at the current situation with Office 365, it may put stress on Microsoft procedures as there are already big variations between the various regions regarding Exchange Online implementations as well as Exchange Online and the on-premises version.

It’s the intention Cumulative Updates will be released on a quarterly basis. Each Cumulative Update will consist of a full installation set, so for example you can install Exchange 2013 Cumulative Update 2 straightaway whereas with Rollups you had to implement the Service Pack level prior to applying the related Rollup. So, this is a big convenience when for example installing greenfield scenarios or adding systems.

However,  unlike Rollups you can’t uninstall a Cumulative Update once it has been installed. This could worry people, looking back at the qualify of some past Rollups which were pulled, rereleased and in some rare cases pulled and rereleased again. But since Microsoft will now implement Cumulative Updates first, bad Cumulative Updates will become Microsoft’s problem first, not yours as it seemed to few people with some of those Rollups.

Security updates will become Cumulative Update bound, meaning they are to be installed on a specific Cumulative Update. However, there can be two supported Cumulative Update “active” at a time, so I assume security updates can be installed on both (unless Microsoft will be making two versions of each security update). The next Cumulative Update will include security updates released since the previous Cumulative Update was released. However, it might be that security updates won’t make it in the a cumulative update because of the freeze period, the period before releasing the Cumulative Update when no more updates will be added, and one needs to wait for the Cumulative Update to be released or install the security update, wait for the Cumulative Update, install the Cumulative update and reinstall the security update, in which case you might prefer waiting for the Cumulative Update. Some might rushing (security) updates won’t harm you, but remember KB2624899 fixing the IE9/MMC issue, the initial EX2010SP2RU5 which caused DAG issues or KB2750149 which broke the WS2012 Fail-over Cluster snap-in and required KB2803748 to fix the issue. Yes, Microsoft will implement Cumulative Updates first but this will also raise the expectations set on Microsoft’s internal Quality Control enormously. They don’t want to end up in a situation releasing a faulty Cumulative Update to public, since it will be impossible to uninstall. Then again, nobody said Cumulative Updates would make the best practice of testing and accepting updates before implementing them in production environments obsolete.

A major change is that Cumulative Updates will be supported for 3 months after the next Cumulative Update is released. Because Cumulative Updates are to be released quarterly, this sets the support-window of a Cumulative Update (or plain, non-Cumulative Update) to 6 months. This may seem long, but I know a lot of companies will have an issue with this window because their test and acceptance periods easily transcends half a year, especially if schema updates are involved (yes, Cumulative Updates can require schema updates). And don’t forget about cases where customers adopted  a building block model where they will need to test that Cumulative Update against their Operating System building block with all the additional components, like Anti-Virus, Backup agents or Management software involved.

Finally, an odd element in this scheme are the Service Packs of which Microsoft said they will be getting released. But where in the past only Service Packs could embed Active Directory schema updates, that’s also something a Cumulative Update might require, making Service Packs effectively an Über Cumulative Update.