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
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.
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.
Related
I am setting or reading reg key from a windows services which runs as local system.
But when I read or set the values in the Registry Editor they are not the same as when i read and set them from the windows services.
If I execute the following command in powershell from the windows services or when i am logged in as a user the results differ as well. Why? Is there a different LocalMachine for a LocalSystem account?
$DefaultUserName = (Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "DefaultUserName").DefaultUserName
Write-Host $DefaultUserName
I am using the following c# lines to execute the powershell script from the windows service:
var process = new Process();
process.StartInfo.UseShellExecute = false;
process.StartInfo.FileName = #"C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe";
process.StartInfo.Arguments = "\"&'" + cacheFile + "'\"";
process.StartInfo.Verb = "runas";
process.Start();
You need to be careful of bitness. On 64-bit Windows, 32-bit applications run using the 'Windows on Windows' subsystem, which by default uses different filesystem paths and registry paths. You are executing powershell from the SysWOW64 folder, which means you are executing the 32-bit version, which will use the 32-bit registry hive.
If you open up regedit, the 32-bit hive for your registry key is: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Winlogon. I suspect you are getting/setting this value.
Please refer to How to access a 64Bit Registry key using 32Bit Powershell without Redirection to WOW6432Node for strategies you can take, including using the Sysnative rather than SysWOW64 version of powershell.
If you need to support 32-bit and 64-bit operating systems, you will need to make sure you are using the appropriate technique.
This answer has beautiful explanation of Windows built in accounts :
The difference between the 'Local System' account and the 'Network Service' account?
A limited service account that is very similar to Network Service and meant to run standard least-privileged services. However, unlike Network Service it accesses the network as an Anonymous user
Completely trusted account, more so than the administrator account. There is nothing on a single box that this account cannot do, and it has the right to access the network as the machine (this requires Active Directory and granting the machine account permissions to something)
Also can you try running the service as SYSTEM?
I have written a Console application that makes an HTTP POST to a ASMX Web Service (within Sharepoint) that I am looking to invoke remotely with WinRM. I have written a PowerShell process that bundles up the built application, moves it to the destination server, and executes it locally. The process works completely fine (ie moving copying, what-have-you), but fails when it gets to the Web Service call. Looking at logs on Fiddler, the HTTP Post request has no credentials in it at all, even though the application is being ran with an account that has all the proper permissions.
Since the application is moved to the destination server locally, I can run it locally, which I have done, and it works completely fine, as the Fiddler logs show the correct credentials in the header.
I am not sure where the issue resides, but I am having a hard time thinking its my code, since it works fine when ran locally. It may be with the WinRM process, but the exact same process works for other environments (this project is part of a larger deployment solution that deploys databases, ssis packages , etc).
I am happy to provide code of certain pieces if needed, and any basic troubleshooting advice would be greatly appreciated.
EDIT
The user credentials I specify in a xml file that contains the username and a hashed password, like this in Powershell
powershell.exe -version 3.0 -ExecutionPolicy RemoteSigned -command "& { $cred=Import-Clixml '%CREDENTIAL_FILENAME%' ; $cred.Password=ConvertTo-SecureString $cred.Password ; $Credential=New-Object System.Management.Automation.PsCredential($cred.UserName, $cred.Password) ; invoke-command -computername %MACHINE% -filepath %Result% -Credential $Credential }"
I am trying to run EMC commands in C#. I am running this from my personal PC that has exchange management tools installed on it.
Our exchange servers have 2007 running on them.
The thing is, when I run Powershell or EMC, I need to run as a different user that has exchange server 2007 permissions since my individual profile doesn't have these permissions.
That being said, this is my code I have running on my personal PC:
RunspaceConfiguration config = RunspaceConfiguration.Create();
PSSnapInException snapEx = null;
PSSnapInInfo info = config.AddPSSnapIn("Microsoft.Exchange.Management.Powershell.Admin", out snapEx);
Runspace runspace = RunspaceFactory.CreateRunspace(config);
runspace.Open();
Command createCMD = new Command("Get-Mailbox ID");
Pipeline pipe = runspace.CreatePipeline();
pipe.Commands.Add(createCMD);
Collection<PSObject> results = pipe.Invoke();
The error I am getting is:
The Windows PowerShell snap-in Microsoft.Exchange.Management.Powershell.Admin is not installed on this computer.
I am getting it when I try and add the Microsoft.Exchange.Management.Powershell.Admin snapIn.
I feel this has something to do with my permissions on my individual profile, but I am not entirely sure. If it is true, how do I fix this.
EDIT
The reason I say it sounds like permissions is because I am able to open powershell and add the snapin. However when I run a command such as get-mailboxstatistics myUserId it throws an error saying MyServer\MyStorageGroup does not exist. However, when I shift-rightCLick and run as different user and use the credentials of my exchange admin account, I am able to run these commands.
If an error says it is not installed on your computer, why do you suspect it has something to do with permissions?
As this post suggests, please check if you have installed the 2007 version of the tools, as the Snapin in question is not available on the 2010 version.
Try the following steps:
Open up a powershell editor of your choice and add the PSSnapin there. If it works, the Snapin is available, if not, it is really not installed on your machine.
If it is available try to set your build configuration from x86 to 64bit or vice versa.
Eventually you can install the .dll in question by hand. Referring to this answer from Keith hill you have to issue the following Powershell commands
$snapinPath = 'Microsoft.Exchange.Management.PowerShell.Admin.dll'
C:\Windows\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe /i $snapinPath
Errors like this are often a 32 bit/64 bit problem. For example, the snapin might be registered as a 32 bit and your C# program is 64 bit or vice versa.
Sometimes you can fix this by running the other version of InstallUtil, e.g.
$snapinPath = 'Microsoft.Exchange.Management.PowerShell.Admin.dll'
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\InstallUtil.exe /i $snapinPath
After fixing that, I think you'll hit another problem with how you're creating the command. You don't specify arguments when creating a command. Instead, you write something like:
Command createCMD = new Command("Get-Mailbox");
createCMD.Parameters.Add(null, "ID");
I am attempting to remotely call an executable on a target machine, with the executable located on a UNC network path. I am using the Win32_Process.Create method to do this. I am able to use this method to launch files that are stored locally on the C: drive, but I get Return Value 2, Access Denied, when I try to launch the file from a UNC path. I am confident the path is correct, because if I alter it to a bogus path, I get Return Value 9, Path Not Found.
In Powershell I am using invoke-wmimethod to call the Create method of Win32_Process and passing a credential object that has administrative rights on the target system and read rights on the UNC path. In C# I am impersonating using ConnectionOptions with the same credentials. The results are the same in both cases.
I have also tried using various methods (CIM_DataFile, remotely invoking XCopy) to copy the EXE file locally first. None of these methods have worked. I want to copy directly from a file server, to a target system, without pulling the file to the application server first, because the application server is not in the same datacenter as most target systems and as such would be pulling a large file down over the WAN twice, which is slow and less reliable. One option I have found is to use FTP, but I consider that a last resort.
I can also remotely invoke the EXE from the UNC path using PSExec and the same credentials, but I want to avoid shelling out from my web application to call PSExec. I know it will work if that's what I have to do, and I have used PSExec many times to solve problems like this, but I really want to do this all within the application and not hacking around it using an external program.
Is there any way I can use Win32_Process to launch an EXE on a remote machine, when that EXE is located on a UNC path? Could this be a Group Policy issue wherein the process launched by WMI does not have permission to invoke an EXE from a network location? I am out of ideas and out of search terms.
Powershell code examples. This works:
$launchproc = Invoke-WmiMethod -ComputerName $compName -Class Win32_process -Name Create -ArgumentList "c:\temp\installer.exe /s /f1c:\temp\installer.iss" #-Credential $adminCreds
This does not:
$launchproc = Invoke-WmiMethod -ComputerName $compName -Class Win32_process -Name Create -ArgumentList "\\fileserver\share\installer.exe /s /f1\\fileserver\share\installer.iss" -Credential $adminCreds
Note that if I issue the command locally from a command window, interactively, the UNC based command DOES work just fine. The funny syntax is an artifact of InstallShield's silent install switches. Also note that if I double-backslash or backtick escape the backslashes, I get Path Not Found, so I don't think it's an escaping issue.
Edit: while not exactly the same problem, I did check the GP rights described here: WMI Win32_Process.Create fails with Insufficient Privs and I do have those rights set correctly.
Edit #2: I found someone else having a similar problem:
Win32_Process Create method. Trying to copy a file from a remote machine to a remote machine Again it's a batch file-ish hack launching Net Use on the remote system. Is this my only real option?
In the end, I just called PsExec using System.Diagnostics.Process() in C#. It's not the solution I wanted, but I wasn't able to make anything else work, and while I don't like shelling out to an external EXE, it does end up being relatively straightforward.
I asked some of the PowerShell MVPs who are more knowledgeable in WMI and got the response that unless the remote machine was the domain controller you won't be able to do it. However, if you could use PowerShell remoting to remote to the computer with -Authentication CredSSP, then you could use Invoke-WmiMethod with the network path. Richard Siddaway did a write up on this that might be useful to peruse.
I'm able to successfully uninstall a third-party application via the command line and via a custom Inno Setup installer.
Command line Execution:
MSIEXEC.exe /x {14D74337-01C2-4F8F-B44B-67FC613E5B1F} /qn
Inno Setup Command:
[Run]
Filename: msiexec.exe; Flags: runhidden waituntilterminated;
Parameters: "/x {{14D74337-01C2-4F8F-B44B-67FC613E5B1F} /qn";
StatusMsg: "Uninstalling Service...";
I am also able to uninstall the application programmatically when executing the following C# code in debug mode.
C# Code:
string fileName = "MSIEXEC.exe";
string arguments = "/x {14D74337-01C2-4F8F-B44B-67FC613E5B1F} /qn";
ProcessStartInfo psi = new ProcessStartInfo(fileName, arguments)
{
CreateNoWindow = true,
UseShellExecute = false,
RedirectStandardOutput = true
};
Process process = Process.Start(psi);
string errorMsg = process.StandardOutput.ReadToEnd();
process.WaitForExit();
The same C# code, however, produces the following failure output when run as a compiled, deployed Windows Service:
"This action is only valid for products that are currently installed."
Additional Comments:
The Windows Service which is issuing
the uninstall command is running on
the same machine as the code being
tested in Debug Mode. The Windows
Service is running/logged on as the
Local system account.
I have consulted my application logs
and I have validated that the
executed command arguments are thhe
same in both debug and release mode.
I have consulted the Event Viewer
but it doesn't offer any clues.
Thoughts? Any help would be greatly appreciated. Thanks.
Step 1: Check the MSI error log files
I'm suspicious that your problem is due to running as LocalSystem.
The Local System account is not the same as a normal user account which happens to have admin rights. It has no access to the network, and its interaction with the registry and file system is quite different.
From memory any requests to read/write to your 'home directory' or HKCU under the registry actually go into either the default user profile, or in the case of temp dirs, c:\windows\temp
I've come across similar problems in the past with installation, a customer was using the SYSTEM account to install and this was causing all sorts of permission problems for non-administrative users.
MSI log files aren't really going to help if the application doesn't appear "installed", I'd suggest starting with capturing the output of MSIINV.EXE under the system account, that will get you an "Inventory" of the currently installed programs (or what that user sees installed) http://blogs.msdn.com/brada/archive/2005/06/24/432209.aspx
I think you probably need to go back to the drawing board and see if you really need the windows service to do the uninstall. You'll probably come across all sorts of Vista UAC issues if you haven't already...
Thanks to those offering help. This appears to be a permissions issue. I have updated my service to run under an Administrator account and it was able to successfully uninstall the third-party application. To Orion's point, though the Local System account is a powerful account that has full access to the system -- http://technet.microsoft.com/en-us/library/cc782435.aspx -- it doesn't seem to have the necessary rights to perform the uninstall.
[See additional comments for full story regarding the LocalSystem being able to uninstall application for which it installed.]
This is bizarre. LocalSystem definitely has the privileges to install applications (that's how Windows Update and software deployment in Active Directory work), so it should be able to uninstall as well.
Perhaps the application is initially installed per-user instead of per-machine?
#Paul Lalonde
The app's installer is wrapped within a custom InnoSetup Installer. The InnoSetup installer, in turn, is manually executed by the logged in user. That said, the uninstall is trigged by a service running under the Local System account.
Apparently, you were on to something. I put together a quick test which had the service running under the LocalSystem account install as well as uninstall the application and everything worked flawlessly. You were correct. The LocalSystem account has required uninstall permissions for applications in which it installs. You saved the day. Thanks for the feedback!