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

**URL:** <https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772>\
**Category:** Chef Infra (archive)\
**Created:** [July 2, 2015, 2:54am UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772 "2015-07-02T02:54:03Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![o\_haya](https://avatars.discourse-cdn.com/v4/letter/o/ea666f/32.png) [@o\_haya](https://discourse.chef.io/u/o_haya)\
**Post date:** [July 2, 2015, 2:54am UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/1 "2015-07-02T02:54:03Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Steven\_Murawski](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/steven_murawski/32/1450_2.png) [@Steven\_Murawski](https://discourse.chef.io/u/Steven_Murawski)\
**Post date:** [July 2, 2015, 7:02pm UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/2 "2015-07-02T19:02:44Z")

</div>

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) [[http://stevenmurawski.com/](http://stevenmurawski.com/)]  
On 7/1/2015 9:54:21 PM, o haya [ohaya@yahoo.com](mailto: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

---

<div class="post-metadata">

**Author:** ![o\_haya](https://avatars.discourse-cdn.com/v4/letter/o/ea666f/32.png) [@o\_haya](https://discourse.chef.io/u/o_haya)\
**Post date:** [July 2, 2015, 7:24pm UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/3 "2015-07-02T19:24:13Z")

</div>

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](mailto: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](mailto:chef@lists.opscode.com)  
Cc: “o haya” [ohaya@yahoo.com](mailto: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](http://stevenmurawski.com)  
On 7/1/2015 9:54:21  
PM, o haya [ohaya@yahoo.com](mailto: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

---

<div class="post-metadata">

**Author:** ![o\_haya](https://avatars.discourse-cdn.com/v4/letter/o/ea666f/32.png) [@o\_haya](https://discourse.chef.io/u/o_haya)\
**Post date:** [July 2, 2015, 7:29pm UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/4 "2015-07-02T19:29:15Z")

</div>

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](mailto: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](mailto:chef@lists.opscode.com)  
Cc: [ohaya@yahoo.com](mailto: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](mailto: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](mailto:chef@lists.opscode.com)  
Cc: “o haya” [ohaya@yahoo.com](mailto: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](http://stevenmurawski.com)

```
     On 7/1/2015 9:54:21

```

PM, o haya  
[ohaya@yahoo.com](mailto: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

---

<div class="post-metadata">

**Author:** ![Tensibai](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tensibai/32/29_2.png) [@Tensibai](https://discourse.chef.io/u/Tensibai)\
**Post date:** [July 2, 2015, 7:43pm UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/5 "2015-07-02T19:43:48Z")

</div>

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](mailto: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](mailto: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](mailto:chef@lists.opscode.com)  
> Cc: [ohaya@yahoo.com](mailto: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](mailto: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](mailto:chef@lists.opscode.com)  
> Cc: "o haya" [ohaya@yahoo.com](mailto: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](http://stevenmurawski.com)
> 
> ```
> On 7/1/2015 9:54:21 
> 
> ```
> 
> PM, o haya  
> [ohaya@yahoo.com](mailto: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

---

<div class="post-metadata">

**Author:** ![Steven\_Murawski](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/steven_murawski/32/1450_2.png) [@Steven\_Murawski](https://discourse.chef.io/u/Steven_Murawski)\
**Post date:** [July 2, 2015, 8:08pm UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/6 "2015-07-02T20:08:00Z")

</div>

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](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) [[http://stevenmurawski.com/](http://stevenmurawski.com/)]  
On 7/2/2015 2:44:09 PM, Tensibai Zhaoying [tensibai@iabis.net](mailto: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](mailto:chef@lists.opscode.com)  
> Cc: [ohaya@yahoo.com](mailto: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](mailto: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](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

---

<div class="post-metadata">

**Author:** ![o\_haya](https://avatars.discourse-cdn.com/v4/letter/o/ea666f/32.png) [@o\_haya](https://discourse.chef.io/u/o_haya)\
**Post date:** [July 2, 2015, 8:31pm UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/7 "2015-07-02T20:31:12Z")

</div>

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](mailto: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](mailto: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](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](http://stevenmurawski.com)  
> On 7/2/2015 2:44:09  
> PM, Tensibai Zhaoying [tensibai@iabis.net](mailto: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](mailto:chef@lists.opscode.com)  
> Cc:  
> [ohaya@yahoo.com](mailto: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](mailto: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](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

> 

> 

> 

>

---

<div class="post-metadata">

**Author:** ![Tensibai](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tensibai/32/29_2.png) [@Tensibai](https://discourse.chef.io/u/Tensibai)\
**Post date:** [July 2, 2015, 9:35pm UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/8 "2015-07-02T21:35:32Z")

</div>

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](mailto: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](mailto: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](mailto: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](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](http://stevenmurawski.com)  
> > On 7/2/2015 2:44:09  
> > PM, Tensibai Zhaoying [tensibai@iabis.net](mailto: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](mailto:chef@lists.opscode.com)  
> > Cc:  
> > [ohaya@yahoo.com](mailto: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](mailto: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](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
> 
> > 
> 
> > 
> 
> > 
> 
> >

---

<div class="post-metadata">

**Author:** ![o\_haya](https://avatars.discourse-cdn.com/v4/letter/o/ea666f/32.png) [@o\_haya](https://discourse.chef.io/u/o_haya)\
**Post date:** [July 2, 2015, 11:22pm UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/9 "2015-07-02T23:22:25Z")

</div>

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](http://stackoverflow.com/questions/31058849/is-there-a-way-for-a-chef-recipe-to-continue-after-a-reboot-windows)), 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](mailto: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](mailto: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](mailto: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](mailto: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](mailto: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](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](http://stevenmurawski.com)

On 7/2/2015 2:44:09

> PM, Tensibai  
> Zhaoying [tensibai@iabis.net](mailto: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](mailto:chef@lists.opscode.com)

> > Cc:  
> > [ohaya@yahoo.com](mailto: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](mailto: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](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

> >

> >

> 

> >

> >

> >

> 

> 

>

---

<div class="post-metadata">

**Author:** ![o\_haya](https://avatars.discourse-cdn.com/v4/letter/o/ea666f/32.png) [@o\_haya](https://discourse.chef.io/u/o_haya)\
**Post date:** [July 3, 2015, 2:27am UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/10 "2015-07-03T02:27:04Z")

</div>

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](mailto: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](mailto:chef@lists.opscode.com)  
Cc: [ohaya@yahoo.com](mailto: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](http://stackoverflow.com/questions/31058849/is-there-a-way-for-a-chef-recipe-to-continue-after-a-reboot-windows)),  
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](mailto: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](mailto: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](mailto: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](mailto: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](mailto: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](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](http://stevenmurawski.com)

On 7/2/2015 2:44:09

> PM, Tensibai  
> Zhaoying [tensibai@iabis.net](mailto: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](mailto:chef@lists.opscode.com)

> > Cc:  
> > [ohaya@yahoo.com](mailto: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](mailto: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](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

> >

> >

> 

> >

> >

> >

> 

> 

>

---

<div class="post-metadata">

**Author:** ![o\_haya](https://avatars.discourse-cdn.com/v4/letter/o/ea666f/32.png) [@o\_haya](https://discourse.chef.io/u/o_haya)\
**Post date:** [July 3, 2015, 2:38am UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/11 "2015-07-03T02:38:07Z")

</div>

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](mailto: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](mailto:chef@lists.opscode.com)  
Cc: [ohaya@yahoo.com](mailto: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](mailto: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](mailto:chef@lists.opscode.com)  
Cc: [ohaya@yahoo.com](mailto: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](http://stackoverflow.com/questions/31058849/is-there-a-way-for-a-chef-recipe-to-continue-after-a-reboot-windows)),  
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](mailto: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](mailto: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](mailto: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](mailto: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](mailto: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](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](http://stevenmurawski.com)

On 7/2/2015 2:44:09

> PM, Tensibai  
> Zhaoying [tensibai@iabis.net](mailto: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](mailto:chef@lists.opscode.com)

> > Cc:  
> > [ohaya@yahoo.com](mailto: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](mailto: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](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

> >

> >

> 

> >

> >

> >

> 

> 

>

---

<div class="post-metadata">

**Author:** ![Tensibai](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tensibai/32/29_2.png) [@Tensibai](https://discourse.chef.io/u/Tensibai)\
**Post date:** [July 3, 2015, 5:37am UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/12 "2015-07-03T05:37:52Z")

</div>

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](http://stackoverflow.com/questions/290559/how-do-i-stop-start-a-scheduled-task-on-a-remote-computer-programatically) 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](mailto: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](mailto: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](mailto:chef@lists.opscode.com)  
> Cc: [ohaya@yahoo.com](mailto: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](mailto: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](mailto:chef@lists.opscode.com)  
> Cc: [ohaya@yahoo.com](mailto: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](http://stackoverflow.com/questions/31058849/is-there-a-way-for-a-chef-recipe-to-continue-after-a-reboot-windows)),  
> 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](mailto: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](mailto: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](mailto: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](mailto: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](mailto: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](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](http://stevenmurawski.com)
> 
> On 7/2/2015 2:44:09
> 
> > PM, Tensibai  
> > Zhaoying [tensibai@iabis.net](mailto: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](mailto:chef@lists.opscode.com)
> 
> > > Cc:  
> > > [ohaya@yahoo.com](mailto: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](mailto: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](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
> 
> > >
> 
> > >
> 
> > 
> 
> > >
> 
> > >
> 
> > >
> 
> > 
> 
> > 
> 
> >

---

<div class="post-metadata">

**Author:** ![o\_haya](https://avatars.discourse-cdn.com/v4/letter/o/ea666f/32.png) [@o\_haya](https://discourse.chef.io/u/o_haya)\
**Post date:** [July 3, 2015, 6:37am UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/13 "2015-07-03T06:37:47Z")

</div>

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](mailto: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](mailto: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](http://stackoverflow.com/questions/290559/how-do-i-stop-start-a-scheduled-task-on-a-remote-computer-programatically)  
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](mailto: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](mailto: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](mailto:chef@lists.opscode.com)

> Cc: [ohaya@yahoo.com](mailto: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](mailto: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](mailto:chef@lists.opscode.com)

> Cc: [ohaya@yahoo.com](mailto: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](http://stackoverflow.com/questions/31058849/is-there-a-way-for-a-chef-recipe-to-continue-after-a-reboot-windows)),

> 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](mailto: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](mailto: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](mailto: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](mailto: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](mailto: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](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](http://stevenmurawski.com)

> On 7/2/2015 2:44:09
> 
> > PM, Tensibai  
> > Zhaoying [tensibai@iabis.net](mailto: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](mailto:chef@lists.opscode.com)

> > > Cc:  
> > > [ohaya@yahoo.com](mailto: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](mailto: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](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
> 
> > >
> 
> > >
> 
> > 
> 
> > >
> 
> > >
> 
> > >

> >

> >

> >

---

<div class="post-metadata">

**Author:** ![o\_haya](https://avatars.discourse-cdn.com/v4/letter/o/ea666f/32.png) [@o\_haya](https://discourse.chef.io/u/o_haya)\
**Post date:** [July 3, 2015, 5:05pm UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/14 "2015-07-03T17:05:11Z")

</div>

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](mailto: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](mailto:chef@lists.opscode.com)  
Cc: [ohaya@yahoo.com](mailto: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](mailto: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](mailto: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](http://stackoverflow.com/questions/290559/how-do-i-stop-start-a-scheduled-task-on-a-remote-computer-programatically)  
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](mailto: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](mailto: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](mailto:chef@lists.opscode.com)

> Cc: [ohaya@yahoo.com](mailto: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](mailto: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](mailto:chef@lists.opscode.com)

> Cc: [ohaya@yahoo.com](mailto: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](http://stackoverflow.com/questions/31058849/is-there-a-way-for-a-chef-recipe-to-continue-after-a-reboot-windows)),

> 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](mailto: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](mailto: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](mailto: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](mailto: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](mailto: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](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](http://stevenmurawski.com)

> On 7/2/2015 2:44:09
> 
> > PM, Tensibai  
> > Zhaoying [tensibai@iabis.net](mailto: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](mailto:chef@lists.opscode.com)

> > > Cc:  
> > > [ohaya@yahoo.com](mailto: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](mailto: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](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
> 
> > >
> 
> > >
> 
> > 
> 
> > >
> 
> > >
> 
> > >

> >

> >

> >

---

<div class="post-metadata">

**Author:** ![o\_haya](https://avatars.discourse-cdn.com/v4/letter/o/ea666f/32.png) [@o\_haya](https://discourse.chef.io/u/o_haya)\
**Post date:** [July 5, 2015, 11:18pm UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/15 "2015-07-05T23:18:38Z")

</div>

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](mailto: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](mailto:chef@lists.opscode.com)  
Cc: [ohaya@yahoo.com](mailto: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](mailto: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](mailto:chef@lists.opscode.com)  
Cc: [ohaya@yahoo.com](mailto: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](mailto: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](mailto: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](http://stackoverflow.com/questions/290559/how-do-i-stop-start-a-scheduled-task-on-a-remote-computer-programatically)  
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](mailto: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](mailto: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](mailto:chef@lists.opscode.com)

> Cc: [ohaya@yahoo.com](mailto: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](mailto: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](mailto:chef@lists.opscode.com)

> Cc: [ohaya@yahoo.com](mailto: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](http://stackoverflow.com/questions/31058849/is-there-a-way-for-a-chef-recipe-to-continue-after-a-reboot-windows)),

> 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](mailto: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](mailto: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](mailto: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](mailto: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](mailto: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](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](http://stevenmurawski.com)

> On 7/2/2015 2:44:09
> 
> > PM, Tensibai  
> > Zhaoying [tensibai@iabis.net](mailto: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](mailto:chef@lists.opscode.com)

> > > Cc:  
> > > [ohaya@yahoo.com](mailto: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](mailto: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](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
> 
> > >
> 
> > >
> 
> > 
> 
> > >
> 
> > >
> 
> > >

> >

> >

> >

---

<div class="post-metadata">

**Author:** ![Nico\_Kadel\_Garcia](https://avatars.discourse-cdn.com/v4/letter/n/ad7895/32.png) [@Nico\_Kadel\_Garcia](https://discourse.chef.io/u/Nico_Kadel_Garcia)\
**Post date:** [July 8, 2015, 1:35pm UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/16 "2015-07-08T13:35:34Z")

</div>

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](mailto:nkadel@gmail.com)  
Sent from iPhone

> On Jul 2, 2015, at 15:44, "Tensibai Zhaoying" [tensibai@iabis.net](mailto: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](mailto: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](mailto: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](mailto:chef@lists.opscode.com)  
> > Cc: [ohaya@yahoo.com](mailto: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](mailto: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](mailto:chef@lists.opscode.com)  
> > Cc: "o haya" [ohaya@yahoo.com](mailto: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](http://stevenmurawski.com)
> > 
> > ```
> > On 7/1/2015 9:54:21 
> > 
> > ```
> > 
> > PM, o haya  
> > [ohaya@yahoo.com](mailto: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

---

<div class="post-metadata">

**Author:** ![Adam\_Edwards1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/adam_edwards1/32/27_2.png) [@Adam\_Edwards1](https://discourse.chef.io/u/Adam_Edwards1)\
**Post date:** [July 8, 2015, 2:04pm UTC](https://discourse.chef.io/t/getting-access-denied-when-use-mount-in-recipe-and-run-chef-client-remotely-via-winrm/6772/17 "2015-07-08T14:04:25Z")

</div>

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](mailto:nkadel@skyhookwireless.com)]  
Sent: Wednesday, July 8, 2015 6:36 AM  
To: [chef@lists.opscode.com](mailto: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](mailto:nkadel@gmail.com)  
Sent from iPhone

> On Jul 2, 2015, at 15:44, "Tensibai Zhaoying" [tensibai@iabis.net](mailto: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](mailto: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](mailto: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](mailto:chef@lists.opscode.com)  
> > Cc: [ohaya@yahoo.com](mailto: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](mailto: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](mailto:chef@lists.opscode.com)  
> > Cc: "o haya" [ohaya@yahoo.com](mailto: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](http://stevenmurawski.com)
> > 
> > ```
> > On 7/1/2015 9:54:21
> > 
> > ```
> > 
> > PM, o haya  
> > [ohaya@yahoo.com](mailto: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