Access Denied trying to change winrm configuration during provisioning

[simoneb]

Hi, after quite some time spent researching why I could not get to install .NET 4.5 as part of the provisioning, though it worked perfectly if I did the same directly on the guest, I figure out it requires increasing the available memory for winrm using the MaxMemoryPerShellMB setting. Now, when trying to do that I always get an error similar to this:

WSManFault
    Message = Access is denied.

Error number:  -2147024891 0x80070005
Access is denied.
An error occurred executing a remote WinRM command.

Shell: powershell
Command:               $old = Get-ExecutionPolicy;
              Set-ExecutionPolicy Unrestricted -force;
              c:\tmp\vagrant-shell.ps1;
              Set-ExecutionPolicy $old -force

Message: Command execution failed with an exit code of 1

Here's the command I'm trying to run:

c.vm.provision :shell, inline: 'cmd /c "winrm set winrm/config/winrs @{MaxMemoryPerShellMB=""1024""}"'

but I tried different options: inline, powershell script, different ways of changing that setting:

Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1024

and

Invoke-Command -ComputerName localhost { Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1024 }

I always get the same error.

Any idea?

[sneal]

The shell provisioner doesn't have true admin access on the box. The chef provisioner works around this by running Chef through a scheduled task that has 'run with highest privileges'.

I've been working on a vagrant-windows branch that runs all provisioners through an elevated shell, so commands that you run locally will run the same through vagrant-windows.

[simoneb]

Using a scheduled task is the workaround I'm investigating in fact. Also, if the installation is done via a scheduled task I would not even need to increase the winrm setting in the first place, but it's not the ideal way to provision the machine. I would rather use puppet, but for the time being that doesn't seem to be an option.
Any other idea about how to workaround this problem? All options I can think of are not very appealing, like having to repackage the box with .NET installed, or using another out-of-process mechanism like puppet librarian to do the provisioning.

[sneal]

You could workaround it using a PowerShell script based off this one. It handles creating the scheduled task, running it, and reporting back output.

If it were me I'd use vagrant-windows and vagrant-berkshelf with the dotnetframework cookbook running through the chef-solo provisioner. Its pretty simple.

[simoneb]

That's neat, but I guess I'll stick with the simpler scheduled task
approach for now.

Thanks

On Thu, Mar 6, 2014 at 2:50 AM, Shawn Neal notifications@github.com wrote:

You could workaround it using a PowerShell script based off this onehttps://github.com/WinRb/vagrant-windows/blob/run-all-provisioners-elevated/lib/vagrant-windows/scripts/elevated_shell.ps1.erb.
It handles creating the scheduled task, running it, and reporting back
output.

If it were me I'd use vagrant-windows and vagrant-berkshelf with the
dotnetframework https://github.com/daptiv/dotnetframework cookbook
running through the chef-solo provisioner. Its pretty simple.

Reply to this email directly or view it on GitHubhttps://github.com//issues/176#issuecomment-36816922
.