Windows Insider

TechNet's Dead: Time for IT To Move On

Instead of lamenting over the loss of the subscription service, Microsoft IT pros should focus on making software development easier in a post-TechNet world.

• By Greg Shields
• 02/07/2014

The discontinuation of the Microsoft paid TechNet subscription program still ruffles feathers among IT pros. Fellow Redmond magazine columnist Don Jones got an earful of comments a few months ago while pondering aloud in his IT Decision Maker blog post, "The TechNet Subscription Thing: You're All Nuts. Or I Am".

Central to the complaints is a Catch-22 felt in the void of the demise of TechNet: the MSDN alternative is too expensive and 180-day trial software is too limiting. IT pros needing to evaluate software are seemingly stuck between a time bomb and an unaffordable credit-card bill. Or, are we?

While I'll agree that the TechNet-to-­MSDN upcharge is a fare change sinful as usury, I disagree entirely that Redmond's 180-day alternative is unworkable. Yes, the pulled-in-a-thousand-directions nature of our profession forces some software evaluations to legitimately require more than half a year to complete. But these days, deploying OSes, installing applications and integrating components together can be automated without much up-front work.

In fact, you could argue that deployment automation has become a minimum requirement for today's IT pro. Many of the tools are free, and the knowledge to use them is freely available. The passing of TechNet only reinforces this idea. There just aren't that many excuses left for deploying OSes and applications the manual way.

Which all leads to the question I keep asking myself: If you can automate an installation -- and easily repeat it over and over again -- need you really care anymore about licensing time limits?

Microsoft System Center offers a most perfect example. Last month I referred to the suite as "big, complicated, overwhelming and radically interconnected." My first few installs of System Center in its entirety cost me two or three days apiece. That much time burned for a mere evaluation is wholly unacceptable in a world of 180-day timeouts.

Stop Waiting, Rebuild!
Rather than waste time petitioning for the return of TechNet, I choose instead to focus on making the deployment of its software a frictionless activity. Here, tools can help, like the Microsoft PowerShell Deployment Toolkit (PDT), which can be downloaded here. The PDT advertises itself as "a set of scripts and knowledge for automated deployment of System Center 2012 SP1/R2, including SQL, all prerequisites, and all automatable post-setup integration."

Tools such as the PDT do an end-run around Redmond's 180-day limit by reducing its implementation time cost to near-zero. If I need more time, I'll just click and rebuild the silly thing.

System Center isn't the only solution seeing the benefits of Windows Power­Shell deployment automation. Also exciting is the Windows PowerShell exposure you can build into Virtual Machine Manager (VMM) Service Templates. These templates keep getting more useful all the time. Consider a few examples only recently made available:

• Microsoft contributor Shawn Gibbs' Service Template Example Kit makes a good starting point and demonstrates the deployment prowess of Windows PowerShell by automatically deploying a single- or multi-tier Web services platform inside VMM.
• Additional service templates for Active Directory Domain Controllers in a separate offering, also from Gibbs.
• Michael Greene can deploy Exchange Server 2013 CU2 with a pair of templates, one each for a single server or multiple server environment.
• Jim Britt put together scripts and a service template to deploy a three-tier SharePoint 2013 environment.
• Sean Lillis constructed an impressive PowerShell App Deployment Toolkit that can automate the deployment of apps with a few Windows PowerShell commands.

Time-Bombless
Indeed, Microsoft hath taken away. I'll miss TechNet just as much as the next person. But Microsoft and the community seem to have giveth as well. These and other tools won't solve every evaluation limitation, but they're not necessarily meant to. They're designed to help us understand the usefulness of Windows PowerShell as a deployment automation tool.

Perhaps we shouldn't care about TechNet's passing. Our lab environments might not be as permanent, but we can be a lot smarter for it.