Windows Server 2003 Custom Support – Patch Forecast

All good server operating systems come to an end

For those of you, who haven’t heard: Microsoft is retiring its Microsoft Windows Server 2003 operating system on July 14. Well, as a matter of fact, Windows Server 2003 has been out of regular end-user support for a while but Microsoft is finally pulling the plug on it completely. That means, even for enterprise customers, there are not going to be any more security fixes or patches after July 14. Still, we are going to do a patch forecast for it today. Read on to see how.

Microsoft has been encouraging migration for a while, of course. However, that doesn’t mean everyone is going to be happily migrated on July 14 – for numerous reasons, ranging from legacy business software to lack of license budget. You name it, you’ll find a company having failed to migrate because of it.

So, for those laggards, who have a “Premiere support” package going for them, Microsoft is offering extended product support or “Custom Support” (in exchange for quite a large lump sum of money of course) for Windows Server 2003. There are two options to acquire this custom support: either the “feel happy” variant where you pay a really large sum of money and get all released patches or you pay a smaller quarterly sum and then are charged per patch you want to acquire, multiplied by the number of systems you want to install it on. If you only intend to get patches as a “worst case scenario”, the later option is clearly the cheaper one.

Nonetheless, this comes with multiple hooks attached: for example, only patches for English versions are provided, servers must be fully patched and – the major bummer: you need to install updates yourself. There is no WSUS or anything automating the process, you need to figure out patch deployment on your own. Of course, you can use a product like Microsoft System Center Configuration Manager – but that assumes you already have it deployed beforehand. You don’t want to start rolling out SCCM just for that purpose, really.

To top it all off, there’s another major hook waiting: of course, there’s no guaranteed security for Windows Server 2003 any more. If you intend to buy extended support on a “per-patch” basis, i.e. only for the event that a system gets compromised and you want tools to patch security holes – then you will first need to have some kind of “detection” mechanism in place that actually tells you that there is a problem (think IDS…). Suddenly this whole endeavor becomes more and more like a rabbit hole, you’re falling into.

There is no clear cut answer to the dilemma of dealing with servers running an outdated operating system like Windows Server 2003. And I won’t try to even start giving one – that could probably fill multiple book volumes.

The Patch Forecast

However, if you find yourself in the spot where you’re acquiring custom support for Windows Server 2003, I might have a tidbit of useful information for you. After all, you might be wondering how many patches you can expect to see over the course of the next year – either because you want to estimate the required effort to deploy patches or budget the costs of acquiring patches until you’ve completed migrating or isolating systems.

For this purpose, I’ve done some extrapolation based on historic patch counts. I’ve taken a listing on Microsoft’s patches and fixes, which were released for Windows Server 2003 since its inception, and split up their counts over each month. This gave me a mean and variance for number of patches per each month. The resulting patch forecast is in the diagram below.

Windows Server 2003 patch forecast
Patch forecast: Average patch count (and variance) per month for Windows Server 2003

Clearly, there’s a two-month cycle going on here; every two months we get a larger number of patches. Furthermore, we can deduce a few more bits of information: assuming this cycle continues, it is likely that we won’t be seeing many new patches in July; however in August, there’s going to be a bunch of new ones.

I believe this actually fits the picture pretty well: July 15, many hackers will try their skills on compromising Windows Server 2003 systems. This will lead to new bugs being identified, which will take some time to create a patch for. Those patches will then be delivered in August (unless it’s really urgent, which will probably get published “out-of-band”, as Microsoft likes to call it).

So, in summary here’s my wild guess for the next few months:

Month Count
August 2015 2 – 5
September 2015 3 – 9
October 2015 0 – 8
November 2015 0 – 13
December 2015 1 – 8
January 2016 0 – 6
February 2016 2 – 11
March 2016 0 – 8
April 2016 0 – 13
May 2016 0 – 6
June 2016 0 – 13

That totals out at somewhere between 8 and 100 patches. Admittedly, this is like guessing lottery numbers, but I’m still confident that we’ll stay close to the ranges I’ve listed. Time will tell if my patch forecast is completely off or hit the target right on the spot. I’m keeping my fingers crossed.

Installing PIP on Cygwin for PyGal

Well, this is a little off-topic, but nonetheless: lately I’ve run into the issue of installing PIP on Cygwin; I used a Python library called “pygal” to do some nice Risk Management charts and the most convenient way to get that running is via PIP.

Said library is usually installed via the Python plugin installer “PIP”.

While I started out on Linux developing the charts, I quickly realized that installing the library on a Windows machine might be a mixed bag of fun. However, after fiddling for about 15 minutes and doing some Google searches, I found a pretty quick resolution.

The error message I was seeing when I tried to run the regular PIP installer get-pip.py script:

Cannot fetch index base URL https://pypi.python.org/simple/
Could not find any downloads that satisfy the requirement pip in /usr/lib/python2.7/site-packages/pip-1.2.1-py2.7.egg

First, make sure you have “curl” installed; then, simply start a Cygwin shell as administrator and get the PIP 1.2.1 installer package using CURL.

curl -O https://pypi.python.org/packages/source/p/pip/pip-1.2.1.tar.gz 

I recommend going with this installation package, because the regular get-pip.py, which you can get from the PIP project site simply falls over – particularly if you are behind a proxy, as it seems.

Afterwards, extract the package: in a Cygwin shell go to the directory you previously extracted and run

python setup.py install

Then, make sure to have the libraries libxml2-devel and libxslt-devel installed (I used the regular Cygwin setup.exe for that purpose); afterwards start a Cygwin shell and run

pip install pygal

and you’re good! From there on out you have PIP on Cygwin – ready and running to install any other libraries you might be interested in.