IUSR and IWAM date back to the very early days of IIS when you installed it separately (not as an OS component). By default, if a web site permits anonymous authentication, the IUSR account is used with respect to permissions on the OS. This can be changed from the default. There are some security recommendations to at least rename the account, so it's not a "known" account, much like there is a recommendation to rename the administrator account on a server. You can learn more about IUSR and authentication at MSDN.
IWAM was designed for any out of process applications and is only used in IIS 6.0 when you're in IIS 5.0 isolation mode. You usually saw it with COM/DCOM objects.
With respect to application pool identities, the default is to run as the Network Service. You should not run as Local System because that account has rights greater than that of an administrator. So that basically leaves you to Network Service, Local Service, or a local/domain account other than those two.
As to what to do, it depends. One advantage of leaving it as Network Service is this is a limited privilege account on the server. However, when it access resources across the network, it appears as Domain\ComputerName$, meaning you can assign permissions that permit the Network Service account to access resources such as SQL Server running on a different box. Also, since it appears as the computer account, If you enable Kerberos authentication, the SPN is already in place if you're accessing the website by the server name.
A case where you'd consider changing the application pool to a particular Windows domain account if you want a particular account accessing networked resources such as a service account accessing SQL Server for a web based application. There are other options within ASP.NET for doing this without changing the application pool identity, so this isn't strictly necessary any longer. Another reason you'd consider using a domain user account is you were doing Kerberos authentication and you had multiple web servers servicing a web application. A good example is if you had two or more web servers serving up SQL Server Reporting Services. The front end would probably to a generic url such as reports.mydomain.com or reporting.mydomain.com. In that case, the SPN can only be applied to one account within AD. If you have the app pools running under Network Service on each server, that won't work, because when they leave the servers, they appear as Domain\ComputerName$, meaning you'd have as many accounts as you had servers serving up the app. The solution is to create a domain account, set the app pool identity on all servers to the same domain user account and create the one SPN, thereby permitting Kerberos authentication. In the case of an app like SSRS, where you may want to pass the user credentials through to the back-end database server, then Kerberos authentication is a must because then you're going to have to configure Kerberos delegation.
I know that's a lot to take in, but the short answer is, except for Local System, it depends.
Best Answer
You have to enclose the path to the Python script in double quotes. Double quotes have to be escaped in XML using
".You do NOT have to enclose the path to the Python executable in double quotes! In fact, this will not work! If your Python installation is in a non-standard path containing spaces, then you don't need to do anything, as spaces will just work for the executable path (it isn't really IIS/FastCGI module that has issues with spaces, but the invocation of Python where the script path is to be passed as a single argument).
As an example, here is what the configuration looks like if Python is installed in a non-standard path containing spaces (just replace it with
C:\python27\if that doesn't apply to you).In
applicationHost.config:In
web.config:EDIT: To set up
applicationHost.configprogrammatically usingappcmd.exe, you must escape the double quotes in the argument as\". For example: