Where have all the Windows Service Packs gone?

Have you noticed the lack of Service Packs for Windows 7 / Server 2008 R2?

We had Service Pack 1 more than 2 years ago and since then just a constant stream of updates. Windows 7 desktops are going to be around for a very long time replacing XP as the de facto Windows version to use in corporate desktops. By the time they expire in 2020(!) hopefully the newer versions of Windows / Android / IOS + current unknown OSs will provide a new paradigm that is better (I have my doubts).

The number of updates every month has stayed steady meaning there is a myriad of updates for a 'fresh' Windows 7 SP1 install. This was brought home the other week when a newly arrived Dell Laptop installed updates and rebooted for a good half an hour. Keeping baselines of updates is becoming unpractical with this number of updates going on. This is a real problem for servers where you want them all patched to the same level without going through a WSUS high frequency update route.

In the past on internal servers we used to apply Service Packs as the building block of Windows build level. If there was a specific reason to apply a patch we would apply it. More often than not it would more likely be a version of the .Net framework linked to an application like SQL Server. Most internal servers are showing vast lists of individual patches required. When servers can obtain typical uptimes of around a year I don't like putting on non required patches and rebooting them every month or so unless there is a very good reason to do so. Rebooting them once per year for a Service Pack seems ideal to me.

The cadence / patch mechanism of Windows releases has changed dramatically over the years. Remember computer magazines with attached disks of  NT4 SP3, SP4 or SP6a as a mechanism of distributing patches! Since then we had Windows 2000 which had 4 Service Packs, Server 2003 which brought in the R2 OS refresh cycle, 2008, then 2008 R2 and now 2012 / R2.

If you look at the release dates of recent software we have Server 2012 R2 in 2013 just a year after Server 2012. With Google and Apple adding new features and not just patches with almost every update every few months. MS have been forced to follow suit. I am running Windows 8.1 on my laptop and it is more a Service Pack on Windows 8 than it is a new release (I know there are new features, well hidden by the dumbed down GUI), at least the 8.1 gives a clue to the lack of fundamental changes. But with Server 2012 R2 a whole raft of new server features have been added. It could be the new update regime without Service Packs is better suited to Windows Azure with fully automated patching or they just build new base images containing the patches already incorporated for cloning on a schedule. It might be that Windows 7 / 2008 R2 will never see another Service Pack - in which case installing a new Windows 7 machine could install literally hundreds of updates to bring it up to date. Maybe keeping base images with incorporated selected updates will be the way to go. At the moment I would be happy to install a Windows 7 SP1 desktop and let it catch up on updates using WSUS plus a daily reboot over a few days. With mainstream support for Windows 7 ending in 2015 we really could do with Service Pack by then!

SQL Server and Exchange Server do (currently) have a steady and structured release system of updates and Service Packs making patching easier to plan. It is a pity that Exchange updates have been such poor quality of late. I would rather run reliable old software than up to date software with broken features myself.

Maybe the days of Service Packs are gone. Get a 'new' OS every year instead! I have heard little from MS on the subject but it must be discussed frequently. If so it makes life just a little harder for on premise installations...

Install Sysinternals suite in environment path variable to save time

One thing I have been doing for years and saved me lots of troubleshooting time is to install the Sysinternals Suite on every server and put that directory into the path environment variable so you can run any Sysinternals application straight from any CMD or Powershell prompt.
At the time of writing the download link was:
http://download.sysinternals.com/files/SysinternalsSuite.zip

I always uncompress the sysinternals zip file and install them in the same directory (eg c:\sysinternals) for consistency. Once you have installed them add the path of that directory to the Windows path environment variable.

Run this in an elevated Powershell prompt to add your new path to the current path.
[Environment]::SetEnvironmentVariable("Path",$Env:Path + ";C:\sysinternals", "Machine")

Now if you (or anybody else) opens a command prompt or Powershell prompt you can run your favourite Sysinternals commands without navigating to the directory.

Since you always install to the same directory it is easy to update all the servers from a central repository by robocopying a new installation to overwrite the old one. The great thing about Sysinternals tools is that they run without any installation.

It goes without saying that tools of this power so easily run can be a significant security risk so make sure you weigh up the pros and cons in your own environment before 'installing' them.

Openfiles Maintain Objects List global flag behaviour change in Server 2012?

The very useful command openfiles documented below:
http://technet.microsoft.com/en-us/library/cc732490.aspx
Needs the Maintain Objects List global flag set AND A RESTART to track local file handles in Server 2008R2, and is turned off by default to reduce overhead, although I have never seen documented how much overhead it may generate.
However in Server 2012 the command generates a strange message on checking the status.
Server 2008 R2

Server 2012

I suspect the flag is pre-set to ON in Server 2012, and the reason it is on by default is that the new Server 2012 Powershell cmdlet Get-SmbOpenFile requires the same code under the covers and MS wanted it to work straight out of the box. If that is the case it does make you wonder how much overhead is really involved by setting it on… If anyone knows any more about this behaviour please comment.

An end to the scalable networking fiasco?

If you run a lot of Windows Servers chances are you will have come across the disgraceful debacle of 'Scalable networking', where the network card takes corrupts some of the load from the OS, thereby improving destroying performance.

This has been a shambles since it first appeared in Server 2003 (service pack 2 as I remember). Instead of realising performance increases you will infrequently but invariably come across some unfathomable glitch that makes a mockery of the whole technology.

When you first come across this 'feature' many hours will be spent trying to track down bizarre problems that just don't add up.
I have come across this on several occasions when I was naive to the problem, most notably when Exchange 2007 OWA clients (running on W2K3 sp2) would not load properly. MS support eventually suggested I turned off scalable networking and everything worked perfectly in an instant.
Other problems include SQL servers with a fraction of the network throughput and sporadic delays. Whenever we replace servers nowadays one of the items to check is the scalable network settings, since you can never tell what will happen with network card A on OS B until you have tried changing all the settings in your own environment. Performance can vary dramatically, and sometimes some settings make your system practically unusable. If in doubt turn it all off, both in Windows and the network card itself. This problem remains in Server 2008R2 running on the latest Dell servers, whereby you need to check which settings give best performance.
There is no logical reason for the sometimes massive performance variations. As I said disgraceful. This story from MS itself perfectly sums up this shameful time wasting technology...
http://blogs.msdn.com/psssql/archive/2010/02/21/tcp-offloading-again.aspx

Here are my own notes on this area when I install 2008R2 on our latest Dell Servers found by trial and error for our environment - mainly SQL and file traffic (we standardise on a model/network hardware as much as possible so we we are not having to do too much retesting in this area)
install broadcom package
netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled

****Broadcom - defaults (ie scalable network settings on the NIC are ON - how bizarre is that)
****Check file copy speed etc
For reasons unknown I have always seen more problems in this area with Broadcom - whether this is statistically valid or not I don't know, but I now specify Intel network cards as they have always been my favourite since NT4 days, and disable the Broadcom network cards.
If you run into problems I recommend you change the settings on both the NIC and Windows itself as there is no correct setting - trial and error only I'm afraid.
I know the next time we buy another batch of servers (the NIC etc will be different model by then) we will need to try the settings again to see what works best.

I personally would put this shambles as the most disastrous Windows Server technology in the last decade. It should either be sorted out once and for all or simply be dropped. I have never worked out if it is a bug in Windows itself or the network card manufacturers at fault.
I have seen the potential performance gains that this technology can give but reliability has to take preference over potential performance gains.

Addendum
I am hoping Server 2012 will solve this problem once and for all as it has NIC teaming baked into the OS and it is likely a lot of work has been done fixing any glitches in this area. We will see...