A client approached me with a need for some mailbox statistics. They wanted a script or some sort of PowerShell code to examine a few mailbox details for a migration from one environment to another that was being processed with third party tools. The source environment was running Exchange Server 2010. This means PowerShell 2.0. Now, I’ve written code for Exchange since Exchange 2007 came out. However, I learned a valuable lesson for these scripts. Test in the same version of Exchange. Yes. Obvious. Maybe even Captain Obvious level here…. However, I didn’t have an Exchange 2010 server with actual verifiable data I could use in my example.
So what did I do? I used Exchange 2013. I had data. I had calendar items, tasks, you name it. The cmdlets I was using are the same for both versions. Well “same” has a different meaning in Exchange PowerShell. So what happened? Lot’s of red. Basically Exchange 2010 wasn’t able to use the same parameters and switches like 2010 did. So I ended up rewriting the script to run on both 2010 and 2013, which would then make it more versatile. The script was also validated to run on Exchange 2016 in a lab. Continue reading
In my day job as an IT consultant I do work outside of Exchange and end on projects that touch Active Directory, Identity Management, Office 365 and more. A lot of these projects require some sort of health check or simply a quick review of an environment before proceeding with any changes. The thought process is that if we can eliminate any issues at the beginning of a project, less issues will occur to cause problems during the project. As a part of these health checks, we can sometimes utilize built-in Best Practices Analyzers for various components on a server.
Why Is This Important?
Exchange really needs a healthy base to stand on. I once worked for a company where there constant infrastructure issues – storage going offline, Active Directory on the fritz, DNS issues, networking issues…. you name it. Exchange reacted badly to these problems. My boss would hound me that Exchange was ‘down again’. Well, of course its down if users can’t get to it or if storage is not available and databases are not mounted or networking is down and emails will not route. So having healthy infrastructure servers (such as Domain Controllers) is very important. Use a BPA to check these servers out will help determine the healthiness of the systems Exchange relies on.
For this quick post on Powershell, I will tag a previous post for a complimenting pair of scripts. The script in this article will check to see who will be affected when databases are put back in order of Activation Preference. In a previous script – Quick PowerShell Stuff 13
– we were able to see which databases were not mounted correctly in terms of Activation Preference. Now if I need to tell the Help Desk who might be affected by a database activation move, I simply use this script to create the list. The script will parse out who’s primary mailbox will be affected and who’s archive will be affected. If both archive and primary mailbox exist on the same database, this will be noted as well. Now on to the script.