I know the old Kiwi is now supposed to be bad because there is a new (NG) version, but I like my old version. The new version can KiSS it! (I'm joking, of course... but I'm not... but I am... but I'm not) The old version is super powerful, but it's also super old. The new version, which I've tried several times, just hasn't impressed me much at all. I've had an empty checkbox for a couple of tasks for a long while now, so I figured I'd take a moment and jump back into that old task and finish it.
The PowerShell script can be found in the following post: Automating Basic Kiwi Maintenance; Syncing StaticHosts File
My brain isn't what it used to be, and it didn't used to be any good to begin with, so just know the solution below is just another way for another person to do another thing. So, what is it? It's simply a method to automatically update my StaticHosts file when new nodes are added. It also backs up a handful of log files, otherwise it's just that basic. No rocket surgery here, just a simple update and backup in the background, without me having to remember that I forgot to remember to update and/or restart the service for the new data to load up.
The first thing I wanted to do was to standardize the formatting and naming convention of the StaticHosts file. The main PowerShell script runs a SWQL query to list all nodes, formatted to fit the StaticHosts file requirements, having IPAddress then Hostname. I've always struggled to find the balance between building insane filters and rules, and building out insane hostnames. Over the years I've settled on simplicity. I take the hostnames and remove all spaces and other such garbage chars, then attach a simple underscore followed by the vendor. Additionally, I add a comment to each line to specify vendor, machine type, and a datetime stamp of when the script was ran.
With the naming good to go, it helps me cut down on filters and rules. Now, I can easily just group by vendor, which solves most of my issues. Previously, I had been using vendor and machine type, but that was too specific, and would often miss messages I needed, or caused me to create additional filters and/or rules. What I have now works for me and is, in no way, the best way for anyone else to do it.
Next up, if you want it to run on a schedule, that's easy enough to do on the server itself. However, if you'd like, you should be able to fire the script via the alert manager, whenever the system detects "Node Added" or "Node Deleted" audit types occur. Make sure the "Trigger Actions" tab is configured to fire off the script, and you should be good to go.
The script will also backup the KSS settings, though it does so in a roundabout way, exporting the registry key path. I'd rather have a CLI argument to pass through to export, but I am not aware of such a solution. After comparing the data between the registry export and the settings .ini export, it appears as if the data is the same. Perhaps a smart person can come through and build a script to parse the registry export and convert it to a .ini file?
Again, the only thing I'm an expert on is knowing that I'm no expert. The script is likely poorly put together, and possibly even worse than bad... There is no error checking, and no built-in fail safes. But, it works for me, and that's pretty much where I leave things as I move along to other adventures.
