Carl, When you run chef-client from an interactive logon session (either via RDP or a console session), you are operating in a different security context then WinRM and PowerShell Remoting does. WinRM and PowerShell Remoting are hosted in the winrm service. When you connect to a remote WinRM or PowerShell Remoting session, you are authenticating to the service and it is a non-interactive logon to the system (which has certain security implications). Unfortunately, KB2918614 "fixes" some security issues with the Windows installer service. That fix breaks several scenarios in trying to install software over WinRM. Since PowerShell Remoting is layered on top of WinRM, it suffers the same security context issue with the Installer service. If you run chef (chef-solo, chef-client using a chef server, or chef-client with local mode) via WinRM or PowerShell Remoting you'll hit the broken behavior of the Installer service. The main workaround is to use a scheduled task (which is what we do in knife-windows now if the bootstrap fails to install chef-client). Until you can apply the later hotfix, this is the only workaround when connecting via WinRM (or PowerShell Remoting). Steve On November 11, 2014 at 9:35:00 AM, ( "> ) wrote:
|
Archive powered by MHonArc 2.6.16.