Test-ECPConnectivity, as the name suggests, tests the connectivity to the Exchange Control Panel virtual directory. It is one of the many test cmdlets which needs a test account to be created prior to running the test. The error below will be shown if the test account is not present.

As mentioned in the error, run the New-TestCASConnectivityUser.ps1 script from the scripts directory and specify a complex password for the test account to be created. Read this article if you get an error while running the script.

The test cmdlet can be executed with a number of parameters, like

• the CAS server to be tested ( all CAS servers are tested if one isn’t specified) Test-ECPConnectivity –ClientAccessServer servername
• the mailbox server to be tested against (all mailbox servers are tested if one isn’t specified) Test-ECPConnectivity –MailboxServer servername
• to trust any SSL cert, Test-ECPConnectivity –TrustAnySSLCertificate
• to run the test for internal / external urls, Test-ECPConnectivity –TestType Internal

The last test in the screenshot has failed, the test for checking the external urls. Looking more into the test result tells me that the url is not resolvable.

After creating an “A” record in DNS, the test succeeded. This test illustrates how to check for problems & fix issues using the test cmdlet.

Part one, two, and three of the series, if you haven’t already read it.

Test-SystemHealth cmdlet speaks for itself. It checks the health of the system from the Exchange Shell. It is pretty much running Exchange Best Practice Analyzer from the command prompt. And yes, it does download the the latest configuration files from the internet every time you run the command.

Execution of the command downloads the latest configuration files, collects info about your server, analyses against Microsoft best practice and gives you an output. You need to run the command locally on the server you want to check. There is no “server” parameter yet to run the command against a remote machine.

Running Test-SystemHealth cmdlet tries to connect to the internet as shown.

Once the latest config files are downloaded, it runs through a set of tests based on the Exchange role.

And finally the output with recommendations, warnings and errors.

It is complaining about the lack of 3rd party cert, filter packs etc in my case. Since it is a lab server, I am not too worried about it. You can tell the cmdlet not to download the config files (say if you don’t have connection to the internet from the Exchange server). Run Test-SystemHealth –DownloadConfigurationUpdates:$false

A simple cmdlet which does the job, although option to check against remote servers would be nice!

Part one & two of the series, if you haven’t already read it.

Test-MAPIConnectivity is the second cmdlet that comes to my mind, which will be very useful in troubleshooting outlook connectivity. The cmdlet verifies server functionality and can test the ability to log on to a specific mailbox (or system mailbox if a mailbox is not specified), the ability to log onto the system mailbox on a specified database and the ability to log onto each system mailbox on a specified server.

In short, the cmdlet takes three parameters to check the connectivity – database, server and identity of mailbox.

Run Test-MAPIConnectivity –identity “domainuser” to check whether the mapi connection is working properly.

Running Test-MAPIConnectivity –identity “domainuser” –MonitoringContext $true will include monitoring events and performance counters in the output.

Run Test-MAPIConnectivity –Server “servername” to check connectivity to the server and Test-MAPIConnectivity –Database “databasename” to check database connectivity. The monitoring context parameter can be used in both cases.

Read part one of the series here

Test-ServiceHealth – the cmdlet name speaks for itself. I was at a customer site yesterday and the fact that the 3rd line engineers didn’t know anything about the test cmdlets in Exchange 2010 has motivated me to write a series of 28 articles, describing each test cmdlet, what it does and how to use it. The first one that comes to my mind is Test-ServiceHealth, a very essential & easy tool to check whether your Exchange services are running as expected.

Test-ServiceHealth cmdlet checks the state of the Exchange services running on the server and outputs whether all the required services are running or not. If a service is not running, it will show you which one it is. If you have a server with different roles, it will check the services for each role and report based on the roles.

Though the cmdlet outputs everything we need, we can customize the syntax with exactly what we need (to know whether all required services are running). Test-ServiceHealth | ft Role, RequiredServicesRunning –autosize gives you a better output.

You can query the service state on a different server by specifying the server name after the “server” parameter. The syntax is Test-ServiceHealth –Server servername | ft Role, RequiredServicesRunnning –autosize.

What if you want to see whether the required services are running on all servers you have? The cmdlet doesn’t output the server name and hence a small script is required.

$servers = Get-ExchangeServer

