Test-IPAllowListProvider Test-IPBlockListProvider Test-IRMConfiguration Test-Mailflow Test-MAPIConnectivity Test-MigrationServerAvailability Test-MRSHealth Test-OAuthConnectivity Test-OrganizationRelationship Test-OutlookConnectivity
Test-IPAllowListProvider
According to Microsoft TechNet Documentation on this command:
On Edge Transport servers, the Test-IPAllowListProvider cmdlet checks connectivity to the specified allow list provider and then issues a lookup request to the allow list provider.
However, this command can indeed be run on regular CAS/Mailbox servers and thus are not Edge Transport Servers. Before running the command, make sure you have an IP Allow List Provider defined like so:
Add-IPAllowListProvider -name "SWL Spamhaus" -lookupdomain swl.spamhaus.org
The test to make sure it is working and functional:
- Parameters – Identity (which list provider), IPAddress to check (use yours unless you need to test an external SMTP entity), Domain controller, Exchange Server (which server to run this from)
Test run shows my server IP address is OK and allowed:
Test-IPBlockListProvider
Again, According to Microsoft TechNet Documentation on this command:
This cmdlet is available or effective only on Edge Transport servers in on-premises Exchange Server 2013.Use the Test-IPBlockListProvider cmdlet to test IP Block list providers on Edge Transport servers.
However, this command can indeed be run on regular CAS/Mailbox servers and thus are not Edge Transport Servers. Also, prior to running this command, make sure you have configured a provider like this example or like this:
Add-IPBlockListProvider -Name Spamhaus -LookupDomain zen.spamhaus.org -AnyMatch $true -Enabled $true -RejectionResponse "IP address is listed by Spamhaus"
A simple run of this command shows the result of checking my IP address against the Spamhaus database.
Parameters – Identity (which provider to check), IPAddress (yours or an external SMTP entity), Domain Controller, Exchange Server
One possible full test for this command would be to loop through each DC and Exchange server to make sure the results are consistent:
$dcs = (get-domaincontroller).name
$exs = (get-exchangeserver).name
foreach ($line in $dcs) {
foreach ($line2 in $exs) {
get-ipblocklistprovider | Test-IPBlockListProvider -domaincontroller $line -server $line2 | ft provider*,matches
}
}
Test-IRMConfiguration
The Test-IRMConfiguration cmdlet performs a series of steps to test IRM configuration and functionality, including availability of an Active Directory Rights Management Services (AD RMS) server, prelicensing, and journal report decryption. In Exchange Online organizations, it checks connectivity to RMS Online and obtains and validates the organization’s Trusted Publishing Domain (TPD).
In my internal test environment, my ADRMS server is offline during this test to see what errors would be generated:
Test for reporting:
$result = (Test-IRMConfiguration -sender damian@scolesfamily.net).results
if ($result -like "*warn*") {write-host $result}
Test-Mailflow
All servers back and forth, dumped to a log file. Results summarized in a table:
As I was writing this article I ran into some discrepancies between different Exchange versions. In particular I was reviewing CU3 and CU6. I noticed some differences when using the ‘-verbose’ switch. In CU3, the results look like this:
For CU6, there is a very truncated version of this -verbose option:
Keep this in mind that commands could be different between versions of Exchange 2013.
Options to use for more complex tests:
- AutoDiscoverTargetMailboxServer – allows for automatic discovery of servers to send test messages
- CrossPremises – for hybrid deployments – Office 365 for example
- crosspremisesexpirationTimeout – allows for additional latency for slow links before an error gets logged in SCOM – Not recommended by Microsoft
- crosspremisespendingerrorcount – allows for additional pending errors an error gets logged in SCOM – Not recommended by Microsoft
- ActiveDirectoryTimeout – increase AD time out from default 15 seconds
- errorlatency – allows for additional latency for slow links before an error gets logged in SCOM
- executiontimeout – default is 15, how long PowerShell will wait to determine the test is a failure
- monitoringcontext – allows results to be passed to SCOM
Avoid testing to email addresses of end users as this will create a test message like this:
One option is to output the command to an HTML file (to be shown in the last article of the series) and / or dumping the output to a text file for later analysis or just general logging.
‘Start-transcript’ command will keep a running log of the console output. When the set of commands you need to run are complete, simply run ‘stop-transcript’ to complete the logging.
Test-MAPIConnectivity
Can test multiple factors:
- Database – specify which database to test against
- ActiveDirectoryTimeout – extend or shorten the 15 second timeout for querying Active Directory
- AllConnectionsTimeout – extend or shorten the 90 second timeout for all connections used in the test
- Archive – Test MAPI connections to the Archive Mailbox as well.
- DomainController – choose which DC is used for and data queries from Active Directory
- PerConnectionTimeout – extend or shorten the 10 second timeout
- Server – if you need to specify which Exchange Server to test
The simplest test is:
Just like Test-MailFlow, the Verbose switch displays what is happening in the background during the test:
Test-MigrationServerAvailability
Use the Test-MigrationServerAvailability cmdlet to test the availability of the target server in preparation to perform cross-forest mailbox moves, migration of on-premises mailboxes to Exchange Online, or to migrate on-premises mailbox data from an IMAP server to Exchange Online mailboxes. For all migration types, the cmdlet attempts to verify the connection settings used to connect to the target server.
For my environment, which has a semi-maintained connection to Office 365, I see that one of my servers is not properly configured. EX02 is a new server I built and is in my DAG, but is not configured for MRS. AutoDiscover located this server for use, however, my test revealed that it is not ready for production moves.
This test helped reveal that the server needs an MRS proxy configured prior to any mailbox moves. Once configured, the test shows like this:
Looks like I still have something misconfigured, or a server is in need of a reboot. Either way, the PowerShell test reveals a potential issue that needs to be fixed.
Test-MRSHealth
Use the Test-MRSHealth cmdlet to test the health of an instance of the Microsoft Exchange Mailbox Replication service.
Sample run of this command:
Cmdlet refined a bit for a quick to read table of results:
get-exchangeserver | test-mrshealth |ft check,passed,identity -auto
That’s about it……
Test-OAuthConnectivity
Use the Test-OAuthConnectivity cmdlet to test OAuth authentication to partner applications for a user.
Older version of Exchange have an inconsistent help file because while the help option lists only 4 options to be used under the -Service parameter:
However, the only example given for the command shows a fifth example ‘Exchange’.:
Yet you are unable to use this parameter:
CU6 now has this:
And the options are now limited to three instead of four from earlier version of Exchange 2013.
Now, for the actual test itself and what it can help troubleshoot:
If Oauth is not in use, expect a long error message like this:
If all is well with Oauth, then the command will return this instead:
Table form of the same data:
Test-OrganizationRelationship
This command simply validates the relationship is valid between two organizations. It does not test functionality like Free/Busy or the ability to move mailboxes between the organizations.
Here is what a sample run of the command would look like:
As you can see, the first run of the command failed with a proxy issue.
Test-OutlookConnectivity
A quick way to run through all the Outlook Providers needed to probe the Outlook tests is to loop the probes and run the probes against one server at a time:
$probes = (Get-MonitoringItemIdentity -Server ex01 -Identity outlook.protocol | ?{$_.Name -like '*probe'}).name
foreach ($line in $probes) {Test-OutlookConnectivity -MailboxId "damian scoles" -ProbeIdentity $line -Hostname "ex01" -wa 0 -ea 0 |ft monitor*,result,error -auto}
The $probe variable holds values for the possible tests/probes that can be used to detect errors with Outlook Connections:
- OutlookServiceProbe
- OutlookRpcSelfTestProbe
- OutlookMapiHttpSelfTestProbe
- OutlookRpcDeepTestProbe
- OutlookMapiHttpDeepTestProbe
- OutlookRpcDeepTestProbe
- OutlookMapiHttpDeepTestProbe
On my test environment, I see I have 3 good and 3 failed results:
Notice that all my errors were RPC related and not MAPIHttp related. To get more information on the probes that can be tested, see this TechNet link to the command.
What To Do Now
In this article we’ve gotten through over half the native Exchange PowerShell Cmdlets for testing. Below I have assembled the above 10 test commands and simplified them to show only what should be important from each test:
get-IPAllowListProvider | Test-IPAllowListProvider -ipaddress <ip addr>
get-IPBlockListProvider | Test-IPBlockListProvider -ipaddress <ip addr>
Test-IRMConfiguration -sender test.user@domain.com
Test-Mailflow -TargetMailboxServer "EXCH01"
Test-MAPIConnectivity -Verbose -Database database01
$credential = get-credential
Test-MigrationServerAvailability -ExchangeRemoteMove -Autodiscover -EmailAddress test.user@domain.com -Credentials $credentials
get-exchangeserver | test-mrshealth |ft check,passed,identity -auto
Test-OAuthConnectivity -Mailbox "Test User" -Service ews -TargetUri <I>https://mail.domain.com/</i> |ft task,resulttype,identity -auto
Get-OrganizationRelationship | Test-OrganizationRelationship -Verbose -UserIdentity <user> -DomainController <domain controller>
$probes = (Get-MonitoringItemIdentity -Server ex01 -Identity outlook.protocol | ?{$_.Name -like '*probe'}).name
foreach ($line in $probes) {Test-OutlookConnectivity -MailboxId "test user" -ProbeIdentity $line -Hostname "EXCH01" -wa 0 -ea 0}
Past Posts in the Series
Testing Exchange Server Updates – Part 1
Testing Exchange Server Updates – Part 2
