4

I am trying to create a setup package that not only installs our app but also copies files to a remote app server and installs a service there. I thought that I would just override the install method in a custom action to have it kick off a powershell script to copy the files. Unfortunately when the code calls the powershell script I get this CmdletProviderInvocationException:

The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

I was able to copy the code I am using to call the powershell script into a test project and it ran just fine, as I would expect since I have logged in to the server through windows explorer and so my user should be authenticated. I think the reason the script won't work when called by the installer must be that the installer switches users in order to get admin permissions to install the app, and the admin user is not authenticated (although I could be wrong).

Does anyone know how I could get this to work?

Here's the custom action code:

Runspace runspace = RunspaceFactory.CreateRunspace();
runspace.Open();

Pipeline pipeline = runspace.CreatePipeline();
string scriptLoc = "c:\\sampleLocation";
pipeline.Commands.AddScript("&\"" + scriptLoc + "\\script.ps1\"");

Collection<PSObject> results = pipeline.Invoke();

runspace.Close();

and here's the script:

$RemotePath = "\\SERVER\C$\Shared\Service"
$Source = "C:\sampleLocation\Service"

Get-ChildItem $Source -Recurse | Copy-Item -Destination $RemotePath
Rob Brenan
  • 85
  • 2
  • 7
  • On which operating system are you running your setup ? – JPBlanc Jul 19 '11 at 04:00
  • Should work on Windows 7 and/or Windows Server 2003 – Rob Brenan Jul 19 '11 at 13:22
  • I think I figured it out, but it's ugly. I have the custom action call a batch file: runas /netonly /user:DOMAIN\user "powershell &'C:\path\script.ps1'" It does prompt for the password, which means it's not totally automatic. I might look into SendKeys (I feel like I'm using duct tape and paper clips...) – Rob Brenan Jul 19 '11 at 16:48
  • As you are doing ugly things, you can just execute a powershell script that exec another one as another user. Doing so you can store the credentials crypted on the disk. – JPBlanc Jul 19 '11 at 18:44
  • any final solution about it ? – Kiquenet Nov 12 '12 at 08:06

2 Answers2

2

There are two major requirements for copying files to a network location:

  • your custom action should run without impersonation
  • the network location should have full permissions for Everyone

A MSI installation runs under the local system account. So it doesn't matter if you have permissions or not.

Since it's not easy to give permissions to SYSTEM account from a network machine, the easiest approach is to give full permissions to Everyone. This needs to be done on the machine which contains the shared folder.

Cosmin
  • 21,216
  • 5
  • 45
  • 60
0

According to @Cosmin Pirvu and Microsoft documentation :

The LocalSystem account is a predefined local account used by the service control manager. It has extensive privileges on the local computer, and acts as the computer on the network.

If your shared folder is on a computer that is on a domain, you can give full permissions to the client computer in spite giving it to Everyone.

enter image description here

JPBlanc
  • 70,406
  • 17
  • 130
  • 175