Getting "Access denied" when use mount in recipe and run chef-client remotely via winrm

[o_haya]

Hi,

I have been implementing some recipes/cookbooks for deploying and configuring Sharepoint and Exchange onto our Windows servers. These servers would be domain mmembers.

I was originally testing by logging into one of the Windows server and then running “chef-client -o myCookbook” and was finally able to get them working this past week.

Both sets of recipes expect the respective installation files to be shared out from the domain controller and the recipes do a “mount” to “Z:” drive, and then the recipes do “cd z:” and then execute the appropriate .exe inside a powershell_script resource.

As I said, I got these recipes working this week, but in the real world, we would want to trigger the cookbook/recipe execution remotely using like “knife winrm”, so I started testing the recipes using “knife winrm” this weekend, and, in both cases, I ran into similar problems with both sets of recipes.

The first problem was that the “mount” would fail with “access denied”, so I’ve since tried (a) pre-creating the mapped drive outside of Chef and also (b) physically copying the entire directories of installation software to the local C: drive and running the installations off of the local files.

Unfortunately, neither (a) nor (b) approach worked either. These failures occur at different points of the installation, but my impression is that all the failures are coming down to some kind of access denied or violation.

So, I’ve spent most of this weekend testing and researching, which lead me to find some older threads and information on things like credssp an “2-hop” that seem to indicate that these problems have been around for awhile, so I was wondering if there’s some mechanism or configuration that should fix he problem nowadays?

Also, I should mention that I’m tried setting the WinRM CredSSP to “true” on both the server side and on my client (Chef workstation) side, but that hasn’t made any difference.

Can anyone here tell me how I can get these cookbooks/recipes to work using “knife winrm”?

Thanks,
Jim

[Steven_Murawski]

You are hitting one of the core challenges in dealing with Windows remote management. The ruby WinRM gem, which we use for knife-windows, doesn’t support CredSSP credential delegation (and there are security concerns with that anyway). A better workaround would be to create a scheduled task that will run Chef Client and trigger that from winrm (with schtasks /run). This gets around the logon type and credential delegation issues running in WinRM provide.

