Hi,
Over the past weeks I’ve worked with a client on a Chef POC involving
mainly Windows (on EC2, Azure and locally) and have a few observations that
I’ll like to provide (and hopefully get some feedback on
First, the actual cookbook execution works fine, we can accomplish
everything we need (and probably more
Now for some of the problems we’ve encountered:
- There are a number of issues with bootstrapping Windows on EC2 which
are already registered and fixes are provided, but no release of the
knife-ec2 plugin has been made (
http://tickets.opscode.com/browse/KNIFE-154,
http://tickets.opscode.com/browse/KNIFE-266) - You cannot actually use knife winrm to execute commands against EC2 as
you cannot get the public IP due to
http://tickets.opscode.com/browse/KNIFE-276
The above can all be solved with new releases of knife-ec2 and
knife-windows.
A more fundamental issue we’ve seen is what seems to be a bug in WinRM 3.0
http://social.technet.microsoft.com/Forums/en-US/w7itproinstall/thread/51810d3b-6236-44f8-99fd-10f004ad8002/
This basically breaks remote execution of chef-client in unpredictable ways
(SQL Server installation aborts, powershell scripts fails etc.). We’ve
worked around this using PsExec but this is quite a hack.
A see a few solutions to this:
- Don’t use WinRM but install and use SSH instead. Would be nice if the
opscode openssh cookbook supported windows - Run chef-client as a service. This not currently optimal for us as we
use this in an automated testing setup and need to know when configuration
is complete. Perhaps a way to force the service to do a chef-client run and
wait for completion?
I’m not a Windows expert but believe WinRM 3.0 is default on Server 2012
and cannot be downgraded, which eventually means that until this problem is
solved, Chef usage on Server 2012 will be suboptimal.
/Jeppe