Adding an Additional Distribution Group Manager/Owner

In Exchange 2010 a group owner/manager is modified by using Set-DistributionGroup with the ManagedBy parameter. You can also configure this parameter in the Exchange Management Console in the properties of the group. Only users can be listed here, not groups. However, you can add multiple users.

If you are updating only a single distribution group then the graphical interface in the Exchange Management Console works well. If you have many distribution groups to update then you will probably be scripting the process in the Exchange Management Shell.

In the Exchange Management Shell, you allow multiple managers of a distribution list by including them as a comma separated list as shown below:

Set-DistributionGroup Accounting -ManagedBy Jeff,Susan

However, it becomes a bit more complicated if you want to add a new person as a group manager. Overall, you need to obtain the list of current managers in a variable, add the new user, and then set the ManagedBy parameter using the entire array. If you specific just a single user then the existing list is overwritten. Let's take a look at the process.

First, obtain the current list of managers:

$Grp=Get-DistributionGroup "All Company"
$List= $Grp.ManagedBy

The next bit is a little tricky. The $List variable is an array of Active Directory objects. You can verify this by displaying the contents of the $List variable as shown below.

If you attempt to just add a name to the $List array, it won't work because the name is treated as a string rather than the name of an Active Directory object. So, instead you need to create another variable with the Active Directory object of the user you want to add. The example below shows how put the Active Directory object for Anna in the variable $New and then add it to the existing $List array. If you are scripting this, the name "Anna" can be replaced with a variable containing the name of the user. The variable can be populated from a csv file.

$New=Get-User Anna
$List+=$New

If you display the contents of the $List variable, you can see that Anna has been added. The object is different from the original two objects, but it is similar enough for the Set-DistributionGroup cmdlet to accept it.

Finally, we can set the ManagedBy for the group:

Set-DistributionGroup "All Company" -ManagedBy $List

I should also note that while there is no built in functionality for a security group to manage a distribution list, you can fake it by using these instructions provided by the Exchange Team at http://blogs.technet.com/b/exchange/archive/2011/05/04/how-to-manage-groups-with-groups-in-exchange-2010.aspx.

SBS 2008 Monitoring Database Problems

I've run into performance issues on SBS 2008 servers related to the monitoring database. I've noticed this issue as a disk access issue when a server is slow. From Resource Monitor, sorting processes under Disk by the Read Bytes has the SBSMonitoring.mdf file with far more activity that other sources. Typically processor and memory utilization are OK, but not necessarily.

Two separate issues can be the source of the problem:

• SBS Monitoring database is too large and is using large amounts of disk space. If so, check this out: http://blog.korteksolutions.com/the-sbsmonitoring-database-is-nearing-maximum-size-on-sbs-2008/. I used the downloadable new database from this location and it worked great.
• Missing indexes in SBS Monitoring database cause high disk and maybe processor activity. If so, check this out:  http://social.technet.microsoft.com/Forums/en/smallbusinessserver/thread/d195baac-da8b-4387-9079-c55d5e1879b4

10135 Exchange 2010 Admin - Useful Links

Each time I teach the Microsoft 10135 Configuring, Managing, and Troubleshooting Microsoft Exchange Server 2010, the students are trying to write down all the sites I show. This is a pain for all of them. So, here is a list of the sites I have noted in my manual along with relevant pages.

