Server 2012/WinRM3 uses different security?

Chef Infra (archive)
1

My question is this: is there a permissions issue of some kind when running
chef through WinRM3 that doesnt allow programs to go out to the internet?

I’m trying to use Chef-client 11.4.4 on Server 2012 Std to deploy SQL 2012.
I’ve run into two problems and I believe they’re related:

windows_feature “NetFx3” do
action :install
end

This fails as DISM is supposed to go to Microsoft update and download the
.Net 3.5.1 files. It works fine if I run
DISM /online /enable-feature /featurename:NetFx3 /norestart
manually through RDP - which is basically what the windows_feature runs. It
also fails if I run:
knife winrm 192.168.170.162 ‘DISM /online /enable-feature
/featurename:NetFx3 /norestart’ -m -x nfox
(note: NetFx3 relies on NetFx3ServerFeatures which I’ve made sure is
already installed)

If I run
DISM /online /enable-feature /featurename:NetFx3 /norestart /LimitAccess
/Source:d:\sources\sxs
through a recipe (with the DVD in), it works. Effectively, this bypasses
the need to go online to download the files.

The second problem is SQL Server 2012 setup tries to go online looking for
updates during install. If I add the /UpdateEnabled=false switch to the
install command, it proceeds. I’m using

windows_package "Microsoft SQL Server 2012 (64-bit)" do
  source "\\\\10.200.1.240\\admin\\Installs\\SQL\\SQL2012Std\\setup.exe"
  timeout 3600
  action :install
  installer_type :custom
  options "/ConfigurationFile=\"#{node['mssql']['installIni']}\"

/SAPWD="#{node[‘mssql’][‘sapw’]}""
end

In the installIni file, I have a setting of UpdateSource=MU.

I’m running chef via:
knife winrm 192.168.170.145 ‘chef-client -c c:/chef/client.rb’ -m -x nfox
if that makes a difference. I do not have this problem when I run
chef-client from an administrator:cmd window in an RDP session. So it seems
to be something with WinRM and I’m guessing some kind of security setting?

As a quick test, I ran it on Server 2008 and also got the same error
installing SQL:
Setup encountered an unexpected failure when trying to run workflow
SEARCHUPDATES.
So apparently its not just Server 2012 like I thought.

2

Hi,

On Fri, May 24, 2013 at 4:39 AM, Nate Fox nfox@neogov.com wrote:

My question is this: is there a permissions issue of some kind when running
chef through WinRM3 that doesnt allow programs to go out to the internet?

I was fighting with the exact same problem yesterday. Yet to find an
answer. It seems it is anything requiring network credentials is
disabled. We can't even access the local DFS. It has been suggested
that we need to set up Multi-hop support [1] for winrm but I have't
yet to figure out how to do that via knife. All of the instructions
seem to be for when using windows as the client where we run chef off
non-windows hosts.

If you do figure out how to address this I would love an update :wink:

BTW I see this behaviour on Win2008R1 and Win2008R2 as well as 2012

[1] Multi-Hop Support in WinRM - Win32 apps | Microsoft Learn

--
Cheers,

Peter Donald

3

WinRM does impose limitations on what you can do over that interface. I
fought with this for a quite a bit a while back when trying to get nodes to
automatically install windows updates.

I ended up on

On that page in the section "The following list contains interfaces and
properties that are not available to remote users and applications" it
lists a number of interfaces which are disallowed. I know in my case, with
Windows updates I was restricted on "
IUpdateSession::CreateUpdateDownloader".

If I ran my windows update code over SSH (WinSSHD), it would work just
fine, however when chef-client was invoked over WinRM, it would fail with "OLE
error code:80070005"

Luckily for me we have WinSSHD across the board, so I was able to just punt
and use SSH.

Sorry thats not really a solution, but I did want to pass along the info I
had learned (the hard way)

On Thu, May 23, 2013 at 4:10 PM, Peter Donald peter@realityforge.orgwrote:

Hi,

On Fri, May 24, 2013 at 4:39 AM, Nate Fox nfox@neogov.com wrote:

My question is this: is there a permissions issue of some kind when
running
chef through WinRM3 that doesnt allow programs to go out to the internet?

I was fighting with the exact same problem yesterday. Yet to find an
answer. It seems it is anything requiring network credentials is
disabled. We can't even access the local DFS. It has been suggested
that we need to set up Multi-hop support [1] for winrm but I have't
yet to figure out how to do that via knife. All of the instructions
seem to be for when using windows as the client where we run chef off
non-windows hosts.

4

Nate Fox nfox@neogov.com writes:

[...]

I'm running chef via:
knife winrm 192.168.170.145 'chef-client -c c:/chef/client.rb' -m -x nfox
if that makes a difference. I do not have this problem when I run
chef-client from an administrator:cmd window in an RDP session. So it seems
to be something with WinRM and I'm guessing some kind of security setting?

As a quick test, I ran it on Server 2008 and also got the same error
installing SQL:
Setup encountered an unexpected failure when trying to run workflow
SEARCHUPDATES.
So apparently its not just Server 2012 like I thought.

I think there's a general problem with WinRM 3.0 as outlined here

http://social.technet.microsoft.com/Forums/en-US/w7itproinstall/thread/51810d3b-6236-44f8-99fd-10f004ad8002/

We've not been able to install SQL Server without using PsExec

/Jeppe

5

Question: has anyone actually repro'd this outside of Win2k12?

