After receiving a couple of emails from my readers requesting to blog about the new stuff in Windows 8 & Server 8, I have decided to broaden the topics that I blog about. Though I signed up for a different domain name, I thought it will be good to have a single site with all my articles and it makes it easier for me to maintain it as well.
So, from now on, it will be roughly 90% Exchange, 10% Windows 8, Server 8, Lync 2010 & PowerShell…
Stay tuned!
The Windows 8 Developer Preview is a pre-beta version of Windows 8 for developers. Continue Reading…
Test-OWAConnectivity cmdlet is similar to Test-ECPConnectivity. It verifies that the Outlook Web App (OWA) is working as expected. The cmdlet can be used in two ways – test OWA connectivity for all Exchange 2010 virtual directories on a specified CAS server for all mailboxes that are in the same AD site or test the connectivity for an individual Outlook Web App URL.
Run Test-OWAConnectivity –ClientAccessServer servername to test against a CAS server.
Run Test-OWAConnectivity –URL “https://emexch1.exchangemaster.me/owa” –MailboxCredential (Get-Credential domainusername) to test owa connectivity for a user.
You can use the “TrustAnySSLCertificate” parameter if your certificate isn’t a trusted one. Run Test-OWAConnectivity –URL “https://emexch1.exchangemaster.me/owa” –MailboxCredential (Get-Credential domainusername) –TrustAnySSLCertificate
The above command quickly checks whether a user can login using OWA. You do need the username and password of the user for the command to work.
Test-MRSHealth is one of the simplest test cmdlets in Exchange 2010. It checks three things – whether the mailbox replication service is running on the server, whether the service is responding to an RPC ping and whether the replication service is scanning database queues for jobs.
The Exchange Mailbox Replication service runs on all CAS servers. It is responsible for all mailbox moves, import and export requests.
Run Test-MRSHealth to find the status of the replication service.
If you want to check the status for all CAS servers, run Get-ClientAccessServer | Test-MRSHealth
Part one, two, three and four of the series, if you haven’t already read it.
The Exchange Team blog has published an article recommending all DAG members running Windows 2008 R2 to have a few hotfixes installed. Microsoft has encountered scenarios in which a transient network failure occurs (a failure of network communications for about 60 seconds) and as a result, the entire cluster is deadlocked and all databases are within the DAG are dismounted. Since it is not very easy to determine which cluster node is actually deadlocked, if a failover cluster deadlocks as a result of the reconnect logic race, the only available course of action is to restart all members within the entire cluster to resolve the deadlock condition.
The following KBs list the recommended hotfixes .
Read full article @ source
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 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 
Follow Me