To be a good engineer, you need a Testlab. End of sentence.
You need it so you can peruse flights of fancy, like making some web services, trying out that new language and other endeavors perhaps not specifically related to your day to day work.
It HAS to be your own too! You can’t just use the one at your work. If things go awry between you and your company, you definitely don’t want to lose your livelihood AND your hard-earned testlab in the same stroke! This is also why you don’t want to have your life insurance purchased through your work too (or if you do, make sure you don’t get fired and die in the same day).
In consulting, I would get assigned to a project and have a month or so to come up to speed on new technologies. I found that when I had a testlab, it was so much quicker to get working, just make a new VM, domain join it and have SQL installed and ready for a new SCCM, Scorch, Air-Watch, whatever. In fact, the periods when I did the best engineering work over my career closely line up to the times that I had a working testlab available to model my customer’s environments and make mistakes on my own time, not theirs.
I hope you guys will tolerate a little bit of navel gazing for this post!
Today at the FoxDeploy Global Headquarters in Marietta, Georgia, we counted down to a very special milestone here!
1 MILLION HITS!
First and foremost, thank you very much for sticking with me through the years and through the awesome engagement, comments and corrections! In this post, we’ll take a quick look back at some of the history of the site, what I’ve learned, some hard knocks and some of the fun to look forward too!
This post has done well over the years, accruing a little more than 1,000 hits over the years. I’m not why this might be, but this post on how to recover your password spikes every year after Cinco De Mayo. What may have happened so that people accidentally locked themselves out?
This post slowly gained some traffic and gave me confidence to focus on my writing in the evenings, but children would prove to make that a little bit difficult. Continue reading →
Oh boy, this has been a rollercoaster of emotions. But guys…we made it. We have finally, and definitively answered what happens to WinRM with HTTPs when certificates expire. If you’re curious about why this is a big question, see my previous posts on this topic.
Up until now, I’ve been able to say, conclusively, that WinRM generally seems to work, even as Certs expire and are renewed. But I’ve never known why: did WinRM automatically update the certs? Does Windows just not care about certs? What is the purpose of life?
Well, I can now shed light on at least some of those questions. I knew what I needed to do
Record a WireShark transfer and extract the certificate to tell definitively, which cert is being used to validate the session. Then we’ll know what happens.
Setting the stage
Two VMs, one domain. Server 2016 server, connected to from a Server 2012 R2 client. Newly created WinRM capable Certificate Template available to all domain members with a 4 hour expiration and 2 hour renewal period.
With the stage set, and the cert was present on both machines, I ran winrm quickconfig -transport:https on each, then made sure they could see each other, and remoted from one into the other. I recorded a WireShark trace of the remote session, uh remoting, then ran a command or two, then stopped recording. Then I opened the trace.
Recently I’ve gone a bit of a blog and twitter hiatus, because the FoxDeploy family just inherited a new child-object! Born February 2nd at 2:02 AM, I had my first son!
I promise I’ve got some nice posts on the way, including the anticipated Part V of my GUI series, as well as Part V of the DSC guide…including a new tool I’ve been working on with some help from my friends in Redmond…