ForEach ($server in $servers) { Write-host “Server Name is” $server.name; Test-ServiceHealth $server | ft Role, RequiredServicesRunnning –autosize }

The title seems simple enough and it is, if the right syntax is used. Removing a CAS array can be performed using the Remove-ClientAccessArray cmdlet. Anyone would think that the identity parameter that follows the remove command will be the name of the CAS array. But no, the identity parameter is looking for the FQDN of the CAS array.

Surprisingly, the TechNet documentation is wrong as well.

I have a CAS array named “HEW CAS Array” with an fqdn outlook.exchangemaster.me.

Running Remove-ClientAccessArray –identity “HEW CAS Array” (as mentioned in TechNet) gives the error shown below.

The correct syntax is Remove-ClientAccessArray –identity “fqdn of cas array”. The identity parameter is optional though.

Hopefully Microsoft will update the article soon

Microsoft has released a word document which explains all the AD schema changes for Exchange 2010 SP2 to install and work properly. Download the doc here. To my surprise, the same doc has all the AD schema changes for Exchange 2007 & 2003.

Though the doc is only 1mb in size, it is packaged in an msi file, which needs to be installed.

Once the installation of the package is complete, the doc is available.

An issue that came my way in response to System Mailboxes in Exchange 2010 & How to recover them is that the exchange admin can’t find any of the arbitration mailboxes while running Get-Mailbox –Arbitration. The command runs without any errors, but doesn’t bring the arbitration mailboxes back. The accounts are in AD and are visible.

The issue was that the environment had a root domain and multiple child domains. The arbitration accounts are in the root domain by default and the Exchange Shell session was only looking at the child domain. To fix the issue, you need to run the following command, so that the scope of the search is changed to the forest level.

Set-ADServerSettings –ViewEntireForest $true

Once the above command is run, Get-Mailbox –Arbitration gives the correct output.

The exchange setup creates a default discovery mailbox, which will be enough for small organizations. For large companies, they may need multiple discovery mailboxes as the searches are performed frequently and the results are kept for a longer period of time.

Creating a new discovery mailbox is simple enough. Run the command below in Shell (you can’t use EMC).

New-Mailbox “Discovery Mailbox 2” –UserPrincipalName discoverymailbox2@domain.local –Discovery

The key is that the switch “-discovery” needs to be added. Apart from that, the command is the same as creating a new user mailbox.

Once the mailbox has been created, you need to assign full access to the “Discovery Management” group. It is easy enough to do it from the console. Right click the mailbox, select “Manage Full Access Permission” and add the group.

A question that came my way – Does Office 2010 filter pack (known as IFilters) be registered after installing Exchange 2010 SP1? The setup of 2010 SP1 requires you to install Office 2010 filter packs (it flags a warning if it is not installed). If the setup is run after installing the filter pack, you don’t have to do anything more. The 2010 SP1 setup registers the IFilters with Exchange search.

But, with 2010 RTM installation, the filter packs had to be registered manually (either by editing the registry or running a PowerShell script provided by Microsoft). It is recommended to install the latest 2010 filter pack (2010 SP1) while deploying Exchange 2010 SP1.

One more task that Exchange setup takes care for you

I got this question via email yesterday – What is the reason to have an additional throttling policy in an environment that has Blackberry Server? The simple answer is – because of the client throttling policy introduced in Exchange 2010.

Let me explain. When Exchange 2010 gets installed, it configures a default client throttling policy. The intention of introducing the policy is to throttle the different type of client connections (OWA, ActiveSync, MAPI etc) when the limits (like number of active sessions) goes over the values specified in the policy. Get-ThrottlingPolicy gives you all the limits configured.

The value that we are interested in is RCAMaxConcurrency, which is set to 20 by default.

This means that a user can’t have more than 20 active sessions at a time. Because BlackBerry uses a single account (besadmin) to access all mailboxes & take care of mail flow to/from the blackberry handhelds, this limit of 20 sessions won’t allow Blackberry server to work properly.

Hence, we need to configure a new policy and change the RCAMaxConcurrency value to a much higher value & apply the policy only to the besadmin account. It is not recommended to edit the default policy, as it is applied to all users and defeats the client throttling process.

Hope this clears the confusion.