Configuring initial Exchange database

Something which I still see many Administrators do, right after installing Exchange 2010, is renaming the mailbox database or relocating the database or logs files that were created during the setup of Exchange 2010.

To configure the initial mailbox database name, the location of the initial mailbox database (and catalog) files or its log files, you can incorporate the following parameters in your setup command line:

  • MdbName is the name of the initially created mailbox database, e.g. MDB01
  • DbFilePath is the full path of the initially created mailbox database file, e.g. E:\MDB01DB\MDB01.edb
  • LogFolderPath is the folder used to store the database log files, e.g. D:\MDB01LOG
    Note that you must use the complete filename of the edb file, including the .edb extension. Also, you don’t need to create the folders; Exchange will do that for you during setup.

So, to setup Exchange with a custom initial mailbox database name and non-default locations of database and log files, you can use the following command line for example:

setup /mode:install /roles:c,h,m,t /mdbname:MDB01 /DbFilePath:E:\MDB01DB\MDB01.edb /LogFolderPath:D:\MDB01LOG

Of course, these parameters are nice to incorporate in your scripted setup to deploy multiple servers.

ManageScheduledTask.ps1 issue uninstalling Exchange

Today I encountered a strange issue when trying to decommission a DAG member, after properly removing it from the DAG as explained here, and checking services like address book generation server where hosted on one of the other DAG members.

I started the removal process from an elevated command prompt (using the GUI doesn’t work as it complains about the need to use setup.com, which I can’t since I’m using the GUI):

setup /m:uninstall

The output was the following:

Hmm. Without even looking at the Exchange setup log, I noticed there was something strange with the error message:

The term ‘C:\Program Files\Microsoft\Exchange Server\V14\Bin\ManageScheduledTask.ps1′ is not recognized as the name of a cmdlet, function, script file, or operable program.

As you probably know, all Exchange scripts are located in the Scripts folder, not the Bin folder.

I tried a quick and dirty fix, which was to copy the ManageScheduledTask.ps1 and ManageScheduledTask.strings files to the Bin folder, and again started setup /m:uninstall. This time, Exchange uninstalled nicely.

From experience, this isn’t expected behavior, but in case you encounter this problem in the field, you now know how you can easily work around this.

Microsoft Office Filter Pack 2010 SP1

Right after launching Office 365, Microsoft released Service Pack 1 for Microsoft Office 2010 (KB2460049) which includes Office 365 support besides a big list of fixes. For those interested, Office 2010 SP1 can be downloaded here (x86) and here (x64). For a full list of changes, check out Microsoft Office 2010 Service Pack 1 Changes Excel sheet.

More interesting for Exchange folks is that there’s also an SP1 for the Microsoft Office Filter Pack 2010, which of course you install during Exchange setup as one of the prerequisites. As you probably know, the Filter Pack is used to index Office documents stored in Exchange databases to speed up queries.

You can download Service Pack 1 for Microsoft Office Filter Pack 2010 x64 Edition here. The related knowledgebase article is KB2460041.

Exchange & Dynamic Memory : Don’t

With the arrival of Service Pack 1 for Windows Server 2008 R2, Dynamic Memory was introduced. In brief, Dynamic Memory is a memory management enhancement for Hyper-V which allows running virtual machines (VM) to allocate memory from the host and releasing it when possible, giving a minimum and maximum memory boundary. The main benefit is a higher VM density, because each VM will only allocate what’s required and you don’t have to approximate memory allocations.

Now this mechanism works well for many applications, but not for Exchange. Exchange’s goal – at least that of servers holding the mailbox role – is to claim as much memory as possible in order to cache information. This amount depends on the installed of memory (more information here). This cache is used for performance reasons, more cache means less I/O’s, less I/O’s result in better performance. You can guess what happens when you run Exchange with a minimal amount of memory and lots of dynamic memory configured, optionally shared with other Dynamic Memory-enabled VM’s. If Exchange starts up and wants to claim memory for caching or allocate memory for other reasons (transactions), instead of the memory being available instantly the host first needs to allocate it, or worse have other VM’s surrendering it their memory. That doesn’t make sense and will result in significant performance penalty.

Besides it being pointless to configure Dynamic Memory for Exchange, it’s also not recommended. From the Exchange 2010 System Requirements:

Many of the performance gains in recent versions of Exchange, especially those related to reduction in I/O, are based on highly efficient usage of large amounts of memory. When that memory is no longer available, the expected performance of the system can’t be achieved. For this reason, memory oversubscription or dynamic adjustment of virtual machine memory should be disabled for production Exchange servers.

