I am facing a strange issue with my site in IIS 7. I have 10 sites with different sub-domains hosted on IIS 7. I am using .NET framework 3.5 and SQL Server 2008 R2. Three sites I have configured on DefaultAppPool while for others I have created separate application pool for each and configured them with their specific.
I allows user to upload video, after upload completes I used to hint it (a process to make bit rates of video equal for on-line streaming on android) using MP4BOX - a command line interpreter, with server side code.
What issue I am facing is while using DefaultAppPool the MP4BOX works fine but when I configured site to its specific appPool, MP4BOX stops working. I have go through the settings but haven't find any issue. Can anyone help me to overcome this issue.
Awaiting for your valuable response.
Resolved it myself by assigning read/writes permission to the application pool to the directory.
After lots of research I have found that it was happening due to read/write permission of this exe to the specific directory. MP4BOX need to have read/write permission to create video file in the IIS directory. So I have added application pool as a user to the specific directory to which mp4box was accessing for read write.
Related
I'm trying to run an exe with parameters from a web application.
I'm using Process.start() but it does not seem to run on iis!
It works fine when running from iis express. I'm publishing the application to my local iis as a test but it does nothing.
I've tried setting the iis admin service to enable interactions with the desktop and ive told iis to connect as my user credentials and set the application pool to use the same user credentials but still nothing works!
is there anything else someone can advise to get this working!
Cheers.
UPDATE
I got iis to run the process by setting the application pool identity to local system and double checking the credentials for the site.
But as expected the applications do not interact with the desktop, so creating a file from command line is simple, but running an application with parameters do not have the application open.
At the moment iis admin service has interact with desktop checked and is using the local system account.
Ok so this isn't really an answer but in the end I got process.start to work by setting the application pool identity to local system.
But as expected the commands do not interact with the desktop, but this was enough for what my application needs to do.
Sorry for the poor answer.
I have a stand-alone IIS7 Server that is not joined to a domain and that is running an simple ASP.Net application. This application has an ActiveReports report that has an image control where I set the path of the image during run time to a network share on another server. When I run the application locally in Visual Studio on a desktop that is joined to the same domain as the network share, I am able to get the images, but when I deploy the application to the stand-alone IIS server and run it locally on the IIS server I am not able to get the images. I added permissions on the network share for the username and password of the login for the IIS server and I am able to navigate using Windows Explorer to the network share from the IIS server now, but I can't get the permissions right on IIS.
What is the correct way to set the permissions so that the application can access the image files on the network share?
When IIS access network resources it uses the security context (account) associated with the IIS process. This is primarily controlled by the Application Pool unless you are doing any kind of impersonation at the code level.
In order to correct you issue you'll probably need to make sure the application pool is running using a security account that has access to the network resource. Here are some links that may help
http://technet.microsoft.com/en-us/library/cc771170(v=WS.10).aspx
http://www.iis.net/learn/manage/configuring-security/application-pool-identities
Also, don't forget, if you are using windows file services for your network share there are two levels of permissions, those that are set at a share level and those that are set at the file level if using NTFS. Here is some info:
http://technet.microsoft.com/en-us/library/cc754178.aspx
One idea: on the IIS7 server, create a Virtual Directory that points to the share. When creating a Virtual Directory, IIS will let you enter credentials needed to access a share.
Then, you'll need your image paths to reference the share.
I have a .NET 4.0 C# console application. The application is deployed to a network file share (which I believe is a Windows 2000 Server file server) like this:
\\server\share\Apps\Beta\Group\JobName\JobName.exe
The agent machine that will execute the application is a Windows 2008 R2 Server, x64. I use a domain user account to run the application from the command line. When run under a certain account we'll call UserBeta, the application throws the following exception when trying to connect to a WCF service:
System.Configuration.ConfigurationErrorsException: Error creating the Web Proxy specified in the 'system.net/defaultProxy' configuration section. ---> System.Net.Sockets.SocketException: An invalid argument was supplied
The user account, UserBeta, has Modify, Read & Execute, List folder contents, Read and Write permissions introduced at the folder Beta and inherited by the child folders in the above path. If I use a second user account, UserStage, which has the same permissions except that they are introduced one folder higher, at the Apps folder, the application runs without exception. Both accounts belong to the local Administrators group on the agent server.
Interestingly enough, if the application is executed as UserBeta within 15 seconds or so of it being executed as UserStage, it will also run successfully.
I should also note that the application runs fine if run from a local drive as the GroupBeta account, so there seems to be some sort of trust issue with the particular account running from the network share.
I need the application to run as the UserBeta account from the network share. ClickOnce is currently not an option. I believe I could solve the problem by adding the permissions for UserBeta at the Apps folder, however I don't like throwing more access at something unless that's really the issue. If anyone has any other ideas or can point me to the reason adjusting permissions is the correct course of action, I'd be much appreciative.
I read some topics here, but I haven't found the solution of my problem.
I wrote application(C#, WPF, EF, sql server compact) that should start at windows startup. I tried to achieve that in two ways:
Add entry to windows register. Unfortunately that wasn't work on Windows 7. I found here that adding a shortcut to Startup folder can solve my problem...
I've added shortcut to my application in Startup folder. Unfortunately again it is not working...
My application is starting with admin permissions because is using external dll's sql server compact. Maybe this is reason? In addition my application is not signed and probably will not be. Also writing a wcf service could be bad idea in my application.
Do you have any suggestions, or solutions for that problem?
It's against windows guidelines ( and enforced by the operating system ) to put a program that requires UAC elevation in the startup process. It's a horrible user experience to be prompted for elevation every time they logon to a computer.
I would factor the wcf / sql into a service and keep the client side UI elevation free.
Reference: Error message when you start a Windows Vista-based computer: "Windows has blocked some startup programs"
The solution for that problem was to make user to install sql server compact on his own computer instead of embeding it in application folder and change permissions for application to asInvoker from admin.
We've got a process currently which causes ASP.NET websites to be redeployed. The code is itself an ASP.NET application. The current method, which has worked for quite a while, is simply to loop over all the files in one folder and copy them over the top of the files in the webroot.
The problem that's arisen is that occasionally files end up being in use and hence can't be copied over. This has in the past been intermittent to the point it didn't matter but on some of our higher traffic sites it happens the majority of the time now.
I'm wondering if anyone has a workaround or alternative approach to this that I haven't thought of. Currently my ideas are:
Simply retry each file until it works. That's going to cause errors for a short time though which isn't really that good.
Deploy to a new folder and update IIS's webroot to the new folder. I'm not sure how to do this short of running the application as an administrator and running batch files, which is very untidy.
Does anyone know what the best way to do this is, or if it's possible to do #2 without running the publishing application as a user who has admin access (Willing to grant it special privileges, but I'd prefer to stop short of administrator)?
Edit
Clarification of infrastructure... We have 2 IIS 7 webservers in an NLB running their webroots off a shared NAS (To be more clear, they're using the exact same webroot on the NAS). We do a lot of deploys, to the point where any approach we can't automate really won't be viable.
What you need to do is temporary stop IIS from processing any incoming requests for that app, so you can copy the new files and then start it again. This will lead to a small downtime for your clients, but unless your website is mission critical, that shouldn't be that big of a problem.
ASP.NET has a feature that targets exactly this scenario. Basically, it boils down to temporarily creating a file named App_Offline.htm in the root of your webapp. Once the file is there, IIS will takedown the worker process for you app and unload any files in use. Once you copy over your files, you can delete the App_Offline.htm file and IIS will happily start churning again.
Note that while that file is there, IIS will serve its content as a response to any requests to your webapp. So be careful what you put in the file. :-)
Another solution is IIS Programmatic Administration.
Then you can copy your new/updated web to an alternative directory then switch the IIS root of your webapp to this alternative directory. Then you don't matter if files are locked in the original root. This a good solution for website availability.
However it requires some permission tuning...
You can do it via ADSI or WMI for IIS 6 or Microsoft.Web.Administration for IIS 7.
About your 2., note that WMI don't require administrator privileges as ADSI do. You can configure rights by objects. Check your WMI console (mmc).
Since you're already load balancing between 2 web servers, you can:
In the load balancer, take web server A offline, so only web server B is in use.
Deploy the updated site to web server A.
(As a bonus, you can do an extra test pass on web server A before it goes into production.)
In the load balancer, take B offline and put A online, so only web server A is in use.
Deploy the updated site to web server B.
(As a bonus, you can do an extra test pass on web server B before it goes into production.)
In the load balancer, put B back online. Now both web servers are upgraded and back in use in production.
List item
You could also try to modify the timestamp of web.config in the root folder before attempting to copy the files. This will unload the application and free used files.
Unless you're manually opening a handle to a file on your web server, IIS won't keep locks on your files.
Try shutting down other services that might be locking your files. Some examples of common services that do just that:
Windows Search
Google Desktop Search
Windows Backup
any other anti-virus or indexing software
We had the same server (2003) and the same problem. Certain dll's were being locked and putting the App_Offline.htm in the website root did jack diddly for us.
Solution:
File permissions!
We were using a web service which runs under the Network Service account or the IIS_WPG account to deploy updates to the web site. Thus it needed write access to all the files. I already knew this, and had already set the permissions on the directory a while ago. But for some strange reason, the necessary permissions were not set on this one problem dll. You should check the permissions not only on the directory, but on the problem file as well.
We gave Network Service and IIS_WPG users read/write access to the entire web root directory and that solved our file in use, file locked, timeout, and access denied issues.