Can't run PSExec in a DSC Configuration

DSC
1

I’m trying to build a DSC script to install Visual Studio from a network installation. As this involves running an executable across a network share I am using PSExec -s to run it as System.
It’s not working, it just hangs and never completes.
You can see the PSExec is running on the target node, but you can leave it all night and it still won’t complete, it never calls the command it is supposed to run.
I am running the script as a user that is in the Administrator group on the target node.
I have cut the script right back to the bare minimum for testing, just trying to run a batch file on the target node via PSExec, and even that is not working.

Configuration testpsexec
{
    param($ComputerName)
    Node $ComputerName
    {
        Script InstallVisualStudio 
        {
            GetScript = { return $false }
            TestScript = { return $false }
            SetScript = { 
                Write-Verbose "STARTING"
                & psexec.exe -s C:\Temp\this.bat
                Write-Verbose "DONE"
            }
        }
    } # End Node
}

When this script is run I see the write-verbose message of STARTING, but then it hangs.
My gut feeling is a permissions issue somewhere, but I just fail to see where.
Any suggestions?
Simon.

2

Maybe I’m not following? It doesn’t matter what account you use to run the configuration script. That just produces a MOF; the MOF is run by the LCM, which runs under System, which doesn’t have non-local permissions.

3

Also
If I run “psexec.exe -s \$TargetNode C:\Temp\this.bat” from the same machine I am running DSC from, it works fine.
If I remote into the target node and run “psexec.exe -s C:\Temp\this.bat” it runs fine.

4

I’d expect both of those to work. You’re using your Admin credential in both cases.

5

In my test script above I have taken the non-local element out of the equation, and just trying to get psexec to run from a mof, but it hangs. Is it not possible to do this?

Or is there an alternate way that I can run a DSC script that can execute an installer over a network share? Am I barking up the wrong tree with psexec ?

6

It might be that PSExec doesn’t like being called by an anonymous caller. Even if you just run it locally, it’s running under System, which doesn’t present a credential to PSExec.

And I’m gonna get nit picky about terminology - you don’t “run a DSC script;” you deploy a MOF. The LCM reads the MOF, and calls on Resources to implement what the MOF says. The Resources are the executable code; the MOF is just states directions. But this nit-picky terminology is important, because it outlines how DSC “wants” to work, and right now you’re a bit at cross-purposes.

First, the Script resource type is just really limited. If you built out a full script resource, your code would look almost the same, but you’d (in v5) get a free Credential setting on the resource. PowerShell manages that for you, and would let you specify a credential in the MOF. The resource would thus run under that credential, not under System. So your Configuration script (which produces the MOF) would specify… I dunno, a target machine, the batch filename, and a credential. The Resource would take that, and then run PSExec under that credential. Again, in v5. In v4, you’d have to code up the credential input yourself, which is harder.

Second, I guess I don’t understand the ultimate thing you’re trying to do. You’re applying a MOF to Machine A, which is then running an executable on Machine B, right? Why not just deploy the MOF directly to Machine B? Or, if you have to do this “proxy configuration” approach, have Machine A use PowerShell Remoting rather than PSExec.

7

Don
Thanks for getting nit-picky, I am new to DSC so it does help me understand it all a bit better.
I guess, getting back to my actual goal. I have a network install for Visual Studio on Server X, so when I want to install VS on Machine A I have to (according to Microsoft) run from Machine A the installer on Server X via a network share i.e. “\ServerX\VSShare\vs_professional.exe /Params”
That is the ultimate goal.
Trying to use Invoke-Command or run the exe directly from powershell (the mof file) fails with permissions issues no matter what I try, and I read somewhere that running an installer over a network share like that would require it run as System.
Getting Invoke-Command to run as system seemed a hack of a work-around using scheduled tasks! but PSExec -s could be run on Machine A, run locally and not targeting a remote machine, and would run as system an allow the installer to execute?
Does that make sense?
Am I over-complicating it?

8

So Don,
Thinking about your explanation of the way DSC works. Once the mof file is deployed, the LCM executes it as System anyway. So therefore my use of psexec to run a command as System is pointless, it is going to run as system anyway if I don’t provide it with other credentials.
Am I reading that correctly?
BTW we’re on v4 still.

9

Yeah. And System couldn’t reach your UNC.

So maybe this is worth a higher-level discussion. Microsoft is, in fits and starts, trying to move toward a simpler software packaging mechanism. More like RPM or YUM on Linux - that’s what PowerShell Package Manager is, and it exists in v5 and will be made available for v3 and v4.

For better or for worse, DSC is going to work best with those kinds of packages. Right now, pending someone coming up with something, DSC ranges from awkward to poor with more traditional installers. If it’s a pure Windows Installer, it can do OK, but you need to copy the package source locally first (and the File resource supports a Credential parameter to enable that). If you’ve got some mega-installer that just WANTS to be run from a central location, it’s going to be an awkward fit for DSC, at best.

Keep in mind that DSC is really geared for server workloads right now - detailed installer scenarios are more a client workload, and DSC hasn’t had much investment there right now. DSC isn’t a software distribution mechanism, so you’re working a bit outside its current scope. Worse, and going out on a limb a bit, you might find that the installer insists on having a user profile context. It would need that to create Start menu shortcuts and whatnot, so it’s really common for user applications - but the LCM doesn’t have a user context. So the installation may just not succeed.

You’re just straddling a line that Microsoft hasn’t crossed yet. You’re trying to install a nonstandard installer, from a UNC, on a client - all of which are things DSC just hasn’t envisioned, yet. It’s not to say that they won’t get it right someday, but right now, they haven’t. So you’re potentially going to spend a lot of time hacking away at something just to make it work, because right now it’s not entirely in the technology’s scope.

Bottom line, the LCM runs as System, with no user profile loaded. You can’t change that. That right there is going to nix a lot of client software installs.

10

Don

That’s awesome, thanks, now I understand a little more of the limitations and capabilities of the system I am working with - even if they are not what I wanted them to be.

I guess I can use the File resource then to copy it locally and then execute the installer with a specific user profile, or even do a web install with Chocolatey, though I was hoping to avoid either of those options.

Thanks for all your help
Simon.

11

Chocolatey would be the way forward. That’s what PPM is based on, in part.