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");
Related
So, I import the System.Management.Automation dll and I'm trying to run a New-Mailbox command with params
so I use:
RunspaceConfiguration config = RunspaceConfiguration.Create();
PSSnapInException psEx = null;
config.AddPSSnapIn("Microsoft.Exchange.Management.PowerShell.E2010", out psEx);
That's all fine and dandy... but when I go to run the application I get the following:
Cannot load Windows PowerShell snap-in Microsoft.Exchange.Management.PowerShell.E2010 because of the following error: The type initializer for 'Microsoft.Exchange.Data.Directory.Globals' threw an exception.
So, I did some research online and found that I need to change from Any CPU to x86 as the platform target.
However, when I do that I get a HTTP Error 503. The service is unavailable. error
I am almost positive that I have to run it as a 32 bit process so that it can use the snapin (which from other reading seems to be what the snapin is running under)
I did change the app pool to Enable 32-bit Applications to True. Which is when I get the error.
I've read other posts... but, I'm not sure how to get past this Service unavailable thing.
I've tried using a x64 build and get Could not load file or assembly 'EmailAdminWeb2' or one of its dependencies. An attempt was made to load a program with an incorrect format.
You don't use this at all:
config.AddPSSnapIn("your snapin here", out psEx);
instead.... just use a connection as follows:
WSManConnectionInfo connectionInfo = new WSManConnectionInfo(new Uri("http://yourdomainhere/Powershell/Microsoft.Exchange"), "http://schemas.microsoft.com/powershell/Microsoft.Exchange", PsCreds);
Runspace runspace = RunspaceFactory.CreateRunspace(connectionInfo);
Now run your commands and you're good to go.
Quick notes:
Make sure you're app is targeting x64 not Any CPU or x86
If you're using .net 4.5 (or 4) make sure you're app pools are set properly (v4.0 not v2.0) and that you have Enable 32bit apps set to false
.Net 3.5
I've built into the service exe the ability for it to install itself using a -i feature. I have a custom installer class and am using a common technique on found online here. That installer class basically has it's own service and serviced process installer.
This code has worked well for a very long time. Finally ran into a Win 7 64 bit machine were it refuses to install.
Basically, the log shows it's installing the service and that succeeds. Then it tries to create an event log and that fails with
An exception occurred during the Install phase.
System.ComponentModel.Win32Exception: The specified service already
exists
I just got done having the OS completely reinstalled from scratch, first thing I did was try to install as a service, and it's the same error. Why is it thinking that event log is already there?
I've already read all the other posts and I've browsed my registry and there is nothing in there for my service or event log. I have full admin rights, when I try to open cmd as administrator, it doesn't even prompt me, so as far as I can tell, I am an admin (I can see that in my user profile).
I even added code to check to see if it found the EventLog using System.Diagnostics.EventLog.SourceExists which does report it found it, and so I added a call to System.Diagnostics.EventLog.DeleteEventSource but that doesn't help.
I even tried removing the EventLog installer from the ServiceInstaller, but then it starts failing for other reasons.
Any ideas?
Here is some sample code for an alternate installer I tried that I found here with the same results:
public partial class Service1Installer : Installer
{
public Service1Installer()
{
InitializeComponent();
ServiceProcessInstaller process = new ServiceProcessInstaller();
process.Account = ServiceAccount.LocalSystem;
ServiceInstaller serviceAdmin = new ServiceInstaller();
serviceAdmin.StartType = ServiceStartMode.Manual;
serviceAdmin.ServiceName = "Service1";
serviceAdmin.DisplayName = "Service1";
serviceAdmin.Description = "Service1";
Installers.Add(serviceAdmin);
Installers.Add(process );
}
}
uninstall your service
installutil /u yourproject.exe
restart your machine
http://msdn.microsoft.com/en-us/library/sd8zc8ha(v=vs.80).aspx
let me know if you still have a issue
Use installutil as #MicahArmantrout mentions, if the exe still resides on disk.
Otherwise, open a commandline as Administrator and execute: sc delete "my service name"
In the end, my problem was our internal installer. I commented it out and now just install the service from the command line and it now installs on 64 bit OS. Still don't know why it would work before on 32 bit.
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.
I have some trouble installing Management Studio 2008 Express through C#-Code.
The code looks like this:
using (Process MMSInstall = new Process())
{
var psi = new ProcessStartInfo(PathExe.FullName, "/qs /Features=SSMS /Action=Install");
MMSInstall.StartInfo = psi;
MMSInstall.Start();
MMSInstall.WaitForExit();
}
PathExe is a FileInfo-Instance.
But the installation always fails:
Exception type: Microsoft.SqlServer.Setup.Chainer.Workflow.NoopWorkflowException
Message:
No features were installed during the setup execution. The requested features may already be installed. Please review the summary.txt log for further details.
When installing via command prompt
C:\>SQLMANAGEMENTSTUDIO_X86_DEU.EXE /qs /Features=SSMS /Action=Install
everything works fine.
I looked through the logfiles (Detail.txt), and spottet a difference:
When running from the command prompt, 'Setting: MEDIALAYOUT' is set to 'Advanced' (pastebin.org/36222), when installing from my little C#-App it's set to 'Core' (pastebin.org/36221)
I tried to append /MEDIALAYOUT=Advanced to the ProcessStartInfo-Arguments in my code, but this options is ignored. I don't know what this parameter does, and I could not find any documentation about it.
Any ideas how to solve this or where to look for?
I am testing on Windows Vista Ultimate SP1
instead of calling the executable directly call %windir%\system32\cmd.exe
Cmd has a /C switch which allows you to pass in a command to run. So you'd pass in '/c "SQLMANAGEMENTSTUDIO_X86_DEU.EXE /qs /Features=SSMS /Action=Install"'
as a parameter.
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!