One workaround is to use scheduled tasks, another is to use psexec - see http://tickets.opscode.com/browse/COOK-1172.

This sounds like the issue we hit when we fixed this bug, originally for Server 2012:
http://tickets.opscode.com/browse/KNIFE-208

Bootstrap was faling on 2k12, and the cause was that job objects in Windows (an NT kernel capability) which are used by winrm to enforce things like maxmemorypershellmb. The knife bug referenced earlier repros the problem without winrm, simply using a script that leverages job objects and works on Win2k3-Win2kR2, but not 2k12. In this case, WinRM was not the root cause, it was a bug in Win2k12.

I'll see if there is something that MSFT is using to publicly track the job object issue. If people are hitting this outside of the bootstrap case we worked around, this is obviously higher priority to fix.

--
Adam Edwards
Software Development Engineer, Opscode, Inc.

From: David Petzel <davidpetzel@gmail.commailto:davidpetzel@gmail.com>
Reply-To: "chef@lists.opscode.commailto:chef@lists.opscode.com" <chef@lists.opscode.commailto:chef@lists.opscode.com>
Date: Thursday, May 23, 2013 4:06 PM
To: "chef@lists.opscode.commailto:chef@lists.opscode.com" <chef@lists.opscode.commailto:chef@lists.opscode.com>
Subject: [chef] Re: Re: Server 2012/WinRM3 uses different security?

WinRM does impose limitations on what you can do over that interface. I fought with this for a quite a bit a while back when trying to get nodes to automatically install windows updates.

I ended up on Using WUA From a Remote Computer - Win32 apps | Microsoft Learn

On that page in the section "The following list contains interfaces and properties that are not available to remote users and applications" it lists a number of interfaces which are disallowed. I know in my case, with Windows updates I was restricted on "IUpdateSession::CreateUpdateDownloader".

If I ran my windows update code over SSH (WinSSHD), it would work just fine, however when chef-client was invoked over WinRM, it would fail with "OLE error code:80070005"

Luckily for me we have WinSSHD across the board, so I was able to just punt and use SSH.

Sorry thats not really a solution, but I did want to pass along the info I had learned (the hard way)

On Thu, May 23, 2013 at 4:10 PM, Peter Donald <peter@realityforge.orgmailto:peter@realityforge.org> wrote:
Hi,

On Fri, May 24, 2013 at 4:39 AM, Nate Fox <nfox@neogov.commailto:nfox@neogov.com> wrote:

My question is this: is there a permissions issue of some kind when running
chef through WinRM3 that doesnt allow programs to go out to the internet?

I was fighting with the exact same problem yesterday. Yet to find an
answer. It seems it is anything requiring network credentials is
disabled. We can't even access the local DFS. It has been suggested
that we need to set up Multi-hop support [1] for winrm but I have't
yet to figure out how to do that via knife. All of the instructions
seem to be for when using windows as the client where we run chef off
non-windows hosts.

6

On Fri, May 24, 2013 at 11:50 AM, Adam Edwards adamed@opscode.com wrote:

Question: has anyone actually repro'd this outside of Win2k12?

Yes, I ran into this on Windows 2008R2

One workaround is to use scheduled tasks, another is to use psexec — see
http://tickets.opscode.com/browse/COOK-1172.

Agreed, the schedule task trick also works. We actually use this trickery
to "fully patch" a box. When we bootstrap a new node, The first thing we do
is created a schedule task, and then append our patching recipe recipe, so
that the schedule task will then fire off the next run including the
patching recipe. We do this because we have some unknown number of reboots
required to fully patch a new node. We use the schedule task to do the
install/reboot/check if more are needed loop. Once no more patches are
needed, the patching recipe is removed from the run_list

7

Your patch trick is cool. I just wrote a similar thing that uses vbscript to patch boxes built from an iso using peewee. I start a scheduled task, though after that, it copies the patching script into the startup folder (was easier for me to watch it in VirtualBox). Once it hits 0 updates to install, it then syspreps and shuts the box down.

If enough people are doing this it should probably make it into veewee, bento, chef cookbook, or other automation.

-Adam

From: David Petzel <davidpetzel@gmail.commailto:davidpetzel@gmail.com>
Reply-To: "chef@lists.opscode.commailto:chef@lists.opscode.com" <chef@lists.opscode.commailto:chef@lists.opscode.com>
Date: Friday, May 24, 2013 8:56 AM
To: "chef@lists.opscode.commailto:chef@lists.opscode.com" <chef@lists.opscode.commailto:chef@lists.opscode.com>
Subject: [chef] Re: Re: Re: Re: Server 2012/WinRM3 uses different security?

On Fri, May 24, 2013 at 11:50 AM, Adam Edwards <adamed@opscode.commailto:adamed@opscode.com> wrote:
Question: has anyone actually repro’d this outside of Win2k12?

Yes, I ran into this on Windows 2008R2

One workaround is to use scheduled tasks, another is to use psexec - see http://tickets.opscode.com/browse/COOK-1172.

Agreed, the schedule task trick also works. We actually use this trickery to “fully patch” a box. When we bootstrap a new node, The first thing we do is created a schedule task, and then append our patching recipe recipe, so that the schedule task will then fire off the next run including the patching recipe. We do this because we have some unknown number of reboots required to fully patch a new node. We use the schedule task to do the install/reboot/check if more are needed loop. Once no more patches are needed, the patching recipe is removed from the run_list