I have the user “SVC_ChefNode” created in the domain and have tested that it can login and has local admin rights.
When I run this the command will just hang without any errors and I’ve even let it sit overnight with no changes.
I can verify that the wsman is available:
knife wsman test 10.100.23.111 --manual-list
Connected successfully to 10.100.23.111 at http://10.100.23.111:5985/wsman.
I’m using the free hosted Chef server. The workstation is Windows 10 behind a proxy and can reach it, but the server is not behind a proxy. I’m not sure if this is causing the problem, but I figured I’d add it just in case.
Just to test if if there was something wrong with my Win10 install of the ChefDK, I deployed a new Windows 2012 R2 VM and installed the ChefDK on that and attempted to run the bootstrap command. It does the same thing and just hangs there. I had a colleague that uses a Mac run the command on his workstation and it works perfectly from the Mac.
C:/opscode/chefdk/embedded/lib/ruby/gems/2.4.0/gems/mixlib-cli-1.7.0/lib/mixlib/cli.rb:230:in `parse_options': ambiguous option: -l (OptionParser::AmbiguousOption)
from C:/opscode/chefdk/embedded/lib/ruby/gems/2.4.0/gems/chef-13.2.20-universal-mingw32/lib/chef/knife.rb:323:in `parse_options'
from C:/opscode/chefdk/embedded/lib/ruby/gems/2.4.0/gems/chef-13.2.20-universal-mingw32/lib/chef/knife.rb:303:in `initialize'
from C:/opscode/chefdk/embedded/lib/ruby/gems/2.4.0/gems/chef-13.2.20-universal-mingw32/lib/chef/knife/bootstrap.rb:268:in `initialize'
from C:/opscode/chefdk/embedded/lib/ruby/gems/2.4.0/gems/chef-13.2.20-universal-mingw32/lib/chef/knife.rb:217:in `new'
from C:/opscode/chefdk/embedded/lib/ruby/gems/2.4.0/gems/chef-13.2.20-universal-mingw32/lib/chef/knife.rb:217:in `run'
from C:/opscode/chefdk/embedded/lib/ruby/gems/2.4.0/gems/chef-13.2.20-universal-mingw32/lib/chef/application/knife.rb:156:in `run'
from C:/opscode/chefdk/embedded/lib/ruby/gems/2.4.0/gems/chef-13.2.20-universal-mingw32/bin/knife:25:in `<top (required)>'
from C:/opscode/chefdk/modules/chef/../../bin/knife:275:in `load'
from C:/opscode/chefdk/modules/chef/../../bin/knife:275:in `<main>'
This might not be exactly the same issue you are seeing (especially if you get no ouput at all running knife overnight) but I had a very similar issue where the knife command, running on Windows Server 2016, would buffer all output until the command ended, potentially giving the impression of the command hanging if it was performing a long running operation.
Whilst mostly an annoyance, more seriously it meant I was unable to respond to any inputs the knife command prompted me for (for example, prompting to overwrite a node on bootstrap if it already existed).
The eventual fix for me was to run ‘Remove-Module chef’ in my ChefDK powershell, although I am unaware of the wider implications of me doing this at the moment (i.e. have I broken other stuff by doing this?)
I haven’t tested on other Windows OS’s, so am unable to confirm if this is just isolated to Windows Server 2016.
I should add : I’ve confirmed this behavour with ChefDK 2.1.11 and 2.0.28.
Just noted that I need to run the ‘Remove-Module chef’ command every time I reopen my ChefDK powershell otherwise I return to knife buffering all output until the end of the command.
Same issue here. Using a Windows 10 (Workstation) to bootstrap via winrm a Windows Server 2016 (Node). All different variations of the knife bootstrap windows winrm commands just hang. However, removing the module fixed this.