Posts Tagged ‘Powershell’

Running in the name of…

In Active Directory, Chef, DevOps, Powershell, Race Against the Machine on February 14, 2015 at 22:28

If you like my content please do check out my new blog at !

During my last post I briefly discussed the issues related to the execution context of the chef-client when developing and testing cookbooks. To summarize: on a windows machine the chef-client runs under the context of the local system account, an account which basically is a local admin but has almost no permissions on other Active Directory joined/secured objects ( such as other machines, Active Directory itself or file shares).

You can always mimic this behaviour by just adding a cookbook to a test node’s runlist and restarting the chef-client service of course. Or create a scheduled task which runs chef-solo or zero. However that leaves you without the direct output from an interactively started chef-run. Also I can’t really see how you could add something like that to a vagrant setup.

Luckily – the need to run stuff under the local system account is not new. Quite some time ago the windows tool legend Mark Russinovich developed a tool which also you to, amoungst other things, to start a process as the local system account. In order to do that it temporarily installs a windows service called PSEXESVC which is used to start a process ( eg. cmd.exe) as the local system account.

The command itself is very simple:

somepath:\psexec /s cmd.exe

You can run this from another command window, or Powershell – doesn’t really matter. Once you do it starts another instance of cmd.exe and everything executed from that instance will be run as the local system account. For instance :


Will return:

nt authority\system

From there you can start chef-client just as you normally would – however you will find out that if you access anything outside of the node that access will be denied – unless the permissions on the resource are set to include the computer account object ( which includes Everyone and Authenticated Users btw). Also the output of the chef-client is a little bit different – more like the output that’s written to the chef log when you run the client as a service.

I’ve tried hacking this into the batch files chef uses to start stuff ( so instead of calling ruby.exe directly I would first open a command console as local system when running chef zero) but that didn’t seem to work – I guess that has something to with the difference between a real interactive session and a session as started by psexec. But I’m sure I’ll find some way to work around that at some point.

But for now – if you really want to know if your cookbook will run as you’d expect in a Windows domain environment – use psexec manually at least once in order to identify any permission issues.


P.S – there is one other fun way to run stuff as local system – replacing the ease of access executable on a box 😉 For more details see Guy’s site.

Movies As Code

In Powershell, Proxy on March 12, 2012 at 21:12

If you like my content please do check out my new blog at ! 


A friend showed me this wonderfully geeky site:

The whole idea is to describe movies or movie titles using runnable code! And I’m glad to say that I contributed the first Movie as Powershell : The Sum of All Fears!

I generously stole the basics from Wayne and used powershell to sum up the number of times the string “fear” appears in the King James Bible, times the number of characters in the word “fear”.

The proxy stuff is quite interesting because I had been searching for a code snippet that allowed me to authenticate to ISA/TMG for a while but I guess I needed a touch of silliness to come up with the right search terms. Here’s my adaption of Wayne’s code:

$proxy= Read-Host “Proxy? Yes/No?”

if ($proxy -eq “yes”)
$user= $env:USERNAME
$webproxy = Read-Host “Proxy address? (like http://your.proxy.server:8080)”
$pwd = Read-Host “Password?” -AsSecureString
$proxy = New-Object system.Net.WebProxy
$proxy.Address = $webproxy
$account = new-object System.Net.NetworkCredential($user,[Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($pwd)), “”)
$proxy.credentials = $account

It’ll ask you if you want to use a proxy and if you do then it’ll ask you for a password (it uses the currently logged on user).

Some more code:


99 Bottles of Beer


This blog has been moved to: