Http response error: 401 - invalid content type

Hello,

I’m using Terraform v0.12.6 and I’m trying to run some commands on a windows 2012R2 node that I’m also creating with terraform, but after the node is created successfully terraform is not able to connect to the windows node and after some time it’s giving me this message:

Error: timeout - last error: http response error: 401 - invalid content type

I already tried like all the available flags like https, insecure, password harcoded instead of variable. The connection between nodes exist, I can reach the node from the machine that I’m running terraform to the WINRM port and the password works. Any advice? On google I was not able to find an answer, just some people in the same situation that I am now.

@JustLeo Where you able to get this resolved? I have the same issue all of a sudden. Things were working fine, then now i get the same error as you. Previously the same files would create the instance and connect with winrm with no issue. Now I get the 401. For reference I’m creating aws instances with amazon win2012R2 base image. I’m using terraform 11.8 and also tried with 11.14.

I also have been through all the normal checks. http, insecure etc. after creation winrm works for me in powershell directly.

Any help from you or others would be greatly appreciated. Banging my head against the wall a bit.

Thanks,

Jeremy

Hi @JustLeo and @jeremywiles,

Using provisioners tends to add all sorts of extra complexity to Terraform usage, due to the need to properly configure credentials, ensure that there is connectivity on the appropriate TCP port between Terraform and the remote host, etc. For that reason, provisioners are a last resort.

While it should be possible to get WinRM working, it’s generally very hard to help with provisioner-related issues in a forum setting due to how many different settings must be configured just right in order to make them work and how dependent the behavior is on your surrounding environment. I’d suggest looking for other ways to solve your problem instead.

For the situation of running Windows Server images provided by Amazon on EC2, I’d suggest investigating the use of the EC2Config service with the user_data setting on aws_instance, aws_launch_template, or aws_launch_configuration.

That avoids the need for Terraform to connect to your EC2 instance at all, because the necessary configuration and/or scripts are provided through the EC2 API instead. This will often also result in faster boot-up times because the user_data processing can happen as soon as the EC2Config service starts up, rather than waiting until Terraform is able to access the instance with WinRM or SSH.

Other cloud compute vendors have similar mechanisms for specifying launch configuration and scripts via the platform API, described in each vendor’s own documentation. The Terraform provisioners documentation lists some examples for common platforms as a starting point.

Hi @jeremywiles,

I was able to solve the connection issue by running the following commands. Have in mind that I’m not using an image directly from AWS Marketplace, it is a custom image:

winrm set winrm/config/service '@{AllowUnencrypted = "true"}'
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord 

Hi @apparentlymart,

Thanks for your answer and suggestions but if provisioners are the last resource, what if I need to run several Chef cookbook in a windows node, what do you suggest in this case? Is there a better way to do it? Thanks in advance.

The guide I linked to gives some other suggestions. I will summarize them here but please see the documentation for more details:

  • Run Chef during your custom image build process instead, so that the image is already pre-configured when it starts up, or
  • Use cloud-init or similar mechanisms to install/run the Chef client via user_data.

In practice it’s reasonable to combine both of these approaches, by doing as much of the work as possible during the image build process (including the installation of the Chef client) but then waiting until boot time in cloud-init to do the final registration with a Chef server, if one is being used.

Terraform’s chef provisioner is just downloading and running the Chef client, so it’s not doing anything that a script run with cloud-init couldn’t do.

@JustLeo Thank you for the reply. I may take a look at those. But I think I am going to take @apparentlymart 's suggestion and reduce my dependence on provisioners.

@apparentlymart Thank you for the guidance. Your link is helpful. I had missed the part that provisioners should be used as a last resort. After banging my head on the wall for the better part of 2 days to fix this winrm issue I’m happy to focus on something more productive like eliminating the provisioners. Thank you for the quick reply and the helpful information.

Thanks all!

Jeremy