Im hosting an asp.net application in IIS8 on windows server 2012.
this application suppose to execute an batch file.
it works perfect if i execute the application with visual studio in debug mode. but when i upload it to the IIS the application cant execute the batch file.
i tried to change the batch file with exe file. same problem.
the batch file suppose to execute from the application(WCF application) that in the IIS:
System.Diagnostics.Process proc = new System.Diagnostics.Process();
proc.StartInfo.WorkingDirectory = #"C:\path";
proc.StartInfo.FileName = #"C:\path\executer.bat";
proc.Start();
proc.Close();
please help,
Most likely the problem you are experiencing is due to permissions. You need to check what account the IIS Application Pool that your app is running under is configured for and whether that account has rights to run your batch file or the commands within that batch file.
When running in Visual Studio you're likely running IIS Express as the interactive user.
When running under IIS by default you're running under ApplicationPoolUser identity which has no rights to execute code, has no file access or anything else. Unless you've explicitly set a different account with appropriate file access rights to the batch file, and rights to execute the commands inside of the batch file, you won't be able to run the batch file from within IIS. To change that change the Application Pool user identity to a user that does have rights to both read and execute the batch file on disk and has any rights required to run what's executing in the batch file.
Make sure any folder or file accessed by your application have permissions granted to the AppPoolUser account. It is also important to check your applications resource folders too. For example, if you are writing logs, make sure you give the appPool user account enough permission to write to that file.
Your code is working fine . May be there is some issue in batch file i faced before .My batch file is
start "" BATCHLOG.exe
where BATCHLOG.exe is the executable
Some times batchfile named only
BATCHLOG.exe
does not work correctly on windows scheduler so may be in that case of yours
Related
I just registered at AWS services (micro, free) and trying to deploy asp.net mvc 4 application.
Everything is working fine, web application deployed and running (the web part, database, etc), but when i am trying to write to filesystem (for example, when i`m saving a file), i'm gettig an exception
System.UnauthorizedAccessException: Access to the path
'C:\inetpub\wwwroot.logs\xxx.log
The folder "C:\inetpub\wwwroot\.logs" exists.
I tried to grant a permission to folder to DefaultAppPool using commands.
I have following web project structure:
WebHost
.ebextensions
aws.config
aws.cofig has following content:
container_commands:
01-logscreate:
command: "mkdir C:\inetpub\wwwroot\.logs > create-logs.log"
cwd: "C:/inetpub/wwwroot/.ebextensions"
01-logspermission:
command: "icacls \"C:/inetpub/wwwroot/.logs\" /grant DefaultAppPool:(OI) (CI) > p-logs.log"
cwd: "C:/inetpub/wwwroot/.ebextensions"
When i accessing the file, i resolving the full path using
HostingEnvironment.MapPath("~/.logs/xxx.log")
But when i trying to write to this file, a get an exception.
Relative path of '.ebextensions' in deployment package is
Content\D_C.git\udsmonitoring.app\WebHost\obj\Debug\Package\PackageTmp\.ebextensions
Thanx in advance
The app pool that gets deployed runs with limited permissions. It doesn't have access to write to that directory.
Further, you really shouldn't need to be writing logs to the instance file system itself. These instances are transient. If you need a logging solution, consider using CloudWatch or LogEntries. Both probably fit into your existing code base with only a config file change required. In general, if what you're doing ends up with you needing to remote into the EC2 instance to do or see something, consider taking an alternate approach.
Finally, if you really do have a need to write to that directory from within the context of your app, you can add a command in your ebextensions that uses appcmd to set the app pool identity to one with greater privileges...or have a command that sets the directory permissions explicitly.
I have a .NET console application written in C# (myApp.exe), that runs an external application ('bob.exe'). The console application works great when I run myApp.exe manually. The C# code that calls the application is:
System.Diagnostics.ProcessStartInfo procStartInfo =
new System.Diagnostics.ProcessStartInfo("C:\\bob.exe");
procStartInfo.RedirectStandardOutput = true;
procStartInfo.UseShellExecute = false;
// Do not create the black window.
procStartInfo.CreateNoWindow = true;
// Create the process and assign its ProcessStartInfo and start it
System.Diagnostics.Process proc = new System.Diagnostics.Process();
proc.StartInfo = procStartInfo;
proc.Start();
In Windows Server 2003, I created a Scheduled Task that executed 'myApp.exe' on a regular basis. It was set to execute even if the user was not logged in. The Scheduled Task worked and called 'bob.exe' (I was able to verify this by viewing the output files from 'bob.exe')
We then upgraded to Windows Server 2012. I created a Scheduled Task in Windows Server 2012, setting it to execute even if the user was not logged in and configuring it for Windows Server 2003.
I set the Action to call 'C:\myApp.exe', similar to how I had it set up in Windows Server 2003
When the scheduled tasks executes and I am logged in, the 'bob.exe' application is executed from 'myApp.exe'. However, when I am not logged in and the scheduled task executes, 'myApp.exe' is executed but 'bob.exe' is never executed (I can verify this by seeing there are no output files from 'bob.exe'). There are no errors reported by the Scheduled Task and the Last Run Result says "The operation completed successfully. (0x0)".
I found a similar post here but I was unable to resolve my situation. What am I missing?
I had a similar issue with my app calling out 7za.exe to archive db backups. When I ran my app manually it worked fine, but when I scheduled my app via Task Scheduler, the 7z routine would not fire off and didn't give my app a verbose error. I found that adding the directory I ran my app from to the task scheduler's Start in (optional): box corrected my issue.
Program/script: "C:\Program Files (x86)\CustApp\CustApp.exe"
Start in (optional) C:\Program Files (x86)\CustApp\
Note not to use double-quotes on the "Start in (optional)" setting for the directory, it errors when I did.
I had a similar problem with running a Batch file (on WS2008) and the problem was due to the permissions given to the user executing the scheduled task on the folders where the Batch file and the Executable files were set.
I'm not sure if the security of WS 2012 is different, but if I were You I'll try to debug the application (if you have the code) checking for permissions.
HTH
I have programmed a Windows Service that is calling another service over the network.
The other service's IP is defined in the hosts file.
The Windows Service is running as local system.
On Windows Server 2008 this works fine. The IP from the hosts file is used.
On Windows 7, the IP from the hosts file is not used. Instead it uses normal DNS.
If I use a normal user instead of local system, the behaviour is correct. The same as on Windows Server 2008. The host file is used.
I can reliably switch between local system and a normal user for the same service binary without touching the hosts file, the error is reproducable. So it's not about caching anything anywhere or having a wrong hosts file.
Is there anything in Windows 7 I missed? Why would a service running as local system not use the hosts file?
The reason why it works as normal user could be this: you could have a duplicate hosts file in %LOCALAPPDATA%\VirtualStore, which is a redirection folder for programs running as non-admin and trying to write to system locations. If this is the case, then you actually see wrong hosts file when you think you edit the system's one!
The other reason could be wrong permissions set to file. Please try point 5 from https://serverfault.com/a/452269
First close other runnings applications and have a look at your system logs
You can run anything as system to debug like explorer.exe or cmd.exe
with the folowing command using PSTools you could then browser your hosts and check it
psexec -i -s cmd.exe
psexec -i -s ping your.host
Avoid multiple entry for the same host on hosts file
Even if you talked about it i post some debug commands
ipconfig /flushdns
nbtstat -R (reset netbios)
You can check DNS Cache
ipconfig /displaydns | more
Windows set the hosts file location with this registry key
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DataBasePath
Check proxy config it could bypass hosts
Check "etc" directory permission and "hosts" file permission
I have a batch file that I have been using to install my C# Windows Services for awhile now, never had a problem until Windows 7. I have attempted to run the batch file with Administrator privileges. I have attempted to run the command prompt with admin privs, navigate to the windows service EXE and run InstallUtil there. Still doesn't work.
After reading some other suggestions I tried moving my files out of the /bin folder and running them from another location but that also didn't work.
The batch file looks like this
#ECHO OFF
REM The following directory is for .NET 2.0
set DOTNETFX2=%SystemRoot%\Microsoft.NET\Framework\v2.0.50727
set PATH=%PATH%;%DOTNETFX2%
echo Installing IEPPAMS Win Service...
echo ---------------------------------------------------
InstallUtil /i IEPPAMS_WinService1.exe
echo ---------------------------------------------------
echo Done.
and I have a install log file that I dump info to. If I just double click the .bat file I get
Running a transacted installation.
Beginning the Install phase of the
installation. See the contents of the
log file for the
C:\Users\Justin\Desktop\service
test\IEPPAMS_WinService1.exe
assembly's progress. The file is
located at
C:\Users\Justin\Desktop\service
test\IEPPAMS_WinService1.InstallLog.
An exception occurred during the
Install phase.
System.InvalidOperationException:
Cannot open Service Control Manager on
computer '.'. This operation might
require other privileges. The inner
exception
System.ComponentModel.Win32Exception
was thrown with the following error
message: Access is denied.
The Rollback phase of the installation
is beginning. See the contents of the
log file for the
C:\Users\Justin\Desktop\service
test\IEPPAMS_WinService1.exe
assembly's progress. The file is
located at
C:\Users\Justin\Desktop\service
test\IEPPAMS_WinService1.InstallLog.
The Rollback phase completed
successfully.
The transacted install has completed.
When I run the .bat file with admin privileges nothing is written to the log file, and the service is still not installed.
Any thoughts? Is there a new way to install services in Windows 7?
Right click on the batch file and run it as Administrator.
You are most likely running into battle with the new security model (User Account Control) from Windows Vista and Windows 7. Even if you are running as an account that has Admin rights you will still need to elevate to do some (most) administrative activities. (Yes it is possible to disable this feature, but don't)
UAC (MSDN)
UAC (Wikipedia)
InstallUtil (MSDN)
Edit... The correct commandline is InstallUtil YourApp.exe. The /i does not look to be a vaild switch for InstallUtil.
So I was able to fix the problem by typing in the command line the entire path to InstallUtil and it worked. So after navigating to the folder that had my EXE I typed the following:
C:\Windows\Microsoft.NET\Framework\v4.0.21006\installutil.exe
IEPPAMS_WinService1.exe
Not sure why I have to do that in Windows 7 now when I never had to in XP, but oh well. Thanks for all the suggestions!
When I run the .bat file with admin privileges nothing is written to the log file, and the service is still not installed.
First off, you HAVE to run as admin permissions.
Second, when you "Run as Administrator", it actually changes the directory to c:\windows\system32 as the initial directory ( no idea why ), which would probably explain why running as admin causes no log file. Manually change to the path IEPPAMS_WinService1.exe resides in that the start of your script.
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!