When I created ImagePlayground, I thought about how to show its usefulness to the general community. On how to deliver what PowerShell can do. Then I saw on some forum people asking BGInfo to expand and allow running PowerShell scripts so that the data on the BGInfo Wallpaper can be gathered from PowerShell rather than VBS. I thought this was a great idea to create BGInfo using PowerShell without the necessity of using BGInfo at all.
module
Office 365 is a huge beast. It has so many services that it’s hard to track all of them. It’s even harder if you want to manage Office 365 using PowerShell. Microsoft makes many different PowerShell modules available for you, such as AzureAD, AzureADPreview, ExchangeOnline, MicrosoftTeams, and recently, Microsoft.Graph. But even with so many different modules, there are still tasks that Microsoft won’t let you do from PowerShell. But it doesn’t mean that it’s not possible to do it. I’ve spent some time tracking how Microsoft does things while you click thru the interface and created an O365Essentials PowerShell module that can do it in an automated way.
A few weeks ago, I posted a concept migration diagram for Office 365 to Twitter and Facebook. Today I thought I would show you how you can do it yourself using PowerShell and PSWriteHTML PowerShell module. When I started working on this, I’ve thought I want to create before and after infrastructure to see how it will look when migration ends. I’ve initially planned to assign myself an Office 365 Visio Plan 2 license and do something manually, thinking it may be just much easier. Unfortunately for me, there were no free Visio licenses in my tenant, and my laziness took over, so I’ve decided to give it a go using PowerShell only.
I’m a big fan of PowerShellGallery. It’s easy to use, Microsoft owned, a place to host your PowerShell modules. Every time I release a new PowerShell module, it’s readily available for me or anyone with a single command Install-Module. No need to host it yourself, no need to prepare anything – plug & play. Additionally, if your PowerShell module has any dependencies, it will download and install them, so it directly works out of the box. But what if you can’t use PowerShellGallery? What if you don’t want to use Install-Module on 100 computers, but you prefer to do it in a more controlled way? What if your servers do not have internet connectivity?
We’re a few days in 2019, and from a time perspective, I can say I had a busy 2018. I must say I’ve never expected that but in 2018 I’ve created or worked on 24 PowerShell modules. Some were simpler ones, some were a bit more advanced, and some will be retired in 2019 because their features will be moved to other modules. In PowerShellGallery alone those were downloaded over 15000 times (I must admit that some of those are surely automated tests – “Hello Pester” that I’ve learned in 2018. It’s a nice number thou, and something I’m kind of proud of myself. After all, before 2018 I’ve not created a single PowerShell module before. Sure, I’ve created a bunch of scripts, hardcoded, that did the task that I had to solve. But I’ve never before built something, that could be installed by one little command Install-Module (something I’ve learned in 2018 as well) and executed by anyone, anywhere. I know the title says Sixteen PowerShell Modules but some modules are just too simple to give them anything else than a small mention.
Another day, another issue one may say. Today I wanted to install one of my modules to a new server and was greeted with a well-known message (it may seem on first look):
A command with name ” is already available on this system. This module ‘PSEventViewer’ may override the existing commands. If you still want to install this module ‘PSEventViewer’, use -AllowClobber parameter.
