Is there a way to start / stop a windows service of a server in a different network
(not \\<server name>) from an asp.net page?
I tried using ServiceController but it's only work if it's in the same network.
RE: ServiceController How to Start/Stop a Windows Service from an ASP.NET app - Security issues
Anything you can do from command line or powershell can be ran from a page (assuming the app pool user has correct permissions etc)
https://serverfault.com/questions/429426/how-can-i-connect-to-a-windows-server-using-a-command-line-interface-cli
Run Command Prompt Commands
How To: Execute command line in C#, get STD OUT results
Powershell is probably your best bet for managing services on a remote server though this will require the server to allow remote powershell.
Calling Powershell from C# (ASP.NET) - pass custom object?
http://www.codeproject.com/Articles/18229/How-to-run-PowerShell-scripts-from-C
and of course for the topic of powershell resetting/stopping remote services.
http://www.powershellmagazine.com/2012/08/28/pstip-starting-and-stopping-services-on-remote-computers/
How to start/stop a service on a remote server using PowerShell - Windows 2008 & prompt for credentials?
Google is definitely your friend on this one :)
Related
I'm new using ASP.Net MVC, so i'm doing an auto-training in order to develop a web portal for an intranet that can receive request from users to deploy Virtual Machines from Azure, the request is received by an administrator who can run a script from the portal to create the Virtual Machine.
For example, The idea is to store the scripts in a database, so when the administrator do the action to create the "virtual Machine 01" (he have limited option of Virtual Machines configurations to create), the software run the script "01" store on the database.
That is possible? I hope I have explained the idea well.
Also, if that is possible, can I also show the possibles error messages is something wrong happened?.
Instead of using Powershell, why not manage it directly from your .NET code?
Azure provides API's that can be called from .NET.
http://azure.microsoft.com/en-us/documentation/api/
You'd probably want to look at their Compute Management API for handling virtual machines.
http://azure.microsoft.com/en-us/documentation/api/management-compute-sdk-net/
I am attempting to upgrade an existing system from Windows XP Professional / IIS 5.1 to Windows 7 Ultimate (32-bit) / IIS 7.5. The original system ran a classic ASP website (only available to the localhost) that used 'ASPExec' to launch desktop applications on the local machine (.bat, .cmd, .exe, etc). Under Windows 7 Ultimate / IIS 7.5, the applications fail to launch from the ASP page.
As tests (The end goal is not to launch notepad), I have tried:
<%
Set Executor = Server.CreateObject("ASPExec.Execute")
Executor.Application = "notepad.exe"
Executor.ShowWindow = True
strResult = Executor.ExecuteWinApp
%>
I have also tried:
<%
Set wshell = CreateObject("WScript.Shell")
wshell.run "notepad.exe"
Set wshell = Nothing
%>
Both methods will cause notepad.exe to show in the Windows Process list, but fail to launch the application on the desktop. This is true for any .exe I try to run, and .bat or .cmd files simply fail to do anything.
With IIS 5.1, the original author of the ASP application used the "Allow Service to Interact with the Desktop" option on the "IIS Admin" service and "World Wide Web Publishing" service to make this work. All issues aside with allowing desktop interactive services, IIS 7 no longer uses the "IIS Admin" service, so this is not an option.
I am looking for either a workaround from the Windows/IIS side or another option in ASP that might acheive the same desired end result.
You won't be able to do this with Windows 7/IIS 7.5. The reason this worked was because you were running IIS5.1. Back in the days of IIS5.0/5.1 you had three different process models:
In Process (or Low Isolation mode) - where every site ran inside the inetinfo.exe process
Pooled Process - sites ran in an external surrogate process inside COM+
Out of Process (or High Isolation mode) - where each site runs inside it's own COM+ process
Most likely your IIS5.1 instance is configured to run in "In Process" mode and under the SYSTEM account. Because you can configure the IIS service to interact with the desktop, and because your Classic ASP script is being executed inside this process it is able to launch executables and they appear on the desktop.
In IIS7 life is different. Your code will run inside an application pool process which is spun up on demand. There is no way to configure pool processes (w3wp.exe) and allow them to interact with the desktop, even if running under the local system account.
Also unlike IIS6 you can't configure IIS7 to behave as if it's IIS5; IIS7 is a bottom up rewrite with a new architecture.
A possible workaround would be to write a simple WCF service with a HTTP endpoint that starts when the user logs on (hosted in a Windows app that hides or minimises itself to the notification area). You could then make calls to this service from your Classic ASP code using something like MSXML2.ServerXMLHttp and get the WCF service to launch these processes on your behalf.
This archived copy of chapter 29 of Keith Brown's "The .NET Developers Guide to Windows Security" explains the machinations involved in getting a service application to interact with the desktop:
The .NET Developers Guide to Windows Security - chapter 29 - How to Display a User Interface from a Daemon (source: archive.org)
Quote:
Option one is to get yourself into the interactive window station, and
option two is to have a process already in the interactive window
station display a UI for you.
An easy way to put a daemon in the interactive window station
(WinSta0) so it can have its own user interface is to package it as a
service that runs as SYSTEM and check the box that says, "Allow
service to interact with the desktop." This tells the SCM to launch
your service process in the SYSTEM logon session (WhatIsALogonSession)
and to attach your process to WinSta0 instead of the noninteractive
window station in which the SYSTEM daemons normally run,
Service-0x0-0x3e7$.
This is what you probably have already on your XP box. But as I explained, there is no way to configure worker processes to do this because you can't configure the "Allow service to interact with the desktop." flag, even though you can configure a pool to run as the local SYSTEM account. When the book was written this applied to Windows 2000/2003. With the advent of Windows Vista/2008 and onwards you have the added complication of UAC and getting past that as well.
What you should consider instead is option two: Use two processes
instead of just one. One process must be launched in the interactive
user's logon session and WinSta0. It should contain all the user
interface elements you need, and it can connect to your daemon process
using any secure form of interprocess communication you're comfortable
with
This is essentially what I've suggested.
I have an ASP.NET application on Windows 2008 R2 (.NET Framework 4.0, IIS 7.5) and I want to run a console application when I click a button on a web page. Here is the code:
protected void btnUpdate_Click(object sender, EventArgs e)
{
string fileLocation = #"D:\DTDocs\App_Code\LoadDTDocsXML.exe";
ProcessStartInfo oStartInfo = new ProcessStartInfo();
oStartInfo.FileName = fileLocation;
oStartInfo.UseShellExecute = false;
Process.Start(oStartInfo);
}
When I run ASP.NET application from within Visual Studio 2010 (with its internal IIS), the console application run Ok. But when I run the ASP.NET application outside the VS 2010, I haven't an error but the console application doesn't make his job (it must create an xml file on the disk).
I think the problem is the configuration of IIS 7.5, I don't know exact to which account I must give access rights to the folders involved in my console application.
In IIS 7.5, I set Physical Path Credential for Specific User = my windows account, but that not solve the problem.
Thanks.
Just to add to the other 2 answers - Do you really need to run an exe from your webserver?
I've had to do it in the past and it's almost always the option of last resort - It weakens your security considerably (Now all someone has to do to run executables on your system is find a single flaw in your code) and has a whole host of other problems (the webserver isn't "logged on" to the server so it doesn't have a desktop, impersonation is a real pain in the a$$ to get working properly (assuming you're going to run the executable with different permissions to the webserver), etc.
If there's any other way to accomplish your goal, it'll almost certainly be simpler.
An option we went for was to have a new app with a WCF endpoint that the webserver can communicate with. So, when someone pushes the button, the WS call's our app via WCF and tells it to run various commands. This way, you've got:
Clean seperation between web and console code.
A dodgy console app won't take down the webserver & vice-versa
If the console app is long-running, this allows you to stagger your releases for website/console app so that you don't kill the app mid-execution just because you need up upodate some CSS and publish.
Huge security benefits - web server can't run executables even if compromised.
The WCF app will be able to closely examine requests to decide if they're valid before execution.
Be aware that however you do it, if someone malicious works out what's going on and can kick off the process, they could probably DoS you with almost zero effort - Make sure that this method is locked down TIGHT.
Edit: having read your comments above, I think you're hitting the "desktop" issue. When launching an executable from the server, the app will never be visible to the logged on user as the logged on user's desktop isn't accessible from IIS and vice-versa. This is very similar to the issue of having a GUI on a windows service.
This may also be of interest.
the first problem I see is security/file access. when running from within VS the server and client are the same machine under your credentials. when run in testing/production environment the server and client are physically different machines and IIS will run the website under restricted permissions. therefore there is a very good chance that IIS cannot access the file at D:... because of security.
the next issue is running a console app from the website. console is another form of UI just like html and a WPF. personally I wouldn't execute the console from the web (unless there was no other choice). I would integrate the API into the web application. 2 UIs sharing the same logic.
ASP.NET Dev Server runs under credentials of current user (it's you).
IIS 7.5 runs ASP.NET applications under user specified in application pool settings -- usually ApplicationPoolIdentity (to which you can refer as user "IIS AppPool\[ApplicationPoolName]", when configuring file permissions). You can also change it to "Network Service" (Default value in IIS 7.0).
Please check, which identity is configured for your application pool, and give this user required permissions.
What is the right approach when users (authenticated domain admins) should be able to start batch jobs (usually exe files) from an IIS (7.x) aspx (c#) page? This is an intranet site. The batch jobs have to run on the web server as Domain Admins. The website pool is executed by network service or some similar restricted account in AD.
Approaches I can think of (and their disadvantages):
1. Start exe file with System.Diagnostics.Process.Start with another account. This feature is disabled in IIS 7.x, how do I allow it?
2. Create a sheduled task and call scheduled task-api. This unmanaged dll is giving VS compiler warnings because it's unsafe to call from managed code.
3. I suppose there's a better approach, because the previous suggestions doesn't appear safe or robust.
I would suggest that you have either a Scheduled Task or Windows Service that polls a common storage repository to see if a batch job should be run - as batch jobs are typically used for long running process.
Your could persist the deatils of which batch file and arguments you want to run from your ASP.NET website into a database (MySQL, Oracle, SQL Server, etc) and then have your Windows Service / Scheduled Task poll against this database at regular intervals.
I agree with Kane. However, if you must do...
http://www.dotnetscraps.com/dotnetscraps/post/Run-a-batch-file-as-a-specific-User-(or-Administrator)-from-ASPNET.aspx
If I have a asp.net web app on a windows box (obviously!), and I need to execute a shell script that is on a linux server, is that possible?
How can I do this safely?
To build on what cxfx has said above your best bet might be to set up a web server on the linux box, and build a web service using, for example, php.
php allows you to run shell scripts - so by calling a web page runscript.php and then using exec (http://php.net/manual/en/function.exec.php) you could run the script.
Security is a consideration - you could restrict access to the linux web server purely to the IP address of the server hosting your asp.net site?
Hope that helps.
One way of doing it is by logging through ssh. You can use the granados C# library for it. This will let you run arbitrary commands. If what you need is to always run the same command, you can take a different approach like a CGI script (hide it with at least HTTPS and user/password).
Your best bet might be to expose the triggering of the shell script through some sort of web interface, like a secure web service.