Also, from the paper Implementing and Configuring Dynamic Memory, on applications that may not perform as well after Dynamic Memory is enabled:

  • Applications that perform their own memory management by taking over certain aspects of memory management from the operating system. Such applications typically grab as much memory as they possibly can in order to ensure the application’s best performance which can cause the amount of memory allocated to their virtual machine to grow until it reaches the amount specified by the Maximum RAM setting;
  • Applications where memory allocation is a one shot operation that is performed either when the application starts for the first time or each time the application starts.

Concluding, yes you can use Dynamic Memory for your lab or testing environment and it works. But don’t use it in production for Exchange Server.

Credits to Jetze who blogged about this originally here (Dutch).

Exchange Server 2010 Architecture poster

Finally, the long awaited Exchange Server 2010 Architecture Poster is here!

This is similar to the Exchange 2007 Component Architecture poster and contains the architecture highlights and feature set of Microsoft Exchange Server 2010. This architecture poster is additional to the already published Microsoft Exchange Server 2010 Transport Server Role Architecture Diagrams which you could already get here.

You can download the Microsoft Exchange Server 2010 Architecture poster here.

Exchange 2010 Endpoint Mapper Issue & Firewall

While upgrading one of my existing Exchange 2010 lab machines from RTM to SP1, I encountered the following error message during the upgrade:

Error:
The following error was generated when "$error.Clear();
          if (!(get-service MSExchangeADTopology* | where {$_.name -eq "MSExchangeADTopology"}))
          {
            install-ADTopologyService
          }
        " was run: "There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)".
There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)

The message appeared at the stage of upgrading the Unified Messaging components. I had a look at the ExchangeSetup.log file and it contained the the following information:

[08/27/2010 10:08:13.0948] [2] Beginning processing install-UMService
[08/27/2010 10:08:14.0011] [2] [WARNING] An unexpected error has occurred and a Watson dump is being generated: There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
[08/27/2010 10:08:14.0027] [2] [ERROR] There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
[08/27/2010 10:08:15.0823] [1] The following 1 error(s) occurred during task execution:
[08/27/2010 10:08:15.0823] [1] 0.  ErrorRecord: There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
[08/27/2010 10:08:15.0823] [1] 0.  ErrorRecord: System.Runtime.InteropServices.COMException (0x800706D9): There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
at Interop.NetFw.INetFwRules.Add(NetFwRule rule)
at Microsoft.Exchange.Security.WindowsFirewall.ExchangeFirewallRule.Add()
at Microsoft.Exchange.Configuration.Tasks.ManageService.Install()
at Microsoft.Exchange.Management.Tasks.UM.InstallUMService.InternalProcessRecord()
at Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord()
at System.Management.Automation.CommandProcessor.ProcessRecord()

It seems the error is caused while trying to add a firewall rule, indicated by Interop.NetFw.INetFwRules.Add (INetFwRules is the rules collection of the built-in Windows Firewall).

I had a quick check with the firewall settings on the machine and it turned out the Windows Firewall was disabled. I figured that perhaps adding the rules failed because setup couldn’t communicate with the firewall service.

I enabled the Windows Firewall and this time the upgrade process went fine:

[08/27/2010 10:23:10.0988] [2] Beginning processing install-UMService
[08/27/2010 10:23:11.0145] [2] Ending processing install-UMService

 

Exchange 2010 SP1 Beta Setup & Prerequisites

Many of us have been setting up and testing SP1 Beta in (I hope) lab environments. One of the nice additions to the setup process people reported is the option Automatically install Windows Server roles and features required for Exchange Server, shown during the Installation Type selection. Be advised that this option is – as stated – limited to Windows Server roles and underlying features only. You still need to install other possible prerequisites first, such as the 2007 Office System Converter. Also, the option doesn’t seem to work 100% in SP1 Beta, as I had to manually add IIS features like IIS7 Basic Authentication and IIS7 Windows Authentication.

Although this potentially saves us executing the well-known Add-WindowsFeauture cmdlets (2008 R2 or ServerManagerCmd in 2008 SP2, see this article), I hope Microsoft includes automatic installation of the additional prerequisite components in SP1 RTM as well. I expect it would be little trouble to include these components as well, accelerating the process of installing Exchange 2010 SP1 and rendering prerequisite installation scripts like this script from Pat Richard obsolete.

Note that Exchange 2010 setup also supports resuming. Nice when setup discovers a pending restart; resuming means you can reboot, start setup again and continue where you left off; no need to enter all the information again. More information on resuming setup and watermarks here.

Note that I’ve been installing Exchange 2010 SP1 Beta on Windows Server 2008 R2 only so far, so on Windows Server 2008 SP2 your mileage may vary.