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.
PowerShell
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.
There was I, deploying PSPasswordExpiryNotifications for one of my Clients when I started getting complaints that some users are not getting their Password Expiry Notifications. Well, that’s a new one. I’ve tested this script multiple times, and it worked just fine. So I dive into the details of my script to see what I did in there (I don’t even remember anymore – it just works) to find out this little line:
I’ve been working today trying to deliver to one of my Clients Active Directory documentation. To my surprise, something that worked fine for a very long time has started to provide weird results. So, after spending about 8 hours taking apart a few of my PowerShell modules trying to find out what is wrong finally, I’ve found it: Export-CliXML / Import-CliXML. Those two commands are great. I’ve used them multiple times with great success (or so I thought).
A few months ago when I first released Dashimo, I’ve promised that Charts will come. Unfortunately, time passed by, and there were no Charts in sight. It’s not that I didn’t want to deliver, I just wasn’t sure on the way I want to allow charts building. Today after playing with the idea for a while I’ve decided to release essential support for diagrams, with a couple of other fixes. Some of that stuff is already there for longer while I just never announced it. There are probably a lot of other hidden gems you may find if you explore PSWriteHTML or Dashimo.
Today I saw an article on how to get Windows Version Report from Active Directory and thought that this is a cool idea. Something handy for migration scenarios or information on how up to date is your infrastructure. Since there are many ways to do the same thing I decided to tackle this myself and further include it into PSWinDocumentation.AD project. By default Active Directory stores Operating System and Operating System Version but it doesn’t really show versions one may expect.