Just ran into an issue where some old Windows server 2008 installs were starting to pop up with could not reach key management server (KMS), and thus bouncing to not genuine. Spent some time searching around for fixes, including running slmgr, swapping out dns, etc. None of it worked.

Turned out the solution was actually easier:

The network driver upgrade will force a reboot. Once that’s done, the instance will be able to activate.

There are a lot of different answers to this question, most which work for older versions of Windows but perhaps not Windows 10.

Once you’ve got the method down, though, it really is straightforward:

  1. Open an admin Powershell window
  2. Create a self-signed cert for your domain. Here, I’m making a wildcard cert for *.test.com:
    New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname *.test.com
  3. Create a password using ConvertTo-SecureString and export the cert. Replace the thumbprint and path with values for your environment:
    $CertPwd = ConvertTo-SecureString -String "foobarpassword" -Force –AsPlainText
    Export-PfxCertificate -cert cert:\localMachine\my\<thumbprint from new cert command above> -FilePath c:\dev\cert.pfx -Password $CertPwd
  4. Open Certificate Manager and import the certificate under Trusted Root Certification Authorities.
  5. Open IIS manager and create an HTTPS binding for the site using your new cert.
  6. Reboot (to clear Chrome cache etc.)

Software is a unique industry because it is constantly self-improving its own productivity. It acts as an accelerating concept like interchangeable parts or the assembly line, rather than a linear incrementing body of study. The use of software applies that acceleration to everywhere it is used, including itself.

So why don't we have lower skilled people building software by drag/dropping building blocks as many have predicted? After all, we have that self accelerating improvement applied to software over decades. Exponential increases in programmer productivity would suggest that lower skilled people could be employed, dropping average salaries, right? That kind of logic leads toward thinking there is a tech worker shortage.

There is no "tech worker shortage". Companies might not be able to find low priced labor, which they believe they should be able to do based on the reasoning above. But like the linked article quotes: "I'm not sure that qualifies as a shortage, any more than my not being able to find a half-priced TV."

What's wrong with this train of thought?

First off, there are many "building block" type software packages available. It's just hard to see them because the demand for new and more complex software has grown so dramatically. There are website builders, time tracking software, component based development tools galore. They've satisfied an enormous amount of what people wanted to do 20 years ago. But in the meantime, demand and complexity of requirements have grown exponentially. The acceleration of productivity is just barely allowing the software industry to run in place.

At the same time, there is an increasing demand for custom built software that is tailored directly to the data and business logic of the client, particularly in the LOB arena. It used to be too expensive for anything other than massive companies to afford custom development. Now, productivity increases allow even small businesses to have staff or contract programmers building software to enhance their business, again, pushing demand for programmers back up.

Finally, and most importantly, software is getting more complex in general. The requirements are bigger, in features, volume, and reliability. The software enabling productivity increases is sitting on layer upon layer of other software packages. 20 years ago, you'd build a simple desktop app in C++ or VB. Or a CGI app for web. It'd be a couple of components, sitting on a single server (or maybe a cluster of two machines if you were really rich and important), with a simple database. The "cloud" was still a twinkle in Jeff Bezos's eye until less than 10 years ago. Now, you have an MVC app using 20 different packages imported by a package manager running on a load balanced set of web servers, a database sharded across several servers, some memcache servers on the backend to accelerate data access, some varnish caches on the front to accelerate static pages, some CDN to accelerate content. Etcetera etcetera.

A senior software engineer that knows all of the possible tools and can orchestrate them together, someone that knows the concepts from the underlying cpu/cache/memory up to the networked cloud, and can use the right tool (out of 100s) for the right job, getting the job done (not to mention done right, and done fast) -- that person's value and productivity is multiplied by the layer upon layer of tooling developed over the past couple of decades. They can do the work that 10 senior people did 10 or 15 years ago, or 100 junior devs, while the junior dev's productivity has remained about the same.

That dichotomy between productivity of a senior and junior is what is throwing big companies for a loop. Their mental model of staffing is hierarchical, with a couple of seniors at the top, then some mids, and a bunch of juniors filling out the crowd. Their sort of thinking around cost is what leads to outsourcing to low skilled body shops. They can't fathom that it would be cheaper and more effective to hire a bunch of seniors and a couple mids to get the job done right -- they just see the dollar signs on the salary packages and scream "tech shortage".

Software development is becoming another market with winner-take-all dynamics. Sure, anybody can get started easy and for free. But the thousands of hours invested over years that it takes to gain an innate understanding of the innumerable tools and techniques involved? That’s another matter entirely.

The WiX docs on the topic (Integrating WiX Projects Into Daily Builds) give a good starting point, but are incomplete, at least for the recent builds. Two additional things they forget to mention: WixToolPath needs to be an absolute path for the Wix.targets project to function properly, and WixExtDir needs to be set to WixToolPath.

To build WiX from the binaries with MSBuild, do the following (requires MSBuild 4):

  1. Snag the binaries from the latest weekly build: WiX Weekly Releases
  2. Extract them into a folder you can access with a relative path inside your source control root
  3. Edit all of your .wixproj files and do the following snippet before the <Import Project="$(WixTargetsPath)" > tag:
  4. Update the RELATIVEPATHTOWIX to be a relative path that points to the WiX binaries you extracted in step 2.

With every new SQL version, it seems there are more and more headaches getting it installed, unless you're installing it on a clean OS install. I ran into error after error trying to install on a Vista box that had been upgraded to Windows 7 and had SQL 2005 already installed.

I finally dug up a blog entry that helped me out on Mark Michaelis's blog. It took a bit of digging, so I figured I'd give him a bit of google juice: SQL 2008 install registry issues and uninstall rollback techniques.