When you work with HTML, CSS, and JavaScript, you often meet three versions on how those are stored in files – minified, formatted, somewhere in the middle (usually a total mess). I have all three versions in my PSWriteHTML module. Some are minified 3rd party resources, some are generated by my PowerShell commands (and are a total mess when it comes to formatting), and finally, some are formatted resources by using built-in VSCode features. In whatever form they are, they generally have no impact on how browsers display them. Browsers will read them in any kind and not care for how they look.
Przemyslaw Klys
I shouldn’t be telling you that, but Active Directory Backup is an essential part of your Active Directory setup. When a backup of Active Directory happens, AD is aware of it. Following PowerShell solution allows you to get Active Directory Last Backup Time for the whole forest or by domain.
Last few weeks, I’ve been working on making creating HTML based Dashboards, Reports, and Emails better. PSWriteHTML already allows fancy looking reports or emails without much effort, but this release makes it even more helpful. I will be mixing three PowerShell modules in this blost post – PSWriteHTML (responsible for creating HTML/CSS/JS code), Emailimo (simplifies creating emails based on PSWriteHTML) and Dashimo (simple dashboard building). If you’ve never heard of those modules before I encourage you to start from earlier blogs about them to understand the concepts before you dive into this one. Hopefully, those will give you some ideas that will match what you will learn today.
One of the common ways to connect to Active Directory is thru LDAP protocol. There are a lot of applications that talk to AD via LDAP. By default Active Directory has LDAP enabled but that’s a bit insecure in today’s world. That’s where LDAPS comes in. It’s not easy to set up, but when you get it done, it works. The problem I had recently is that while setting up LDAPS on DC’s I only did this on some of the DC’s, and not all of them as I should.
In Active Directory when you change something, it’s replicated to other Domain Controllers regularly. It’s a standard procedure that happens automatically in the background for you. It’s a handy feature because you can have multiple DC’s all over the world and have your users data in sync. You can change almost anything on DC nearest to you and be sure it will be the same value all over the place. But is it always the same? Well, it should be unless it isn’t. Today I was given a new migration from Exchange to Office 365. I started with ADConnect installation and wanted to make sure that UserPrincipalNames have all UPNSuffixes in place.
When you write PowerShell modules, there’s a high chance you will have conflicts with either existing system commands (you should avoid that) or with someone else’s modules. There are also times when someone wants to use a private function from a module that only exports essential functions. Here’s a couple of ways how to deal with those scenarios.
I’m on a tight deadline for one of the chapters for PowerShell Conference Book vol. 2. That means my brain wants me to do a lot of different things but writing that chapter. I’ve decided to write this simple PowerShell command that allows me to use Lansweeper in PowerShell. If you never heard of Lansweeper, it’s a great inventory tool that can scan Windows, Linux, Network, Printers, and other types of assets gathering it all in SQL Database. Usually, you would use their friendly, fast interface to access data it stores because it offers a lot of flexibility, export options, and many many features.
Having Bitlocker and LAPS in modern Active Directory is a must. But just because you enable GPO and have a process that should say Bitlocker and LAPS are enabled doesn’t mean much. Now and then you should verify things yourself. One of the Facebook users on PowerShell group just had this idea of exporting Bitlocker keys and then giving that list to his colleagues for manual verification. He wanted to do it half PowerShell and half manually. While the idea was great, why not take full advantage of PowerShell and have a helpful report with all the necessary information?
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.
Last few days, I’ve fulfilled my little dream related to building HTML tables. You know I’ve been using HTML based scripts for a long while for Microsoft Exchange from multiple people like Steve Goodman or Paul Cunningham (and others) and when I was going thru their PowerShell building code on how they create an HTML table with multi-row titles I thought Those guys are crazy. The effort to build an HTML table for a report for a person who has no clue how to do it is not something one can easily digest and understand. Sure I’ve learned how to build HTML tables at some point, but there was one final piece that I was missing – multi-row headers. If you don’t know what I mean, and how they look like the below image from Steve’s Goodman script should give you a hint.