This Quick PowerShell blog article will cover how to test that a server can receive a remote PowerShell request (like Invoke-Command), how to add this ability an at the end remove the changes if need be as well. The reason I wrote this code is that I am in the process of creating health check scripts that sometimes need to run code locally on a server because the code cannot be executed remotely. An example of this would be using PowerShell to run the various BPA PowerShell cmdlets. These need to be executed locally on a server to get the proper BPA to run and leave results to be collected later. As such, PowerShell needs to invoke cmdlets on the remote server.
I wrote a script to gather Event Log data and posted it here – Quick PowerShell Stuff 17. That script would fail if WinRM or remote PowerShell sessions were not allowed to connect to a Domain Controller for example. What I needed was a more automatic way to fix this as I am now automating my health check data collection process.
Last week I wrote that Microsoft had released their Teams PowerShell module. It was rumored to not be a great PowerShell module, which could be true as it would be inline with Microsoft’s current cloud release structure which is feature first, administration (PowerShell and more) last. However, for this article we will start with an open mind. Let’s see what this module brings to the table.
Getting the Teams PS Module
First, how do we get our hands on the module? First we can see what Microsoft has documented in their PowerShell Gallery – https://www.powershellgallery.com/packages/MicrosoftTeams/0.9.0. As we can tell from the link, this is still an early release as the module version is less than 1.0.0. The current list of cmdlets is small at the moment with a concentration on Team Users, Channels and Team configuration settings.
Now like a lot of modules available for PowerShell 5.0, we can either save the Teams PS module for later use or installation on another computer
Save-Module -Name MicrosoftTeams -Path <path><!--more-->
Or we can install the module with this one-liner:
Install-Module -Name MicrosoftTeams
** Note ** Just remember that in order to install the module, you need to have Administrative rights (right click and ‘Run As Administrator’) for Windows PowerShell as well as Internet access to get the module from its repository. Continue reading
If you were Ignite you may have heard about the transition plans for Skype and Teams. Skype Online is being absorbed by Teams in order to provide a more unified experience. Whether or not the end user or administrator sees this as good or not, it is happening. Microsoft has also begun to add Teams cmdlets to the Skype connection point in Office 365.
Microsoft Informational Articles
Team PowerShell Cmdlet Releases
Here is a quick timeline of the cmdlets released (your Office 365 tenant may have received these cmdlets before or after mine, so YMMV)
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)