• Companion MOC with zip of discussion answers (old CD content): http://www.microsoft.com/learning/en/us/training/companionmoc.aspx
• 1-19, Exchange 2010 pricing: http://www.microsoft.com/exchange/en-us/pricing-exchange-server-email.aspx
• 1-19, Exchange 2010 licensing: http://www.microsoft.com/exchange/en-us/licensing-exchange-server-email.aspx
• 1-27, Exchange 2010 installation prerequisites: http://technet.microsoft.com/en-us/library/bb691354.aspx
• 2-22, Large Exchange databases should be 64KB NTFS blocks: http://blogs.technet.com/b/mikelag/archive/2011/02/09/how-fragmentation-on-incorrectly-formatted-ntfs-volumes-affects-exchange.aspx
• 2-23, Mailbox Requirements Calculator:  http://gallery.technet.microsoft.com/v144-of-the-Exchange-2010-1912958d 
• 2-25, Exchange Server 2010 Design and Architecture at Microsoft: http://technet.microsoft.com/en-us/library/ff829232.aspx
• 2-37, ExFolders for graphical administration of public folders: http://gallery.technet.microsoft.com/Exchange-2010-SP1-ExFolders-e6bfd405
• 3-14, Migrating Resource Mailboxes from Exchange 2003 to Exchange 2010: http://technet.microsoft.com/en-us/library/bb232130.aspx
• 3-39, Filterable properties for get-user and more: http://technet.microsoft.com/en-us/library/bb738155.aspx
• 4-57, Supported features for versions of ActiveSync (both have different client versions): http://en.wikipedia.org/wiki/Comparison_of_Exchange_ActiveSync_Clients and http://social.technet.microsoft.com/wiki/contents/articles/exchange-activesync-client-comparison-table.aspx
• 5-27, Anonymous relay connector: http://technet.microsoft.com/en-us/library/bb232021.aspx
• 6-37, SPF Record Wizard: http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard
• 7-22, More RPC client access array info: http://blogs.technet.com/b/exchange/archive/2010/05/20/3409978.aspx
• 12-19, Common Outlook 2003 issues with Exchange 2010: http://msexchangeteam.com/archive/2010/04/23/454711.aspx

Objects Available to the Scripting Agent

The Scripting Agent uses $ProvisioningHandler and $readOnlyIConfigurable to represent objects available during an action. I could not find any documentation on these objects and did some experimentation. The following is my results:

• The variable $ProvisioningHandler contains information about the cmdlet being executed. This includes  the name of the cmdlet, parameters for the cmdlet, and the user that ran the cmdlet.
• The name of the cmdlet is stored in $provisioningHandler.TaskName
• The user running the cmdlet is stored in $provisioningHandler.UserScope.UserID
• The parameters passed to the cmdlet are stored in $provisioningHandler.UserSpecifiedParameters[“PName”] where PName is the name of the parameter that was passed. For example, Identity and Alias are common parameter names that would be used in place of PName.
• The variable $readOnlyIConfigurable contains the properties of the object being acted upon. For example, when using the Set-Mailbox cmdlet, $readOnlyIConfigurable contains the object for the mailbox being modified. The values listed are those about to be applied, not the current values of the object.
• The content of these variables can change depending on the ApiCall being used. For example, when using the Validate ApiCall the $readOnlyIConfigurable variable is populated but when using the OnComplete ApiCall the $readOnlyIConfigurable variable is empty. I’ve not tested all of the possible permutations.

The following example of ScriptingAgentConfig.xml shows how you can check the data available to you for various cmdlets:

As far as I can tell, it is not possible to have actions of the Scripting Agent displayed on the screen. However, you can have it dump to text file as shown in the example. I also attempted to get more information about the objects by using Get-Member, but no information was returned. You can modify this example to see what information is available for each of ApiCall options and different cmdlets. Each time you run it, any previous text files are overwritten.

ScriptingAgentConfig.xml Syntax

The Scripting Agent for Exchange 2010 SP1 uses ScriptingAgentConfig.xml to define additional content used when running specified cmdlets. This file needs to be located in in C:\Program Files\Microsoft\Exchange\v14\Bin\CmdletExtensionAgents. This file uses the following generic format:

Line 1 <?xml version “1.0” encoding=”utf-8”?>

Line 2 <Configuration version=”1.0”>

Line 3 <Feature Name=”YouPickName” Cmdlets=”CsvList”>

Line 4 <ApiCall Name=”NameOfAPI”>

