Tuesday, September 20, 2011

Using the Wrong Tool for the Wrong Job

In this ServerFault question, the user asks a question about why two VMs on the same Windows 2008 R2 DataCenter Edition host can't ping each other. If you ignore the actual question and look at the underlying details, you'll see that the user is using VirtualBox as his hypervisor. If you dig a little more, you'll see that he also has VMWare virtual adapters installed, which means that he probably has VMWare Workstation or Player installed as well. This brings me to the point of today's post: Don't blindly pass on native tools.

My comment on the question was, "Why on earth are you using virtualbox when you have hyper-v available?" It's a comment that was never answered, since the user apparently abandoned the question. I assume that the user was using this server for testing and not production. I make this assumption because the cost of Datacenter Edition is pretty high and I would hope that anyone spending that kind of money wouldn't turn to VirtualBox for server virtualization. Most likely, the user in question has a TechNet account and was playing around in a test environment. He could have a very justifiable reason for not using Hyper-V. He may have had pre-built VMs, for example; there are exceptions to every rule. I always prefer to use native tools whenever possible and would have opted for Hyper-V 10 times out of 10 in that situation.

Another example: If I'm working in PowerShell, I prefer to use the official Active Directory cmdlets instead of the Quest AD ones. There's nothing wrong with the Quest cmdlets, and they exceed the capability of the Microsoft ones in many ways. The problem is that if I'm in a pinch and not on the machine in my office, I probably won't have the third party tools readily available. It's more important to me that my environment is portable than slightly more convenient. This is a choice that every IT administration should consider.

One thing that is essential as an IT environment grows is consistency. Consistency allows for scalability and scalability makes everyone happy. Using native tools is one easy way to begin to introduce consistency into an environment. There is certainly a time and place for third-party add-ins and applications. There are at least a dozen that I can think of off of the top of my head that I couldn't do my job without. The problem is that too many people have it in their head that if there is a third party option, it must be better than the native tool and in many cases, this is just wrong. Now someone track that guy down and go enable the Hyper-V role for him already.

Thursday, September 15, 2011

Provisioning Computer Accounts with netbootGUID for WDS Deployment

At $EmployingUniversity we have a relatively unique spin on WDS image deployment. We use WDS with a single answer file for all labs that calls a PowerShell script that installs the appropriate software based on the computer name. In all labs, the beginning of the computer names designate what lab it's in, so it's easy for us to parse.

Since the entire process relies on the computer name being right, pre-staging computer accounts in Active Directory is a must. Our WDS servers are configured to not respond to unknown clients, which means that the netbootGUID attribute for each computer account needs to be set before WDS will respond with a PXE image. Luckily for me, Lenovo includes a barcode that has the serial number and MAC address on it. If you didn't know, WDS will respond to machines that have either their GUID set in netbootGUID or that has twenty zeroes and the MAC address in that field. It's much easier for us to use the MAC for this purpose, since Lenovo makes it easy to get that with a hand scanner.

Tuesday, September 13, 2011

Why improper terminology can be terminal.

I started this blog with the intention of sharing some of my experience as a Systems Administrator in Higher Education. I plan on it being mostly a rundown of technical solutions, experience with products that see a lot of play in education, the challenges of lab management vs corporate desktop management and all that fun stuff, but for the very first post, I'm going to tackle a universal topic that I see some people struggle with unnecessarily: terminology and communication.

On many occasions, our Systems Technicians will call me or send me an email to get some perspective on an issue that they can't solve themselves. Most of the time, I'm more than willing to lend them a hand if I have the time available, even though I'm not obligated to. If I can help to improve their knowledge, it will keep less crap from rolling uphill to me.