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:

kubectl create deployment nginx --image=nginx --dry-run=client --output=yaml > .\ourchart\templates\deployment.yaml

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

helm install ourchart .\ourchart
# Error: unable to build kubernetes objects from release manifest: error parsing : error converting YAML to JSON: yaml: invalid leading UTF-8 octet

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):

kubectl create deployment nginx --image=nginx --dry-run=client --output=yaml | Out-File .\ourchart\templates\deployment.yaml -Encoding UTF8

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)! 🙂


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):

Error Creating/Updating LoadBalancer: network.LoadBalancersClient
Failure sending request:
Original Error:
Code="InvalidResourceReference... .../k8sthw-lb/backendAddressPools/k8sthw-lb-pool referenced by resource
/subscriptions/fake-azure-subscription-id/resourceGroups/k8sthw-rg/providers/Microsoft.Network/... ... or verify that both resources are in the same region." Details=[]


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.


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:

terraform destroy -help
# ...
# -target=resource Resource to target. Operation will be limited to this
#                  resource and its dependencies. This flag can be used
#                  multiple times.
# ...

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!):

terraform destroy -target azurerm_lb_outbound_rule.k8sthw-lb-out
# Warning: Resource targeting is in effect
# You are creating a plan with the -target option, which means that the result
# of this plan may not represent all of the changes requested by the current
# configuration.
# The -target option is not for routine use, and is provided only for
# exceptional situations such as recovering from errors or mistakes, or when
# Terraform specifically suggests to use it as part of an error message.
# Do you really want to destroy all resources?
# Terraform will destroy all your managed infrastructure, as shown above.
# There is no undo. Only 'yes' will be accepted to confirm.
# Enter a value: yes
# ...


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


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

terraform destroy -target azurerm_lb_outbound_rule.k8sthw-lb-out -target azurerm_lb_rule.k8sthw-lb-80-rule -target azurerm_lb_rule.k8sthw-lb-443-rule --auto-approve
# ...
# Destroy complete! Resources: 3 destroyed.

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

# ...
# azurerm_lb_backend_address_pool.k8sthw-controllers-lb-pool: Refreshing state... [id=/subscriptions/fake-azure-subscription-id/resourceGroups/k8sthw-rg/providers/Micro...
# ...
# Apply complete! Resources: 2 added, 0 changed, 3 destroyed.

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!


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…”.


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:

Get-SCManagementPack | sort -Property Name | ft Name,Version -AutoSize

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


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:

Get-SCManagementPack | where {$_.Name -like "Microsoft.SystemCenter.WebApplicationSolutions.Library.Resources.*"}

And the output looks like this:




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):

Get-SCManagementPack -Id "09988ce5-edea-8ed2-868a-0ecc1193338b" | Remove-SCManagementPack

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


Hope this helps.


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:


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.


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


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.


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


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:


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!


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).


Latest “Patch Tuesday” – errors installing update

Latest “Patch Tuesday” (May 13th, 2014) has brought us a pack of updates (you can read all the details about them here and here), but one of them was making trouble for me. The update I’m talking about is called “Security Update for Windows Server 2012 R2 (KB2920189)”. You can read more about this update in KB2920189.

I’ve tried to install it on a number of my Hyper-V virtual machines (Generation 2), but the update keeps failing with error 800F0922:


This error and its cause is described in
KB2962824. In short, this update expects that the BitLocker feature is installed (not enabled or used, but installed) – in my case, the problem was Secure Boot, which is enabled by default on Generation 2 virtual machines.

You can install the BitLocker feature on your Windows Server 2012 R2 servers before installing this update, or you can switch the Secure Boot off, install the update and switch it back on (I’ve decided to do the latter).

After switching the Secure Boot off, installing the update and switching it on again, the update installed successfully:


Have fun!