Server 2012 - Out with the Old, In with the New

I came across this Technet article that details features that are being removed or deprecated as of Windows Server 2012.  Below are a few of my inane and probably ill-informed thoughts:

"AD Federation Services - Support for using Active Directory Lightweight Directory Services (AD LDS) as an authentication store is removed"

I guess this means AD FS can only store authentication information in AD now? I know that some people use it, but I think I wouldn't mind seeing AD LDS go altogether.

"Oclist.exe has been removed. Instead, use Dism.exe."

I'm all for consolidating redundant tools and putting all the various bits of related functionality in one place.

  • "The Cluster Automation Server (MSClus) COM application programming interface (API) has been made an optional component called FailoverCluster-AutomationServer which is not installed by default. Cluster programmatic functionality is now provided by the Failover Cluster API and the Failover Cluster WMI provider.
  • The Cluster.exe command-line interface has been made an optional component called FailoverCluster-CmdInterface which is not installed by default. Cluster command-line functionality is provided by the Failover Cluster PowerShell cmdlets.
  • Support for 32-bit cluster resource DLLs has been deprecated. Use 64-bit versions instead."

I'm also behind the move to a united effort based on Powershell. Knowing that you can use Powershell to manage all the parts of your server, as opposed to a hundred separate CLI executables is a good thing. I also like deprecating 32-bit junk... although that is going to cause some heartburn for some enterprises, as uprooting 15 year-old technology in a big enterprise can often be like pulling teeth. Actually more like getting approval from Congress first before you commence pulling teeth.

"Support for Token Rings has been removed."

Oh no what ever will I do without my token ring network!? Oh wait that's right, 1972 called and they want their network back. Next thing you know they'll be telling me to get rid of Banyan Vines too!

"Versions of Microsoft SQL Server prior to 7.0 are no longer supported. Computers running Windows Server 2012 that connect to computers running SQL Server 6.5 (or earlier) will receive an error message."

This is another interesting one. A lot of very large companies rely on really old SQL servers... I see a lot of painstaking migrations in my near future.

  • "ODBC support for 16- and 32-bit applications and drivers is deprecated. Use 64-bit versions instead.
  • ODBC/OLEDB support for Microsoft Oracle is deprecated. Migrate to drivers and providers supplied by Oracle.
  • Jet Red RDBMS and ODBC drivers are deprecated."

Ouch again! Microsoft seems to really be emphasizing "stop using old shit, k thx."*

(* not an actual Microsoft quote)

"The Subsystem for UNIX-based Applications (SUA) is deprecated. If you use the SUA POSIX subsystem with this release, use Hyper-V to virtualize the server. If you use the tools provided by SUA, switch to Cygwin's POSIX emulation, or use either mingw-w64 (available from or MinGW (available from for doing a native port."

I for one am glad to see this go. Just make a *nix VM if you need to fork() so badly.

  • "The WMI provider for Simple Network Management Protocol (SNMP) is deprecated because the SNMP service is being deprecated.
  • The WMI provider for the Win32_ServerFeature API is deprecated.
  • The WMI provider for Active Directory is deprecated. Manage Active Directory with PowerShell cmdlets.
  • The WMI command-line tool (Wmic) is deprecated. Use PowerShell cmdlets instead.
  • The namespace for version 1.0 of WMI is deprecated. Prepare to adapt scripts for a revised namespace."

All good stuff. Dropping off the really old vestigial junk, and consolidating everything under the banner of Powershell.

There are a few more bullet points in the original article, but those were the ones I cared most about. I'm a little surprised to see them cutting ties with 32-bit SQL, but I'm glad they're doing it. It's going to cause some work for people (like me) who still use large, distributed SQL systems to start migrating, but we'll all be better off in the long run.

"SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Vulnerability"

Good afternoon, and sorry I haven't posted in a while.  I've been staying pretty busy.

So if you have been in IT or working with servers for very long, you're probably familiar with this guy:

*The most annoying appliance ever?*

So in case you're not familiar, this little guy sits in your datacenter, scanning your network, and spits out reports about all the potential vulnerabilities it finds on all your network devices and servers. Then you get to go fix all of those potential vulnerabilities so that you can maintain PCI compliance and such. Sometimes it's as easy as applying an OS patch. Sometimes it's making an obscure configuration change to an application that is just as likely to break the application as it is to plug the vulnerability.

"SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Vulnerability" was a particularly annoying one. I'm making sure to put the exact title of the vulnerability as Qualys puts it so that maybe someday it will show up in somebody's Internet search and help them.  I wasn't so lucky.  There really wasn't much information out there on this particular vulnerability that applied to me; or so I thought at the time.  It seemed like the only information I could find on this vulnerability either pertained to Linux servers, or particularly to IIS on Windows Servers.  My server was a physical HP machine running Windows Server 2008 R2 with all the HP software installed... and I wasn't the only guy on the team who was hung up on this particular vulnerability.

Qualys will tell you that this vulnerability is tied to CVE-2011-3389 and so my first instinct was to look for the Microsoft-issued security advisory.  The particular Windows patch it was suggesting was already installed, and I didn't even have IIS installed on this server anyway.  This led me down the path of modifying system-wide registry settings like this, to no avail.  The same vulnerability kept showing up on subsequent scans.

So after taking a step back and thinking for a second, it occurred to me that Qualys was reporting this particular vulnerability on port 2381.  That's the port used by the HP System Management Homepage.  (A glorious piece of software... please note the sarcasm.) So maybe there's a configuration change I can make just to the SMH... and after Googling through some HP documentation I found this gem:

C:\hp\hpsmh\bin>smhconfig.exe -Z 'RC4-SHA'

That should restrict the cipher modes that the SMH is allowed to use to only RC4-SHA. (With a capital Z.)  But my version of smhconfig.exe didn't implement the -Z switch, so I updated it via the Proliant Support Pack, and then was able to successfully run the command.

Problem solved. Vulnerability gone.

It was only after I went through all that, I went back to the original CVE-2011-3389 page and noticed this.  :P

SQL Server - Unable to Generate SSPI Context

The different sorts of authentication mechanisms in play in a Windows network can be pretty complex.  So when someone asked me, "Why do I get a 'Could not generate SSPI context' error when I try to log in to a SQL server?" I knew that there could be several answers to that question.  Go ahead and Google it yourself -- you won't get a definite *This is absolutely your problem* sort of answer.

First I remembered that there was a situation where RSA SecureID tokens (essentially certificates for our purposes) were used for various authentication tasks in the domain, and if one tried to authenticate to a SQL Server with Windows authentication without having one's RSA token plugged in, the "Could not generate SSPI context" error would be generated. Plug the SecureID device into a USB slot, and you'd log in to the SQL server just fine. But I knew that policy was not an issue in this situation...

Then I thought about how services not having their SPNs registered with Active Directory can cause authentication problems.  Specifically, if a SQL Server doesn't have its SPN registered properly in Active Directory, Kerberos authentication cannot be used.  But that still shouldn't prevent you from authenticating whatsoever... it'll just drop you down to NTLM instead of Kerberos.

Also, I was able to perform a logon with Windows auth to the same SQL Server at the same privilege and security level as the user, so I knew it had to be something at their end.

The only other thing I could think of was that something was just wrong with their security token that was confusing their SSPI?  Maybe it was corrupt somehow?  I'm not sure.  So, I recommended that the user run "klist purge" to purge all their domain controller-issued tickets, knowing that they would be refreshed as soon as they requested access to a domain resource...

Bingo.  Problem solved.

Windows Internals 6th Edition, and a Bonus Powershell Script

I started reading Windows Internals, 6th Edition about a week ago. In case you don't know, it was authored by Mark Russinovich, David Solomon and Alex Ionescu. It's been great so far, packed full of ridiculously detailed technical information on how the Windows operating system works at its most fundamental level. And there is no one on the planet who knows more about that very topic than those three guys. Weighing in at about 750 very dense pages - and that's just part 1 - it's not for the faint of heart. But if you do have the fortitude and desire to consume this kind of material, you'll be rewarded with being able to explain to people what the differences between the Kernel and the Executive are, how to examine the Kernel Processor Control Block in Windbg, etc.  Good stuff.

Now, context switch:

