Gyrate Dot Org

With the net user command, it’s possible to modify active directory user accounts on the command line.

net user myuser mypassword

Similarly, it’s possible to modify group membership with the net group command.

net group mygroup myuser /add

This is all well and good, but Microsoft in all its infinite stupidity did not include a way to set account passwords as non-expiring (and you might want to do this when creating active directory accounts with a script). That’s where the dsquery and dsmod commands come in. The following code will use dsquery to locate all the users with names like “myuser” and use dsmod to set the passwords as non-expiring.

for /f "delims=" %D in ('dsquery user -name myuser*') do dsmod user %D -pwdneverexpires yes

Ignore the part of Microsoft’s documentation that says the ds* commands ship in Windows 2008 Server. They also ship in Windows 2003 Server.

I have been using Kaseya for over six months now, and even after the recent update to version 5.0, the network monitoring functionality remains pretty much a joke. I don’t understand how this app became so popular in the MSP world. Here’s a list of reasons why:

• No concept of “state” for services - Kaseya keeps track of host state (ie: online/offline) with a nice little icon, but it does not do anything similar for services. Therefore, there is no way to get a complete picture of a network’s current state “at a glance.” Services should not be treated like 2nd class citizens this way, because plenty of services are just as critical as (if not more than) the actual hosts they are running on.
• No alerts when a service returns to an “OK” state - It’s not enough to receive an alert just when a host/service check fails. You need a corresponding alert when it starts succeeding again too, and here’s why: False alarms are pretty much a fact of life with all monitoring applications. There are lots of reasons why a check might fail every now and then (network congestion, etc.). Therefore, I don’t want to have to scramble every time I see an alert just to find out that the service is already back up again. I want the monitoring application to tell me when it’s back up. This is especially important when I don’t have immediate access to a computer (e.g. if I’m on the road and I have alerts going to my phone).
• Graphs are limited to ~2000 data points - This is the problem with storing raw performance data in a SQL database (I admit that I am simply assuming that’s what they have done here). More data makes a slower database, so it makes sense that they would hard-code a limit on the amount of data that can be stored. But how in the hell do they expect their customers to do trend analysis with only ~2000 data points? Assuming a service check every 10 minutes: 60 minutes * 24 hours / 10 = 144 data points per day. ~2000 data points total / 144 per day = a history of ~14 days. Compare this to something like Cacti which can easily handle years worth of performance data using RRDtool.
• SNMP monitoring will bring your network to its knees - Amazingly, there is no way to modify the polling interval for SNMP queries. It appears that the Kaseya agent will simply execute snmpget in rapid succession until you notice that your server’s CPU is pinned to 100% and you are forced to disable SNMP monitoring altogether. Even if they increased the hard-coded polling interval, you still have no control over the size of your graphs due to the data point limit listed above (in my experience, you might get 1-2 days if you’re lucky). What baffles me the most is that you can set the polling interval for WMI monitoring. So why would they not implement this for SNMP too? I don’t get it.

To be fair, Kaseya seems to be paying a lot of attention the user complaints on their forums lately, and they’ve already started to address some of these problems. Hopefully I’ll have less to complain about in the coming weeks.

Until today, I never thought much about writing scripts that rely on a GUI. I knew there were tools out there to do it, but I never looked into it, because it always seemed kind of tasteless to me; like something a VB programmer would do out of ignorance. And then when I did some research for a project I was working on today, I found confirmation of that in some hilarious quotes about one particular GUI scripting language being “the nicest procedural programming language I’ve [sic] ever worked with.” Obviously these people spend too much time dragging around windows and clicking on buttons to know what the hell they’re talking about, so before I go any further with this post, I’m going to give you a list of reasons why it’s generally not a good idea to write a script for a GUI:

• It requires a GUI. That’s a lot of overhead for a script. So you either leave your computer logged in with some predetermined user account, or you somehow script the logon and logoff part too. Both methods are insecure and a waste of system resources.
• It’s basically reverse “screen scraping,” and the same caveats apply. Your script is relying on display elements that are more or less guaranteed to change in the future (upgrades, etc.). That means your script will most likely have a very short lifespan, lots of updates, or both.
• It’s an inefficient method of programming. A GUI is designed for interaction between a human and a computer; not between a computer and itself. All those mouse clicks are translated into machine instructions anyway, so if I already know the machine instructions I want to execute, why would I want to waste time telling the computer where to type text and click the mouse? A GUI script is working with an unnecessary layer of abstraction, which is only useful when building Rube Goldberg machines, and Rube Goldberg machines have no place in any IT department.

There are a few situations, however, where automating a GUI is a very good idea. The most obvious use for GUI automation is in unit testing and software quality control. Obviously, good unit tests are a lot cheaper and less error-prone than QA people, and from what I can tell, software developers are the target audience for most commercial GUI scripting tools.

Another good use for GUI automation (as I discovered today) is when working with shitty old software with proprietary databases of which there is no hope of accessing with Python. In my case, I had to come up with a way to pull a report out of the biometric security system for one of our datacenters and email it to someone on a weekly basis. My first thought was to connect directly to the database using the Python DBI and do the query myself, but gave up on that idea when I discovered that not only was everything written in German (the filenames, the documentation, everything), but the actual “database” was just a bunch of crusty old binary files.

The ultimate solution was a free scripting language called AutoIT. It isn’t exactly pretty, but it works. And seeing as how the GUI for our security system looks like something out of Windows 95, I figure I probably won’t have to worry about it changing my script any time soon.