Our monthly commentary and collected links for September 2013.
Let $env:computername Do That For You
Well, September was hardly a banner month for me. I managed to contract three viruses consecutively, and not the lovely computer kind that you can just wipe away with a tool or a few commands. Even though I managed to drag myself into work most every day, I had difficulty maintaining focus and certainly was not operating at anywhere near my peak efficiency. Fortunately, the only thing that really suffered (besides me) was the projects that I’ve been assigned to. Things could have been a lot worse.
In my current environment, I’m a fairly small cog in a pretty big machine. There are dozens of administrators and hundreds of servers. We have three active data centers, and we’re just a division of a larger organization. So, percentage-wise, I’m not responsible for very much. But, the systems that are mine are all mine. I’m the designated expert for them, so I’m the one they’ll call if something isn’t working. Before they call, though, there’s a few places they can check to see if there’s a regular procedure for dealing with outages. We have a great many third-party applications, some less stable than ideal. They crash predictably, and therefore have standardized recovery processes. Others may not crash often, but there are at least some basic items that need to be running or can be reset, etc. There’s really nothing magic or unusual here. Your systems need to be documented.
So, what does that have to do with human illness? A lot, actually. If you can document it, you might be able to take it a step further: complete or partial automation. For instance, I once managed a software application that depended on IIS. We knew that every four to five days, it would completely overrun all of IIS’s buffers and we’d have to reset IIS. The vendor blamed everyone except their own software and refused to fix it. At first, we just had a permanent note that when the users called in about the application not responding, the answering technician would reset IIS. It wasn’t long before we decided to just set up a batch file and scheduled task to reset IIS every three days. Of course, this also made its way into the documentation, since such a system is often completely forgotten about. With fading memories (or turnover), such a system could be a surprise to a later administrator. So, documentation is critical: what is automated and why is it automated?
This is what got me through the month without anything collapsing. My systems didn’t have any meaningful issues, but if they had, I’m reasonably certain another administrator could have followed my notes and gotten them back in shape again. However, the real trick is in the automation. The system I just described was crude, but effective. We had a monitoring system in place, so we could have had it only reset IIS when there was a problem (although, having it auto-reset during off-hours was probably providing a superior user experience).
The first thing in all this that I want to push is documentation. I’ve never been in any organization, large or small, that was truly properly documented. No one has time, and that’s just a fact. Fortunately, there are solutions. Something I just recently learned about is PowerShell’s ability to create Word documents. Not more than a couple of weeks later, Richard Siddaway wrote a guest blog for The Scripting Guys that shows you how to make a Word file that will automatically document servers. This is a pretty basic process as presented, but it could be tweaked in many ways. Get your hands on copies of PowerShell in Depth or PowerShell and WMI or any number of other books that talk about systems administration automation and PowerShell, and you’ll be building some very high-powered documentation in no time. You can include BIOS information, driver versions, and all sorts of things. Of course, you’ll still need to manually insert sections that cover manual correction processes. But, the more you automate, the less that is necessary as well. If you’ve got a “Scripts” folder that contains all the automation routines for that system, you can have your script automatically read the contents of that folder and record the scripts that it finds. If those scripts implement comment-based help, you can even have your documentation script include the relevant portions.
Hmm, I may have just come up with an idea for a nice how-to article…
Anyway, the point is that there are a lot of routines in our jobs, whether we work in huge organizations or much smaller shops. Automation and documentation are the real cornerstones of our duties. If those are done well, then we can afford to be sick for a month. Our well-designed systems can do the daily work for us.
- If you’re using System Center Orchestrator, you have a tool that can help you with datacenter-wide automation. Since buying System Center probably emptied your budget, you’ll be happy to know that you can get an eBook to help you configure your runbooks at no charge. You an order a print copy as well, if you like, although that is not free.
- I don’t know how many people actually use the QoS capabilities of the Hyper-V switch, but it can sometimes be a real chore. Marc van Eijk wrote a nifty article that helps determine how your QoS is set in a readable tabular format. The bonus part of this article is a good explanation of the -ExpandProperty parameter. I’m sad to say that, despite trying to immerse myself in PowerShell over the last couple of years, I never noticed this parameter existed. I’ve been pulling data from sub-fields out using much more complicated tricks than necessary. Hopefully this will save someone else some time as well.
- Hopefully, you’re not using pass-through disks anymore. If you are and have seen the error of your ways, you’ll be happy to know that you can do the right thing and move to VHD/VHDX with very little effort.
- If you’re running Hyper-V Server in a cluster, you are (hopefully) aware of the Cluster Name Object (CNO) — the Active Directory object that represents the entire cluster. Hyper-V Server doesn’t care as much about the CNO as most other clustered applications, so you might not know much about it. I certainly didn’t know much until I got involved in a project where I needed to. Fortunately for you, there’s now an article that really handles this topic quite nicely.
- One tool I use fairly often is NetMon. WireShark is more common, and probably better, but I have less trouble with the standards and security people if I use a tool that’s distributed and supported by Microsoft. NetMon, however, is dead. It has been replaced with Message Analyzer. I haven’t yet had occasion to use it, but it certainly looks promising.