I wrote this little Powershell script a few days ago to help me automate some SQL stuff.  I realize that there are already other ways to do distributed SQL queries and so I'm sort of reinventing the wheel here, but hey... now it's in Powershell. Automation-ready and no Management Studio required.

	Name  : Execute-DistributedSQLQuery.ps1
	Author: Ryan Ries
	Email :
	Date  : June 07, 2012	


	This script executes a SQL query across multiple SQL servers as defined
	either on the command line or in a file.

	This script executes a SQL query across multiple SQL servers as defined
	either on the command line or in a file. Use the -Servers parameter to
	define multiple SQL servers on the command line. Alternatively, use the
	-File parameter to specify a text file of SQL servers, one per line.
	Use the NonQuery switch if your SQL statement is not a SELECT-style
	query, but a stored procedure or other operation. If Username and 
	Password is specified, then SQL authentication will be used. Otherwise,
	SSPI will be used. If you want to specify a different database for each
	server, use a ! between the server name and the DB name. (On either
	the command line or in a file.) Otherwise, "master" will be the default
	database and you must specify the desired database name as part of
	your query.
	Use Get-Help <script> -Full for examples and more info.

	.\Execute-DistributedSQLQuery.ps1 -Servers SQLSERVER01,SQLSERVER02 -Query "SELECT * FROM DB.dbo.Inventory"
	Queries the Inventory table in the DB database on both SQLSERVER01 and SQLSERVER02. Uses SSPI authentication.
	.\Execute-DistributedSQLQuery.ps1 -File servers.txt -Query "SELECT * FROM DB.dbo.Inventory"
	Runs identical queries on each server found in servers.txt.
	.\Execute-DistributedSQLQuery.ps1 -File svrs.txt -Query "SELECT * FROM Inv" -Username ryan -Password xyz
	By specifying a username and password, the authentication method is changed from SSPI to SQL authentication.
	.\Execute-DistributedSQLQuery.ps1 -File servers.txt -Query "EXEC Clear_Inventory" -NonQuery
	Use the -NonQuery switch if executing a SQL statement that is not a SELECT query.
	.\Execute-DistributedSQLQuery.ps1 -Servers SVR01!DB1,SVR02!MgtDB -Query "SELECT * FROM Inv"
	You can specify a separate database on each server by separating the server\instance name and the database
	name with an exclamation mark. This is useful if you want to run an identical query on multiple SQL
	servers with differently-named databases. The exclamation mark syntax works both on the command line
	and in a file.
	.\Execute-DistributedSQLQuery.ps1 -Servers SVR01,SVR02 -Query "SELECT * FROM DB.dbo.Inv"
	Remember that if no database is specified by using an exclamation mark, the master database
	will be selected by default, so to run a query on a different database on the server, you must
	specify that in your query.
      [Parameter(Mandatory=$false)][ValidateScript({Test-Path $_ -PathType Leaf})][String]$File,
	  [Parameter(Mandatory=$true)] [String]$Query,

If(($Servers -And $File) -Or (!$Servers -And !$File))
	Throw "You must specify either -Servers or -File; not both, not neither."
If(($Username -And !$Password) -Or (!$Username -And $Password))
	Throw "You need to specify both Username and Password if using SQL authentication."

If($File) {	$Servers = Get-Content $File }

ForEach ($_ in $Servers)
	If($_.Split("!").Count -gt 1)
		If($_.Split("!").Count -gt 2)
			Throw "Error parsing Server.DB name. Did you use too many exclamation marks?"
		$Instance = $_.Split("!")[0]
		$DB = $_.Split("!")[1]
		$Instance = $_
		$DB = "master"
		$ConnectionString = "server=$Instance;database=$DB;user=$Username;password=$Password"
		$ConnectionString = "server=$Instance;database=$DB;Integrated Security=SSPI"
		$SQLConnection = New-Object System.Data.SqlClient.SqlConnection $ConnectionString
		$SQLCommand = $SQLConnection.CreateCommand()   
		$SQLCommand.CommandText = $Query
		$rdr = $SQLCommand.ExecuteNonQuery();
		$DataAdapter = New-Object System.Data.SqlClient.SqlDataAdapter ($Query, $ConnectionString)
		$DataTable = New-Object System.Data.DataTable
		$DataAdapter.Fill($DataTable) | Out-Null
		$DataTable | Out-GridView -Title "$Instance      DB: $DB"

Server 2012 Goodies

Windows Server 2012 is getting close now.  Of course I've been playing with the release candidate.  One of my favorite things so far is how easy it is to turn off the GUI, therefore turning the server into a Core installation. You can also turn off the GUI, but leave the Server Manager enabled.  Another thing that I think is going to be awesome is the Hyper-V Extensible Virtual Switch. It's obvious that Microsoft listened to its customers when they complained that the Hyper-V Virtual Switch in 2008 R2 was a bit anemic/featureless.  This is a huge enhancement, in my opinion, and is going to introduce some very interesting opportunities, such as migrating a VM to another datacenter without changing its IP address, etc.

There are a lot of other new enhancements.  I found this free eBook entitled Introducing Windows Server 2012. Check it out; there are tons of neat and enticing bits of information in there.