The cause of the issue is that when you land in a remote shell hosted inside WinRM (either WinRS or PowerShell Remoting), you’re connecting to a service and that service does not have the right to pass on your credentials to other services/computers. So when you try to mount the outside resource, it attempts to connect as the computer’s Network Service account. The path around this is either Kerberos delegation (which has requirements on the client side and in Active Directory) or CredSSP, which the WinRM gem doesn’t handle. Task scheduler suffers no such problems (and is a better way to run Chef Client - and closer to how it should run in a production context.

Steve

Steven Murawski
Community Software Development Engineer @ Chef
Microsoft MVP - PowerShell
http://stevenmurawski.com [http://stevenmurawski.com/]
On 7/1/2015 9:54:21 PM, o haya ohaya@yahoo.com wrote:
Hi,

I have been implementing some recipes/cookbooks for deploying and configuring Sharepoint and Exchange onto our Windows servers. These servers would be domain mmembers.

I was originally testing by logging into one of the Windows server and then running “chef-client -o myCookbook” and was finally able to get them working this past week.

Both sets of recipes expect the respective installation files to be shared out from the domain controller and the recipes do a “mount” to “Z:” drive, and then the recipes do “cd z:” and then execute the appropriate .exe inside a powershell_script resource.

As I said, I got these recipes working this week, but in the real world, we would want to trigger the cookbook/recipe execution remotely using like “knife winrm”, so I started testing the recipes using “knife winrm” this weekend, and, in both cases, I ran into similar problems with both sets of recipes.

The first problem was that the “mount” would fail with “access denied”, so I’ve since tried (a) pre-creating the mapped drive outside of Chef and also (b) physically copying the entire directories of installation software to the local C: drive and running the installations off of the local files.

Unfortunately, neither (a) nor (b) approach worked either. These failures occur at different points of the installation, but my impression is that all the failures are coming down to some kind of access denied or violation.

So, I’ve spent most of this weekend testing and researching, which lead me to find some older threads and information on things like credssp an “2-hop” that seem to indicate that these problems have been around for awhile, so I was wondering if there’s some mechanism or configuration that should fix he problem nowadays?

Also, I should mention that I’m tried setting the WinRM CredSSP to “true” on both the server side and on my client (Chef workstation) side, but that hasn’t made any difference.

Can anyone here tell me how I can get these cookbooks/recipes to work using “knife winrm”?

Thanks,
Jim

[o_haya]

Hi,

Thanks for the info. I was just about to post that I’ve had some success today, but doing something different… leveraging the Chef Windows service. What I did was set the user’s credentials in place of whatever was in that service (in my case the Windows domain Administrator) and then let the service fire off my recipe/cookbook. I have to so some tweaking of the design of my recipes to prevent them from re-running more than once, but I was surprised that it works after that.

I had seen mention of using task scheduler/schtasks before, and I would’ve tried that for this situation, but when I was looking into how to do processing across reboots, but even though I was able to get the task scheduling part done, the recipes appeared to run into the same type of access denied problems. I fought with that for a couple of days, and finally gave up on it.

In particular, I was doing a recipe for deploying Exchange, and it required installing some prerequisites and then a reboot and then the actual installation. So back then, I would have the first part of the recipe create a scheduled task via schtasks, for the 2nd part, but when the 2nd part, which was what actually ran the setup.exe and psconfig.exe, ran, it kept throwing errors indicating that something wasn’t accessible.

So, at this point, the service approach is the only approach that works for me.

Thanks again,
Jim

P.S. I kind of guessed that there wasn’t something, but I posted because the threads, etc I found on the credssp and chef were a couple of years old, and was hoping that there’d be something better by now :(…

---

On Thu, 7/2/15, Steven Murawski steven.murawski@gmail.com wrote:

Subject: [chef] Re: Getting “Access denied” when use mount in recipe and run chef-client remotely via winrm
To: chef@lists.opscode.com
Cc: “o haya” ohaya@yahoo.com
Date: Thursday, July 2, 2015, 3:02 PM

                                     You are hitting one of the

core challenges in dealing with Windows remote management.
The ruby WinRM gem, which we use for knife-windows,
doesn’t support CredSSP credential delegation (and there
are security concerns with that anyway). A better
workaround would be to create a scheduled task that will run
Chef Client and trigger that from winrm (with schtasks
/run). This gets around the logon type and credential
delegation issues running in WinRM provide.
The cause of the issue is that when you
land in a remote shell hosted inside WinRM (either WinRS or
PowerShell Remoting), you’re connecting to a service and
that service does not have the right to pass on your
credentials to other services/computers. So when you try
to mount the outside resource, it attempts to connect as the
computer’s Network Service account. The path around
this is either Kerberos delegation (which has requirements
on the client side and in Active Directory) or CredSSP,
which the WinRM gem doesn’t handle. Task scheduler
suffers no such problems (and is a better way to run Chef
Client - and closer to how it should run in a production
context.
Steve
Steven MurawskiCommunity Software Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com
On 7/1/2015 9:54:21
PM, o haya ohaya@yahoo.com wrote:Hi,

I have been implementing some
recipes/cookbooks for deploying and configuring Sharepoint
and Exchange onto our Windows servers. These servers would
be domain mmembers.

I was originally testing by logging into
one of the Windows server and then running “chef-client
-o myCookbook” and was finally able to get them working
this past week.

Both sets of recipes expect the respective
installation files to be shared out from the domain
controller and the recipes do a “mount” to
"Z:" drive, and then the recipes do “cd
z:” and then execute the appropriate .exe inside a
powershell_script resource.

As I said, I got these recipes working this
week, but in the real world, we would want to trigger the
cookbook/recipe execution remotely using like “knife
winrm”, so I started testing the recipes using
"knife winrm" this weekend, and, in both cases, I
ran into similar problems with both sets of recipes.

The first problem was that the
"mount" would fail with “access denied”,
so I’ve since tried (a) pre-creating the mapped drive
outside of Chef and also (b) physically copying the entire
directories of installation software to the local C: drive
and running the installations off of the local files.

Unfortunately, neither (a) nor (b) approach
worked either. These failures occur at different points of
the installation, but my impression is that all the failures
are coming down to some kind of access denied or violation.

So, I’ve spent most of this weekend
testing and researching, which lead me to find some older
threads and information on things like credssp an
"2-hop" that seem to indicate that these problems
have been around for awhile, so I was wondering if
there’s some mechanism or configuration that should fix
he problem nowadays?

Also, I should mention that I’m tried
setting the WinRM CredSSP to “true” on both the
server side and on my client (Chef workstation) side, but
that hasn’t made any difference.

Can anyone here tell me how I can get these
cookbooks/recipes to work using “knife winrm”?

Thanks,

Jim

[o_haya]

BTW, I should mention that I have a ticket on a slightly “larger” question and this came up right in the middle of that ticket, so I’ve conveyed info on what I di to the support person (Vikas). I also was wondering out loud if maybe you guys might make something like a credential proxy or maybe add that capability to the existing Chef Windows service.

Understanding that this is generically a Windows problem, it still seems like both the scheduled task (if it worked for me) and the service approaches are kind of “un-natural” (read: kludgy) ways to do this, but that’s just my opinion.

---

On Thu, 7/2/15, o haya ohaya@yahoo.com wrote:

Subject: Re: [chef] Re: Getting “Access denied” when use mount in recipe and run chef-client remotely via winrm
To: chef@lists.opscode.com
Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 3:24 PM

Hi,

Thanks for the info. I was just about to post
that I’ve had some success today, but doing something
different… leveraging the Chef Windows service. What I
did was set the user’s credentials in place of whatever
was in that service (in my case the Windows domain
Administrator) and then let the service fire off my
recipe/cookbook. I have to so some tweaking of the design
of my recipes to prevent them from re-running more than
once, but I was surprised that it works after that.

I had seen mention of using
task scheduler/schtasks before, and I would’ve tried
that for this situation, but when I was looking into how to
do processing across reboots, but even though I was able to
get the task scheduling part done, the recipes appeared to
run into the same type of access denied problems. I fought
with that for a couple of days, and finally gave up on it.

In particular, I was doing
a recipe for deploying Exchange, and it required installing
some prerequisites and then a reboot and then the actual
installation. So back then, I would have the first part of
the recipe create a scheduled task via schtasks, for the 2nd
part, but when the 2nd part, which was what actually ran the
setup.exe and psconfig.exe, ran, it kept throwing errors
indicating that something wasn’t accessible.

So, at this point, the service
approach is the only approach that works for me.

Thanks again,
Jim

P.S. I
kind of guessed that there wasn’t something, but I
posted because the threads, etc I found on the credssp and
chef were a couple of years old, and was hoping that
there’d be something better by now :(…

---

On Thu, 7/2/15, Steven Murawski steven.murawski@gmail.com
wrote:

Subject: [chef] Re:
Getting “Access denied” when use mount in recipe
and run chef-client remotely via winrm
To:
chef@lists.opscode.com
Cc: “o haya” ohaya@yahoo.com
Date: Thursday, July 2, 2015, 3:02 PM

You are hitting one of the

core challenges in dealing with Windows remote
management.
The ruby WinRM gem, which we
use for knife-windows,
doesn’t support
CredSSP credential delegation (and there

are security concerns with that anyway). A better
workaround would be to create a scheduled task
that will run
Chef Client and trigger that
from winrm (with schtasks
/run). This
gets around the logon type and credential

delegation issues running in WinRM provide.

The cause of the issue is that when you

land in a remote shell hosted inside WinRM (either WinRS
or
PowerShell Remoting), you’re
connecting to a service and
that service
does not have the right to pass on your

credentials to other services/computers. So when you
try
to mount the outside resource, it
attempts to connect as the
computer’s
Network Service account. The path around

this is either Kerberos delegation (which has
requirements
on the client side and in
Active Directory) or CredSSP,
which the
WinRM gem doesn’t handle. Task scheduler
suffers no such problems (and is a better way
to run Chef
Client - and closer to how it
should run in a production
context.
Steve
Steven
MurawskiCommunity Software Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com

     On 7/1/2015 9:54:21

PM, o haya
ohaya@yahoo.com
wrote:Hi,

I have been implementing
some
recipes/cookbooks for deploying and
configuring Sharepoint
and Exchange onto
our Windows servers. These servers would

be domain mmembers.

I was originally testing by
logging into
one of the Windows server and
then running “chef-client
-o
myCookbook” and was finally able to get them working
this past week.

Both sets
of recipes expect the respective

installation files to be shared out from the domain
controller and the recipes do a
"mount" to
"Z:" drive,
and then the recipes do "cd
z:"
and then execute the appropriate .exe inside a
powershell_script resource.

As I
said, I got these recipes working this

week, but in the real world, we would want to trigger the
cookbook/recipe execution remotely using like
"knife
winrm", so I started
testing the recipes using
"knife
winrm" this weekend, and, in both cases, I
ran into similar problems with both sets of
recipes.

The first problem was that
the
"mount" would fail with
"access denied",
so I’ve
since tried (a) pre-creating the mapped drive
outside of Chef and also (b) physically
copying the entire
directories of
installation software to the local C: drive

and running the installations off of the local files.

Unfortunately, neither (a) nor (b) approach
worked either. These failures occur at
different points of
the installation, but
my impression is that all the failures
are
coming down to some kind of access denied or violation.

So, I’ve spent most of this weekend
testing and researching, which lead me to find
some older
threads and information on
things like credssp an
"2-hop"
that seem to indicate that these problems

have been around for awhile, so I was wondering if
there’s some mechanism or configuration
that should fix
he problem nowadays?

Also, I should mention that I’m tried
setting the WinRM CredSSP to "true"
on both the
server side and on my client
(Chef workstation) side, but
that
hasn’t made any difference.

Can anyone
here tell me how I can get these

cookbooks/recipes to work using “knife winrm”?

Thanks,

Jim

[Tensibai]

In my opinion, running chef (or any Configuration management system) on demand remotely is an anti-pattern.

If you're describing a state, the targeted machine should launch the check by itself periodically and try to fix itself as much as it can.

It's harder to compromise a network from a machine who will overwrite your exploits changes every 30 minutes and enforce you to restart your compromission from scratch over and over again.

That's just my opinion too

Le 2 juil. 2015 21:29, o haya ohaya@yahoo.com a écrit :

BTW, I should mention that I have a ticket on a slightly "larger" question and this came up right in the middle of that ticket, so I've conveyed info on what I di to the support person (Vikas). I also was wondering out loud if maybe you guys might make something like a credential proxy or maybe add that capability to the existing Chef Windows service.

Understanding that this is generically a Windows problem, it still seems like both the scheduled task (if it worked for me) and the service approaches are kind of "un-natural" (read: kludgy) ways to do this, but that's just my opinion.

---

On Thu, 7/2/15, o haya ohaya@yahoo.com wrote:

Subject: Re: [chef] Re: Getting "Access denied" when use mount in recipe and run chef-client remotely via winrm
To: chef@lists.opscode.com
Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 3:24 PM

Hi,

Thanks for the info. I was just about to post
that I've had some success today, but doing something
different... leveraging the Chef Windows service. What I
did was set the user's credentials in place of whatever
was in that service (in my case the Windows domain
Administrator) and then let the service fire off my
recipe/cookbook. I have to so some tweaking of the design
of my recipes to prevent them from re-running more than
once, but I was surprised that it works after that.

I had seen mention of using
task scheduler/schtasks before, and I would've tried
that for this situation, but when I was looking into how to
do processing across reboots, but even though I was able to
get the task scheduling part done, the recipes appeared to
run into the same type of access denied problems. I fought
with that for a couple of days, and finally gave up on it.

In particular, I was doing
a recipe for deploying Exchange, and it required installing
some prerequisites and then a reboot and then the actual
installation. So back then, I would have the first part of
the recipe create a scheduled task via schtasks, for the 2nd
part, but when the 2nd part, which was what actually ran the
setup.exe and psconfig.exe, ran, it kept throwing errors
indicating that something wasn't accessible.

So, at this point, the service
approach is the only approach that works for me.

Thanks again,
Jim

P.S. I
kind of guessed that there wasn't something, but I
posted because the threads, etc I found on the credssp and
chef were a couple of years old, and was hoping that
there'd be something better by now :(...

---

On Thu, 7/2/15, Steven Murawski steven.murawski@gmail.com
wrote:

Subject: [chef] Re:
Getting "Access denied" when use mount in recipe
and run chef-client remotely via winrm
To:
chef@lists.opscode.com
Cc: "o haya" ohaya@yahoo.com
Date: Thursday, July 2, 2015, 3:02 PM

You are hitting one of the

core challenges in dealing with Windows remote
management.
The ruby WinRM gem, which we
use for knife-windows,
doesn't support
CredSSP credential delegation (and there

are security concerns with that anyway). A better
workaround would be to create a scheduled task
that will run
Chef Client and trigger that
from winrm (with schtasks
/run). This
gets around the logon type and credential

delegation issues running in WinRM provide.

The cause of the issue is that when you

land in a remote shell hosted inside WinRM (either WinRS
or
PowerShell Remoting), you're
connecting to a service and
that service
does not have the right to pass on your

credentials to other services/computers. So when you
try
to mount the outside resource, it
attempts to connect as the
computer's
Network Service account. The path around

this is either Kerberos delegation (which has
requirements
on the client side and in
Active Directory) or CredSSP,
which the
WinRM gem doesn't handle. Task scheduler
suffers no such problems (and is a better way
to run Chef
Client - and closer to how it
should run in a production
context.
Steve
Steven
MurawskiCommunity Software Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com

    On 7/1/2015 9:54:21 

PM, o haya
ohaya@yahoo.com
wrote:Hi,

I have been implementing
some
recipes/cookbooks for deploying and
configuring Sharepoint
and Exchange onto
our Windows servers. These servers would

be domain mmembers.

I was originally testing by
logging into
one of the Windows server and
then running "chef-client
-o
myCookbook" and was finally able to get them working
this past week.

Both sets
of recipes expect the respective

installation files to be shared out from the domain
controller and the recipes do a
"mount" to
"Z:" drive,
and then the recipes do "cd
z:"
and then execute the appropriate .exe inside a
powershell_script resource.

As I
said, I got these recipes working this

week, but in the real world, we would want to trigger the
cookbook/recipe execution remotely using like
"knife
winrm", so I started
testing the recipes using
"knife
winrm" this weekend, and, in both cases, I
ran into similar problems with both sets of
recipes.

The first problem was that
the
"mount" would fail with
"access denied",
so I've
since tried (a) pre-creating the mapped drive
outside of Chef and also (b) physically
copying the entire
directories of
installation software to the local C: drive

and running the installations off of the local files.

Unfortunately, neither (a) nor (b) approach
worked either. These failures occur at
different points of
the installation, but
my impression is that all the failures
are
coming down to some kind of access denied or violation.

So, I've spent most of this weekend
testing and researching, which lead me to find
some older
threads and information on
things like credssp an
"2-hop"
that seem to indicate that these problems

have been around for awhile, so I was wondering if
there's some mechanism or configuration
that should fix
he problem nowadays?

Also, I should mention that I'm tried
setting the WinRM CredSSP to "true"
on both the
server side and on my client
(Chef workstation) side, but
that
hasn't made any difference.

Can anyone
here tell me how I can get these

cookbooks/recipes to work using "knife winrm"?

Thanks,

Jim

[Steven_Murawski]

So, I wasn't referring to running part of the recipe as a scheduled task, but to making the full chef-client run the scheduled task.

Understanding that this is generically a Windows problem, it still seems like both the scheduled task (if it worked for me) and the service approaches are kind of "un-natural" (read: kludgy) ways to do this, but that's just my opinion.

The general use case for Chef Client is to run in the background on a schedule, validating the known good state of the system and picking up changes when necessary. This is usually accomplished as a service (or daemon) or via a scheduled task (or cron job). On Windows, I find the task scheduler the better option, as you have more flexibility in determining the conditions you can run the task in, it easily supports alternate credentials, can be run on demand as well, and isn't treated as a service logon.

There is an use case for invoking chef-client over winrm (or ssh) via some orchestration engine rather than running on a schedule, but that means you'll have to deal with the limitations of WinRM. There are just too many "gotchas" in running in the WinRM context. Many Win32 APIs can't be called from a non-interactive logon (which WinRM is treated as) and you have the credential delegation problem.

As for setting up Chef to run as a service or scheduled task, the chef-client cookbook ( https://supermarket.chef.io/cookbooks/chef-client ) can help with that (though I don't think it wires up "on reboot").

Steven Murawski
Community Software Development Engineer @ Chef
Microsoft MVP - PowerShell
http://stevenmurawski.com [http://stevenmurawski.com/]
On 7/2/2015 2:44:09 PM, Tensibai Zhaoying tensibai@iabis.net wrote:
In my opinion, running chef (or any Configuration management system) on demand remotely is an anti-pattern.

If you're describing a state, the targeted machine should launch the check by itself periodically and try to fix itself as much as it can.

It's harder to compromise a network from a machine who will overwrite your exploits changes every 30 minutes and enforce you to restart your compromission from scratch over and over again.

That's just my opinion too

Le 2 juil. 2015 21:29, o haya a écrit :

BTW, I should mention that I have a ticket on a slightly "larger" question and this came up right in the middle of that ticket, so I've conveyed info on what I di to the support person (Vikas). I also was wondering out loud if maybe you guys might make something like a credential proxy or maybe add that capability to the existing Chef Windows service.

Understanding that this is generically a Windows problem, it still seems like both the scheduled task (if it worked for me) and the service approaches are kind of "un-natural" (read: kludgy) ways to do this, but that's just my opinion.

---

On Thu, 7/2/15, o haya wrote:

Subject: Re: [chef] Re: Getting "Access denied" when use mount in recipe and run chef-client remotely via winrm
To: chef@lists.opscode.com
Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 3:24 PM

Hi,

Thanks for the info. I was just about to post
that I've had some success today, but doing something
different... leveraging the Chef Windows service. What I
did was set the user's credentials in place of whatever
was in that service (in my case the Windows domain
Administrator) and then let the service fire off my
recipe/cookbook. I have to so some tweaking of the design
of my recipes to prevent them from re-running more than
once, but I was surprised that it works after that.

I had seen mention of using
task scheduler/schtasks before, and I would've tried
that for this situation, but when I was looking into how to
do processing across reboots, but even though I was able to
get the task scheduling part done, the recipes appeared to
run into the same type of access denied problems. I fought
with that for a couple of days, and finally gave up on it.

In particular, I was doing
a recipe for deploying Exchange, and it required installing
some prerequisites and then a reboot and then the actual
installation. So back then, I would have the first part of
the recipe create a scheduled task via schtasks, for the 2nd
part, but when the 2nd part, which was what actually ran the
setup.exe and psconfig.exe, ran, it kept throwing errors
indicating that something wasn't accessible.

So, at this point, the service
approach is the only approach that works for me.

Thanks again,
Jim

P.S. I
kind of guessed that there wasn't something, but I
posted because the threads, etc I found on the credssp and
chef were a couple of years old, and was hoping that
there'd be something better by now :(...

---

On Thu, 7/2/15, Steven Murawski
wrote:

Subject: [chef] Re:
Getting "Access denied" when use mount in recipe
and run chef-client remotely via winrm
To:
chef@lists.opscode.com
Cc: "o haya"
Date: Thursday, July 2, 2015, 3:02 PM

You are hitting one of the

core challenges in dealing with Windows remote
management.
The ruby WinRM gem, which we
use for knife-windows,
doesn't support
CredSSP credential delegation (and there

are security concerns with that anyway). A better
workaround would be to create a scheduled task
that will run
Chef Client and trigger that
from winrm (with schtasks
/run). This
gets around the logon type and credential

delegation issues running in WinRM provide.

The cause of the issue is that when you

land in a remote shell hosted inside WinRM (either WinRS
or
PowerShell Remoting), you're
connecting to a service and
that service
does not have the right to pass on your

credentials to other services/computers. So when you
try
to mount the outside resource, it
attempts to connect as the
computer's
Network Service account. The path around

this is either Kerberos delegation (which has
requirements
on the client side and in
Active Directory) or CredSSP,
which the
WinRM gem doesn't handle. Task scheduler
suffers no such problems (and is a better way
to run Chef
Client - and closer to how it
should run in a production
context.
Steve
Steven
MurawskiCommunity Software Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com

    On 7/1/2015 9:54:21

PM, o haya

wrote:Hi,

I have been implementing
some
recipes/cookbooks for deploying and
configuring Sharepoint
and Exchange onto
our Windows servers. These servers would

be domain mmembers.

I was originally testing by
logging into
one of the Windows server and
then running "chef-client
-o
myCookbook" and was finally able to get them working
this past week.

Both sets
of recipes expect the respective

installation files to be shared out from the domain
controller and the recipes do a
"mount" to
"Z:" drive,
and then the recipes do "cd
z:"
and then execute the appropriate .exe inside a
powershell_script resource.

As I
said, I got these recipes working this

week, but in the real world, we would want to trigger the
cookbook/recipe execution remotely using like
"knife
winrm", so I started
testing the recipes using
"knife
winrm" this weekend, and, in both cases, I
ran into similar problems with both sets of
recipes.

The first problem was that
the
"mount" would fail with
"access denied",
so I've
since tried (a) pre-creating the mapped drive
outside of Chef and also (b) physically
copying the entire
directories of
installation software to the local C: drive

and running the installations off of the local files.

Unfortunately, neither (a) nor (b) approach
worked either. These failures occur at
different points of
the installation, but
my impression is that all the failures
are
coming down to some kind of access denied or violation.

So, I've spent most of this weekend
testing and researching, which lead me to find
some older
threads and information on
things like credssp an
"2-hop"
that seem to indicate that these problems

have been around for awhile, so I was wondering if
there's some mechanism or configuration
that should fix
he problem nowadays?

Also, I should mention that I'm tried
setting the WinRM CredSSP to "true"
on both the
server side and on my client
(Chef workstation) side, but
that
hasn't made any difference.

Can anyone
here tell me how I can get these

cookbooks/recipes to work using "knife winrm"?

Thanks,

Jim

[o_haya]

Steven and Tensibai (et al),

Thanks for the interesting comments and discussion.

With that, I think that my perspective is probably a little (maybe a lot) different, which probably explains the differences in opinion.

In our case, we are not looking to maintaining an environment or environments over time, but rather, our desire is to be able to deploy specified environments kind of "on demand", mostly one-time events. That is why the winrm-type approach is/would be most attractive (and as I said, "natural") to us.

Thanks again,
Jim

---

On Thu, 7/2/15, Steven Murawski steven.murawski@gmail.com wrote:

Subject: [chef] Re: Re: Re: Re: Getting "Access denied" when use mount in recipe and run chef-client remotely via winrm
To: chef@lists.opscode.com
Date: Thursday, July 2, 2015, 4:08 PM

So, I wasn't referring to
running part of the recipe as a scheduled task, but to
making the full chef-client run the scheduled
task.

Understanding that this is generically a Windows
problem, it still seems like both the scheduled task (if it
worked for me) and the service approaches are kind of
"un-natural" (read: kludgy) ways to do this, but
that's just my opinion.
The
general use case for Chef Client is to run in the background
on a schedule, validating the known good state of the system
and picking up changes when necessary. This is usually
accomplished as a service (or daemon) or via a scheduled
task (or cron job). On Windows, I find the task scheduler
the better option, as you have more flexibility in
determining the conditions you can run the task in, it
easily supports alternate credentials, can be run on demand
as well, and isn't treated as a service
logon.
There is an use
case for invoking chef-client over winrm (or ssh) via some
orchestration engine rather than running on a schedule, but
that means you'll have to deal with the limitations of
WinRM. There are just too many "gotchas" in
running in the WinRM context. Many Win32 APIs can't be
called from a non-interactive logon (which WinRM is treated
as) and you have the credential delegation
problem.
As for
setting up Chef to run as a service or scheduled task, the
chef-client cookbook (
https://supermarket.chef.io/cookbooks/chef-client ) can help
with that (though I don't think it wires up "on
reboot").
Steven MurawskiCommunity Software Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com
On 7/2/2015 2:44:09
PM, Tensibai Zhaoying tensibai@iabis.net
wrote:In my opinion, running chef (or any Configuration
management system) on demand remotely is an anti-pattern.

If you're describing a
state, the targeted machine should launch the check by
itself periodically and try to fix itself as much as it
can.

It's harder to
compromise a network from a machine who will overwrite your
exploits changes every 30 minutes and enforce you to restart
your compromission from scratch over and over again.

That's just my opinion too

Le 2 juil. 2015 21:29,
o haya a écrit :

BTW, I should mention that I have a ticket
on a slightly "larger" question and this came up
right in the middle of that ticket, so I've conveyed
info on what I di to the support person (Vikas). I also
was wondering out loud if maybe you guys might make
something like a credential proxy or maybe add that
capability to the existing Chef Windows service.

Understanding that
this is generically a Windows problem, it still seems like
both the scheduled task (if it worked for me) and the
service approaches are kind of "un-natural" (read:
kludgy) ways to do this, but that's just my opinion.

---

On Thu, 7/2/15, o haya wrote:

Subject: Re: [chef] Re: Getting
"Access denied" when use mount in recipe and run
chef-client remotely via winrm
To:
chef@lists.opscode.com
Cc:
ohaya@yahoo.com
Date: Thursday, July
2, 2015, 3:24 PM

Hi,

Thanks for
the info. I was just about to post

that I've had some success today, but doing something

different... leveraging the Chef
Windows service. What I
did was set
the user's credentials in place of whatever
was in that service (in my case the
Windows domain
Administrator) and then
let the service fire off my

recipe/cookbook. I have to so some tweaking of the design

of my recipes to prevent them from
re-running more than
once, but I was
surprised that it works after that.

I had seen mention of using
task scheduler/schtasks before, and I
would've tried
that for this
situation, but when I was looking into how to
do processing across reboots, but even
though I was able to
get the task
scheduling part done, the recipes appeared to
run into the same type of access denied
problems. I fought
with that for a
couple of days, and finally gave up on it.

In particular, I was doing

a recipe
for deploying Exchange, and it required installing
some prerequisites and then a reboot and
then the actual
installation. So
back then, I would have the first part of
the recipe create a scheduled task via
schtasks, for the 2nd
part, but when
the 2nd part, which was what actually ran the
setup.exe and psconfig.exe, ran, it kept
throwing errors
indicating that
something wasn't accessible.

So, at this point, the service
approach is the only approach that works
for me.

Thanks
again,
Jim

P.S. I
kind of
guessed that there wasn't something, but I
posted because the threads, etc I found on
the credssp and
chef were a couple of
years old, and was hoping that

there'd be something better by now :(...

---

On Thu, 7/2/15, Steven Murawski
wrote:

Subject: [chef] Re:
Getting "Access denied" when use
mount in recipe
and run chef-client
remotely via winrm
To:
chef@lists.opscode.com
Cc: "o haya"
Date: Thursday, July 2, 2015, 3:02 PM

You are hitting one of the 

core challenges in dealing with Windows
remote
management.
The ruby WinRM gem, which we
use for knife-windows,
doesn't support
CredSSP credential delegation (and there

are security
concerns with that anyway). A better

workaround would be to create a scheduled task

that will run

Chef Client and trigger that

from
winrm (with schtasks
/run). This

gets around the logon type and
credential

delegation issues running in WinRM provide.

The cause of the
issue is that when you

land in a remote shell hosted inside WinRM
(either WinRS
or

PowerShell Remoting), you're

connecting to a service and

that
service
does not have the right to
pass on your

credentials to other services/computers. So when you

try
to mount the
outside resource, it
attempts to
connect as the
computer's
Network Service account. The path around

this is either
Kerberos delegation (which has

requirements

on the client side and
in
Active Directory) or CredSSP,
which the
WinRM
gem doesn't handle. Task scheduler
suffers no such problems (and is a
better way
to run Chef
Client - and closer to how it
should run in a production
context.
Steve

Steven

MurawskiCommunity Software Development Engineer @

ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com

    On 7/1/2015 9:54:21

PM, o haya

wrote:Hi,

I have been implementing
some

recipes/cookbooks for deploying and

configuring Sharepoint

and Exchange
onto
our Windows servers. These
servers would

be
domain mmembers.

I was originally testing by
logging into
one
of the Windows server and
then running
"chef-client
-o
myCookbook" and was finally able to
get them working
this past week.

Both sets
of recipes expect the respective

installation files to
be shared out from the domain

controller and the recipes do a

"mount" to

"Z:"
drive,
and then the recipes do
"cd
z:"
and then execute the appropriate .exe
inside a
powershell_script
resource.

As I
said, I got
these recipes working this

week, but in the real world, we would want
to trigger the
cookbook/recipe
execution remotely using like

"knife

winrm", so I
started
testing the recipes using
"knife

winrm" this weekend, and, in both cases, I

ran into similar problems with both
sets of
recipes.

The first
problem was that
the
"mount" would fail with
"access denied",
so I've
since
tried (a) pre-creating the mapped drive
outside of Chef and also (b) physically

copying the entire
directories of

installation software to the local C: drive

and running the
installations off of the local files.

Unfortunately, neither (a) nor (b)
approach
worked either. These
failures occur at
different points of

the installation, but
my impression is that all the failures
are
coming down
to some kind of access denied or violation.

So, I've
spent most of this weekend
testing
and researching, which lead me to find

some older

threads and information
on
things like credssp an
"2-hop"

that seem to indicate that these problems

have been around for
awhile, so I was wondering if

there's some mechanism or configuration

that should fix

he problem nowadays?

Also, I should mention that I'm
tried
setting the WinRM CredSSP to
"true"
on both the
server side and on my client
(Chef workstation) side, but
that
hasn't
made any difference.

Can anyone
here
tell me how I can get these

cookbooks/recipes to work using
"knife winrm"?

Thanks,

Jim

[Tensibai]

Firing a scheduled task remotely is easy and get you rid of the whole credential replay needed from winrm.

This method works since winnt4 (at least) and has been used for decades to trigger db stop and then server Shutdown when there's a power outage and batteries lifetime is running low (usually this was part of the weekly reboot task under nt4 :p)

This gives you the enforcement part on a regular basis + the ability to trigger a run on an event with a lot of way to trigger it (winrm may not be allowed to so this that's said, I'm unsure about the latest limitations )

In brief, this could be a way to solve your problem on both sides (credentials of the process and on demand ability)

Le 2 juil. 2015 22:31, o haya ohaya@yahoo.com a écrit :

Steven and Tensibai (et al),

Thanks for the interesting comments and discussion.

With that, I think that my perspective is probably a little (maybe a lot) different, which probably explains the differences in opinion.

In our case, we are not looking to maintaining an environment or environments over time, but rather, our desire is to be able to deploy specified environments kind of "on demand", mostly one-time events. That is why the winrm-type approach is/would be most attractive (and as I said, "natural") to us.

Thanks again,
Jim

---

On Thu, 7/2/15, Steven Murawski steven.murawski@gmail.com wrote:

Subject: [chef] Re: Re: Re: Re: Getting "Access denied" when use mount in recipe and run chef-client remotely via winrm
To: chef@lists.opscode.com
Date: Thursday, July 2, 2015, 4:08 PM

So, I wasn't referring to
running part of the recipe as a scheduled task, but to
making the full chef-client run the scheduled
task.

Understanding that this is generically a Windows
problem, it still seems like both the scheduled task (if it
worked for me) and the service approaches are kind of
"un-natural" (read: kludgy) ways to do this, but
that's just my opinion.
The
general use case for Chef Client is to run in the background
on a schedule, validating the known good state of the system
and picking up changes when necessary. This is usually
accomplished as a service (or daemon) or via a scheduled
task (or cron job). On Windows, I find the task scheduler
the better option, as you have more flexibility in
determining the conditions you can run the task in, it
easily supports alternate credentials, can be run on demand
as well, and isn't treated as a service
logon.
There is an use
case for invoking chef-client over winrm (or ssh) via some
orchestration engine rather than running on a schedule, but
that means you'll have to deal with the limitations of
WinRM. There are just too many "gotchas" in
running in the WinRM context. Many Win32 APIs can't be
called from a non-interactive logon (which WinRM is treated
as) and you have the credential delegation
problem.
As for
setting up Chef to run as a service or scheduled task, the
chef-client cookbook (
https://supermarket.chef.io/cookbooks/chef-client ) can help
with that (though I don't think it wires up "on
reboot").
Steven MurawskiCommunity Software Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com
On 7/2/2015 2:44:09
PM, Tensibai Zhaoying tensibai@iabis.net
wrote:In my opinion, running chef (or any Configuration
management system) on demand remotely is an anti-pattern.

If you're describing a
state, the targeted machine should launch the check by
itself periodically and try to fix itself as much as it
can.

It's harder to
compromise a network from a machine who will overwrite your
exploits changes every 30 minutes and enforce you to restart
your compromission from scratch over and over again.

That's just my opinion too

Le 2 juil. 2015 21:29,
o haya a écrit :

BTW, I should mention that I have a ticket
on a slightly "larger" question and this came up
right in the middle of that ticket, so I've conveyed
info on what I di to the support person (Vikas). I also
was wondering out loud if maybe you guys might make
something like a credential proxy or maybe add that
capability to the existing Chef Windows service.

Understanding that
this is generically a Windows problem, it still seems like
both the scheduled task (if it worked for me) and the
service approaches are kind of "un-natural" (read:
kludgy) ways to do this, but that's just my opinion.

---

On Thu, 7/2/15, o haya wrote:

Subject: Re: [chef] Re: Getting
"Access denied" when use mount in recipe and run
chef-client remotely via winrm
To:
chef@lists.opscode.com
Cc:
ohaya@yahoo.com
Date: Thursday, July
2, 2015, 3:24 PM

Hi,

Thanks for
the info. I was just about to post

that I've had some success today, but doing something

different... leveraging the Chef
Windows service. What I
did was set
the user's credentials in place of whatever
was in that service (in my case the
Windows domain
Administrator) and then
let the service fire off my

recipe/cookbook. I have to so some tweaking of the design

of my recipes to prevent them from
re-running more than
once, but I was
surprised that it works after that.

I had seen mention of using
task scheduler/schtasks before, and I
would've tried
that for this
situation, but when I was looking into how to
do processing across reboots, but even
though I was able to
get the task
scheduling part done, the recipes appeared to
run into the same type of access denied
problems. I fought
with that for a
couple of days, and finally gave up on it.

In particular, I was doing

a recipe
for deploying Exchange, and it required installing
some prerequisites and then a reboot and
then the actual
installation. So
back then, I would have the first part of
the recipe create a scheduled task via
schtasks, for the 2nd
part, but when
the 2nd part, which was what actually ran the
setup.exe and psconfig.exe, ran, it kept
throwing errors
indicating that
something wasn't accessible.

So, at this point, the service
approach is the only approach that works
for me.

Thanks
again,
Jim

P.S. I
kind of
guessed that there wasn't something, but I
posted because the threads, etc I found on
the credssp and
chef were a couple of
years old, and was hoping that

there'd be something better by now :(...

---

On Thu, 7/2/15, Steven Murawski
wrote:

Subject: [chef] Re:
Getting "Access denied" when use
mount in recipe
and run chef-client
remotely via winrm
To:
chef@lists.opscode.com
Cc: "o haya"
Date: Thursday, July 2, 2015, 3:02 PM

You are hitting one of the

core challenges in dealing with Windows
remote
management.
The ruby WinRM gem, which we
use for knife-windows,
doesn't support
CredSSP credential delegation (and there

are security
concerns with that anyway). A better

workaround would be to create a scheduled task

that will run

Chef Client and trigger that

from
winrm (with schtasks
/run). This

gets around the logon type and
credential

delegation issues running in WinRM provide.

The cause of the
issue is that when you

land in a remote shell hosted inside WinRM
(either WinRS
or

PowerShell Remoting), you're

connecting to a service and

that
service
does not have the right to
pass on your

credentials to other services/computers. So when you

try
to mount the
outside resource, it
attempts to
connect as the
computer's
Network Service account. The path around

this is either
Kerberos delegation (which has

requirements

on the client side and
in
Active Directory) or CredSSP,
which the
WinRM
gem doesn't handle. Task scheduler
suffers no such problems (and is a
better way
to run Chef
Client - and closer to how it
should run in a production
context.
Steve

Steven

MurawskiCommunity Software Development Engineer @

ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com

    On 7/1/2015 9:54:21 

PM, o haya

wrote:Hi,

I have been implementing
some

recipes/cookbooks for deploying and

configuring Sharepoint

and Exchange
onto
our Windows servers. These
servers would

be
domain mmembers.

I was originally testing by
logging into
one
of the Windows server and
then running
"chef-client
-o
myCookbook" and was finally able to
get them working
this past week.

Both sets
of recipes expect the respective

installation files to
be shared out from the domain

controller and the recipes do a

"mount" to

"Z:"
drive,
and then the recipes do
"cd
z:"
and then execute the appropriate .exe
inside a
powershell_script
resource.

As I
said, I got
these recipes working this

week, but in the real world, we would want
to trigger the
cookbook/recipe
execution remotely using like

"knife

winrm", so I
started
testing the recipes using
"knife

winrm" this weekend, and, in both cases, I

ran into similar problems with both
sets of
recipes.

The first
problem was that
the
"mount" would fail with
"access denied",
so I've
since
tried (a) pre-creating the mapped drive
outside of Chef and also (b) physically

copying the entire
directories of

installation software to the local C: drive

and running the
installations off of the local files.

Unfortunately, neither (a) nor (b)
approach
worked either. These
failures occur at
different points of

the installation, but
my impression is that all the failures
are
coming down
to some kind of access denied or violation.

So, I've
spent most of this weekend
testing
and researching, which lead me to find

some older

threads and information
on
things like credssp an
"2-hop"

that seem to indicate that these problems

have been around for
awhile, so I was wondering if

there's some mechanism or configuration

that should fix

he problem nowadays?

Also, I should mention that I'm
tried
setting the WinRM CredSSP to
"true"
on both the
server side and on my client
(Chef workstation) side, but
that
hasn't
made any difference.

Can anyone
here
tell me how I can get these

cookbooks/recipes to work using
"knife winrm"?

Thanks,

Jim

[o_haya]

Hi,

I might go back and try that (schtasks) again later. I'd be happy if that worked, but if you recall from the Stackoverflow thread that you posted on (scheduled tasks - Is there a way for a Chef recipe to continue after a reboot (Windows)? - Stack Overflow), I did try that, but had problems with getting it to work, and actually I never got it working, so ended up abandoning using that for the Sharepoint installation because it turned out I didn't need a mid-installation reboot. The Exchange installation, on the other hand, does require a mid-installation reboot, and because I wasn't able to make the schtasks approach work earlier, I went with the Chef service approach instead. It would be good if I could get the schtasks approach working :(...

Later,
Jim

---

On Thu, 7/2/15, Tensibai Zhaoying tensibai@iabis.net wrote:

Subject: [chef] Re: Re: Re: Re: Re: Re: Getting "Access denied" when use mount in recipe and run chef-client remotely via winrm
To: chef@lists.opscode.com
Date: Thursday, July 2, 2015, 5:35 PM

Firing a scheduled task
remotely is easy and get you rid of the whole credential
replay needed from winrm.

This method works since winnt4 (at least) and
has been used for decades to trigger db stop and then server
Shutdown when there's a power outage and batteries
lifetime is running low (usually this was part of the weekly
reboot task under nt4 :p)

This gives you the enforcement part on a
regular basis + the ability to trigger a run on an event
with a lot of way to trigger it (winrm may not be allowed to
so this that's said, I'm unsure about the latest
limitations )

In brief,
this could be a way to solve your problem on both sides
(credentials of the process and on demand ability)

Le 2 juil. 2015 22:31, o haya ohaya@yahoo.com a
écrit :

Steven
and Tensibai (et al),

Thanks for the interesting comments and
discussion.

With
that, I think that my perspective is probably a little
(maybe a lot) different, which probably explains the
differences in opinion.

In our case, we are not looking to
maintaining an environment or environments over time, but
rather, our desire is to be able to deploy specified
environments kind of "on demand", mostly one-time
events. That is why the winrm-type approach is/would be
most attractive (and as I said, "natural") to us.

Thanks again,
Jim

---

On Thu, 7/2/15, Steven Murawski steven.murawski@gmail.com
wrote:

Subject:
[chef] Re: Re: Re: Re: Getting "Access denied"
when use mount in recipe and run chef-client remotely via
winrm
To: chef@lists.opscode.com

Date: Thursday, July 2, 2015, 4:08 PM

So, I wasn't
referring to
running part of the
recipe as a scheduled task, but to

making the full chef-client run the scheduled

task.

Understanding that this is
generically a Windows
problem, it
still seems like both the scheduled task (if it
worked for me) and the service approaches
are kind of
"un-natural"
(read: kludgy) ways to do this, but

that's just my opinion.

The

general use case for Chef Client is to
run in the background
on a schedule,
validating the known good state of the system
and picking up changes when necessary.
This is usually
accomplished as a
service (or daemon) or via a scheduled

task (or cron job). On Windows, I find the task scheduler

the better option, as you have more
flexibility in
determining the
conditions you can run the task in, it

easily supports alternate credentials, can be run on demand

as well, and isn't treated as a
service
logon.

There is an use

case for invoking
chef-client over winrm (or ssh) via some
orchestration engine rather than running
on a schedule, but
that means
you'll have to deal with the limitations of
WinRM. There are just too many
"gotchas" in
running in the
WinRM context. Many Win32 APIs can't be
called from a non-interactive logon (which
WinRM is treated
as) and you have the
credential delegation
problem.
As for
setting up
Chef to run as a service or scheduled task, the
chef-client cookbook (
https://supermarket.chef.io/cookbooks/chef-client
) can help
with that (though I
don't think it wires up "on

reboot").

Steven
MurawskiCommunity Software Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com

On 7/2/2015 2:44:09

PM, Tensibai
Zhaoying tensibai@iabis.net

wrote:In my opinion, running chef (or
any Configuration
management system)
on demand remotely is an anti-pattern.

If you're describing a

state, the
targeted machine should launch the check by
itself periodically and try to fix itself
as much as it
can.

It's harder to

compromise a network from a machine
who will overwrite your
exploits
changes every 30 minutes and enforce you to restart
your compromission from scratch over and
over again.

That's just my opinion too

Le 2 juil. 2015
21:29,
o haya a écrit :

BTW, I
should mention that I have a ticket
on
a slightly "larger" question and this came up
right in the middle of that ticket, so
I've conveyed
info on what I di to
the support person (Vikas). I also

was wondering out loud if maybe you guys might make

something like a credential proxy or maybe
add that
capability to the existing
Chef Windows service.

Understanding that
this is generically a Windows problem, it
still seems like
both the scheduled
task (if it worked for me) and the

service approaches are kind of "un-natural" (read:

kludgy) ways to do this, but
that's just my opinion.

---

On Thu, 7/2/15, o haya wrote:

Subject:
Re: [chef] Re: Getting
"Access
denied" when use mount in recipe and run
chef-client remotely via winrm
To:
chef@lists.opscode.com

Cc:
ohaya@yahoo.com
Date: Thursday, July
2, 2015, 3:24 PM

Hi,

Thanks
for
the info. I was just about to
post

that
I've had some success today, but doing something

different...
leveraging the Chef
Windows service.
What I
did was set
the user's credentials in place of
whatever
was in that service (in
my case the
Windows domain
Administrator) and then
let the service fire off my

recipe/cookbook. I have to so some tweaking of the design

of my
recipes to prevent them from

re-running more than

once, but I
was
surprised that it works after
that.

I had seen mention of using

task
scheduler/schtasks before, and I

would've tried

that for this

situation, but when I was looking into
how to

do processing across
reboots, but even
though I was able to

get the task
scheduling part done, the recipes appeared
to
run into the same type of
access denied
problems. I fought
with that for a

couple of days, and finally gave up on it.

In particular,
I was doing

a recipe
for deploying Exchange, and it required
installing
some prerequisites and
then a reboot and
then the actual
installation. So
back then, I would have the first part of

the recipe create a scheduled
task via
schtasks, for the 2nd
part, but when

the 2nd part, which was what actually ran the

setup.exe and psconfig.exe, ran, it
kept
throwing errors
indicating that

something wasn't accessible.

So, at this point, the service

approach is the only approach
that works
for me.

Thanks
again,
Jim

P.S. I

kind of

guessed that there wasn't something, but I

posted because the threads, etc I
found on
the credssp and
chef were a couple of
years old, and was hoping that

there'd be
something better by now :(...

---

On Thu, 7/2/15, Steven Murawski
wrote:

Subject: [chef] Re:
Getting "Access denied"
when use
mount in recipe
and run chef-client
remotely via winrm

To:

chef@lists.opscode.com

Cc: "o haya"
Date: Thursday, July 2, 2015, 3:02
PM

You are
hitting one of the

core challenges in dealing with
Windows
remote

management.

The ruby
WinRM gem, which we
use for
knife-windows,
doesn't
support
CredSSP credential
delegation (and there

are
security
concerns with that anyway).
A better

workaround would be to create a scheduled task

that will run

Chef Client and trigger that

from
winrm
(with schtasks
/run). This

gets around
the logon type and
credential

delegation issues running in WinRM
provide.

The cause of the
issue is that
when you

land in a remote shell hosted inside WinRM
(either WinRS

or

PowerShell Remoting), you're

connecting to a service and

that
service

does not have the right to
pass on your

credentials
to other services/computers. So when you

try
to
mount the
outside resource, it
attempts to

connect as the

computer's

Network Service account. The
path around

this is either
Kerberos delegation (which has

requirements

on the client side and
in
Active
Directory) or CredSSP,
which
the
WinRM

gem doesn't handle. Task scheduler

suffers no such problems (and is a

better way

to run Chef

Client - and
closer to how it
should run in a
production
context.
Steve

Steven

MurawskiCommunity Software Development
Engineer @

ChefMicrosoft MVP -
PowerShell
http://stevenmurawski.com

     On 7/1/2015 9:54:21 

PM, o haya

wrote:Hi,

I have been implementing
some

recipes/cookbooks for deploying and

configuring
Sharepoint

and Exchange
onto
our
Windows servers. These
servers would

be
domain mmembers.

I was originally
testing by
logging into
one
of the
Windows server and
then running

"chef-client

-o

myCookbook" and was finally able to

get them working

this past week.

Both
sets
of recipes expect the
respective

installation files to
be shared
out from the domain

controller and the recipes do a

"mount" to

"Z:"

drive,

and then the recipes do
"cd

z:"

and then execute the
appropriate .exe
inside a
powershell_script
resource.

As I

said, I got

these recipes working this

week, but in the real world, we would
want
to trigger the
cookbook/recipe
execution remotely using like

"knife

winrm", so I
started
testing
the recipes using
"knife

winrm"
this weekend, and, in both cases, I

ran into similar problems with both
sets of

recipes.

The first

problem was that

the
"mount" would fail with

"access denied",
so I've

since
tried (a) pre-creating the
mapped drive

outside of Chef
and also (b) physically

copying the entire
directories of

installation
software to the local C: drive

and running the
installations off of the local files.

Unfortunately, neither (a) nor (b)

approach

worked either. These

failures occur
at

different points of

the
installation, but
my impression
is that all the failures
are

coming down

to some kind of access denied or violation.

So,
I've
spent most of this weekend

testing

and researching, which lead me to find

some older

threads and information
on

things like credssp an
"2-hop"

that seem to
indicate that these problems

have been around for
awhile, so I was wondering if

there's
some mechanism or configuration

that should fix

he problem nowadays?

Also, I should mention
that I'm
tried
setting the WinRM CredSSP to
"true"

on both the

server side
and on my client
(Chef
workstation) side, but
that

hasn't

made any difference.

Can anyone

here
tell me how I can get these

cookbooks/recipes to work using

"knife winrm"?

Thanks,

Jim

[o_haya]

I went back and checked and luckily I still had the test recipes I had been using to test using schtasks to get through the reboot, so I tested again, and... it worked!!

I'll do more testing with that, and also start looking at using schtasks to do the remote running of chef-client.

But, does anyone happen to have the powershell code to calculate 'x' time in the future, for the schtasks for running chef-client after a reboot?

Thanks,
Jim

---

On Thu, 7/2/15, o haya ohaya@yahoo.com wrote:

Subject: Re: [chef] Re: Re: Re: Re: Re: Re: Getting "Access denied" when use mount in recipe and run chef-client remotely via winrm
To: chef@lists.opscode.com
Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 7:22 PM

Hi,

I might go back and try that (schtasks) again later.
I'd be happy if that worked, but if you recall from the
Stackoverflow thread that you posted on (scheduled tasks - Is there a way for a Chef recipe to continue after a reboot (Windows)? - Stack Overflow),
I did try that, but had problems with getting it to work,
and actually I never got it working, so ended up abandoning
using that for the Sharepoint installation because it turned
out I didn't need a mid-installation reboot. The
Exchange installation, on the other hand, does require a
mid-installation reboot, and because I wasn't able to make
the schtasks approach work earlier, I went with the Chef
service approach instead. It would be good if I could
get the schtasks approach working :(...

Later,
Jim

---

On Thu, 7/2/15, Tensibai Zhaoying tensibai@iabis.net
wrote:

Subject: [chef] Re: Re: Re: Re: Re: Re: Getting "Access
denied" when use mount in recipe and run chef-client
remotely via winrm
To: chef@lists.opscode.com
Date: Thursday, July 2, 2015, 5:35 PM

Firing a scheduled task
remotely is easy and get you rid of the whole credential
replay needed from winrm.

This method works since winnt4 (at least) and
has been used for decades to trigger db stop and then
server
Shutdown when there's a power outage and batteries
lifetime is running low (usually this was part of the
weekly
reboot task under nt4 :p)

This gives you the enforcement part on a
regular basis + the ability to trigger a run on an event
with a lot of way to trigger it (winrm may not be allowed
to
so this that's said, I'm unsure about the latest
limitations )

In brief,
this could be a way to solve your problem on both sides
(credentials of the process and on demand ability)

Le 2 juil. 2015 22:31, o haya ohaya@yahoo.com
a
écrit :

Steven
and Tensibai (et al),

Thanks for the interesting comments and
discussion.

With
that, I think that my perspective is probably a little
(maybe a lot) different, which probably explains the
differences in opinion.

In our case, we are not looking to
maintaining an environment or environments over time, but
rather, our desire is to be able to deploy specified
environments kind of "on demand", mostly one-time
events. That is why the winrm-type approach is/would be
most attractive (and as I said, "natural") to us.

Thanks again,
Jim

---

On Thu, 7/2/15, Steven Murawski steven.murawski@gmail.com
wrote:

Subject:
[chef] Re: Re: Re: Re: Getting "Access denied"
when use mount in recipe and run chef-client remotely via
winrm
To: chef@lists.opscode.com

Date: Thursday, July 2, 2015, 4:08 PM

So, I wasn't
referring to
running part of the
recipe as a scheduled task, but to

making the full chef-client run the scheduled

task.

Understanding that this is
generically a Windows
problem, it
still seems like both the scheduled task (if it
worked for me) and the service approaches
are kind of
"un-natural"
(read: kludgy) ways to do this, but

that's just my opinion.

The

general use case for Chef Client is to
run in the background
on a schedule,
validating the known good state of the system
and picking up changes when necessary.
This is usually
accomplished as a
service (or daemon) or via a scheduled

task (or cron job). On Windows, I find the task
scheduler

the better option, as you have more
flexibility in
determining the
conditions you can run the task in, it

easily supports alternate credentials, can be run on
demand

as well, and isn't treated as a
service
logon.

There is an use

case for invoking
chef-client over winrm (or ssh) via some
orchestration engine rather than running
on a schedule, but
that means
you'll have to deal with the limitations of
WinRM. There are just too many
"gotchas" in
running in the
WinRM context. Many Win32 APIs can't be
called from a non-interactive logon (which
WinRM is treated
as) and you have the
credential delegation
problem.
As for
setting up
Chef to run as a service or scheduled task, the
chef-client cookbook (
https://supermarket.chef.io/cookbooks/chef-client
) can help
with that (though I
don't think it wires up "on

reboot").

Steven
MurawskiCommunity Software Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com

On 7/2/2015 2:44:09

PM, Tensibai
Zhaoying tensibai@iabis.net

wrote:In my opinion, running chef (or
any Configuration
management system)
on demand remotely is an anti-pattern.

If you're describing a

state, the
targeted machine should launch the check by
itself periodically and try to fix itself
as much as it
can.

It's harder to

compromise a network from a machine
who will overwrite your
exploits
changes every 30 minutes and enforce you to restart
your compromission from scratch over and
over again.

That's just my opinion too

Le 2 juil. 2015
21:29,
o haya a écrit :

BTW, I
should mention that I have a ticket
on
a slightly "larger" question and this came up
right in the middle of that ticket, so
I've conveyed
info on what I di to
the support person (Vikas). I also

was wondering out loud if maybe you guys might make

something like a credential proxy or maybe
add that
capability to the existing
Chef Windows service.

Understanding that
this is generically a Windows problem, it
still seems like
both the scheduled
task (if it worked for me) and the

service approaches are kind of "un-natural" (read:

kludgy) ways to do this, but
that's just my opinion.

---

On Thu, 7/2/15, o haya wrote:

Subject:
Re: [chef] Re: Getting
"Access
denied" when use mount in recipe and run
chef-client remotely via winrm
To:
chef@lists.opscode.com

Cc:
ohaya@yahoo.com
Date: Thursday, July
2, 2015, 3:24 PM

Hi,

Thanks
for
the info. I was just about to
post

that
I've had some success today, but doing something

different...
leveraging the Chef
Windows service.
What I
did was set
the user's credentials in place of
whatever
was in that service (in
my case the
Windows domain
Administrator) and then
let the service fire off my

recipe/cookbook. I have to so some tweaking of the
design

of my
recipes to prevent them from

re-running more than

once, but I
was
surprised that it works after
that.

I had seen mention of using

task
scheduler/schtasks before, and I

would've tried

that for this

situation, but when I was looking into
how to

do processing across
reboots, but even
though I was able to

get the task
scheduling part done, the recipes appeared
to
run into the same type of
access denied
problems. I fought
with that for a

couple of days, and finally gave up on it.

In particular,
I was doing

a recipe
for deploying Exchange, and it required
installing
some prerequisites and
then a reboot and
then the actual
installation. So
back then, I would have the first part of

the recipe create a scheduled
task via
schtasks, for the 2nd
part, but when

the 2nd part, which was what actually ran the

setup.exe and psconfig.exe, ran, it
kept
throwing errors
indicating that

something wasn't accessible.

So, at this point, the service

approach is the only approach
that works
for me.

Thanks
again,
Jim

P.S. I

kind of

guessed that there wasn't something, but I

posted because the threads, etc I
found on
the credssp and
chef were a couple of
years old, and was hoping that

there'd be
something better by now :(...

---

On Thu, 7/2/15, Steven Murawski
wrote:

Subject: [chef] Re:
Getting "Access denied"
when use
mount in recipe
and run chef-client
remotely via winrm

To:

chef@lists.opscode.com

Cc: "o haya"
Date: Thursday, July 2, 2015, 3:02
PM

You are
hitting one of the

core challenges in dealing with
Windows
remote

management.

The ruby
WinRM gem, which we
use for
knife-windows,
doesn't
support
CredSSP credential
delegation (and there

are
security
concerns with that anyway).
A better

workaround would be to create a scheduled task 

that will run

Chef Client and trigger that

from
winrm
(with schtasks
/run). This

gets around
the logon type and
credential

delegation issues running in WinRM
provide.

The cause of the
issue is that
when you

land in a remote shell hosted inside WinRM
(either WinRS

or

PowerShell Remoting), you're

connecting to a service and

that
service

does not have the right to
pass on your

credentials
to other services/computers. So when you

try
to
mount the
outside resource, it
attempts to

connect as the

computer's

Network Service account. The
path around

this is either
Kerberos delegation (which has

requirements

on the client side and
in
Active
Directory) or CredSSP,
which
the
WinRM

gem doesn't handle. Task scheduler

suffers no such problems (and is a

better way

to run Chef

Client - and
closer to how it
should run in a
production
context.
Steve

Steven

MurawskiCommunity Software Development
Engineer @

ChefMicrosoft MVP -
PowerShell
http://stevenmurawski.com

      On 7/1/2015 9:54:21 

PM, o haya

wrote:Hi,

I have been implementing
some

recipes/cookbooks for deploying and

configuring
Sharepoint

and Exchange
onto
our
Windows servers. These
servers would

be
domain mmembers.

I was originally
testing by
logging into
one
of the
Windows server and
then running

"chef-client

-o

myCookbook" and was finally able to

get them working

this past week.

Both
sets
of recipes expect the
respective

installation files to
be shared
out from the domain

controller and the recipes do a

"mount" to

"Z:"

drive,

and then the recipes do
"cd

z:"

and then execute the
appropriate .exe
inside a
powershell_script
resource.

As I

said, I got

these recipes working this

week, but in the real world, we would
want
to trigger the
cookbook/recipe
execution remotely using like

"knife

winrm", so I
started
testing
the recipes using
"knife

winrm"
this weekend, and, in both cases, I

ran into similar problems with both
sets of

recipes.

The first

problem was that

the
"mount" would fail with

"access denied",
so I've

since
tried (a) pre-creating the
mapped drive

outside of Chef
and also (b) physically

copying the entire
directories of

installation
software to the local C: drive

and running the
installations off of the local files.

Unfortunately, neither (a) nor (b)

approach

worked either. These

failures occur
at

different points of

the
installation, but
my impression
is that all the failures
are

coming down

to some kind of access denied or violation.

So,
I've
spent most of this weekend

testing

and researching, which lead me to find

some older

threads and information
on

things like credssp an
"2-hop"

that seem to
indicate that these problems

have been around for
awhile, so I was wondering if

there's
some mechanism or configuration

that should fix

he problem nowadays?

Also, I should mention
that I'm
tried
setting the WinRM CredSSP to
"true"

on both the

server side
and on my client
(Chef
workstation) side, but
that

hasn't

made any difference.

Can anyone

here
tell me how I can get these

cookbooks/recipes to work using

"knife winrm"?

Thanks,

Jim

[o_haya]

Hi,

BTW, this is the schtasks that I had in my recipe that finally worked (I hard-coded the date/time in this test):

schtasks /create /tn Task_Name /tr "chef-client -o install-SHAREPOINT2007FULL-PART2" /sc once /RU "env2\Administrator" /RP "xxxxxxx" /RL HIGHEST /SD 07/02/2015 /ST 21:20

Jim

---

On Thu, 7/2/15, o haya ohaya@yahoo.com wrote:

Subject: Re: [chef] Re: Re: Re: Re: Re: Re: Getting "Access denied" when use mount in recipe and run chef-client remotely via winrm
To: chef@lists.opscode.com
Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 10:27 PM

I went back and checked and luckily I
still had the test recipes I had been using to test using
schtasks to get through the reboot, so I tested again,
and... it worked!!

I'll do more testing with that, and also start looking at
using schtasks to do the remote running of chef-client.

But, does anyone happen to have the powershell code to
calculate 'x' time in the future, for the schtasks for
running chef-client after a reboot?

Thanks,
Jim

---

On Thu, 7/2/15, o haya ohaya@yahoo.com
wrote:

Subject: Re: [chef] Re: Re: Re: Re: Re: Re: Getting "Access
denied" when use mount in recipe and run chef-client
remotely via winrm
To: chef@lists.opscode.com
Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 7:22 PM

Hi,

I might go back and try that (schtasks) again later.
I'd be happy if that worked, but if you recall from the
Stackoverflow thread that you posted on (scheduled tasks - Is there a way for a Chef recipe to continue after a reboot (Windows)? - Stack Overflow),
I did try that, but had problems with getting it to work,
and actually I never got it working, so ended up
abandoning
using that for the Sharepoint installation because it
turned
out I didn't need a mid-installation reboot. The
Exchange installation, on the other hand, does require a
mid-installation reboot, and because I wasn't able to make
the schtasks approach work earlier, I went with the Chef
service approach instead. It would be good if I could
get the schtasks approach working :(...

Later,
Jim

---

On Thu, 7/2/15, Tensibai Zhaoying tensibai@iabis.net
wrote:

Subject: [chef] Re: Re: Re: Re: Re: Re: Getting
"Access
denied" when use mount in recipe and run chef-client
remotely via winrm
To: chef@lists.opscode.com
Date: Thursday, July 2, 2015, 5:35 PM

Firing a scheduled task
remotely is easy and get you rid of the whole
credential
replay needed from winrm.

This method works since winnt4 (at least) and
has been used for decades to trigger db stop and
then
server
Shutdown when there's a power outage and batteries
lifetime is running low (usually this was part of
the
weekly
reboot task under nt4 :p)

This gives you the enforcement part on a
regular basis + the ability to trigger a run on an
event
with a lot of way to trigger it (winrm may not be
allowed
to
so this that's said, I'm unsure about the latest
limitations )

In brief,
this could be a way to solve your problem on both
sides
(credentials of the process and on demand ability)

Le 2 juil. 2015 22:31, o haya ohaya@yahoo.com
a
écrit :

Steven
and Tensibai (et al),

Thanks for the interesting comments and
discussion.

With
that, I think that my perspective is probably a
little
(maybe a lot) different, which probably explains the
differences in opinion.

In our case, we are not looking to
maintaining an environment or environments over time,
but
rather, our desire is to be able to deploy specified
environments kind of "on demand", mostly one-time
events. That is why the winrm-type approach
is/would be
most attractive (and as I said, "natural") to us.

Thanks again,
Jim

---

On Thu, 7/2/15, Steven Murawski steven.murawski@gmail.com
wrote:

Subject:
[chef] Re: Re: Re: Re: Getting "Access denied"
when use mount in recipe and run chef-client remotely
via
winrm
To: chef@lists.opscode.com

Date: Thursday, July 2, 2015, 4:08 PM

So, I wasn't
referring to
running part of the
recipe as a scheduled task, but to

making the full chef-client run the scheduled

task.

Understanding that this is
generically a Windows
problem, it
still seems like both the scheduled task (if it
worked for me) and the service approaches
are kind of
"un-natural"
(read: kludgy) ways to do this, but

that's just my opinion.

The

general use case for Chef Client is to
run in the background
on a schedule,
validating the known good state of the system
and picking up changes when necessary.
This is usually
accomplished as a
service (or daemon) or via a scheduled

task (or cron job). On Windows, I find the task
scheduler

the better option, as you have more
flexibility in
determining the
conditions you can run the task in, it

easily supports alternate credentials, can be run on
demand

as well, and isn't treated as a
service
logon.

There is an use

case for invoking
chef-client over winrm (or ssh) via some
orchestration engine rather than running
on a schedule, but
that means
you'll have to deal with the limitations of
WinRM. There are just too many
"gotchas" in
running in the
WinRM context. Many Win32 APIs can't be
called from a non-interactive logon (which
WinRM is treated
as) and you have the
credential delegation
problem.
As for
setting up
Chef to run as a service or scheduled task, the
chef-client cookbook (
https://supermarket.chef.io/cookbooks/chef-client
) can help
with that (though I
don't think it wires up "on

reboot").

Steven
MurawskiCommunity Software Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com

On 7/2/2015 2:44:09

PM, Tensibai
Zhaoying tensibai@iabis.net

wrote:In my opinion, running chef (or
any Configuration
management system)
on demand remotely is an anti-pattern.

If you're describing a

state, the
targeted machine should launch the check by
itself periodically and try to fix itself
as much as it
can.

It's harder to

compromise a network from a machine
who will overwrite your
exploits
changes every 30 minutes and enforce you to restart
your compromission from scratch over and
over again.

That's just my opinion too

Le 2 juil. 2015
21:29,
o haya a écrit :

BTW, I
should mention that I have a ticket
on
a slightly "larger" question and this came up
right in the middle of that ticket, so
I've conveyed
info on what I di to
the support person (Vikas). I also

was wondering out loud if maybe you guys might make

something like a credential proxy or maybe
add that
capability to the existing
Chef Windows service.

Understanding that
this is generically a Windows problem, it
still seems like
both the scheduled
task (if it worked for me) and the

service approaches are kind of "un-natural" (read:

kludgy) ways to do this, but
that's just my opinion.

---

On Thu, 7/2/15, o haya wrote:

Subject:
Re: [chef] Re: Getting
"Access
denied" when use mount in recipe and run
chef-client remotely via winrm
To:
chef@lists.opscode.com

Cc:
ohaya@yahoo.com
Date: Thursday, July
2, 2015, 3:24 PM

Hi,

Thanks
for
the info. I was just about to
post

that
I've had some success today, but doing something

different...
leveraging the Chef
Windows service.
What I
did was set
the user's credentials in place of
whatever
was in that service (in
my case the
Windows domain
Administrator) and then
let the service fire off my

recipe/cookbook. I have to so some tweaking of the
design

of my
recipes to prevent them from

re-running more than

once, but I
was
surprised that it works after
that.

I had seen mention of using

task
scheduler/schtasks before, and I

would've tried

that for this

situation, but when I was looking into
how to

do processing across
reboots, but even
though I was able to

get the task
scheduling part done, the recipes appeared
to
run into the same type of
access denied
problems. I fought
with that for a

couple of days, and finally gave up on it.

In particular,
I was doing

a recipe
for deploying Exchange, and it required
installing
some prerequisites and
then a reboot and
then the actual
installation. So
back then, I would have the first part of

the recipe create a scheduled
task via
schtasks, for the 2nd
part, but when

the 2nd part, which was what actually ran the

setup.exe and psconfig.exe, ran, it
kept
throwing errors
indicating that

something wasn't accessible.

So, at this point, the service

approach is the only approach
that works
for me.

Thanks
again,
Jim

P.S. I

kind of

guessed that there wasn't something, but I

posted because the threads, etc I
found on
the credssp and
chef were a couple of
years old, and was hoping that

there'd be
something better by now :(...

---

On Thu, 7/2/15, Steven Murawski
wrote:

Subject: [chef] Re:
Getting "Access denied"
when use
mount in recipe
and run chef-client
remotely via winrm

To:

chef@lists.opscode.com

Cc: "o haya"
Date: Thursday, July 2, 2015, 3:02
PM

You are
hitting one of the

core challenges in dealing with
Windows
remote

management.

The ruby
WinRM gem, which we
use for
knife-windows,
doesn't
support
CredSSP credential
delegation (and there

are
security
concerns with that anyway).
A better

 workaround would be to create a scheduled task 

that will run

Chef Client and trigger that

from
winrm
(with schtasks
/run). This

gets around
the logon type and
credential

delegation issues running in WinRM
provide.

The cause of the
issue is that
when you

land in a remote shell hosted inside WinRM
(either WinRS

or

PowerShell Remoting), you're

connecting to a service and

that
service

does not have the right to
pass on your

credentials
to other services/computers. So when you

try
to
mount the
outside resource, it
attempts to

connect as the

computer's

Network Service account. The
path around

this is either
Kerberos delegation (which has

requirements

on the client side and
in
Active
Directory) or CredSSP,
which
the
WinRM

gem doesn't handle. Task scheduler

suffers no such problems (and is a

better way

to run Chef

Client - and
closer to how it
should run in a
production
context.
Steve

Steven

MurawskiCommunity Software Development
Engineer @

ChefMicrosoft MVP -
PowerShell
http://stevenmurawski.com

       On 7/1/2015 9:54:21 

PM, o haya

wrote:Hi,

I have been implementing
some

recipes/cookbooks for deploying and

configuring
Sharepoint

and Exchange
onto
our
Windows servers. These
servers would

be
domain mmembers.

I was originally
testing by
logging into
one
of the
Windows server and
then running

"chef-client

-o

myCookbook" and was finally able to

get them working

this past week.

Both
sets
of recipes expect the
respective

installation files to
be shared
out from the domain

controller and the recipes do a

"mount" to

"Z:"

drive,

and then the recipes do
"cd

z:"

and then execute the
appropriate .exe
inside a
powershell_script
resource.

As I

said, I got

these recipes working this

week, but in the real world, we would
want
to trigger the
cookbook/recipe
execution remotely using like

"knife

winrm", so I
started
testing
the recipes using
"knife

winrm"
this weekend, and, in both cases, I

ran into similar problems with both
sets of

recipes.

The first

problem was that

the
"mount" would fail with

"access denied",
so I've

since
tried (a) pre-creating the
mapped drive

outside of Chef
and also (b) physically

copying the entire
directories of

installation
software to the local C: drive

and running the
installations off of the local files.

Unfortunately, neither (a) nor (b)

approach

worked either. These

failures occur
at

different points of

the
installation, but
my impression
is that all the failures
are

coming down

to some kind of access denied or violation.

So,
I've
spent most of this weekend

testing

and researching, which lead me to find

some older

threads and information
on

things like credssp an
"2-hop"

that seem to
indicate that these problems

have been around for
awhile, so I was wondering if

there's
some mechanism or configuration

that should fix

he problem nowadays?

Also, I should mention
that I'm
tried
setting the WinRM CredSSP to
"true"

on both the

server side
and on my client
(Chef
workstation) side, but
that

hasn't

made any difference.

Can anyone

here
tell me how I can get these

cookbooks/recipes to work using

"knife winrm"?

Thanks,

Jim

[Tensibai]

You may create the task with no schedule and add a registry entry in a run_once to trigger the task.

See windows - How do I stop/start a scheduled task on a remote computer programmatically? - Stack Overflow for exemple, locally you can omit the machine Switch or use a dot to target the local machine.

Le 3 juil. 2015 04:38, o haya ohaya@yahoo.com a écrit :

Hi,

BTW, this is the schtasks that I had in my recipe that finally worked (I hard-coded the date/time in this test):

schtasks /create /tn Task_Name /tr "chef-client -o install-SHAREPOINT2007FULL-PART2" /sc once /RU "env2\Administrator" /RP "xxxxxxx" /RL HIGHEST /SD 07/02/2015 /ST 21:20

Jim

---

On Thu, 7/2/15, o haya ohaya@yahoo.com wrote:

Subject: Re: [chef] Re: Re: Re: Re: Re: Re: Getting "Access denied" when use mount in recipe and run chef-client remotely via winrm
To: chef@lists.opscode.com
Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 10:27 PM

I went back and checked and luckily I
still had the test recipes I had been using to test using
schtasks to get through the reboot, so I tested again,
and... it worked!!

I'll do more testing with that, and also start looking at
using schtasks to do the remote running of chef-client.

But, does anyone happen to have the powershell code to
calculate 'x' time in the future, for the schtasks for
running chef-client after a reboot?

Thanks,
Jim

---

On Thu, 7/2/15, o haya ohaya@yahoo.com
wrote:

Subject: Re: [chef] Re: Re: Re: Re: Re: Re: Getting "Access
denied" when use mount in recipe and run chef-client
remotely via winrm
To: chef@lists.opscode.com
Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 7:22 PM

Hi,

I might go back and try that (schtasks) again later.
I'd be happy if that worked, but if you recall from the
Stackoverflow thread that you posted on (scheduled tasks - Is there a way for a Chef recipe to continue after a reboot (Windows)? - Stack Overflow),
I did try that, but had problems with getting it to work,
and actually I never got it working, so ended up
abandoning
using that for the Sharepoint installation because it
turned
out I didn't need a mid-installation reboot. The
Exchange installation, on the other hand, does require a
mid-installation reboot, and because I wasn't able to make
the schtasks approach work earlier, I went with the Chef
service approach instead. It would be good if I could
get the schtasks approach working :(...

Later,
Jim

---

On Thu, 7/2/15, Tensibai Zhaoying tensibai@iabis.net
wrote:

Subject: [chef] Re: Re: Re: Re: Re: Re: Getting
"Access
denied" when use mount in recipe and run chef-client
remotely via winrm
To: chef@lists.opscode.com
Date: Thursday, July 2, 2015, 5:35 PM

Firing a scheduled task
remotely is easy and get you rid of the whole
credential
replay needed from winrm.

This method works since winnt4 (at least) and
has been used for decades to trigger db stop and
then
server
Shutdown when there's a power outage and batteries
lifetime is running low (usually this was part of
the
weekly
reboot task under nt4 :p)

This gives you the enforcement part on a
regular basis + the ability to trigger a run on an
event
with a lot of way to trigger it (winrm may not be
allowed
to
so this that's said, I'm unsure about the latest
limitations )

In brief,
this could be a way to solve your problem on both
sides
(credentials of the process and on demand ability)

Le 2 juil. 2015 22:31, o haya ohaya@yahoo.com
a
écrit :

Steven
and Tensibai (et al),

Thanks for the interesting comments and
discussion.

With
that, I think that my perspective is probably a
little
(maybe a lot) different, which probably explains the
differences in opinion.

In our case, we are not looking to
maintaining an environment or environments over time,
but
rather, our desire is to be able to deploy specified
environments kind of "on demand", mostly one-time
events. That is why the winrm-type approach
is/would be
most attractive (and as I said, "natural") to us.

Thanks again,
Jim

---

On Thu, 7/2/15, Steven Murawski steven.murawski@gmail.com
wrote:

Subject:
[chef] Re: Re: Re: Re: Getting "Access denied"
when use mount in recipe and run chef-client remotely
via
winrm
To: chef@lists.opscode.com

Date: Thursday, July 2, 2015, 4:08 PM

So, I wasn't
referring to
running part of the
recipe as a scheduled task, but to

making the full chef-client run the scheduled

task.

Understanding that this is
generically a Windows
problem, it
still seems like both the scheduled task (if it
worked for me) and the service approaches
are kind of
"un-natural"
(read: kludgy) ways to do this, but

that's just my opinion.

The

general use case for Chef Client is to
run in the background
on a schedule,
validating the known good state of the system
and picking up changes when necessary.
This is usually
accomplished as a
service (or daemon) or via a scheduled

task (or cron job). On Windows, I find the task
scheduler

the better option, as you have more
flexibility in
determining the
conditions you can run the task in, it

easily supports alternate credentials, can be run on
demand

as well, and isn't treated as a
service
logon.

There is an use

case for invoking
chef-client over winrm (or ssh) via some
orchestration engine rather than running
on a schedule, but
that means
you'll have to deal with the limitations of
WinRM. There are just too many
"gotchas" in
running in the
WinRM context. Many Win32 APIs can't be
called from a non-interactive logon (which
WinRM is treated
as) and you have the
credential delegation
problem.
As for
setting up
Chef to run as a service or scheduled task, the
chef-client cookbook (
https://supermarket.chef.io/cookbooks/chef-client
) can help
with that (though I
don't think it wires up "on

reboot").

Steven
MurawskiCommunity Software Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com

On 7/2/2015 2:44:09

PM, Tensibai
Zhaoying tensibai@iabis.net

wrote:In my opinion, running chef (or
any Configuration
management system)
on demand remotely is an anti-pattern.

If you're describing a

state, the
targeted machine should launch the check by
itself periodically and try to fix itself
as much as it
can.

It's harder to

compromise a network from a machine
who will overwrite your
exploits
changes every 30 minutes and enforce you to restart
your compromission from scratch over and
over again.

That's just my opinion too

Le 2 juil. 2015
21:29,
o haya a écrit :

BTW, I
should mention that I have a ticket
on
a slightly "larger" question and this came up
right in the middle of that ticket, so
I've conveyed
info on what I di to
the support person (Vikas). I also

was wondering out loud if maybe you guys might make

something like a credential proxy or maybe
add that
capability to the existing
Chef Windows service.

Understanding that
this is generically a Windows problem, it
still seems like
both the scheduled
task (if it worked for me) and the

service approaches are kind of "un-natural" (read:

kludgy) ways to do this, but
that's just my opinion.

---

On Thu, 7/2/15, o haya wrote:

Subject:
Re: [chef] Re: Getting
"Access
denied" when use mount in recipe and run
chef-client remotely via winrm
To:
chef@lists.opscode.com

Cc:
ohaya@yahoo.com
Date: Thursday, July
2, 2015, 3:24 PM

Hi,

Thanks
for
the info. I was just about to
post

that
I've had some success today, but doing something

different...
leveraging the Chef
Windows service.
What I
did was set
the user's credentials in place of
whatever
was in that service (in
my case the
Windows domain
Administrator) and then
let the service fire off my

recipe/cookbook. I have to so some tweaking of the
design

of my
recipes to prevent them from

re-running more than

once, but I
was
surprised that it works after
that.

I had seen mention of using

task
scheduler/schtasks before, and I

would've tried

that for this

situation, but when I was looking into
how to

do processing across
reboots, but even
though I was able to

get the task
scheduling part done, the recipes appeared
to
run into the same type of
access denied
problems. I fought
with that for a

couple of days, and finally gave up on it.

In particular,
I was doing

a recipe
for deploying Exchange, and it required
installing
some prerequisites and
then a reboot and
then the actual
installation. So
back then, I would have the first part of

the recipe create a scheduled
task via
schtasks, for the 2nd
part, but when

the 2nd part, which was what actually ran the

setup.exe and psconfig.exe, ran, it
kept
throwing errors
indicating that

something wasn't accessible.

So, at this point, the service

approach is the only approach
that works
for me.

Thanks
again,
Jim

P.S. I

kind of

guessed that there wasn't something, but I

posted because the threads, etc I
found on
the credssp and
chef were a couple of
years old, and was hoping that

there'd be
something better by now :(...

---

On Thu, 7/2/15, Steven Murawski
wrote:

Subject: [chef] Re:
Getting "Access denied"
when use
mount in recipe
and run chef-client
remotely via winrm

To:

chef@lists.opscode.com

Cc: "o haya"
Date: Thursday, July 2, 2015, 3:02
PM

You are
hitting one of the

core challenges in dealing with
Windows
remote

management.

The ruby
WinRM gem, which we
use for
knife-windows,
doesn't
support
CredSSP credential
delegation (and there

are
security
concerns with that anyway).
A better

workaround would be to create a scheduled task 

that will run

Chef Client and trigger that

from
winrm
(with schtasks
/run). This

gets around
the logon type and
credential

delegation issues running in WinRM
provide.

The cause of the
issue is that
when you

land in a remote shell hosted inside WinRM
(either WinRS

or

PowerShell Remoting), you're

connecting to a service and

that
service

does not have the right to
pass on your

credentials
to other services/computers. So when you

try
to
mount the
outside resource, it
attempts to

connect as the

computer's

Network Service account. The
path around

this is either
Kerberos delegation (which has

requirements

on the client side and
in
Active
Directory) or CredSSP,
which
the
WinRM

gem doesn't handle. Task scheduler

suffers no such problems (and is a

better way

to run Chef

Client - and
closer to how it
should run in a
production
context.
Steve

Steven

MurawskiCommunity Software Development
Engineer @

ChefMicrosoft MVP -
PowerShell
http://stevenmurawski.com

      On 7/1/2015 9:54:21 

PM, o haya

wrote:Hi,

I have been implementing
some

recipes/cookbooks for deploying and

configuring
Sharepoint

and Exchange
onto
our
Windows servers. These
servers would

be
domain mmembers.

I was originally
testing by
logging into
one
of the
Windows server and
then running

"chef-client

-o

myCookbook" and was finally able to

get them working

this past week.

Both
sets
of recipes expect the
respective

installation files to
be shared
out from the domain

controller and the recipes do a

"mount" to

"Z:"

drive,

and then the recipes do
"cd

z:"

and then execute the
appropriate .exe
inside a
powershell_script
resource.

As I

said, I got

these recipes working this

week, but in the real world, we would
want
to trigger the
cookbook/recipe
execution remotely using like

"knife

winrm", so I
started
testing
the recipes using
"knife

winrm"
this weekend, and, in both cases, I

ran into similar problems with both
sets of

recipes.

The first

problem was that

the
"mount" would fail with

"access denied",
so I've

since
tried (a) pre-creating the
mapped drive

outside of Chef
and also (b) physically

copying the entire
directories of

installation
software to the local C: drive

and running the
installations off of the local files.

Unfortunately, neither (a) nor (b)

approach

worked either. These

failures occur
at

different points of

the
installation, but
my impression
is that all the failures
are

coming down

to some kind of access denied or violation.

So,
I've
spent most of this weekend

testing

and researching, which lead me to find

some older

threads and information
on

things like credssp an
"2-hop"

that seem to
indicate that these problems

have been around for
awhile, so I was wondering if

there's
some mechanism or configuration

that should fix

he problem nowadays?

Also, I should mention
that I'm
tried
setting the WinRM CredSSP to
"true"

on both the

server side
and on my client
(Chef
workstation) side, but
that

hasn't

made any difference.

Can anyone

here
tell me how I can get these

cookbooks/recipes to work using

"knife winrm"?

Thanks,

Jim

[o_haya]

Hi,

I'd really like to be able to have my recipe calculate a date/time in the future, then create a task via schtasks, because I think I can use this type of approach for several different situations, but I'm kind of stuck figuring out how to parameterize the schtasks creation.

I think that I've figured out the code to calculate the future date and time, and even put the date and time into some vars formatted the way that schtasks wants them, but I am kind of baffled about how to actually use those two vars ($mydate and $mytime) in the schtasks command.

Here's what I have:

$future_time = $(Get-Date).AddMinutes(15)

echo "Future time is: " $future_time >> c:/install-SHAREPOINT2007FULL.log

$mydate = $future_time.ToString("MM/dd/yyyy")
$mytime = $future_time.ToString("HH:MM")

schtasks /create /tn Task_Name /tr "chef-client -o install-SHAREPOINT2007FULL-PART2" /sc once /RU "env2\Administrator" /RP "xxxxx" /RL HIGHEST /SD $mydate /ST $mytime

I think the problem is that the two vars are not being expanded or something like that, but I can't figure out what the correct syntax is for doing that. I've tried double-quoting the vars (e.g., "$mydate") and putting them inside parens (e.g., $($mydate), and other variants, but keep getting an error saying that the date is less than current or something like that.

I know that this is getting a little off-topic, but if anyone knows how to set that schtasks with the two vars, can you please post?

Thanks!

Jim

---

On Fri, 7/3/15, Tensibai Zhaoying tensibai@iabis.net wrote:

Subject: [chef] Re: Re: Re: Re: Re: Re: Re: Re: Getting "Access denied" when use mount in recipe and run chef-client remotely via winrm
To: chef@lists.opscode.com
Date: Friday, July 3, 2015, 1:37 AM

You may create the task with no
schedule and add a registry entry in a run_once to trigger
the task.

See windows - How do I stop/start a scheduled task on a remote computer programmatically? - Stack Overflow
for exemple, locally you can omit the machine
Switch or use a dot to target the local machine.

Le 3 juil. 2015 04:38, o haya ohaya@yahoo.com a
écrit :

Hi,

BTW, this is the schtasks that I had in my recipe that
finally worked (I hard-coded the date/time in this test):

schtasks /create /tn Task_Name /tr "chef-client -o
install-SHAREPOINT2007FULL-PART2" /sc once /RU
"env2\Administrator" /RP "xxxxxxx" /RL HIGHEST /SD
07/02/2015 /ST 21:20

Jim

---

On Thu, 7/2/15, o haya ohaya@yahoo.com
wrote:

Subject: Re: [chef] Re: Re: Re: Re: Re: Re: Getting
"Access denied" when use mount in recipe and run chef-client
remotely via winrm
To: chef@lists.opscode.com

Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 10:27 PM

I went back and checked and luckily I
still had the test recipes I had been using to test
using
schtasks to get through the reboot, so I tested again,

and... it worked!!

I'll do more testing with that, and also start looking
at
using schtasks to do the remote running of chef-client.

But, does anyone happen to have the powershell code to

calculate 'x' time in the future, for the schtasks for

running chef-client after a reboot?

Thanks,
Jim

---

On Thu, 7/2/15, o haya ohaya@yahoo.com
wrote:

Subject: Re: [chef] Re: Re: Re: Re: Re: Re: Getting
"Access
denied" when use mount in recipe and run chef-client
remotely via winrm
To: chef@lists.opscode.com

Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 7:22 PM

Hi,

I might go back and try that (schtasks) again
later.
I'd be happy if that worked, but if you recall from
the
Stackoverflow thread that you posted on (scheduled tasks - Is there a way for a Chef recipe to continue after a reboot (Windows)? - Stack Overflow),

I did try that, but had problems with getting it to
work,
and actually I never got it working, so ended up
abandoning
using that for the Sharepoint installation because
it
turned
out I didn't need a mid-installation reboot. The
Exchange installation, on the other hand, does
require a
mid-installation reboot, and because I wasn't able
to make
the schtasks approach work earlier, I went with the
Chef
service approach instead. It would be good if I
could
get the schtasks approach working :(...

Later,
Jim

---

On Thu, 7/2/15, Tensibai Zhaoying tensibai@iabis.net

wrote:

Subject: [chef] Re: Re: Re: Re: Re: Re: Getting
"Access
denied" when use mount in recipe and run chef-client

remotely via winrm
To: chef@lists.opscode.com

Date: Thursday, July 2, 2015, 5:35 PM

Firing a scheduled task
remotely is easy and get you rid of the whole
credential
replay needed from winrm.

This method works since winnt4 (at least) and
has been used for decades to trigger db stop and
then
server
Shutdown when there's a power outage and batteries
lifetime is running low (usually this was part of
the
weekly
reboot task under nt4 :p)

This gives you the enforcement part on a
regular basis + the ability to trigger a run on an
event
with a lot of way to trigger it (winrm may not be
allowed
to
so this that's said, I'm unsure about the latest
limitations )

In brief,
this could be a way to solve your problem on both
sides
(credentials of the process and on demand ability)

Le 2 juil. 2015 22:31, o haya ohaya@yahoo.com
a
écrit :

Steven
and Tensibai (et al),

Thanks for the interesting comments and
discussion.

With
that, I think that my perspective is probably a
little
(maybe a lot) different, which probably explains the

differences in opinion.

In our case, we are not looking to
maintaining an environment or environments over
time,
but
rather, our desire is to be able to deploy specified

environments kind of "on demand", mostly one-time
events. That is why the winrm-type approach
is/would be
most attractive (and as I said, "natural") to us.

Thanks again,
Jim

---

On Thu, 7/2/15, Steven Murawski steven.murawski@gmail.com

wrote:

Subject:
[chef] Re: Re: Re: Re: Getting "Access denied"
when use mount in recipe and run chef-client
remotely
via
winrm
To: chef@lists.opscode.com

Date: Thursday, July 2, 2015, 4:08 PM

So, I wasn't
referring to
running part of the
recipe as a scheduled task, but to

making the full chef-client run the scheduled

task.

Understanding that this is
generically a Windows
problem, it
still seems like both the scheduled task (if it
worked for me) and the service approaches
are kind of
"un-natural"
(read: kludgy) ways to do this, but

that's just my opinion.

The

general use case for Chef Client is to
run in the background
on a schedule,
validating the known good state of the system
and picking up changes when necessary.
This is usually
accomplished as a
service (or daemon) or via a scheduled

task (or cron job). On Windows, I find the task
scheduler

the better option, as you have more
flexibility in
determining the
conditions you can run the task in, it

easily supports alternate credentials, can be run on

demand

as well, and isn't treated as a
service
logon.

There is an use

case for invoking
chef-client over winrm (or ssh) via some
orchestration engine rather than running
on a schedule, but
that means
you'll have to deal with the limitations of
WinRM. There are just too many
"gotchas" in
running in the
WinRM context. Many Win32 APIs can't be
called from a non-interactive logon (which
WinRM is treated
as) and you have the
credential delegation
problem.
As for
setting up
Chef to run as a service or scheduled task, the
chef-client cookbook (
https://supermarket.chef.io/cookbooks/chef-client
) can help
with that (though I
don't think it wires up "on

reboot").

Steven
MurawskiCommunity Software Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com

On 7/2/2015 2:44:09

PM, Tensibai
Zhaoying tensibai@iabis.net

wrote:In my opinion, running chef (or
any Configuration
management system)
on demand remotely is an anti-pattern.

If you're describing a

state, the
targeted machine should launch the check by
itself periodically and try to fix itself
as much as it
can.

It's harder to

compromise a network from a machine
who will overwrite your
exploits
changes every 30 minutes and enforce you to restart

your compromission from scratch over and
over again.

That's just my opinion too

Le 2 juil. 2015
21:29,
o haya a écrit :

BTW, I
should mention that I have a ticket
on
a slightly "larger" question and this came up
right in the middle of that ticket, so
I've conveyed
info on what I di to
the support person (Vikas). I also

was wondering out loud if maybe you guys might make

something like a credential proxy or maybe
add that
capability to the existing
Chef Windows service.

Understanding that
this is generically a Windows problem, it
still seems like
both the scheduled
task (if it worked for me) and the

service approaches are kind of "un-natural" (read:

kludgy) ways to do this, but
that's just my opinion.

---

On Thu, 7/2/15, o haya wrote:

Subject:
Re: [chef] Re: Getting
"Access
denied" when use mount in recipe and run
chef-client remotely via winrm
To:
chef@lists.opscode.com

Cc:
ohaya@yahoo.com
Date: Thursday, July
2, 2015, 3:24 PM

Hi,

Thanks
for
the info. I was just about to
post

that
I've had some success today, but doing something

different...
leveraging the Chef
Windows service.
What I
did was set
the user's credentials in place of
whatever
was in that service (in
my case the
Windows domain
Administrator) and then
let the service fire off my

recipe/cookbook. I have to so some tweaking of the

design

of my
recipes to prevent them from

re-running more than

once, but I
was
surprised that it works after
that.

I had seen mention of using

task
scheduler/schtasks before, and I

would've tried

that for this

situation, but when I was looking into
how to

do processing across
reboots, but even
though I was able to

get the task
scheduling part done, the recipes appeared
to
run into the same type of
access denied
problems. I fought
with that for a

couple of days, and finally gave up on it.

In particular,
I was doing

a recipe
for deploying Exchange, and it required
installing
some prerequisites and
then a reboot and
then the actual
installation. So
back then, I would have the first part of

the recipe create a scheduled
task via
schtasks, for the 2nd
part, but when

the 2nd part, which was what actually ran the

setup.exe and psconfig.exe, ran, it
kept
throwing errors
indicating that

something wasn't accessible.

So, at this point, the service

approach is the only approach
that works
for me.

Thanks
again,
Jim

P.S. I

kind of

guessed that there wasn't something, but I

posted because the threads, etc I
found on
the credssp and
chef were a couple of
years old, and was hoping that

there'd be
something better by now :(...

---

On Thu, 7/2/15, Steven Murawski
wrote:

Subject: [chef] Re:
Getting "Access denied"
when use
mount in recipe
and run chef-client
remotely via winrm

To:

chef@lists.opscode.com

Cc: "o haya"
Date: Thursday, July 2, 2015, 3:02
PM

You are
hitting one of the

core challenges in dealing with
Windows
remote

management.

The ruby
WinRM gem, which we
use for
knife-windows,
doesn't
support
CredSSP credential
delegation (and there

are
security
concerns with that anyway).
A better

workaround would be to create a scheduled task 

that will run

Chef Client and trigger that

from
winrm
(with schtasks
/run). This

gets around
the logon type and
credential

delegation issues running in WinRM
provide.

The cause of the
issue is that
when you

land in a remote shell hosted inside WinRM
(either WinRS

or

PowerShell Remoting), you're

connecting to a service and

that
service

does not have the right to
pass on your

credentials
to other services/computers. So when you

try
to
mount the
outside resource, it
attempts to

connect as the

computer's

Network Service account. The
path around

this is either
Kerberos delegation (which has

requirements

on the client side and
in
Active
Directory) or CredSSP,
which
the
WinRM

gem doesn't handle. Task scheduler

suffers no such problems (and is a

better way

to run Chef

Client - and
closer to how it
should run in a
production
context.
Steve

Steven

MurawskiCommunity Software Development
Engineer @

ChefMicrosoft MVP -
PowerShell
http://stevenmurawski.com

      On 7/1/2015 9:54:21 

PM, o haya

wrote:Hi,

I have been implementing
some

recipes/cookbooks for deploying and

configuring
Sharepoint

and Exchange
onto
our
Windows servers. These
servers would

be
domain mmembers.

I was originally
testing by
logging into
one
of the
Windows server and
then running

"chef-client

-o

myCookbook" and was finally able to

get them working

this past week.

Both
sets
of recipes expect the
respective

installation files to
be shared
out from the domain

controller and the recipes do a

"mount" to

"Z:"

drive,

and then the recipes do
"cd

z:"

and then execute the
appropriate .exe
inside a
powershell_script
resource.

As I

said, I got

these recipes working this

week, but in the real world, we would
want
to trigger the
cookbook/recipe
execution remotely using like

"knife

winrm", so I
started
testing
the recipes using
"knife

winrm"
this weekend, and, in both cases, I

ran into similar problems with both
sets of

recipes.

The first

problem was that

the
"mount" would fail with

"access denied",
so I've

since
tried (a) pre-creating the
mapped drive

outside of Chef
and also (b) physically

copying the entire
directories of

installation
software to the local C: drive

and running the
installations off of the local files.

Unfortunately, neither (a) nor (b)

approach

worked either. These

failures occur
at

different points of

the
installation, but
my impression
is that all the failures
are

coming down

to some kind of access denied or violation.

So,
I've
spent most of this weekend

testing

and researching, which lead me to find

some older

threads and information
on

things like credssp an
"2-hop"

that seem to
indicate that these problems

have been around for
awhile, so I was wondering if

there's
some mechanism or configuration

that should fix

he problem nowadays?

Also, I should mention
that I'm
tried
setting the WinRM CredSSP to
"true"

on both the

server side
and on my client
(Chef
workstation) side, but
that

hasn't

made any difference.

Can anyone

here
tell me how I can get these

cookbooks/recipes to work using

"knife winrm"?

Thanks,

Jim

[o_haya]

Hi,

For the record, I wanted to let you all know that I was able to get schtasks working. What I ended up having to do was to build the entire schtasks command line as a string (the whole thing with quotes/double-quotes and interpolation drove me nuts though :)!), and then do "Invoke-expression" on the string variable.

FYI, I've also been able to run a test scenario where I was on one Windows machine and ran "schtasks" to create a scheduled task on one of my nodes to run "chef-client -o xxxx" where the xxxx cookbook/recipe itself created a scheduled task (to run the 2nd part of the install after the reboot) and, amazingly, that all worked!

So, I think that I'm good on this now. Thanks for all of the help!!

Jim

---

On Fri, 7/3/15, o haya ohaya@yahoo.com wrote:

Subject: Re: [chef] Re: Re: Re: Re: Re: Re: Re: Re: Getting "Access denied" when use mount in recipe and run chef-client remotely via winrm
To: chef@lists.opscode.com
Cc: ohaya@yahoo.com
Date: Friday, July 3, 2015, 2:37 AM

Hi,

I'd really like to be able to have my recipe calculate a
date/time in the future, then create a task via schtasks,
because I think I can use this type of approach for several
different situations, but I'm kind of stuck figuring out how
to parameterize the schtasks creation.

I think that I've figured out the code to calculate the
future date and time, and even put the date and time into
some vars formatted the way that schtasks wants them, but I
am kind of baffled about how to actually use those two vars
($mydate and $mytime) in the schtasks command.

Here's what I have:

$future_time = $(Get-Date).AddMinutes(15)

echo "Future time is: " $future_time >>
c:/install-SHAREPOINT2007FULL.log

$mydate = $future_time.ToString("MM/dd/yyyy")
$mytime = $future_time.ToString("HH:MM")

schtasks /create /tn Task_Name /tr "chef-client -o
install-SHAREPOINT2007FULL-PART2" /sc once /RU
"env2\Administrator" /RP "xxxxx" /RL HIGHEST /SD $mydate
/ST $mytime

I think the problem is that the two vars are not being
expanded or something like that, but I can't figure out what
the correct syntax is for doing that. I've tried
double-quoting the vars (e.g., "$mydate") and putting them
inside parens (e.g., $($mydate), and other variants, but
keep getting an error saying that the date is less than
current or something like that.

I know that this is getting a little off-topic, but if
anyone knows how to set that schtasks with the two vars, can
you please post?

Thanks!

Jim

---

On Fri, 7/3/15, Tensibai Zhaoying tensibai@iabis.net
wrote:

Subject: [chef] Re: Re: Re: Re: Re: Re: Re: Re: Getting
"Access denied" when use mount in recipe and run chef-client
remotely via winrm
To: chef@lists.opscode.com
Date: Friday, July 3, 2015, 1:37 AM

You may create the task with no
schedule and add a registry entry in a run_once to trigger
the task.

See windows - How do I stop/start a scheduled task on a remote computer programmatically? - Stack Overflow
for exemple, locally you can omit the machine
Switch or use a dot to target the local machine.

Le 3 juil. 2015 04:38, o haya ohaya@yahoo.com
a
écrit :

Hi,

BTW, this is the schtasks that I had in my recipe
that
finally worked (I hard-coded the date/time in this test):

schtasks /create /tn Task_Name /tr "chef-client -o
install-SHAREPOINT2007FULL-PART2" /sc once /RU
"env2\Administrator" /RP "xxxxxxx" /RL HIGHEST /SD
07/02/2015 /ST 21:20

Jim

---

On Thu, 7/2/15, o haya ohaya@yahoo.com
wrote:

Subject: Re: [chef] Re: Re: Re: Re: Re: Re: Getting
"Access denied" when use mount in recipe and run
chef-client
remotely via winrm
To: chef@lists.opscode.com

Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 10:27 PM

I went back and checked and luckily I
still had the test recipes I had been using to test
using
schtasks to get through the reboot, so I tested
again,

and... it worked!!

I'll do more testing with that, and also start
looking
at
using schtasks to do the remote running of
chef-client.

But, does anyone happen to have the powershell code
to

calculate 'x' time in the future, for the schtasks
for

running chef-client after a reboot?

Thanks,
Jim

---

On Thu, 7/2/15, o haya ohaya@yahoo.com
wrote:

Subject: Re: [chef] Re: Re: Re: Re: Re: Re:
Getting
"Access
denied" when use mount in recipe and run chef-client
remotely via winrm
To: chef@lists.opscode.com

Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 7:22 PM

Hi,

I might go back and try that (schtasks) again
later.
I'd be happy if that worked, but if you recall
from
the
Stackoverflow thread that you posted on (scheduled tasks - Is there a way for a Chef recipe to continue after a reboot (Windows)? - Stack Overflow),

I did try that, but had problems with getting it
to
work,
and actually I never got it working, so ended up
abandoning
using that for the Sharepoint installation because
it
turned
out I didn't need a mid-installation reboot. The

Exchange installation, on the other hand, does
require a
mid-installation reboot, and because I wasn't able
to make
the schtasks approach work earlier, I went with
the
Chef
service approach instead. It would be good if I
could
get the schtasks approach working :(...

Later,
Jim

---

On Thu, 7/2/15, Tensibai Zhaoying tensibai@iabis.net

wrote:

Subject: [chef] Re: Re: Re: Re: Re: Re: Getting
"Access
denied" when use mount in recipe and run
chef-client

remotely via winrm
To: chef@lists.opscode.com

Date: Thursday, July 2, 2015, 5:35 PM

Firing a scheduled task
remotely is easy and get you rid of the whole
credential
replay needed from winrm.

This method works since winnt4 (at least) and
has been used for decades to trigger db stop and
then
server
Shutdown when there's a power outage and batteries

lifetime is running low (usually this was part of
the
weekly
reboot task under nt4 :p)

This gives you the enforcement part on a
regular basis + the ability to trigger a run on an

event
with a lot of way to trigger it (winrm may not be
allowed
to
so this that's said, I'm unsure about the latest
limitations )

In brief,
this could be a way to solve your problem on both
sides
(credentials of the process and on demand ability)

Le 2 juil. 2015 22:31, o haya ohaya@yahoo.com
a
écrit :

Steven
and Tensibai (et al),

Thanks for the interesting comments and
discussion.

With
that, I think that my perspective is probably a
little
(maybe a lot) different, which probably explains
the

differences in opinion.

In our case, we are not looking to
maintaining an environment or environments over
time,
but
rather, our desire is to be able to deploy
specified

environments kind of "on demand", mostly one-time
events. That is why the winrm-type approach
is/would be
most attractive (and as I said, "natural") to us.

Thanks again,
Jim

---

On Thu, 7/2/15, Steven Murawski steven.murawski@gmail.com

wrote:

Subject:
[chef] Re: Re: Re: Re: Getting "Access denied"
when use mount in recipe and run chef-client
remotely
via
winrm
To: chef@lists.opscode.com

Date: Thursday, July 2, 2015, 4:08 PM

So, I wasn't
referring to
running part of the
recipe as a scheduled task, but to

making the full chef-client run the scheduled

task.

Understanding that this is
generically a Windows
problem, it
still seems like both the scheduled task (if it
worked for me) and the service approaches
are kind of
"un-natural"
(read: kludgy) ways to do this, but

that's just my opinion.

The

general use case for Chef Client is to
run in the background
on a schedule,
validating the known good state of the system
and picking up changes when necessary.
This is usually
accomplished as a
service (or daemon) or via a scheduled

task (or cron job). On Windows, I find the task
scheduler

the better option, as you have more
flexibility in
determining the
conditions you can run the task in, it

easily supports alternate credentials, can be run
on

demand

as well, and isn't treated as a
service
logon.

There is an use

case for invoking
chef-client over winrm (or ssh) via some
orchestration engine rather than running
on a schedule, but
that means
you'll have to deal with the limitations of
WinRM. There are just too many
"gotchas" in
running in the
WinRM context. Many Win32 APIs can't be
called from a non-interactive logon (which
WinRM is treated
as) and you have the
credential delegation
problem.
As for
setting up
Chef to run as a service or scheduled task, the
chef-client cookbook (
https://supermarket.chef.io/cookbooks/chef-client
) can help
with that (though I
don't think it wires up "on

reboot").

Steven
MurawskiCommunity Software Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com

On 7/2/2015 2:44:09

PM, Tensibai
Zhaoying tensibai@iabis.net

wrote:In my opinion, running chef (or
any Configuration
management system)
on demand remotely is an anti-pattern.

If you're describing a

state, the
targeted machine should launch the check by
itself periodically and try to fix itself
as much as it
can.

It's harder to

compromise a network from a machine
who will overwrite your
exploits
changes every 30 minutes and enforce you to
restart

your compromission from scratch over and
over again.

That's just my opinion too

Le 2 juil. 2015
21:29,
o haya a écrit :

BTW, I
should mention that I have a ticket
on
a slightly "larger" question and this came up
right in the middle of that ticket, so
I've conveyed
info on what I di to
the support person (Vikas). I also

was wondering out loud if maybe you guys might
make

something like a credential proxy or maybe
add that
capability to the existing
Chef Windows service.

Understanding that
this is generically a Windows problem, it
still seems like
both the scheduled
task (if it worked for me) and the

service approaches are kind of "un-natural" (read:

kludgy) ways to do this, but
that's just my opinion.

---

On Thu, 7/2/15, o haya wrote:

Subject:
Re: [chef] Re: Getting
"Access
denied" when use mount in recipe and run
chef-client remotely via winrm
To:
chef@lists.opscode.com

Cc:
ohaya@yahoo.com
Date: Thursday, July
2, 2015, 3:24 PM

Hi,

Thanks
for
the info. I was just about to
post

that
I've had some success today, but doing something

different...
leveraging the Chef
Windows service.
What I
did was set
the user's credentials in place of
whatever
was in that service (in
my case the
Windows domain
Administrator) and then
let the service fire off my

recipe/cookbook. I have to so some tweaking of
the

design

of my
recipes to prevent them from

re-running more than

once, but I
was
surprised that it works after
that.

I had seen mention of using

task
scheduler/schtasks before, and I

would've tried

that for this

situation, but when I was looking into
how to

do processing across
reboots, but even
though I was able to

get the task
scheduling part done, the recipes appeared
to
run into the same type of
access denied
problems. I fought
with that for a

couple of days, and finally gave up on it.

In particular,
I was doing

a recipe
for deploying Exchange, and it required
installing
some prerequisites and
then a reboot and
then the actual
installation. So
back then, I would have the first part of

the recipe create a scheduled
task via
schtasks, for the 2nd
part, but when

the 2nd part, which was what actually ran the

setup.exe and psconfig.exe, ran, it
kept
throwing errors
indicating that

something wasn't accessible.

So, at this point, the service

approach is the only approach
that works
for me.

Thanks
again,
Jim

P.S. I

kind of

guessed that there wasn't something, but I

posted because the threads, etc I
found on
the credssp and
chef were a couple of
years old, and was hoping that

there'd be
something better by now :(...

---

On Thu, 7/2/15, Steven Murawski
wrote:

Subject: [chef] Re:
Getting "Access denied"
when use
mount in recipe
and run chef-client
remotely via winrm

To:

chef@lists.opscode.com

Cc: "o haya"
Date: Thursday, July 2, 2015, 3:02
PM

You are
hitting one of the

core challenges in dealing with
Windows
remote

management.

The ruby
WinRM gem, which we
use for
knife-windows,
doesn't
support
CredSSP credential
delegation (and there

are
security
concerns with that anyway).
A better

workaround would be to create a scheduled task 

that will run

Chef Client and trigger that

from
winrm
(with schtasks
/run). This

gets around
the logon type and
credential

delegation issues running in WinRM
provide.

The cause of the
issue is that
when you

land in a remote shell hosted inside WinRM
(either WinRS

or

PowerShell Remoting), you're

connecting to a service and

that
service

does not have the right to
pass on your

credentials
to other services/computers. So when you

try
to
mount the
outside resource, it
attempts to

connect as the

computer's

Network Service account. The
path around

this is either
Kerberos delegation (which has

requirements

on the client side and
in
Active
Directory) or CredSSP,
which
the
WinRM

gem doesn't handle. Task scheduler

suffers no such problems (and is a

better way

to run Chef

Client - and
closer to how it
should run in a
production
context.
Steve

Steven

MurawskiCommunity Software Development
Engineer @

ChefMicrosoft MVP -
PowerShell
http://stevenmurawski.com

      On 7/1/2015 9:54:21 

PM, o haya

wrote:Hi,

I have been implementing
some

recipes/cookbooks for deploying and

configuring
Sharepoint

and Exchange
onto
our
Windows servers. These
servers would

be
domain mmembers.

I was originally
testing by
logging into
one
of the
Windows server and
then running

"chef-client

-o

myCookbook" and was finally able to

get them working

this past week.

Both
sets
of recipes expect the
respective

installation files to
be shared
out from the domain

controller and the recipes do a

"mount" to

"Z:"

drive,

and then the recipes do
"cd

z:"

and then execute the
appropriate .exe
inside a
powershell_script
resource.

As I

said, I got

these recipes working this

week, but in the real world, we would
want
to trigger the
cookbook/recipe
execution remotely using like

"knife

winrm", so I
started
testing
the recipes using
"knife

winrm"
this weekend, and, in both cases, I

ran into similar problems with both
sets of

recipes.

The first

problem was that

the
"mount" would fail with

"access denied",
so I've

since
tried (a) pre-creating the
mapped drive

outside of Chef
and also (b) physically

copying the entire
directories of

installation
software to the local C: drive

and running the
installations off of the local files.

Unfortunately, neither (a) nor (b)

approach

worked either. These

failures occur
at

different points of

the
installation, but
my impression
is that all the failures
are

coming down

to some kind of access denied or violation.

So,
I've
spent most of this weekend

testing

and researching, which lead me to find

some older

threads and information
on

things like credssp an
"2-hop"

that seem to
indicate that these problems

have been around for
awhile, so I was wondering if

there's
some mechanism or configuration

that should fix

he problem nowadays?

Also, I should mention
that I'm
tried
setting the WinRM CredSSP to
"true"

on both the

server side
and on my client
(Chef
workstation) side, but
that

hasn't

made any difference.

Can anyone

here
tell me how I can get these

cookbooks/recipes to work using

"knife winrm"?

Thanks,

Jim

[o_haya]

Hi,

I've been continuing to work on my project, and now using schtasks, and I'll be darned, as I think that I might've just figured why the tests I did earlier with schtasks with Chef, where I couldn't get it working, failed.

I was just looking at the "schtasks /create /?" help and also at the (now-)working example I have, and I noticed that "schtasks /create" has two DIFFERENT username/password pairs. the /U and /P pair and the /RU and /RP pair.

The working example I have now uses /RU and /RP, with <domain_admin_user> and the <domain_admin_user>'s password. This corresponds to the successful test I did earlier where I was using the Chef Windows service and I put the domain admin user in the Windows services.

I don't have the original example (the one that failed), but I'm pretty sure that I had been using the domain admin user and the /U and /P parameters (I guess the /U and /P are the user that is used to run the schtasks.exe itself).

Anyway, this is just for the record :)...

Jim

---

On Fri, 7/3/15, o haya ohaya@yahoo.com wrote:

Subject: Re: [chef] Re: Re: Re: Re: Re: Re: Re: Re: Getting "Access denied" when use mount in recipe and run chef-client remotely via winrm
To: chef@lists.opscode.com
Cc: ohaya@yahoo.com
Date: Friday, July 3, 2015, 1:05 PM

Hi,

For the record, I wanted to let you all know that I was able
to get schtasks working. What I ended up having to do
was to build the entire schtasks command line as a string
(the whole thing with quotes/double-quotes and interpolation
drove me nuts though :)!), and then do "Invoke-expression"
on the string variable.

FYI, I've also been able to run a test scenario where I was
on one Windows machine and ran "schtasks" to create a
scheduled task on one of my nodes to run "chef-client -o
xxxx" where the xxxx cookbook/recipe itself created a
scheduled task (to run the 2nd part of the install after the
reboot) and, amazingly, that all worked!

So, I think that I'm good on this now. Thanks for all
of the help!!

Jim

---

On Fri, 7/3/15, o haya ohaya@yahoo.com
wrote:

Subject: Re: [chef] Re: Re: Re: Re: Re: Re: Re: Re: Getting
"Access denied" when use mount in recipe and run chef-client
remotely via winrm
To: chef@lists.opscode.com
Cc: ohaya@yahoo.com
Date: Friday, July 3, 2015, 2:37 AM

Hi,

I'd really like to be able to have my recipe calculate a
date/time in the future, then create a task via schtasks,
because I think I can use this type of approach for
several
different situations, but I'm kind of stuck figuring out
how
to parameterize the schtasks creation.

I think that I've figured out the code to calculate the
future date and time, and even put the date and time into
some vars formatted the way that schtasks wants them, but
I
am kind of baffled about how to actually use those two
vars
($mydate and $mytime) in the schtasks command.

Here's what I have:

$future_time = $(Get-Date).AddMinutes(15)

echo "Future time is: " $future_time >>
c:/install-SHAREPOINT2007FULL.log

$mydate = $future_time.ToString("MM/dd/yyyy")
$mytime = $future_time.ToString("HH:MM")

schtasks /create /tn Task_Name /tr "chef-client -o
install-SHAREPOINT2007FULL-PART2" /sc once /RU
"env2\Administrator" /RP "xxxxx" /RL HIGHEST /SD $mydate
/ST $mytime

I think the problem is that the two vars are not being
expanded or something like that, but I can't figure out
what
the correct syntax is for doing that. I've tried
double-quoting the vars (e.g., "$mydate") and putting them
inside parens (e.g., $($mydate), and other variants, but
keep getting an error saying that the date is less than
current or something like that.

I know that this is getting a little off-topic, but if
anyone knows how to set that schtasks with the two vars,
can
you please post?

Thanks!

Jim

---

On Fri, 7/3/15, Tensibai Zhaoying tensibai@iabis.net
wrote:

Subject: [chef] Re: Re: Re: Re: Re: Re: Re: Re:
Getting
"Access denied" when use mount in recipe and run
chef-client
remotely via winrm
To: chef@lists.opscode.com
Date: Friday, July 3, 2015, 1:37 AM

You may create the task with no
schedule and add a registry entry in a run_once to
trigger
the task.

See windows - How do I stop/start a scheduled task on a remote computer programmatically? - Stack Overflow
for exemple, locally you can omit the machine
Switch or use a dot to target the local machine.

Le 3 juil. 2015 04:38, o haya ohaya@yahoo.com
a
écrit :

Hi,

BTW, this is the schtasks that I had in my
recipe
that
finally worked (I hard-coded the date/time in this
test):

schtasks /create /tn Task_Name /tr "chef-client
-o
install-SHAREPOINT2007FULL-PART2" /sc once /RU
"env2\Administrator" /RP "xxxxxxx" /RL HIGHEST /SD
07/02/2015 /ST 21:20

Jim

---

On Thu, 7/2/15, o haya ohaya@yahoo.com
wrote:

Subject: Re: [chef] Re: Re: Re: Re: Re: Re:
Getting
"Access denied" when use mount in recipe and run
chef-client
remotely via winrm
To: chef@lists.opscode.com

Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 10:27 PM

I went back and checked and luckily I
still had the test recipes I had been using to
test
using
schtasks to get through the reboot, so I tested
again,

and... it worked!!

I'll do more testing with that, and also start
looking
at
using schtasks to do the remote running of
chef-client.

But, does anyone happen to have the powershell
code
to

calculate 'x' time in the future, for the
schtasks
for

running chef-client after a reboot?

Thanks,
Jim

---

On Thu, 7/2/15, o haya ohaya@yahoo.com
wrote:

Subject: Re: [chef] Re: Re: Re: Re: Re: Re:
Getting
"Access
denied" when use mount in recipe and run
chef-client
remotely via winrm
To: chef@lists.opscode.com

Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 7:22 PM

Hi,

I might go back and try that (schtasks)
again
later.
I'd be happy if that worked, but if you
recall
from
the
Stackoverflow thread that you posted on (scheduled tasks - Is there a way for a Chef recipe to continue after a reboot (Windows)? - Stack Overflow),

I did try that, but had problems with getting
it
to
work,
and actually I never got it working, so ended
up
abandoning
using that for the Sharepoint installation
because
it
turned
out I didn't need a mid-installation
reboot. The

Exchange installation, on the other hand,
does
require a
mid-installation reboot, and because I wasn't
able
to make
the schtasks approach work earlier, I went
with
the
Chef
service approach instead. It would be good
if I
could
get the schtasks approach working :(...

Later,
Jim

---

On Thu, 7/2/15, Tensibai Zhaoying tensibai@iabis.net

wrote:

Subject: [chef] Re: Re: Re: Re: Re: Re:
Getting
"Access
denied" when use mount in recipe and run
chef-client

remotely via winrm
To: chef@lists.opscode.com

Date: Thursday, July 2, 2015, 5:35 PM

Firing a scheduled task
remotely is easy and get you rid of the whole

credential
replay needed from winrm.

This method works since winnt4 (at least) and

has been used for decades to trigger db stop
and
then
server
Shutdown when there's a power outage and
batteries

lifetime is running low (usually this was
part of
the
weekly
reboot task under nt4 :p)

This gives you the enforcement part on a
regular basis + the ability to trigger a run
on an

event
with a lot of way to trigger it (winrm may
not be
allowed
to
so this that's said, I'm unsure about the
latest
limitations )

In brief,
this could be a way to solve your problem on
both
sides
(credentials of the process and on demand
ability)

Le 2 juil. 2015 22:31, o haya ohaya@yahoo.com
a
écrit :

Steven
and Tensibai (et al),

Thanks for the interesting comments and

discussion.

With
that, I think that my perspective is probably
a
little
(maybe a lot) different, which probably
explains
the

differences in opinion.

In our case, we are not looking to
maintaining an environment or environments
over
time,
but
rather, our desire is to be able to deploy
specified

environments kind of "on demand", mostly
one-time
events. That is why the winrm-type approach

is/would be
most attractive (and as I said, "natural") to
us.

Thanks again,
Jim

---

On Thu, 7/2/15, Steven Murawski steven.murawski@gmail.com

wrote:

Subject:
[chef] Re: Re: Re: Re: Getting "Access
denied"
when use mount in recipe and run chef-client
remotely
via
winrm
To: chef@lists.opscode.com

Date: Thursday, July 2, 2015, 4:08 PM

So, I wasn't
referring to
running part of the
recipe as a scheduled task, but to

making the full chef-client run the scheduled

task.

Understanding that this is
generically a Windows
problem, it
still seems like both the scheduled task (if
it
worked for me) and the service
approaches
are kind of
"un-natural"
(read: kludgy) ways to do this, but

that's just my opinion.

The

general use case for Chef Client is to
run in the background
on a schedule,
validating the known good state of the system

and picking up changes when necessary.
This is usually
accomplished as a
service (or daemon) or via a scheduled

task (or cron job). On Windows, I find the
task
scheduler

the better option, as you have more
flexibility in
determining the
conditions you can run the task in, it

easily supports alternate credentials, can be
run
on

demand

as well, and isn't treated as a
service
logon.

There is an use

case for invoking
chef-client over winrm (or ssh) via some
orchestration engine rather than running

on a schedule, but

that means
you'll have to deal with the limitations of
WinRM. There are just too many
"gotchas" in
running in the
WinRM context. Many Win32 APIs can't be
called from a non-interactive logon
(which
WinRM is treated
as) and you have the
credential delegation
problem.
As for
setting up
Chef to run as a service or scheduled task,
the
chef-client cookbook (
https://supermarket.chef.io/cookbooks/chef-client
) can help
with that (though I
don't think it wires up "on

reboot").

Steven
MurawskiCommunity Software Development
Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com

On 7/2/2015 2:44:09

PM, Tensibai
Zhaoying tensibai@iabis.net

wrote:In my opinion, running chef (or
any Configuration
management system)
on demand remotely is an anti-pattern.

If you're describing a

state, the
targeted machine should launch the check by
itself periodically and try to fix
itself
as much as it
can.

It's harder to

compromise a network from a machine
who will overwrite your
exploits
changes every 30 minutes and enforce you to
restart

your compromission from scratch over and

over again.

That's just my opinion too

Le 2 juil. 2015
21:29,
o haya a écrit :

BTW, I
should mention that I have a ticket
on
a slightly "larger" question and this came up

right in the middle of that ticket, so
I've conveyed
info on what I di to
the support person (Vikas). I also

was wondering out loud if maybe you guys
might
make

something like a credential proxy or
maybe
add that
capability to the existing
Chef Windows service.

Understanding that
this is generically a Windows problem,
it
still seems like
both the scheduled
task (if it worked for me) and the

service approaches are kind of "un-natural"
(read:

kludgy) ways to do this, but
that's just my opinion.

---

On Thu, 7/2/15, o haya wrote:

Subject:
Re: [chef] Re: Getting
"Access
denied" when use mount in recipe and run
chef-client remotely via winrm
To:
chef@lists.opscode.com

Cc:
ohaya@yahoo.com
Date: Thursday, July
2, 2015, 3:24 PM

Hi,

Thanks
for
the info. I was just about to
post

that
I've had some success today, but doing
something

different...
leveraging the Chef
Windows service.
What I
did was set
the user's credentials in place of
whatever
was in that service (in
my case the
Windows domain
Administrator) and then
let the service fire off my

recipe/cookbook. I have to so some tweaking
of
the

design

of my
recipes to prevent them from

re-running more than

once, but I
was
surprised that it works after
that.

I had seen mention of using

task
scheduler/schtasks before, and I

would've tried

that for this

situation, but when I was looking into
how to

do processing across
reboots, but even
though I was able to

get the task
scheduling part done, the recipes
appeared
to
run into the same type of
access denied
problems. I fought
with that for a

couple of days, and finally gave up on it.

In particular,
I was doing

a recipe
for deploying Exchange, and it required

installing

some prerequisites and
then a reboot and
then the actual
installation. So
back then, I would have the first part
of

the recipe create a scheduled
task via
schtasks, for the 2nd
part, but when

the 2nd part, which was what actually ran the

setup.exe and psconfig.exe, ran, it

kept

throwing errors

indicating that

something wasn't accessible.

So, at this point, the service

approach is the only approach
that works
for me.

Thanks
again,
Jim

P.S. I

kind of

guessed that there wasn't something, but I

posted because the threads, etc I
found on
the credssp and
chef were a couple of
years old, and was hoping that

there'd be
something better by now :(...

---

On Thu, 7/2/15, Steven Murawski
wrote:

Subject: [chef] Re:
Getting "Access denied"
when use
mount in recipe
and run chef-client
remotely via winrm

To:

chef@lists.opscode.com

Cc: "o haya"
Date: Thursday, July 2, 2015,
3:02
PM

You are
hitting one of the

core challenges in dealing with
Windows
remote

management.

The ruby
WinRM gem, which we
use for
knife-windows,
doesn't
support
CredSSP credential
delegation (and there

are
security
concerns with that anyway).
A better

workaround would be to create a scheduled

task

that will run

Chef Client and trigger that

from
winrm
(with schtasks
/run). This

gets around
the logon type and
credential

delegation issues running in WinRM
provide.

The cause of the
issue is that
when you

land in a remote shell hosted inside
WinRM
(either WinRS

or

PowerShell Remoting), you're

connecting to a service and

that
service

does not have the right to
pass on your

credentials
to other services/computers. So when you

try
to
mount the
outside resource, it
attempts to

connect as the

computer's

Network Service account. The
path around

this is either
Kerberos delegation (which has

requirements

on the client side and
in
Active
Directory) or CredSSP,
which
the
WinRM

gem doesn't handle. Task scheduler

suffers no such problems (and is
a

better way

to run Chef

Client - and
closer to how it
should run in a
production
context.
Steve

Steven

MurawskiCommunity Software Development
Engineer @

ChefMicrosoft MVP -
PowerShell
http://stevenmurawski.com

      On 7/1/2015 9:54:21 

PM, o haya

wrote:Hi,

I have been implementing
some

recipes/cookbooks for deploying and

configuring
Sharepoint

and Exchange
onto
our
Windows servers. These
servers would

be
domain mmembers.

I was originally
testing by
logging into
one
of the
Windows server and
then running

"chef-client

-o

myCookbook" and was finally able to

get them working

this past week.

Both
sets
of recipes expect the
respective

installation files to
be shared
out from the domain

controller and the recipes do a

"mount" to

"Z:"

drive,

and then the recipes do
"cd

z:"

and then execute the
appropriate .exe
inside a
powershell_script
resource.

As I

said, I got

these recipes working this

week, but in the real world, we
would
want
to trigger the
cookbook/recipe
execution remotely using like

"knife

winrm", so I
started
testing
the recipes using
"knife

winrm"
this weekend, and, in both cases, I

ran into similar problems with both
sets of

recipes.

The first

problem was that

the
"mount" would fail with

"access denied",
so I've

since
tried (a) pre-creating the
mapped drive

outside of Chef
and also (b) physically

copying the entire
directories of

installation
software to the local C: drive

and running the
installations off of the local files.

Unfortunately, neither (a) nor
(b)

approach

worked either. These

failures occur
at

different points of

the
installation, but
my impression
is that all the failures
are

coming down

to some kind of access denied or violation.

So,
I've
spent most of this weekend

testing

and researching, which lead me to find

some older

threads and information
on

things like credssp an
"2-hop"

that seem to
indicate that these problems

have been around for
awhile, so I was wondering if

there's
some mechanism or configuration

that should fix

he problem nowadays?

Also, I should mention
that I'm
tried
setting the WinRM CredSSP to
"true"

on both the

server side
and on my client
(Chef
workstation) side, but
that

hasn't

made any difference.

Can anyone

here
tell me how I can get these

cookbooks/recipes to work using

"knife winrm"?

Thanks,

Jim

[Nico_Kadel_Garcia]

Updating your config every 30 minutes on a high availability system is, I'm afraid, begging to break core live services such as NFS, DNS, monitoring, and authentication. The extra work to lock cookbooks to specific, tested releases for all production environments is burdensome and quite rarely done. And the potential for a single unexpected "obvious" and "safe" change to knock out an entire network is quite large.

I refer especially to the DNS, authentication, and web service related cookbooks. Restarting a DNS or web daemon will interrupt active connections, and even a white space config change typically restarts the service. And a one character error in a DNS or authentication configuration will prevent the service from restarting.

It's gotten better for DNS, since some cookbooks now verify the config and error out if it's broken. But few other cookbooks have this kind of check.

Nico Kadel-Garcia
Email: nkadel@gmail.com
Sent from iPhone

On Jul 2, 2015, at 15:44, "Tensibai Zhaoying" tensibai@iabis.net wrote:

In my opinion, running chef (or any Configuration management system) on demand remotely is an anti-pattern.

If you're describing a state, the targeted machine should launch the check by itself periodically and try to fix itself as much as it can.

It's harder to compromise a network from a machine who will overwrite your exploits changes every 30 minutes and enforce you to restart your compromission from scratch over and over again.

That's just my opinion too

Le 2 juil. 2015 21:29, o haya ohaya@yahoo.com a écrit :

BTW, I should mention that I have a ticket on a slightly "larger" question and this came up right in the middle of that ticket, so I've conveyed info on what I di to the support person (Vikas). I also was wondering out loud if maybe you guys might make something like a credential proxy or maybe add that capability to the existing Chef Windows service.

Understanding that this is generically a Windows problem, it still seems like both the scheduled task (if it worked for me) and the service approaches are kind of "un-natural" (read: kludgy) ways to do this, but that's just my opinion.

---

On Thu, 7/2/15, o haya ohaya@yahoo.com wrote:

Subject: Re: [chef] Re: Getting "Access denied" when use mount in recipe and run chef-client remotely via winrm
To: chef@lists.opscode.com
Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 3:24 PM

Hi,

Thanks for the info. I was just about to post
that I've had some success today, but doing something
different... leveraging the Chef Windows service. What I
did was set the user's credentials in place of whatever
was in that service (in my case the Windows domain
Administrator) and then let the service fire off my
recipe/cookbook. I have to so some tweaking of the design
of my recipes to prevent them from re-running more than
once, but I was surprised that it works after that.

I had seen mention of using
task scheduler/schtasks before, and I would've tried
that for this situation, but when I was looking into how to
do processing across reboots, but even though I was able to
get the task scheduling part done, the recipes appeared to
run into the same type of access denied problems. I fought
with that for a couple of days, and finally gave up on it.

In particular, I was doing
a recipe for deploying Exchange, and it required installing
some prerequisites and then a reboot and then the actual
installation. So back then, I would have the first part of
the recipe create a scheduled task via schtasks, for the 2nd
part, but when the 2nd part, which was what actually ran the
setup.exe and psconfig.exe, ran, it kept throwing errors
indicating that something wasn't accessible.

So, at this point, the service
approach is the only approach that works for me.

Thanks again,
Jim

P.S. I
kind of guessed that there wasn't something, but I
posted because the threads, etc I found on the credssp and
chef were a couple of years old, and was hoping that
there'd be something better by now :(...

---

On Thu, 7/2/15, Steven Murawski steven.murawski@gmail.com
wrote:

Subject: [chef] Re:
Getting "Access denied" when use mount in recipe
and run chef-client remotely via winrm
To:
chef@lists.opscode.com
Cc: "o haya" ohaya@yahoo.com
Date: Thursday, July 2, 2015, 3:02 PM

You are hitting one of the

core challenges in dealing with Windows remote
management.
The ruby WinRM gem, which we
use for knife-windows,
doesn't support
CredSSP credential delegation (and there

are security concerns with that anyway). A better
workaround would be to create a scheduled task
that will run
Chef Client and trigger that
from winrm (with schtasks
/run). This
gets around the logon type and credential

delegation issues running in WinRM provide.

The cause of the issue is that when you

land in a remote shell hosted inside WinRM (either WinRS
or
PowerShell Remoting), you're
connecting to a service and
that service
does not have the right to pass on your

credentials to other services/computers. So when you
try
to mount the outside resource, it
attempts to connect as the
computer's
Network Service account. The path around

this is either Kerberos delegation (which has
requirements
on the client side and in
Active Directory) or CredSSP,
which the
WinRM gem doesn't handle. Task scheduler
suffers no such problems (and is a better way
to run Chef
Client - and closer to how it
should run in a production
context.
Steve
Steven
MurawskiCommunity Software Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com

    On 7/1/2015 9:54:21 

PM, o haya
ohaya@yahoo.com
wrote:Hi,

I have been implementing
some
recipes/cookbooks for deploying and
configuring Sharepoint
and Exchange onto
our Windows servers. These servers would

be domain mmembers.

I was originally testing by
logging into
one of the Windows server and
then running "chef-client
-o
myCookbook" and was finally able to get them working
this past week.

Both sets
of recipes expect the respective

installation files to be shared out from the domain
controller and the recipes do a
"mount" to
"Z:" drive,
and then the recipes do "cd
z:"
and then execute the appropriate .exe inside a
powershell_script resource.

As I
said, I got these recipes working this

week, but in the real world, we would want to trigger the
cookbook/recipe execution remotely using like
"knife
winrm", so I started
testing the recipes using
"knife
winrm" this weekend, and, in both cases, I
ran into similar problems with both sets of
recipes.

The first problem was that
the
"mount" would fail with
"access denied",
so I've
since tried (a) pre-creating the mapped drive
outside of Chef and also (b) physically
copying the entire
directories of
installation software to the local C: drive

and running the installations off of the local files.

Unfortunately, neither (a) nor (b) approach
worked either. These failures occur at
different points of
the installation, but
my impression is that all the failures
are
coming down to some kind of access denied or violation.

So, I've spent most of this weekend
testing and researching, which lead me to find
some older
threads and information on
things like credssp an
"2-hop"
that seem to indicate that these problems

have been around for awhile, so I was wondering if
there's some mechanism or configuration
that should fix
he problem nowadays?

Also, I should mention that I'm tried
setting the WinRM CredSSP to "true"
on both the
server side and on my client
(Chef workstation) side, but
that
hasn't made any difference.

Can anyone
here tell me how I can get these

cookbooks/recipes to work using "knife winrm"?

Thanks,

Jim

[Adam_Edwards1]

Steve Murawski, couldn't they use credssp via powershell (from a Windows box
of course) to trigger the remote chef-client run? That would sidestep the
winrm gem.

A "hack" way to do this is to use winrm to run the following commands if you
have chef-client running as a service:

net stop chef-client
net start chef-client

When chef-client restarts, you'll get a chef run. The downside of course is
that you're temporarily turning off the chef service. There may also be race
conditions that make this less than desirable.

Push jobs is also an option here. Task scheduler will work, particularly
easy if you just want to fire and forget and don't need to get status back
when you initiate the task (just rely on the chef server for that).

Lastly, you could use some sort of 'trigger' in your chef-client run that
looks for some state -- a data bag, a git tag, something else, that you can
set when you want a manual chef run. It could be at the start of your
runlist, and would abort (without error) the chef run if the state weren't
there. Combine this with a more frequent background chef-client run (e.g.
Chef set up as a service) and you could get what feels like on-demand
execution.

Ultimately, I think this is a good justification for the "run me now"
feature for the chef service. A user could use winrm to run a command that
tells the service to run chef now. Steve, what do you think?

-Adam

-----Original Message-----
From: Nico Kadel-Garcia [mailto:nkadel@skyhookwireless.com]
Sent: Wednesday, July 8, 2015 6:36 AM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: Re: Re: Getting "Access denied" when use mount in
recipe and run chef-client remotely via winrm

Updating your config every 30 minutes on a high availability system is, I'm
afraid, begging to break core live services such as NFS, DNS, monitoring,
and authentication. The extra work to lock cookbooks to specific, tested
releases for all production environments is burdensome and quite rarely
done. And the potential for a single unexpected "obvious" and "safe" change
to knock out an entire network is quite large.

I refer especially to the DNS, authentication, and web service related
cookbooks. Restarting a DNS or web daemon will interrupt active connections,
and even a white space config change typically restarts the service. And a
one character error in a DNS or authentication configuration will prevent
the service from restarting.

It's gotten better for DNS, since some cookbooks now verify the config and
error out if it's broken. But few other cookbooks have this kind of check.

Nico Kadel-Garcia
Email: nkadel@gmail.com
Sent from iPhone

On Jul 2, 2015, at 15:44, "Tensibai Zhaoying" tensibai@iabis.net wrote:

In my opinion, running chef (or any Configuration management system) on
demand remotely is an anti-pattern.

If you're describing a state, the targeted machine should launch the check
by itself periodically and try to fix itself as much as it can.

It's harder to compromise a network from a machine who will overwrite your
exploits changes every 30 minutes and enforce you to restart your
compromission from scratch over and over again.

That's just my opinion too

Le 2 juil. 2015 21:29, o haya ohaya@yahoo.com a écrit :

BTW, I should mention that I have a ticket on a slightly "larger"
question and this came up right in the middle of that ticket, so I've
conveyed info on what I di to the support person (Vikas). I also was
wondering out loud if maybe you guys might make something like a
credential proxy or maybe add that capability to the existing Chef
Windows service.

Understanding that this is generically a Windows problem, it still seems
like both the scheduled task (if it worked for me) and the service
approaches are kind of "un-natural" (read: kludgy) ways to do this, but
that's just my opinion.

---

On Thu, 7/2/15, o haya ohaya@yahoo.com wrote:

Subject: Re: [chef] Re: Getting "Access denied" when use mount in
recipe and run chef-client remotely via winrm
To: chef@lists.opscode.com
Cc: ohaya@yahoo.com
Date: Thursday, July 2, 2015, 3:24 PM

Hi,

Thanks for the info. I was just about to post that I've had some
success today, but doing something different... leveraging the Chef
Windows service. What I did was set the user's credentials in place
of whatever was in that service (in my case the Windows domain
Administrator) and then let the service fire off my recipe/cookbook.
I have to so some tweaking of the design of my recipes to prevent
them from re-running more than once, but I was surprised that it
works after that.

I had seen mention of using
task scheduler/schtasks before, and I would've tried that for this
situation, but when I was looking into how to do processing across
reboots, but even though I was able to get the task scheduling part
done, the recipes appeared to run into the same type of access denied
problems. I fought with that for a couple of days, and finally gave
up on it.

In particular, I was doing
a recipe for deploying Exchange, and it required installing some
prerequisites and then a reboot and then the actual installation. So
back then, I would have the first part of the recipe create a
scheduled task via schtasks, for the 2nd part, but when the 2nd part,
which was what actually ran the setup.exe and psconfig.exe, ran, it
kept throwing errors indicating that something wasn't accessible.

So, at this point, the service
approach is the only approach that works for me.

Thanks again,
Jim

P.S. I
kind of guessed that there wasn't something, but I posted because the
threads, etc I found on the credssp and chef were a couple of years
old, and was hoping that there'd be something better by now :(...

---

On Thu, 7/2/15, Steven Murawski steven.murawski@gmail.com
wrote:

Subject: [chef] Re:
Getting "Access denied" when use mount in recipe and run chef-client
remotely via winrm
To:
chef@lists.opscode.com
Cc: "o haya" ohaya@yahoo.com
Date: Thursday, July 2, 2015, 3:02 PM

You are hitting one of the

core challenges in dealing with Windows remote management.
The ruby WinRM gem, which we
use for knife-windows,
doesn't support
CredSSP credential delegation (and there

are security concerns with that anyway). A better
workaround would be to create a scheduled task that will run
Chef Client and trigger that
from winrm (with schtasks
/run). This
gets around the logon type and credential

delegation issues running in WinRM provide.

The cause of the issue is that when you

land in a remote shell hosted inside WinRM (either WinRS or
PowerShell Remoting), you're
connecting to a service and
that service
does not have the right to pass on your

credentials to other services/computers. So when you try
to mount the outside resource, it
attempts to connect as the
computer's
Network Service account. The path around

this is either Kerberos delegation (which has requirements
on the client side and in
Active Directory) or CredSSP,
which the
WinRM gem doesn't handle. Task scheduler
suffers no such problems (and is a better way to run Chef
Client - and closer to how it
should run in a production
context.
Steve
Steven
MurawskiCommunity Software Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com

    On 7/1/2015 9:54:21

PM, o haya
ohaya@yahoo.com
wrote:Hi,

I have been implementing
some
recipes/cookbooks for deploying and configuring Sharepoint
and Exchange onto
our Windows servers. These servers would

be domain mmembers.

I was originally testing by
logging into
one of the Windows server and
then running "chef-client
-o
myCookbook" and was finally able to get them working
this past week.

Both sets
of recipes expect the respective

installation files to be shared out from the domain
controller and the recipes do a
"mount" to
"Z:" drive,
and then the recipes do "cd
z:"
and then execute the appropriate .exe inside a
powershell_script resource.

As I
said, I got these recipes working this

week, but in the real world, we would want to trigger the
cookbook/recipe execution remotely using like "knife
winrm", so I started
testing the recipes using
"knife
winrm" this weekend, and, in both cases, I
ran into similar problems with both sets of recipes.

The first problem was that
the
"mount" would fail with
"access denied",
so I've
since tried (a) pre-creating the mapped drive
outside of Chef and also (b) physically copying the entire
directories of
installation software to the local C: drive

and running the installations off of the local files.

Unfortunately, neither (a) nor (b) approach
worked either. These failures occur at different points of
the installation, but
my impression is that all the failures
are
coming down to some kind of access denied or violation.

So, I've spent most of this weekend
testing and researching, which lead me to find some older
threads and information on
things like credssp an
"2-hop"
that seem to indicate that these problems

have been around for awhile, so I was wondering if
there's some mechanism or configuration that should fix
he problem nowadays?

Also, I should mention that I'm tried
setting the WinRM CredSSP to "true"
on both the
server side and on my client
(Chef workstation) side, but
that
hasn't made any difference.

Can anyone
here tell me how I can get these

cookbooks/recipes to work using "knife winrm"?

Thanks,

Jim