Updated on May 1, 2017 by Alan Sharp-Paul
We've been working with a lot of Windows shops recently and IIS configuration seems to be a big pain point for many enterprises. Other than a brief stint in mainframe purgatory after university, I started life as a .Net developer and these conversations reminded me of my fun with IIS back in the day. In reflecting on this, I realized that the developer/operations interaction around IIS configuration is a near perfect example of the type of conflict that gave birth to the DevOps movement.
As a .Net developer I certainly didn't always help. Good IIS configuration to me meant "my site is working," and I'd tweak every knob in the IIS Manager until I got there. Needless to say I had a tendency to annoy my sysadmins and security guys. They returned the favor though, with last minute performance or security tweaks often ruining my deployments.
Thankfully today there is a way to get control of this situation. A simple way to gain first visibility, then control of IIS Configuration. Unsurprisingly, this help does not come from the open source DevOps tools that usually treat Windows as an afterthought (at best). It also doesn't come from Microsoft itself, although their native DevOps focused toolchain is expanding. No, this is the UpGuard blog, so I'm going to show you how you can do this all with UpGuard. :)
IIS Configuration may appear user friendly in the IIS Manager, but the underlying changes being made to the XML files involved can be hard to comprehend, and even harder to track. Enter UpGuard. For the sake of this blog I'm going to play the sysadmin in charge of two IIS 8 web servers. As a developer, I'm a lousy one though, so I need all the help I can get.
To start with, I simply want to understand and compare the configurations on two production IIS servers, so I have connected them up to my UpGuard account. I just start typing their name in the search bar and find them instead of filtering through hundreds of servers.
I'll kick off a first scan on each server to pull back their configurations for analysis. This usually only takes a minute.
This is the first bit of magic you get from UpGuard. Once complete, the configurations are presented to me in a visual format that allows me to browse and filter all the key elements.
Better still, the scan detected IIS and has custom scan options for IIS specific configurations.
Great, now I have both servers scanned, including their IIS configuration!
Before doing anything else, I'd like to check that the two servers have the same configuration. With UpGuard this is as simple as searching for the server you want to compare configurations with from the left nav.
Now we're looking at a visual difference of the two machines. Gray indicates items missing from the IIS-PROD01 box. Blue indicates items that only exist on the IIS-PROD01 box. Yellow indicates items that differ between the two machines.
We can narrow down to only the differences by toggling off common items in the bottom left. This is now what we see:
We can also switch to a table view for a different visualization:
There are a few things in the list that interest me, but the thing that stands out most is that there is a difference in the web.config file.
UpGuard allows you to perform a raw file diff though so I can zero in quickly on the issue:
Yikes! These are production servers and one of them is pointing to a QA database. That is a major problem, so I'm very happy that got picked up!
There are other differences between the boxes that stand out as well. For example, those with a keen eye would have seen that the hotfixes were very different on each server. Thankfully expanding the table view gives me a link to the relevant KB articles, so I can understand the risk and plan the necessary updates:
To recap then, despite my shortcomings as a sysadmin, with the help of UpGuard I have:
Best of all, now that these servers are connected to UpGuard they will be getting scanned every day, with any important changes in their configuration being sent to me in my preferred format.
So, even if I'm not able to identify and talk to the developer responsible for making that database connection string change (hey, I'm a sysadmin now, of course I'm blaming the devs ;)) I can rest easy knowing that nothing else will change without me finding out.
Try it today by clicking the below button.
Misconfigurations are an internal problem that emanate from within the IT infrastructure of any enterprise; no hacker is necessary for massive damage to occur to digital systems and stored data. And the problem is pervasive, with Gartner estimating anywhere from 70% to 99% of data breaches result not from external, concerted attacks, but from internal misconfiguration of the affected IT systems.