Does having Format-Table or Format-List in the middle of the pipeline makes sense?

I’ve been using Ubiquiti Unifi for some years now, for both home and work usage. It’s great hardware at a great price, and the best thing for a software maniac like me is that it’s continuously updated. Some time ago I upgraded Ubuntu to 18.04, and things went a bit sideways. You see Unifi started to add to their DEB packages that Mongo 3.6 is not supported and therefore blocking any installation. The idea is, it works perfectly fine on MongoDB 3.6 but migration between 3.4 to 3.6 is just not straightforward. Long story short when I upgraded Ubuntu I was suddenly greeted with not working Unifi.  I’ve fixed that, and blogged about it how you can do so using manual steps – Ubuntu 18.04 – Fixing Unifi .deb package to run with 3.6 MongoDB. The thing is with each new version out I have to do multiple steps to fix every single package from Unifi (you see where I’m going right?). While a few years ago I would be stuck to use bash or some other workaround which would be a pain for me, this is 2019, and PowerShell Core works excellent on Linux systems! I know that installing PowerShell Core for hardcore Linux fans may not be as fun as it is for me, but you do get a lot of benefits from it.

PowerShell language allows you to work and build complicated objects. There are multiple ways to save them, such as XML or JSON, but sometimes using them is impossible or inadequate. Sometimes you want to use HTML or CSV or any other single dimension output.

I saw this article by Altaro tweeted Building PowerShell Tools for MSPs: HTML Tables for Reporting, and it describes how you can create HTML emails with just a few lines of code. Luke created that article in 2018 (tweets from the archive I guess), but I just saw it now so thought I would make a slight comparison. In 2018 I would probably go the same way as shown by Luke Orellana, who takes a simple example of querying WMI to get disk drive sizes and send them over, formatted via Email.

Setting up a new Active Directory is an easy task. You download and install Windows Server, install required roles and in 4 hours or less have a basic Active Directory setup. In an ideal world that would be all and your only task would be to manage users, computers, and groups occasionally creating some Group Policies. Unfortunately, things with Active Directory aren’t as easy as I’ve pictured it. Active Directory is a whole ecosystem and works well ranging from small companies with ten users to 500k users or more (haven’t seen one myself – but so they say!). When you scale Active Directory adding more servers, more domains things tend to get complicated, and while things on top may look like they work correctly, in practice, they may not. That’s why, as an Administrator, you need to manage Active Directory in terms of its Health and Security. Seems easy right? Not quite. While you may think you have done everything, checked everything, there’s always something missing. Unless you have instructions for everything and can guarantee that things stay the same way as you left them forever, it’s a bit more complicated. That’s why Microsoft delivers you tools to the troubleshoot your Active Directory, such as dcdiag, repadmin and some others. They also sell monitoring solutions such as Microsoft SCOM which can help and detect when some things happen in your AD while you were gone. Surely there are some 3rd party companies give you some tools that can help with a lot of that as well. Finally, there is lo of folks within the community creating PowerShell scripts or functions that help with some Health Checks of your Active Directory.

As you may know, PowerShell has multiple streams. Write-Output, Write-Error, Write-Warning, Write-Verbose, Write-Debug, and Write-Information. It also has Write-Host which until PowerShell 5 was a bit special. Since PowerShell 5.1 it’s a wrapper over Write-Information, so it doesn’t kill puppies anymore. While I could spend the next five pages trying to give my best and describe those streams, there are already many articles describing them in detail. Please check the following link if you need that information.

Today I’m pushing forward with PSWinDocumentation project. I’ve fixed some bugs but I also added a couple of new features. I did lie a bit in the first sentence because this time it’s not all me. I got help from Mateusz Niemczyk who is a certified AWS engineer working for Euvic with me on some projects. If you’ve not yet guessed where I got him involved from the introduction – yes we’re adding basic AWS data support to PSWinDocumentation. But that’s not all…

It’s been less than 24 hours since I’ve released PSBlackListChecker with support, among other improvements, for Microsoft Teams and Slack and I’m now adding Discord to the mix. Discord was a popular request (well not really, just one person asked, but let’s pretend everyone loves PSBlackListChecker so much that they are too shy to ask for feature requests!).

Some months ago, I created PowerShell Script to create local administrative users on workstations – Create a local user or administrator account in Windows using PowerShell. It’s a bit overcomplicated, but the goal was it should work for Windows 7 and up, and that means supporting PowerShell 2.0. As part of that exercise, I’ve been using Win32_UserAccount WMI based query to find local users and manage them to an extent. While Get-LocalUser exists, it’s not suitable for the PowerShell 2.0 scenario. I also use the same query in GPO for WMI filtering. You can say it’s been a good friend of mine.

Recently I got a simple task to implement LAPS for the newly created local user instead of using the built-in local administrator account. It seemed easy at first. Go to Group Policies, create a new user, add it to an administrators group, and then follow standard steps to implement LAPS. That is until you find out it’s actually not possible anymore due to password encryption key being available in the wild, which made Microsoft block that Group Policy Preference. While that road is blocked, I still need to get my user-created somehow. Let’s do it with PowerShell. It’s quite simple – use New-LocalUser a few parameters, some random password that I don’t need to save as LAPS will overwrite it. Except it’s not available on PowerShell 2.0, which is the default for Windows 7 that I have to support. Things get even more complicated if you consider that Administrators group is called differently in different countries. While I stopped supporting anything below PowerShell 5.1, I can’t say if it’s the project requirement.

Today I had a need to connect to Microsoft Graph and do some tasks on Office 365. Since I have already done similar stuff for my PSwinDocumentation.O365HealthService PowerShell module that I’ve described in PowerShell to get all information about Office 365 Service Health, I thought this will be easy run as I’ll just reuse the code I’ve done for that module. As always for Graph related tasks you need to register your application and assign correct permissions. I’ve used my own article for that with changes to which API I want to access. Now that I’ve done all that I’ve extracted my Connect-O365Graph function from my module and started connecting.