Line 5 The script goes here

Line 6 </ApiCall>

Line 7 </Feature>

Line 8 </Configuration>

Description of example:

• Line 1 defines the version of XML . This line is always here and always the same.
• Line 2 opens the configuration tag. The configuration tag exists once in the file.
• Line 3 opens the feature tag. There can be multiple feature tags in the file. Each feature tag has a name that you define. The name needs to be unique, but can be anything that makes sense to you. Each feature tag also has a list of cmdlets that it applies to. If the feature applies to multiple cmdlets the they are separated by commas.
• Line 4 opens the ApiCall tag. This defines how/when the following script is used. The name defines the ApiCall that is used. Valid values are: ProvisionDefaultProperties, UpdateAffectedIConfigurable, Validate, and OnComplete. Multiple ApiCall tags can be used in each feature tag.
• Line 5 the script within the ApiCall tag is run when defined by the ApiCall name used. This is a PowerShell script that is typically short, but can be complex. It can include ligic structures such as if statements. It can also use data in the ProvisioningHandler and IConfigurable objects. These objects contain information about the request.
• Lines 6-8 close the open tags started in Lines 2-4. Notice that these tags are nested and the last tag to be opened is the first tag to be closed.

You can also use the <Common> </Common> tag to define functions that are used by scripts within multiple feature tags. The common tag is placed inside the configuration tag at the same level as the feature tag, but not inside the feature tag.

I suggest liberally using comments within your xml file to document what each section is doing. For a single line the # symbol designates a comment. Block quotes are done by placing content within <!--   -->.

I will be posting some specific examples with explanations. You can also view the example file that comes with Exchange 2010 sp1 at C:\Program Files\Microsoft\Exchange Server\V14\Bin\CmdletExtensionAgents\ScriptingAgentConfig.xml.sample.

Customize Exchange Cmdlets

There have been many times in class when students have asked me if there is a way to change default settings in Exchange 2010 when perform task such as creating users. If you had asked me two weeks ago, my answer would have been: “Nope. You’ll need to modify those users after you create them.” Turns out I was wrong.

Exchange 2010 SP1 includes a component called the Scripting Agent. The Scripting Agent lets you define scripts that run when specific cmdlets, such as New-Mailbox, are used. Since the Exchange Management Console (EMC) runs cmdlets in the background, this will apply there too.

First you need to enable the Scripting Agent:

Enable-CmdletExtensionAgent “Scripting Agent”

Next, you need to create an XML file that defines the scripts to be run and for which cmdlets. The file must be named ScriptingAgentConfig.xml and located in C:\Program Files\Microsoft\Exchange\v14\Bin\CmdletExtensionAgents.  I’ll post some examples later. In this post I will limit myself to describing generally what it can do.

Each time a cmdlet is used, the ScriptingAgentConfig.xml file is checked to see whether there is a script defined for the cmdlet. If there is a script defined for the cmdlet, it is executed. There are four ways a script can be run. The documentation refers to these ways as APIs.

• ProvisionDefaultProperties. This is exactly what you think it is. It lets you define default values for cmdlets parameters. For example, you could specify a default OU when creating new users. If a user running the cmdlet provides values, they override the defaults that you provide with this API.
• UpdateAffectedIConfigurable. Instead of providing defaults, this will overwrite values provided by the user running the cmdlet.
• Validate. This API is called just before the cmdlet writes data. The intent of this is to validate data that is being written before it is actually written. Your script provides the validation. If the script runs without errors, then the cmdlet proceeds to write data. Otherwise, your script needs to generate the error if the conditions you specify are not met. For example, you could verify that a valid database has been specified for a new mailbox to prevent it from being randomly assigned to a database.
• OnComplete. This API is called after the cmdlet is complete. This provides you with an opportunity to modify setting related to the original cmdlet, but not part of the original cmdlet. For example, after creating a new mailbox, you could set calendar settings that are not possible with the New-Mailbox cmdlet.

