Having transitioned more and more to using PowerShell 5.0, instead of 4.0, I thought I would pass along one tip when using it. Typically when working with Exchange PowerShell and listing object attributes. I like to select a single column of the data and past it into a CSV file or documentation I am making. However, in PS 5.0, the default ‘Mark’ in PowerShell has changes. Instead of a single column, the select tool selects entire likes like so:
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.
In this latest installment, I am going to revisit a script I had written before that is now in it’s second major iteration. The first iteration was just to simply be able to scan all event logs for a list of servers that your typed in and look for Critical, Warning and Error messages in all relevant logs. Let me review the changes that have ben made so far:
- Choose to scan all Domain Controllers – added option
- Choose to scan all Exchange Servers – added option
- Use a CSV file – added option
- Menu added for ease of use
- Speed – the old script could take days, now it takes hours (looking to trim this in the next version)
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.
In this next quick PowerShell post, I am going to cover a quick way to look at your database copies. This script will look for failed copies of the database. I wrote this because of a client I have that have over 150 databases and over 500 copies of all of their databases. This script provides a simple view into this part of your Exchange databases.
The code for the script is listed below. Fairly simply, the script will make sure no copies are failed. If failed copies are found then it will process lines 24-47. At this point all the script will determine how many are good and bad, and provide a total copy list as well. If all copies are good, then the script will process lines 10-22. Continue reading
In this quick PowerShell post I will cover a quick way to get a handle on corrupt content indexes for your databases. In Exchange the content index is created by the Exchange Search processes for each database in your DAG. When the index is corrupt it is possible that clients will suffer delays or not be able to search at all via their clients. In order to prevent this from becoming an issue, I wrote a script that I can run during the day (or night) to check the status of all content indexes for all mailbox databases in Exchange.