Andrew Hale: IT Talk & Other Topics

In my last post on my vSphere upgrade project , I wrote about my frustrating experience when upgrading our Windows vCenter install from v5.1 to v5.5. In this post, I'll talk about upgrading everything else. vCenter, while important, it's certainly not the only aspect of a vSphere install. You've also got VMware Update Manager (VUM), ESXi (the hypervisor installed on your host servers), your VMTools installs on your VMs and your virtual hardware version. Let's get started because we've got a lot to cover.

One of the awesome things about OpsMgr is that if you can't find a management pack to do something you need done, you can write your own. At a basic level, you don't need to write a whole management pack. If writing your own MP is akin to writing a cookbook, making a custom monitor is like writing a simple recipe. We're going to write a basic custom monitor in the instructions below.

As mentioned in the documentation for importing MPs, there's 2 kinds of MPs. Sealed and Unsealed. Examples of sealed MPs would be the majority of those available from Microsoft. Examples of unsealed MPs would be the MPs you make for a custom monitor. With an unsealed MP, you can get in there, root around, change things, etc. With a sealed MP, you cannot. The way to change the behavior of monitors and rules in sealed MPs are to create overrides. Overrides basically step in to tell OpsMgr “Look, I know what the Management Pack said but we're going to do it this way, kapeesh?”

OpsMgr is best described as a framework rather than an application. After installation, you'll notice there's really nothing going on. You have to teach it what you want it to do. This is done with Management Packs. This post is designed to provide a basic explanation of the purpose of Management Packs and how to import one into OpsMgr, not to provide in-depth detail as to what they are and their inter workings. If you do want to know more about the nuts and bolts of Management Packs, click here.

OpsMgr supports both Agent and Agentless monitoring. Agent monitoring is generally easier on the management server as collection processes and tasks run on the target host rather than the management server. Agent monitoring is akin to “So $server, tell me about yourself.” while agentless monitoring is more like “$server, tell me about your friend. Is she single? What's the deal?” Agentless monitoring is primarily used for monitoring network devices rather than workstations or servers. In my environment, cacti is already monitoring network devices with pings or SNMP queries so we aren't using agentless monitoring in OpsMgr in our environment. However, should you want to know more about it in the future, you can read all about it here. Below are instructions for deploying an agent in OpsMgr.

For longer than I care to admit, my DPM server has had the same error every night about an auto-protection failure on one of my SQL servers. I've looked into it before but never came away with anything useful until recently. I've finally found information on how to fix this annoying issue. The Advanced Information link in the error will tell you to make sure WMI is in a good state on the machine. The error itself isn't very descriptive. It'll look something like "DPM could not enumerate SQL Server instances using Windows Management Instrumentation on the protected computer $serverFQDN."

Protecting a server in DPM is a relatively simple process, but there's a couple extra steps for protecting Exchange 2013 that I wanted to discuss. This is assuming you've already got an Exchange 2013 server(s) and you want to back it/them up with DPM 2012 R2. You'll need two things before you go creating your Exchange server protection group on your DPM server. Firstly, on both your DPM and your Exchange servers, you'll want to make sure you have Visual C++ redistributable for Visual Studio Update 4 installed. I've found this step was only necessary for protecting Exchange 2013 with DPM 2012 R2. For say, protecting Exchange 2010 with a different version of DPM, then you only need the second item discussed below. Secondly, you'll need t copy a couple files from the Exchange server over to the DPM server. Specifically, you'll need to copy the ese.dll and eseutil.exe files, which are usually in C:\Program Files\Microsoft\Exchange Server\V15\Bin. Copy those ...

When I worked in a Technical Support role, we installed Windows by disc. You know, next, next, computer name, next, accept the End User License Agreement, etc. It wasn't because I did it so long ago. My employer at the time just liked doing things manually for some reason. The way most modern IT shops work isn't by installing Windows "by hand" everyte a new machine comes in. They automate it by turning a single vanilla Windows install into an image they can push out or deploy to a new machine and any other new machine after that. This allows you to install windows on multiple computers simultaneously and with zero input from you, the IT guy/gal. There's a number of steps to creating a System Image but I'm only going to discuss the SysPrep tool and what role it plays in creating an image. Image-based installation is a method cloning or copying pre-configured OS onto target computers. This works for both servers and/or workstations.

DFS stands for Distributed File System. It's not a particularly new technology (it's been around for several Windows versions now) but it comes with a number of strengths and weaknesses. Before we dive into DFS and what it can do for your environment, let's look at how messy traditional file servers can become.

I've talked a few times about backups and one common word that comes up when talking about backups is replication. Well, what is Replication and how does it differ from backups? Replication is the process of duplicating all data to another source in real-time, or near real-time. It's very different than backups. Let's look at why.