Virus Total is an excellent service. It’s a single place where hundreds of antivirus engines can verify if the file, URL, domain name, or IP Address is trusted or not. Of course, it’s not a silver bullet, but it brings tremendous value, and I often verify files I download before executing. Since I release a lot of new or updated PowerShell modules on a weekly/monthly basis, I thought it would be great to send newly released versions straight to Virus Total so I can have them checked before anyone executes them. I also hope to prevent false positives from some antivirus vendors that may tag my modules as malware because they haven’t seen the DLL or PowerShell module in this form before. I’ve seen it happen to DBATools, so why not try and push my modules before users even use them?
I work a lot with Active Directory-related tasks. One of the tasks is to know the group membership of critical Active Directory Groups such as Domain Admins, Enterprise Admins, Schema Admins, Event Log Readers, and a few others that are a bit less known. As I did it, I got bored of typing the group names repeatedly and decided that enough was enough and there must be an easier way for me to do that.
In my earlier blog post, I showed you a way to find duplicate DNS entries using PowerShell, but the focus was on finding duplicate entries based on hostname. But what if you would like to find duplicate entries based on IP Addresses? This was the question I was asked on Reddit, and I thought it was a legitimate request, so today’s focus will be on transposing table output from earlier functions to present data differently.
Today’s blog post is about Active Directory-integrated DNS and how to find duplicate entries. By duplicate, I mean those where one DNS name matches multiple IP addresses. While some duplicate DNS entries are expected, in other cases, it may lead to problems. For example, having a static IP assigned to a hostname that later on is also updated with dynamic entries.
I’ve created a cross-platform (Windows, Linux, macOS) Word library based on Open XML SDK that heavily simplifies creating and modifying Word documents. Open XML SDK, while excellent, requires you to do a lot of work to make even simple documents. For example, if you want to use Table styles, you need first to define those styles, put them in a specific place, and assign them to a table. The same goes for lists, images, hyperlinks, bookmarks, and many other Microsoft Word types. Creating sections, managing headers, and footers – all that is possible using Open XML SDK, but it’s far from easy. At least for a noob like me. You have to know the order to put them into the document; you must know the places and track IDs to all the elements. And trust me – it’s not fun.
Today I was reading Twitter, as I am pretty addicted to technology news when Adam Bacon mentioned that he’s surprised that no one has rebuilt IIS Parser as pure PowerShell. While this is not entirely true, and some modules can do some parsing, I decided to try my luck. While doing it from scratch in PowerShell is possible, I opted to use an external C# library that does all the heavy lifting and is optimized for speed.
Two years ago, I wrote a blog post on how you can compare two or more objects visually in PowerShell that works on Windows, Linux, or macOS. I’ve been using that for a while, but it had a specific flaw. Comparing more advanced objects that you often see (for example, returned by Graph API, two config files) wasn’t working correctly, often throwing errors. The reason for this was that having nested hashtables arrays require more advanced logic. Today I’ve updated my module to use the ConvertTo-FlatObject function, which allows the Compare-MultipleObjects function to compare suitably more advanced objects hopefully. Of course, it should not throw errors anymore.
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.
Two years ago, I wrote a PowerShell module called PSWinDocumentation.O365HealthService. The idea was simple – replicate Health Service data Microsoft offers in Office Portal so you can do with data whatever you want and display it however you like. I’ve written about it in this blog post. A few weeks back, someone reported that the module stopped working, and I’ve confirmed it indeed no longer works! Initially, I thought that maybe some data format changed, as it changed multiple times, or perhaps the date format was wrong again, but no. Microsoft has deprecated Office 365 Service Communications API reference and instead tells us that Service Health is now only available via Microsoft Graph API. Is it only me who didn’t get the memo about this?
Today’s story is about me making assumptions on how things work based on the method’s name. As the blog post says, I want to focus on two similar methods – GetTempFileName() and GetRandomFileName(), when using PowerShell. Still, since those methods are .NET based, it applies to a whole range of other languages – C#, F#, VisualBasic, and all others that I’ve never used.