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.
Upon finishing my last project and stopping to take a look back at the past year or so I’ve realized that most (90%+) involved Office 365. Quite a dramatic change from my previous rate of around 50%. I have worked on a couple of migrations over the past year that revealed that Outlook 2016 is quite a different animal than all of its predecessors. Specifically when it comes to Public Folders on Legacy Exchange 2010 servers which is the last Exchange Server version to support Public Folders with actual Public Folder databases.
In my most recent migration I had a customer that was moving from Exchange 2010 to Exchange 2016. In doing to we needed to configure coexistence for Public Folders. The reason is that with Public Folders, if a mailbox is on Exchange 2016, it can access Public Folders on Exchange 2016 AND Exchange 2010. However, a user with a mailbox on Exchange 2010 can only access Public Folders on Exchange 2010. This is due to the way that Microsoft has always proxied requests from a higher version to a lower version, but never in the reverse (exception now would be 2013/2016).
For the past 3 months I have been hard at work with a client migrating from Lotus Notes to Office 365. Most migrations present some challenges, when coming from a system other than Exchange and migrating users to Office 36, there are additional challenges that present itself. In order to make the migration go smoother and to keep your own sanity, PowerShell scripts are necessary. With this migration I have an assortment of scripts that I have users and help with Forwarders, Retention Policies, Licensing and more.
Scripts and Background
One of the issues with this type of migration is Free Busy sharing between Office 365 and Lotus Notes users. This requires a bit of a special setup as well as a third-party tool to handle the query traffic between users of both email systems. In this scenario we used the Quest Coexistence product to provide this. This entails a multi-tiered approach to mailboxes and mail objects in Office 365. The underlying function of free busy has a dependency on the SMTP domain of the user to query. So we have this in Office 365:
Office 365 Users – User have a domain of @cloud.domain.com
Lotus Notes Users – A contact with @lotus.domain.com is used to direct email to Lotus Notes
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:
** Note **
Wanted to make something clear – this is an issue with Windows and PowerShell, Exchange 2016 is not the root cause of this issue. Now on to the article!
A few weeks ago I ran a poll on this and it seems that a fair number of you depend on Get-Help for finding information on PowerShell cmdlets in Exchange 2016. Now, if you are an active user of PowerShell and Exchange 2016, you may have noticed that it is broken. Yes. Broken. But it isn’t broken everywhere. If you have Exchange Server 2016 AND Windows Server 2012 R2 then Get-Help works for you. If you have Exchange 2016 AND Windows Server 2016 then your Get-Help experience isn’t good. For this article, we will cover what is wrong and ways to get around this broken experience.