Change management using Automated Server Documentation

We’re going to discuss the importance of working with the right tools to keep track of changes in your infrastructure. Besides, having automated server documentation always makes server monitoring and administration easier.

By keeping track of what’s going on in your infrastructure, you can pinpoint exactly what went wrong in minutes, whereas otherwise it would have taken you hours.

So far, most tools out there on the market are based on PowerShell scripts that were developed to emulate automated server documentation. The trouble with PowerShell is that it can generate the settings you want to set; however, it can’t spot changes or compare different server settings over time.

Picture this:

You have a PowerShell script for documenting 500 of your servers. But now you need to track changes manually.

System admin’s main goal should be to have a comprehensive inventory and documented configuration for all servers and workstations. Unfortunately, that’s not always the case.

Having complete insight into your servers at all times is no mean feat. If somebody did make a change, I can tell you with absolute certainty that he did not inform his fellow admins, because I’m guessing there’s no strict policy to take care of that.

What can you do to change this?

The key is automated server documentation

For starters, it’s best to have all the different server technologies documented in one place. We recommend Active Directory, but you can use VMWare as well, or Hyper-V, Citrix, SharePoint, or any other virtualization technology that you find suitable.

Let’s hold on a for a minute.

We need to address the problem that lies underneath the need to have comprehensive server documentation. Let’s go through some of the common use cases to try to wrap our heads around it. I mentioned above a rather familiar example to all of you. You get a call that the servers on which you have been working don’t seem to be working anymore. Where in heaven do you start looking for the reason why?

It would be much easier if you had some sort of documentation to go through and track changes, right? Of course. But you don’t have any, and now you need to find a solution.

The only option you have right about now is to just keep on searching and digging in hope of finding out what the heck happened. Then, you stumble on the fact that, yet again, somebody in your company (we’re not gonna say who; there’s always that somebody dude) made a change in the group policy.

A similar thing happened to one of our clients. And I bet it has happened to you too.

Moving on to the next case.

Just as when you convince yourself that you have everything under control, something happens with Office 365 and it’s not syncing anymore. When you go through all the imaginable scenarios, you notice that a consultant disabled the sync service on one of the servers.

Lovely. Just lovely.

The automated server documentation shows you that yesterday the sync service was running on the automatic option and today it stopped. Then you see that somebody has changed the service state to “disable.” And that can’t be good, since it breaks the sync with Office 365.

Change management implementation is no joke

You’ve already figured out that change management implementation is required. Whether we’re talking about a Citrix, Windows or VMware environment, creating a baseline configuration is essential.

I’m aware that it takes up time, and it’s a repetitive task involving a lot of copy/pasting. You have better things to do, right? The message I’m trying to convey is that you ought to have an automated server documentation tool that will reduce, as much as possible, the time and effort needed for change management.

How to best handle and track changes?

For example, you can set up certain rules for what kind of changes you allow and how they should be performed.

The most important thing is for YOU to be aware of any changes made to your environment. That includes settings, upgrades, and Windows updates.

And patching—yes, that’s the most important task out there. You need to have the same patch level on all your SharePoint WFE servers. That’s why you need to have a tool that can compare installed updates among different servers. It would also be convenient if it could tell you which patch has not been applied to certain servers.

So which solution might that be?

Remember Occam’s razor? In a nutshell, it’s the principle that states that the simplest solution is usually the right one. And that’s SysKit.

SysKit is an enterprise server monitoring solution with automated server documentation built in. With SysKit, you can create snapshots of the documentation so you can compare different servers or different points in time on the same server.

That in itself wouldn’t be of any value if it didn’t offer an option to compare different snapshots taken over time and track the changes, would it? That’s exactly what SysKit can do for you!

We built an engine so you can write a PowerShell script to get some settings, and then store that in the database. For example, if you type in PowerShell "Get-Service", the command will list the state of all the services on the particular server. Then the tool will create a snapshot every day for every server, and if somebody changes the state of any service, you’ll be able to see that immediately.

Automated Server Documentation

A second scenario could be to get you all the scheduled tasks on all the servers and create a central location where you can monitor whether some particular important scheduled task hasn’t finished successfully. If you don’t want the default Windows server scheduled tasks, don’t worry, you can just monitor the scheduled tasks created by the users.

The possibilities are limitless, because you can type any PowerShell script that is out there and get the settings, and store them in the database for review later.

Generate detailed server documentation using PowerShell scripts.

Try SysKit for free

Here’s a perfect deal for you:

SysKit has a free 30-day trial, and it’s fully featured, making it a great opportunity for you to test the heart and soul of our tool.

I’m curious to know how you like SysKit and whether it solved your server administration problems. Did you find a certain feature particularly beneficial to your server environment?

Give SysKit a try and send me your feedback, or leave a comment in the section below.