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…
System Center Orchestrator–formerly Opalis Orchestrator– and now lovingly called SCORCH by its fans is a powerful automation tool, but there are a lot of gotcha’s that makes it difficult to begin rolling out in the environment.
For instance, it’s desirable to Return Data back from a Runbook either to a parent runbook, or to Service Manager or another system to act on the results. As an example, imagine a runbook that can fork in many places and then return an exit code that we then send off to a parent runbook to register as an Operations Manager event, or to send in an e-mail. There’s lot of options. Well, even with this common scenario, people still run into a brick wall when they experience the following
When a runbook has valid data pushed to the SCORCH Databus, adding a Return Data step results in a blank window like the following.