The knife-windows plugin extends Chef’s knife CLI with subcommands to bootstrap and manage Microsoft Windows nodes over Windows Remote Management (WinRM) or SSH. It enables:
- Bootstrapping Windows Server nodes via WinRM (
httpport5985orhttpsport5986). - Executing ad-hoc remote commands via
knife winrm. - Testing and configuring WinRM listeners (
knife wsman).
This guide walks through installing knife-windows, preparing WinRM on a target Windows host, verifying WS-Management connectivity, troubleshooting common WinRMAuthorizationError pitfalls (such as UAC local token filtering vs. built-in Administrator), and running a complete Windows bootstrap that registers chef-client as a Windows service.
Step 1: Install Required Chef Gems on the Workstation
On your Chef Workstation, verify or install the winrm and knife-windows gems inside ChefDK’s embedded Ruby environment:
chef gem install winrm
chef gem install knife-windows
(Note: In newer versions of Chef Workstation, WinRM bootstrapping is built directly into knife bootstrap via --connection-protocol winrm, while knife bootstrap windows winrm remains supported for backward compatibility.)
Step 2: Configure WinRM on the Target Windows Node
On the target Windows Server, open PowerShell as Administrator and enable PowerShell Remoting / WinRM:
Enable-PSRemoting -Force
Open TCP port 5985 (WinRM HTTP) in Windows Firewall:
netsh advfirewall firewall add rule name="WinRM-HTTP" dir=in localport=5985 protocol=TCP action=allow
Lab / Test WinRM Configuration
In a non-domain lab environment where Kerberos is unavailable and you are testing over HTTP (5985), configure the WinRM client and service listeners to accept Basic authentication and unencrypted WinRM payloads:
winrm set winrm/config/client/auth @{Basic="true"}
winrm set winrm/config/service/auth @{Basic="true"}
winrm set winrm/config/service @{AllowUnencrypted="true"}
Security Warning (Lab Only): Enabling
Basic="true"andAllowUnencrypted="true"over HTTP (5985) is strictly for isolated test environments. In production, always use Negotiate / NTLM / Kerberos authentication (which encrypts the WinRM payload even over port5985) or configure a WinRM HTTPS listener on TCP port5986with a valid TLS certificate.
Step 3: Verify WinRM Connectivity from the Chef Workstation
- Test TCP reachability on port
5985:nc -zv 172.22.2.222 5985 # Or with telnet: telnet 172.22.2.222 5985 - Test the WS-Management endpoint using
knife wsman test:knife wsman test 172.22.2.222 -mConnected successfully to 172.22.2.222 at http://172.22.2.222:5985/wsman.
Step 4: Troubleshooting Common knife bootstrap windows winrm Errors
When bootstrapping a non-domain Windows machine, several common authentication errors can occur. Here is a summary of each failure mode and why it happens:
Attempt 1 & 4: WinRM::WinRMAuthorizationError (Wrong Password or Untrusted SSL Cert)
└─▪ knife bootstrap windows winrm 172.16.2.35 --winrm-user Administrator --winrm-password 'REPLACE_WITH_PASSWORD' --node-name nagios_test_windows_client --run-list 'recipe[chef-client]'
Waiting for remote response before bootstrap.ERROR: Failed to authenticate to 172.16.2.35 as Administrator
Response: WinRM::WinRMAuthorizationError
Hint: Make sure to prefix domain usernames with the correct domain name.
Hint: Local user names should be prefixed with computer name or IP address.
Why it happens: Either the password/account name is mismatched, or knife cannot verify the SSL certificate when negotiating the session.
Attempt 2: Non-Built-In Local Admin Account (CHEF-WINDOWS-01\chef) Denied by Windows UAC
└─▪ knife bootstrap windows winrm 172.22.2.222 --winrm-user 'CHEF-WINDOWS-01\chef' --winrm-password 'REPLACE_WITH_PASSWORD' --node-name nagiosxi_test_windows_client --winrm-ssl-verify-mode verify_none -y --run-list 'recipe[chef-client]'
Waiting for remote response before bootstrap.ERROR: Failed to authenticate to 172.22.2.222 as CHEF-WINDOWS-01\chef
Response: WinRM::WinRMAuthorizationError
Why it happens: By default, Windows User Account Control (UAC) Remote Restrictions (LocalAccountTokenFilterPolicy = 0) strip administrative privileges from non-built-in local accounts (such as chef) logging in remotely over WinRM, whereas the built-in local Administrator account (RID -500) is exempt. To use a custom local administrator account over WinRM, either use the built-in Administrator account or set LocalAccountTokenFilterPolicy = 1 under HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.
Attempt 3: Validatorless Bootstrap Blocked Over Unencrypted Basic Auth
└─▪ knife bootstrap windows winrm 172.22.2.222 --winrm-user 'CHEF-WINDOWS-01\chef' --winrm-password 'REPLACE_WITH_PASSWORD' --node-name nagiosxi_test_windows_client --winrm-authentication-protocol basic -VV -y --run-list 'recipe[chef-client]'
DEBUG: Looking for key winrm_authentication_protocol and found value basic
DEBUG: Looking for key winrm_transport and found value plaintext
ERROR: Validatorless bootstrap over unsecure winrm channels could expose your key to network sniffing
Why it happens: Chef refuses to perform a validatorless bootstrap over plaintext HTTP with --winrm-authentication-protocol basic because the newly generated client private key would be transmitted in cleartext over the network. Leaving --winrm-authentication-protocol at its default (negotiate, which uses NTLM/Kerberos message-level encryption) resolves this error.
Step 5: Successful Windows Bootstrap (Try 5)
Using the built-in Administrator account, default negotiate WinRM authentication, and --winrm-ssl-verify-mode verify_none:
knife bootstrap windows winrm 172.22.2.222 \
--winrm-user 'Administrator' \
--winrm-password 'REPLACE_WITH_ADMIN_PASSWORD' \
--node-name nagiosxi_test_windows_client \
--winrm-ssl-verify-mode verify_none \
-V -y \
--run-list 'recipe[chef-client]'
What Happens Under the Hood During Bootstrap
As shown in the verbose (-V) bootstrap output below, knife bootstrap windows winrm:
- Creates the client and node objects (
nagiosxi_test_windows_client) on the Chef Server. - Connects to
172.22.2.222over WinRM and renders a temporary bootstrap batch script (C:\Users\ADMINI~1\AppData\Local\Temp\bootstrap-*.bat). - Creates
C:\chef, generates helper download scripts (C:\chef\wget.vbsandC:\chef\wget.ps1), and downloads the latest Chef Client MSI installer for Windows Server (chef-client-latest.msi). - Installs the Chef Client MSI silently (
msiexec /qn /i ...). - Writes the trusted Chef Server certificate into
C:\chef\trusted_certs\, writesC:\chef\client.rbandC:\chef\first-boot.json, and invokeschef-client. - Converges
recipe[chef-client], which createsC:\chef\run,C:\chef\cache,C:\chef\backup,C:\chef\log, andC:\chef\client.service.rb, then registers and starts thechef-clientWindows service.
Creating new client for nagiosxi_test_windows_client
Creating new node for nagiosxi_test_windows_client
Waiting for remote response before bootstrap.172.22.2.222 .
172.22.2.222 Response received.
Remote node responded after 0.01 minutes.
172.22.2.222 AMD64
Bootstrapping Chef on 172.22.2.222
172.22.2.222 Rendering "C:\Users\ADMINI~1\AppData\Local\Temp\bootstrap-18039-1472729874.bat" chunk 1..8
172.22.2.222 Checking for existing directory "C:\chef"...
172.22.2.222 Existing directory not found, creating.
...
172.22.2.222 Detected Windows Version 6.3 Build 9600
172.22.2.222 Installing downloaded client package...
172.22.2.222 C:\Users\Administrator>msiexec /qn /log "C:\Users\ADMINI~1\AppData\Local\Temp\chef-client-msi22296.log" /i "C:\Users\ADMINI~1\AppData\Local\Temp\chef-client-latest.msi"
172.22.2.222 Successfully installed Chef Client package.
172.22.2.222 Writing validation key...
172.22.2.222 C:\Users\Administrator>mkdir C:\chef\trusted_certs
...
172.22.2.222 C:\Users\Administrator>chef-client -c c:/chef/client.rb -j c:/chef/first-boot.json
172.22.2.222 [2016-09-01T14:40:22+03:00] INFO: *** Chef 12.13.37 ***
172.22.2.222 [2016-09-01T14:40:22+03:00] INFO: Platform: x64-mingw32
172.22.2.222 [2016-09-01T14:40:54+03:00] INFO: Run List is [recipe[chef-client]]
172.22.2.222 [2016-09-01T14:40:55+03:00] INFO: Loading cookbooks [chef-client@5.0.0, cron@1.7.6, logrotate@2.1.0, compat_resource@12.13.37, windows@1.44.3, chef_handler@1.4.0]
...
172.22.2.222 [2016-09-01T14:41:09+03:00] INFO: directory[C:/chef/run] created directory C:/chef/run
172.22.2.222 [2016-09-01T14:41:09+03:00] INFO: directory[C:/chef/backup] created directory C:/chef/backup
172.22.2.222 [2016-09-01T14:41:09+03:00] INFO: directory[C:/chef/log] created directory C:/chef/log
172.22.2.222 [2016-09-01T14:41:09+03:00] INFO: template[C:/chef/client.service.rb] created file C:/chef/client.service.rb
172.22.2.222 [2016-09-01T14:41:14+03:00] INFO: execute[register-chef-service] ran successfully
172.22.2.222 [2016-09-01T14:41:14+03:00] INFO: Processing windows_service[chef-client] action enable (chef-client::windows_service line 50)
172.22.2.222 [2016-09-01T14:41:22+03:00] INFO: windows_service[chef-client] started
172.22.2.222 [2016-09-01T14:41:22+03:00] INFO: Chef Run complete in 27.546223 seconds
The Windows node is now bootstrapped, registered with the Chef Server, and running chef-client as a background Windows service.