After you create ScriptingAgentConfig.xml, you need to copy it to all of your Exchange 2010 SP1 servers.

Microsoft provides some very limited documentation here: http://technet.microsoft.com/en-us/library/dd297951.aspx

Exchange 2010 Management Pack for SCOM

In April 2011 Microsoft released an updated management pack for System Center Operations Manager (SCOM) and Exchange Server 2010. The new version of the management pack is designed for Exchange 2010 SP1 and should be implemented by anyone monitoring Exchange Server 2010 SP1.

The installation of the management pack is fairly well documented, but for some reason I found it difficult to pull out the information that was relevant to me. So, here is my summary of important points for implementing the Exchange Server 2010 Monitoring Management Pack (http://www.microsoft.com/download/en/details.aspx?id=692)

• SCOM 2007 R2 should be at minimum cumulative update 1 (KB974144) . There is a different patch level for SCOM 2007 SP1 (KB971541).
• The SCOM agent installed on the Exchange servers should be at minimum rollup update 1.
• SCOM agents need on the Exchange servers need to have the Agent Proxy enabled on the Exchange servers will not be discovered properly.
• The management pack is distributed as an MSI file. When you run the MSI file, it installs the correlation engine and unpacks the management pack files that need to be imported into SCOM (C:\Program Files\System Center Management Packs). This should be done on the root management server.
• There are 32-bit and 64-bit versions of the management pack. You should use the appropriate version based on the version of Windows that you are running.
• The documentation of the previous version of this management pack referenced preventing Exchange 2010 DAG members from being monitored as a cluster. This was not required at that time and the reference has been removed from the documentation in this version.
• The management pack runs many TEST-* cmdlets as part of monitoring Exchange 2010. Some of these will fail if test mailboxes have not been created by running New-TestCasConnectivityUser.ps1. This should be done for each Active Directory site you want to monitor.
• You cannot override alerts generated by this management pack. You must use the health explorer to identify the monitor that is causing the alert and override the monitor. Generally you should override only for specific servers or groups rather than disabling the monitor.
• A new monitor is created that monitors the version of SCOM agent for all servers. This monitor identifies any server that does not have the minimum version of SCOM agent required by the management pack and generates an alert. It is preferred to update the SCOM agent on all servers to prevent this from happening. However, you can also modify the monitor to apply only to Exchange servers as per this blog posting: http://anandthearchitect.wordpress.com/2011/04/02/scom-critical-hotfixes-required-for-reliable-operation-of-the-exchange-server-2010alerts-on-wrong-servers/.

*As a note, I'm told that the product group for Operations Manager hate the acronym SCOM, but for some reason I can't help myself.

Static RPC Ports for Exchange 2010

By default Exchange 2010 uses a dynamic range of ports for RPC communication between Outlook clients and CAS servers. In most cases, dynamic ports are fine. However, you may want to configure static ports if there are firewalls between the clients and the CAS servers or to optimize load balancing. I was recently part of a project where we set static ports to optimize and simplify load balancing.

You can configure static ports for RPC client access, the address book service, and public folders.

A few notes to be aware of:

• The registry key for the address book is a string (REG_SZ) not a number (REG_DWORD).
• The registry key for public folders needs to be configured on the Mailbox server with the public folder database because clients communicate directly with the information store to get public folder data.
• The ports for RPC client access and the address book service are configured on CAS servers. All CAS servers should be configured with the same port to support load balancing.
• The method for changing the address book static port changes from Exchange 2010 RTM and SP1. The value from RTM is not retained when SP1 is installed.
• You can verify the static ports have taken effect by using netstat or Resource Monitor. Both of these utilities allow you to view listening ports and the executable that is listening.

This article has the details about which registry keys need to configured:  http://social.technet.microsoft.com/wiki/contents/articles/configure-static-rpc-ports-on-an-exchange-2010-client-access-server.aspx