Checking certificate expiration with PowerShell

Had an idea to write some (PowerShell) script which will check and maybe notify me of certificates that are nearing expiration for a bunch of (public) sites that… somewhat matter to me. šŸ˜Š

As it turns out, someone already had this idea and wrote very nice PowerShell script that does just that, available here – thank you!

While testing it, there were sites on which the script worked just fine, and there were sites on which I got errors like this one (Error: “String was not recognized as a valid DateTime.”):

Seems to be connected to my regional settings (I know… who would ever use hr-HR instead of en-US, but… šŸ˜Š) and date/time formatting:

I’ve tried to fix it in a couple of ways, but the one that finally did it (for me) was explained on Dan Sheehan’s blog (thanks!), implemented on lines 25-26 below.

So, my adapted script looks like this (and works with my hr-HR culture):

It provides the following output (which can be further customized per your needs, of course… and I know – need to insert some line breaks, convert output to HTML, send it via e-mail, … it’s a start! šŸ˜Š):

Note that I’m returning expiration date “the Croatian way”, by using the following formatting:

Hope it helps someone (and #kudos to original authors)!

Cheers!

Beware of the proxy!

Had a (somewhat) interesting case the other day – after (finally) upgrading my Windows Admin Center (WAC) gateway machine to the new Windows Server 2022, my WAC suddenly stopped working. I couldn’t connect to any of the servers from within the console, couldn’t add new ones, … nothing.

When tried adding new servers, nothing happened – wizard stays at “Searching for…“:

Even PowerShell couldn’t connect anymore (which is actually the root cause of the above).

So, what happened?

Everything worked before and I wasn’t aware of other changes… other than upgrading my OS (in-place upgrade, Windows Server 2019 to Windows Server 2022), that is.

Let’s try and make sense of all this.

Test-NetConnection says everything is fine, Test-WSMan from another machine works:

However, Test-WSMan from this (WAC) machine simply doesn’t work:

Tried checking the logs next – two errors inside Applications and Services Logs -> Microsoft -> Windows Remote Management -> Operational log caught my eye:

  • Error 138: The client got a timeout from the network layer (ERROR_WINHTTP_TIMEOUT)
  • Error 142: WSMan operation Identify failed, error code 2150859046

So, it’s something with the network after all – more specifically, seems like there is some issue on the HTTP/S part!

After some thinking, I remembered that we have a HTTP/S proxy in our network – maybe my PowerShell session actually tries to go through it?! šŸ˜€

Checking if proxy is set (with netsh winhttp show proxy) – it is! This could be the issue.

Now I’m resetting the proxy settings (with netsh winhttp reset proxy, of course):

And then trying Test-WSMan again:

It finally works! And WAC works as well! šŸ˜€

Hope this helps!

Cheers!

Having fun with Helm and file encoding

Had some spare time, so I’ve tried to learn a bit more about Helm, the package manager for Kubernetes.

I’ve decided to follow the relatively new Pluralsight course called – Kubernetes Package Administration with Helm, done by my MVP colleague Andrew Pruski.Ā And it was great – not too long, clear and easy to follow, with only a handful of prerequisites if you want to follow along! Great job!

Of course, there is also the nice, official documentation.

But why am I writing this post?

I was normally following this course on my Windows 10 laptop, using Visual Studio Code, as suggested, and also using PowerShell terminal, with Helm v3.3.1.

It all went well until the part when we are creating our Helm Chart, more specifically – when we’re filling up our deployment.yaml and service.yaml files. Suggested (and simplest) method is to use the simple output redirection (with “>“), like this:

But, this gave me the following error when trying to deploy the chart:

It’s quite obvious – Helm works with UTF-8, and my .yaml files seem to be encoded differently.Ā Quick look at the bottom of my VSCode confirms it:

How can I fix it?

As I’m using PowerShell, it’s pretty easy – instead of doing the simple output redirection (“>“), I pipe output to Out-File cmdlet with -Encoding UTF8 option, in all cases, which takes care of the encoding (and sets it to UTF-8 with BOM, which is just fine for Helm):

So, long story short – if you run into the error above (Error: unable to build kubernetes objects from release manifest: error parsing : error converting YAML to JSON: yaml: invalid leading UTF-8 octet”), remember to check your file’s encoding (and change it to UTF-8, if needed)! šŸ™‚

Cheers!

P.S. Thanks to good people at Pluralsight for providing me a complimentary subscription!

Fixing things with… terraform destroy

I like Terraform, because it’s so clean, fast and elegant; OK, I also suck at it, but hey – I’m trying! šŸ™‚

The long story

Usually, Terraform and its providers are very good at doing things in the order they should be done. But sometimes people do come up with silly ideas, and mine was such (of course) – I’ve decided to rename something and it broke things. Just a little.

I have a simple lab in Azure, with a couple of virtual machines behind the Azure Load Balancer, no big deal. All this is being deployed (and redeployed) via Terraform, using the official azurerm provider. It’s actually a Standard SKU Azure Load Balancer (don’t ask why), with a single backend pool and a few probes and rules. Nothing special.

I’ve deployed this lab a few days ago (thanks to good people at Microsoft, I have some free credits to spare), everything worked just fine, but today I’ve got the wild idea – I’ve decided to rename my backend pool.

With all the automation in place, this shouldn’t be a problem… one would think. šŸ™‚

So, as I’ve updated my code and during the make it soĀ phase (terraform apply), I’ve got some errors (truncated, with only the useful stuff):

Issue

After going through these errors, I’ve realized that my resources are indeed in the same region, but existing rules are referencing the current backend pool by name and actually blocking Terraform in renaming the backend pool.

There are a couple of options at this stage – you can destroy your deployment and run it again (as I normally would) and it should all be fine. Or you can try to fix only the dependent resources and make it work as part of the existing deployment.

With some spare time at my hands, I’ve tried to fix it using the second one and it actually worked.

Resolution

Terraform has a nice option for destroying just some parts of the deployment.

If you look at help for the terraform destroy command, you can see the target option:

And if you run it to fix your issues, you’ll get a nice red warning saying that this is only for exceptional situations (and they mean it!):

 

So… BE CAREFUL! (can’t stress this enough!)

 

Anyhow, I’ve destroyed rules which were preventing my rename operation:

And then another terraform apply –auto-approve recreated everything that was needed, and finally – my backend pool got renamed:

Another idea I’ve had was to taint the resources (terraform taint -help), which would probably be a lot nicer. Oh, well… maybe next time. šŸ™‚

As things are constantly improving, it shouldn’t be long until this is fixed (should it even be fixed?!). Until then, hope this will help you with similar issues!

Cheers!

Updates and Recommendations not working in SCOM 2016

Not so long ago, there was a thread about this issue on TechNet Forums ā€“ long story short, in some cases (if you didnā€™t do a clean installation of System Center 2016 ā€“ Operations Manager, for example), the shiny, new feature called Updates and Recommendations didnā€™t work.

Even better ā€“ there was a rather cryptic error saying ā€œAn error occurred while displaying the Updates and Recommendations view. This might be because the database query has encountered an errorā€¦ā€.

image

Soā€¦ it looks that maybe the database query has indeed ā€œencountered an errorā€.

What can we do to make sure and resolve this?

As the user Chandra Bose suggested, we can look for duplicates in our imported management packsā€¦ and maybe we will be smarter then.

PowerShell command we can use:

This will list our imported management packs and their versions, and we can start looking for duplicate(s).

image

In my case, there were some ā€“ some of them were the two management packs called Microsoft.SystemCenter.WebApplicationSolutions.Library.Resources.*.

To get a better look on those two, we can use the following command:

And the output looks like this:

image

image

image

This shows that we really have two ā€œduplicateā€ management packs in our SCOM database, one installed in 2013, and another in 2014 (why? and how? donā€™t really matter Smile). We need to remove one, obviously.

For that, we can use the following command (by using the Id property from previous command):

And, if there are no more duplicates, our Updates and Recommendations view should work now:

image

Hope this helps.

Cheers!

Windows Server 2012 R2 installation media issues (OEM)

Hereā€™s an easy one ā€“ you may have encountered and solved it already, but let this be hereā€¦ as a reminder. Smile

If you ever tried to install the Windows Server 2012 R2 into a Hyper-V virtual machine by using the provided OEM installation media (in my case, from IBM), your installation may fail even before it started because the hardware youā€™re using (i.e. ā€œvirtualā€ hardware) is not the one the installation expects (which is ā€œimprinted in the media itselfā€).

So, you get an error like this:

image

Solution here is kind of simple ā€“ IBM provided the little utility (just 5 KB) called Hyper-V-OEM-BIOS-V2.exe, which makes the virtual machine ā€œproduced by IBMā€ (actually, virtual machine BIOS gets updated to contain the IBM specific information, that the Windows installation is looking for, and which is the cause of this error).

After you run the utility (on your Hyper-V host), Windows installation using the OEM media proceeds as it should.

image

Other solution (actually a workaround) is to use the retail media for the virtual machine installation. In this case, you wonā€™t get the error, and installation proceeds as it should right from the beginning.

IBM published a document explaining this issue, and the possible resolution/workaround, you can view it here.

As Iā€™ve said ā€“ quick & easy (hope it helps)! Smile

Cheers!

Adventure of installing the Windows Azure Active Directory Module for PowerShell

Well, you know the story ā€“ ā€œsomething needs to be done immediately, usually in the middle of the night, involving PowerShell, and you donā€™t have all the needed modules installedā€¦ā€.

The solution seems easy enough ā€“ install the required modules, connect to Office 365 and do the job. Yeahā€¦ but no! Smile

More specific ā€“ Iā€™ve tried to install the Windows Azure Active Directory Module for Windows PowerShell the other night. In the end, Iā€™ve succeeded, but something kept me awake a little longer than necessary.

Iā€™ve read an article on TechNet, explaining the management of Azure Active Directory using PowerShell. Why? Because I couldnā€™t do what was needed via the (nice) user interface.

So, instructions said ā€œInstall the Windows Azure AD Moduleā€ ā€“ Iā€™ve downloaded the appropriate installer (Windows Azure Active Directory Module for Windows PowerShell (64-bit version)), and started the installation.

Almost immediately, Iā€™ve got an error saying that the Microsoft Online Services Sign-In Assistant (version 7.0 or greater) needs to be already installed. OK, Iā€™ve downloaded this piece of software as well (from here), and installed it. ā€œFortunatelyā€ it demands a machine reboot. Rebooted.

image

Now Iā€™ve tried to install the Windows Azure AD Module again, and got the same error:

image

I must say that Iā€™m little confused at this point, because I was convinced that Iā€™ve installed this just a minute or two ago. Ok, itā€™s late. No big deal ā€“ Iā€™ve ran the installation again, and got the following screen:

image

So, it is installed after all. Maybe itā€™s the wrong version (on the other hand, the TechNet article contains the link to download)? After a few moments of searching, Iā€™ve found the more recent version of this Sign-In Assistant, called Microsoft Online Services Sign-In Assistant for IT Professionals BETA. Iā€™ve installed this version now, and tried to install the Windows Azure AD Module afterwards. Now it finally worked!

image

The conclusion ā€“ this TechNet article is slightly out-of-date (linked to the wrong version of the Sign-In Assistant, which doesnā€™t work with the current version of Windows Azure AD Module) and, until this is resolved, youā€™ll need to install the BETA version from the link provided above (this one).

Cheers!