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.

Well now there are a couple of scripts out there that will examine your server’s runtime statistics and provide you with advice on what to change (kind of like what Bastille does for Linux).

• Tuning Primer by Matthew Montgomery
• MySQL Tuner by Major Hayden

Either one of this scripts will likely save you hours of Googling/experimenting. Both do essentially the same thing, but it never hurts to have a 2nd opinion. And if you’re still not sure about something, a trip to MySQL Performance Blog should fix you right up.

• 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.

Seriously, what the fuck are those people doing over there?

Update According to Microsoft, there will be “a technology like this included in Windows Server 2008 called WinRS; or Windows Remote Shell. This command line tool allows administrators to remotely execute most cmd.exe commands using the WS_Management protocol.” Too bad it sucks!

See Also: “Not Invented Here Syndrome“

• 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.

Compared to the old hardware…

root@old-server:~# hdparm -Tt /dev/hda

/dev/hda:
 Timing cached reads:   278 MB in  2.01 seconds = 138.26 MB/sec
 Timing buffered disk reads:   88 MB in  3.00 seconds =  29.32 MB/sec

the new hardware shows huge improvements in disk transfer rates, pretty much in line with what I expected.

root@new-server:~# hdparm -tT /dev/md0

/dev/md0:
 Timing cached reads:   950 MB in  2.00 seconds = 474.49 MB/sec
 Timing buffered disk reads:  222 MB in  3.01 seconds =  73.81 MB/sec

With twice as much memory as before, I’m also not swapping nearly as much (or really at all for that matter). But what I didn’t expect was for Linux software RAID and LVM2 to have such a big impact on my load average. It actually seems to be around 10-20% higher on average, even with a much faster CPU. Interesting…

• Don’t just use whatever the hell domain name you want and justify it by saying “we’ll only be using this domain internally, so it doesn’t matter if we actually own it or not.” That’s just as dumb as using someone else’s public IP addresses on your LAN, and if you don’t understand what’s wrong with that, you’re fired. Make sure the domain you want to use is unique on the internet, and register it.
• Do use a standard TLD; not that .local bullshit. Using a non-standard TLD like .local is a great way of showing the world that your IT staff doesn’t know what the hell they’re doing.
• Do use different internal and external namespaces. If your external namespace is example.com, don’t use example.com for your internal (i.e. Active Directory) namespace too. Otherwise, you’ll run into problems when your internal users can’t resolve external resources (like your website which may be hosted off-site). If you were stupid enough to make this mistake, one solution is to mirror all your external resource records on your internal DNS servers, but then you’ll have to make every change in two places (your punishment for being an idiot).
• Don’t go out and register two entirely different domains (e.g. example.com and example.net) for your internal and external namespaces. This is unnecessary, will confuse your users, and will tell the world that you don’t understand how DNS works. Just use sub-domains (e.g. hq.example.com, office.example.com, etc.) for your internal networks, and reserve the root domain (i.e. example.com) for your external resources.
• Do run your internal and external namespaces on separate servers. It’s not a good idea to make your internal resource records available to the whole world in the first place, but if you’re using proper private IP addresses on your LAN, this won’t help anyone access your servers over the internet anyway.

Before you ask, if you think you have a good reason not to follow any of the above rules, you are wrong. Don’t do it. I’m begging you.