What Is The Default App Pool Foder

Application Pool

Internet Information Services 7.5 feature focus

Dustin Hannifin , ... Joey Alpern , in Microsoft Windows Server 2008 R2, 2010

Application pools

Application pools help isolate Web sites so that issues that may occur on one site do not bring down other sites running on the same server. Application pools can also be used to restart a Web site if it begins to consume too many resources on the server, again preventing a single site from interfering with the performance of other sites on the same server. Additionally, application pools allow administrators to set specific sites to run as a defined identity or user account. This gives the application a security context in which it can connect to and access other resources on the network if necessary.

Each IIS Web site runs in an application pool. An application pool can contain one or more IIS Web sites. If an application pool stops or restarts, the IIS Web site is also offline during the time the application pool is stopped.

During the installation of the Web Server role, DefaultAppPool, and Classic.Net AppPools are created along with a Default Web site.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597495783000062

Administration of an IIS 7.0 Web Server

In The Best Damn Exchange, SQL and IIS Book Period, 2007

Creating Application Pools

Application pools is a concept that was added in IIS 6.0. In IIS 7.0, it changed very little and is basically the same and defines what applications run within what worker process. This is IIS's isolation functionality and is where you can recycle, change process identity security, and view health and diagnostics information. By default, IIS 7.0 provides you with a single application pool called DefaultAppPool.

Some Independent Advice

The default behavior for adding new Web sites in Windows Vista is to add it to the DefaultAppPool. This behavior is by design since Windows Vista is a client environment and isolating each Web site and its root application into its own application pool would hinder the performance of the client.

In Windows Server "Codenamed" Longhorn, though, each time you create a new Web site using IIS Manager it will create a new application pool. This behavior is expected and creates maximum isolation of your Web applications and is a good security practice.

To create an application pool, do the following:

1.: In the IIS Manager Connections pane, expand the server node and click Application Pools.
2.: On the Application Pools node, right-click and choose Add Application Pool…
3.: In the Add Application Pool dialog, provide a name for the application pool in the Name field.
4.: From the .NET Framework version list, select the version required by your managed applications. Otherwise, choose No Managed Code if the applications in this pool don't require the .NET Framework.
5.: From the Managed pipeline mode list, select the ASP request processing mode.
6.: Select the Start application pool immediately check box to start the pool when the WWW service is started.
7.: Click OK to create the new Application Pool.

Note

The Actions pane provides the same "right click" functionality for the Application Pools.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597492195000169

Administration of an IIS 7.0 Web Server

Chris Adams , ... Gene Whitley , in How to Cheat at IIS 7 Server Administration, 2007

Creating Application Pools

The important step in creating an application pool is having applications read to define or run within your newly created application pool. Thus, after creating an application pool, you will want to assign your application to that application pool. The syntax for creating a new application pool is the following:

In the preceding case, appPoolName specifies the name of your new application pool.

By default, IIS adds application pools that run integrated managed pipeline mode and use .NET Framework version 2.0 for managed code execution. Otherwise, you can specify the .NET Framework version and managed code request-processing mode.

To add an application pool to a Web server with different settings, use the following:

In this example, dotNetVersion equals the .NET Framework version the application pool runs. The possible options are v1.0, v1.1, v2.0, or blank for no managed code support.

Lastly, we set the application pool to run in either IIS 7.0's new pipelineMode as Integrated or the IIS 6.0 with ASP.NET mode called Classic.

Enter the following command to create an application pool that does not run managed code and uses classic mode:

Notice /managedRuntimeVersion: is followed by a blank (space).

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597491556500094

Configuring Web Application Services

Tony Piltzecker , Brien Posey , in The Best Damn Windows Server 2008 Book Period (Second Edition), 2008

Application Pool Settings

Each application pool has number of settings that can be tuned to optimize how it behaves for your Web application. These settings are available through the Advanced Settings action available in the Application Pools section (see Figure 11.25).

Outside of the application pool process identity most settings in their default state will service a majority of applications. Briefly we will take a look at each section, and highlight some of the features that are new to IIS 7:

▪: General Settings The ability to change pipeline modes, as discussed earlier, is exposed in this section.
▪: CPU The Processor Affinity settings, which enable you to configure your application to favor specific processors, is now exposed through the graphical user interface.
▪: Process Model In previous releases of IIS each application pool would run under a shared user profile, thereby accessing the same temporary folder when performing various file system operations. This introduced the potential for cross-pool information disclosure. In IIS 7 this option was added to allow you to take advantage of a more secure configuration where each individual worker process would maintain their own user profile on the server and thereby isolate activities such as temporary file storage.
▪: Process Orphaning The options in this section are new and exciting for developers as it allows you to attach a debugger to processes to capture their state upon failure. In previous releases you needed to use the tools that shipped as part of the IIS Resource Kit to perform similar actions.
▪: Rapid-Fail Protection The ability to modify the response type when services fail is powerful for scenarios that leverage load balancing. The option to fail to TCP as opposed to a 503 Service Unavailable message allows network load balancers to respond faster as they have less processing overhead to detect server failure.
▪: Recycling Exposes a number of options that were previously hidden in the metabase.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597492737000112

Configuring Web Infrastructure Services

Tony Piltzecker , Brien Posey , in The Best Damn Windows Server 2008 Book Period (Second Edition), 2008

Application Pools

With the changes in architecture in this release, FTP sites have been shifted to use application pools for processing requests. This allows you to separate out the sites into individual worker processes and control their process identity and resource utilization as you would with a Web site.

Configuring & Implementing…

Converting a Folder to an Application

1: Open Control Panel and under System and Maintenance | Administration Tools double-click the Internet Information Services (IIS) Manager shortcut.
2: In the Internet Information Services (IIS) Manager management console, expand the server and sites nodes in the left-hand pane, right-click a folder within a FTP site, and select Convert to Application.
3: In the Add Application dialog select the application pool you want your application to run under, if desired set a content access identity, and click OK (see Figure 12.13).

Figure 12.13. Add Application Dialog

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597492737000124

Troubleshooting 101: Diagnostics in IIS 7.0

Chris Adams , ... Gene Whitley , in How to Cheat at IIS 7 Server Administration, 2007

<httpErrors> Configuration

With the rich integration between ASP.NET and IIS 7.0, a developer or administrator can define the httpError configuration at the server, Web site, or virtual directory level. This provides a greater amount of control versus what was previously available in IIS. The default <httpErrors> section is defined in the applicationHost.config file. (More information on the location and use of the applicationHost.config file can be found in Chapter 4.)

The default location for the custom error pages is %SystemDrive%\inetpub\custerr. Within that folder will be additional folders that map to a localized code. For U.S. English, that subfolder is labeled "en-US." The localized version that will be used for the response will be defined by the actual browser setting that is set by the end user.

The <httpErrors> node defines the base values for all the child <error> nodes (see Table 6.2).

Table 6.2. Child >error<Node Attributes and Values

Attribute Name	Value
defaultPath	Default path to the HTTP error file or URL that will be used within the child *<error>* node.
detailedMoreInformationUnk	At the bottom of a Detailed error page, a "More Information" link redirects the user to a Microsoft Support article. Setting the Detailed More InformationLink property can override the base URL for this link. This can be extremely useful if you want to capture these errors, even for internal testing, to store in a database or provide a response using an internal Knowledge Base article that directly references a particular product or module (Default="http://go.microsoft.com/fwlink/?LinkID=62293").
defaultResponseMode	Used to define the default Response Mode that will be used within the child *<error>* node (Default= File): File Static file will be used. ExecuteURL Points to a URL within the same server. For this to work, it must be a URL that points to a dynamic page (e.g., ASPX page) that resides within the same application pool that generated the error. Needless to say, you might not want to set this at the server level if you host a number of sites with more than one application pool. By default, you will receive an error if you attempt to do this to a location outside the appPool. However, you can actually get around this and allow it to happen with an appropriate registry key. Read the "Some Independent Advice" sidebar for more details. Redirect Redirects to a specific URL. The URL can be on the same server or a completely different server or site.
errorMode	Defines whether a Custom Error page or Detailed Error page is used upon a given error being generated (Default=DetailedLocalOnly). DetailedLocalOnly A detailed error will only be displayed when the request comes from the local machine. Custom Custom pages will be used upon an error. Detailed A detailed error response will be provided regardless of a custom page being assigned or outside the local machine.
existingResponse	ASP.NET and IIS 7 are not integrated when it comes to error responses. Thus this value allows you to control the way you want to handle error responses (Default=Auto): Auto IIS 7.0 will go through a series of checks to decide which error response will be used: 1. If the IHttpResponse::SetStatus method was called with the fTrySkipCustomErrors flag, the existing response is passed through, and no detailed or custom error is shown. 2. If the ErrorMode property is set to Custom, the response is replaced. 3. If ErrorMode is set to Detailed and there is an existing response, the response is passed through. 4. If ErrorMode is set to Detailed and there is no existing response, the response is replaced with a detailed error message. Replace When an error message is generated (e.g., 404, File not Found), IIS will take over the error and call the appropriate custom error page or URL. PassThrough When an error message is generated (e.g., 404, File not Found), IIS will not call out to the custom page but will allow the error to be handled by a module. For example, when calling a page that doesn't exist and has an extension of. aspx, which results in a 404 File not Found error, the error response will be created by ASP.NET and not IIS. So in this case, the custom page or detailed page, as defined in the web.config, will not be generated.

SOME INDEPENDENT ADVICE

For a site or application to leverage an error page that's in a different application pool than its own, the following registry change will need to be made. Keep in mind that this is a serverwide change and could open the attack surface on a Web server that is "hosting" a number of different Web sites.

Note: It is recommended that you back up your registry before modifying the registry with the new data. If you use Registry Editor (Regedit.exe) incorrectly, you could cause serious problems that might require you to reinstall your operating system.

1.: Open Regedit.exe (you can quickly find this using Windows Vista search by clicking the Windows button and typing in RegEdit).
2.: Navigate to the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC.
3.: Within the W3SVC key, create a new DWORD called IgnoreAppPoolForCustomErrors and with a value of 1.
4.: For this change to take effect, you'll need to restart IIS 7.0.

The child nodes for <httpErrors> are <error>,<remove>, and <clear>. The <error> node defines a set of properties for a given error code. As you can see, each error code is then mapped to a specific file, which then provides appropriate error response. A number of options are available by error code, including handling suberror codes.

Table 6.3 provides details on the available attributes that can be used as part of the <error> XML node.

Table 6.3. <error> XML Node Attributes and Values

Attribute Name	Value Type	Value
statusCode	String	Primary status code for a given error.
subStatusCode	Integer	Substatus code for a given error that is a "child" of a high-level code.
prefixLanguageFilePath	String	Location of language-specific error code folders.
Path	String	Actual filename for the given page that will be used to provide the error message to the user.
responseMode	String	Defines the type of response that will be given. This will also treat the value in Path a bit differently. This is the same as Path Type as defined in the IIS Manager.

Within a given error code, additional suberror codes provide an even greater amount of detail.

The following XML node can be added to the <httpErrors> node to handle a suberror code:

This XML looks much like the previous XML, except it uses a new XML attribute, subStatusCode, which takes an integer and is the suberror code. Thus, the preceding XML is capturing the 404.14 statusCode and is then being redirected to the 404-14.htm file. If an error code is raised and it's actually a suberror code, but no subStatusCode is defined in the <httpErrors> XML, the "parent" statusCode will be used.

The following URL points to a Microsoft Support page that provides a general list and description of Error Codes used by IIS 6.0 and 7.0: http://support.microsoft.com/kb/318380

The prefixLanguageFilePath attribute provides a pointer to a folder that holds additional folders with the language-specific error pages. For example, the default error code pages are located at ="%SystemDrive%\inetpub\custerr and contain a child folder named en-US. The en-US folder contains all of the individual error pages, such as 404-14.htm. The syntax (folder name) and acceptable languages that can be used here are defined in RFC 1766 (www.ietf.org/rfc/rfcl766.txt).

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597491556500100

Internet Information Server (IIS) Authentication and Authorization Models, and Locking Down File Access with EFS and WebDAV

Timothy "Thor" Mullen , in Thor's Microsoft Security Bible, 2011

The Service User

We need to keep the concept of least privilege in mind when we create the user for the application pool. A good example of least privilege would be removing newly created service accounts from the default domain users group once they have been set up. The domain users group is widely used by many administrators to give both read and write access to resources when they are users authenticated by the domain. Our user account does not need this type of access, so we will pull them out the moment we create it. To make this process easy and to better track service users, I create a global group for service users and populate that group with service accounts. That way I can create access rules specific to service users. In this example, I will be using gServiceUsers. Not exactly creative, but it is self-explanatory. This overall least privilege process is covered in detail in the Chapter 5, titled "The Creation and Maintenance of Low-Privileged Service Users." Detailed suggestions regarding service account creation and administration are also discussed there, including password expiration policies and lockout considerations for service accounts.

My service account user will end up being a very low-privileged user that is a member of gServiceUsers, and only gServiceUsers. A user must have a primary group set in AD, and this is the domain users group by default. The other reason to create a separate gServiceUsers group is so you can add them to the service group, set the service group as the primary group, and then delete their membership from domain users. You cannot remove the user from domain users until you do this.

Pursuant to the instructions in the chapter about service users, we will end up with a lowly user. I will call the account MyWebApp, which is so far only a member of the gServiceUsers group. This is shown in Figure 2.27.

Create a new application pool in IIS and edit the advanced settings to change the default entry of ApplicationPoolIdentity to specify the MyWebApp custom account to be used as the application pool identity. This is illustrated in Figure 2.28.

Now that we have changed the application pool identity as reflected in Figure 2.28, we are all set. Take note of the fact that the custom account credentials have to be entered here and are stored by IIS. If you change the password of the account in AD without changing the password stored here, your application will stop working. The passwords are not synchronized.

All that is left to do is to add the MyWebApp service account to the gShared group that is already configured to have read access, and our site is ready to go. Since the gShared group already contains Steve and Greg, this is a simple way of ensuring that all the parties involved have read access (see Figure 2.29).

Note that this example access policy will still give Steve and Greg access to each other's files, but we know how to change permissions to accommodate access requirements as shown in Figures 2.12 through 2.14.

It is important that we have a web application that is configured to allow for easy access to virtual directories on other servers within the context of a user account that is very limited in authorization scope. This is a Good Thing. Since existing share structures will already have access permissions in place that meet your needs, these shares can be extended to external users for remote read access by simply including the MyWebApp user, the gShared group, or the equivalent group in read access. We may now consider our milestone reached as outlined in Figure 2.11. Yippee!

However, as is typically the case in IT security, the extension of functionality often inherits an expanded scope of risk. And this case is no different. We no longer have a user context limited to local-server-only file access where granted. We now have a web application using a domain account that, by design, can read files and folders on other servers (again, where granted). Sure, the localized IIS APPPOOL\DefaultAppPool could also reach network shared where EVERYONE or authenticated users are granted access if the web server is a domain member, but this is an actual domain user. Does that make this a poor solution? Not at all. If you want a web application to have access to virtual directories on other servers, then it has to be able to read the data. In configuring this solution, we have performed our due diligence in design and deployed the account while considering the concept of least privilege.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597495721000093

Getting Started with IIS 7.0

Chris Adams , ... Gene Whitley , in How to Cheat at IIS 7 Server Administration, 2007

Runtime State and Control API (RSCA)

RSCA allows developers to see running requests on a server in real-time. This feature exposes the active state of sites and application pools and running worker processes. RSCA allows administrators to start and stop sites and recycle application pools. This capability comes in handy when investigating server issues or tuning server performance, because being able to quickly see what is going on in the system itself and controlling it while troubleshooting is powerful. To break it down, RSCA does the following:

▪: Provides in-process state information (current processes running, application pools process ID, currently executing requests, and AppDomains loaded)
▪: Real-time starting and stopping of sites

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597491556500057

Windows Server 2008 R2 delta changes

Dustin Hannifin , ... Joey Alpern , in Microsoft Windows Server 2008 R2, 2010

Support for managed service accounts

You learned in Chapter 4 that Windows Server 2008 R2 AD allows administrators to create managed service accounts. Managed service accounts allow administrators to change the password of a service account without having to update each service using that particular account. IIS 7.5 application pools provide support for managed service accounts. For example, an IIS application pool could be running under the account IIS_Service. For security purposes, an administrator needs to change the password on this account. The administrator simply has to change the password of the AD account. Once the password has been changed, the IIS application pool will automatically update the password field to reflect the new password without administrator interaction.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597495783000141

Performance Tuning

Kelly C. Bourne , in Application Administrators Handbook, 2014

17.3.3 Support software

As stated before, the application you're supporting isn't the only software running on the server. If your examination of the server and the application haven't resolved your performance issues, then the next step is to start looking at the support software that's also running on the server. Any of those programs could be something that affects the performance of your application. For example, one of them might be consuming an excess amount of CPU time, memory, or disk I/O operations.

One of the first considerations is to make sure that all support software running on the server is the most recent version. Newer versions of the software typically run faster or more efficiently than older versions. Newer versions are also intended to be more secure and to have resolved problems. There are exceptions to these rules, but for the most part, newer is better.

Turn off or remove any software running on the server that isn't specifically needed by the application. Doing this has multiple benefits. It frees up resources like memory, CPU cycles, and disk space. Removing unused software also has the benefit of reducing the attack surface that a hacker might use to compromise your server. Some examples of software that might exist on the server that can be removed are:

•: File and printer sharing services like NetBIOS, NFS, and FTP
•: Wireless networking services
•: Remote control and remote access programs like telnet
•: E-mail services like SMTP
•: Language compilers and libraries
•: System development tools like Visual Studio and Eclipse

17.3.3.1 IIS

If your application is web based, there is a reasonable chance that IIS (Internet Information Services) is running on the server. If your application depends on IIS, there are some settings on it that can potentially make your application run faster. Before making any of the following suggestions, you should check with the vendor's support group to make sure doing it won't cause a problem. It would also be an excellent idea to test these changes on a development, test, or QA environment before making them on your production environment.

The following are some IIS adjustments that might help improve your application's performance:

•: A setting exists that determines whether HTTP files should be compressed or not. Compressing HTML data can reduce the amount of data passed between your server and the user's browser by a factor of 5 or more.
•: Cache limits related to ASP can be increased. The number of ASP files being cached and the number of scripts engines that are cached can be increased.
•: Logging being done by IIS can be adjusted to be more appropriate to your environment. Cutting down on the amount of logging reduces disk I/O activity as well as the amount of disk space being consumed.
•: Sessions that are inactive for a configurable amount of time are terminated by IIS. You have the ability to set this amount of time. This setting is very sensitive from both a user convenience and security aspect. If the session timeout value is too low, then users will have their application sessions terminated inconveniently early. If it's too high, then it might leave sessions open so long that other people can access it if the user walks away from his PC.
•: IIS uses Application Pools, which are Windows operating system processes. User session state information is held within the Application Pool. There are a number of settings for Application Pools that can affect the application's performance. For example, how often worker processes are recycled and how long worker processes have to be idle before they are shut down.

17.3.3.2 Antivirus software

If your server has antivirus software running on it, then it's entirely possible that the AV software could affect performance on the server. To know whether this is true or not, you should know exactly what it is doing. If you can't answer the following questions, then you should research it so you more fully understand whether the AV software could be at the root of any performance issues on the server.

•: Does it use signature-based detection, heuristics, or both identify viruses?
•: What are the names of the processes it runs on the server?
•: Are those processes running at the kernel level?
•: How many false positives does it generate?
•: What percentage of CPU time does each process typically consume?
•: Does it examine every file that is?
•: Does it examine every file that is opened?
•: Does it automatically download new virus signatures?
•: How often does it do this?
•: What time of day do these downloads occurring?
•: How much data is downloaded every time?
•: Does it perform a regular scan of the server? On what schedule?

17.3.3.3 Distribution software

Does your organization have software in place that pushes updates out to servers and user workstations? These tools allow a Systems Administrator to automate the process of distributing changes to multiple servers and user PCs. Examples of such packages are:

•: Altiris
•: LANDesk
•: SCCM
•: System Center

If a package like one of the above exists on your server, it can have an effect of the server's performance. You need to know the answers to the following questions.

•: Does the package have an agent or process on your server?
•: What is being pushed to your server? Operating system changes? Support software changes?
•: How often are changes pushed out?
•: Can you prevent an update from being pushed out?
•: Once installed, can an update be backed out?
•: Are these changes tested on another server in your organization before being distributed?
•: What time of day are changes pushed out?
•: What happens if the update requires that the server be rebooted for changes to take effect?
•: Does your server need to have distribution software on it? Or can it be removed?

17.3.3.4 Backup software

Every server needs to have its contents backed up on a regular basis. This is true for development servers, test servers, QA servers, and most importantly production servers. Your organization certainly has the choice regarding what software is going to be used to do the backups. Your organization might have developed its own backup process and software. Or it might have installed a package to handle this important process. Either way, a backup process moves a lot of data back and forth, so it can cause performance problems on a server.

You need to know the answers to the following backup-related questions:

•: What backup-related processes are running on the server?
•: What days do they run?
•: What time do they run?
•: What time do they usually complete?
•: What happens if the backup doesn't complete, either at all or by the normal time?
•: Does the application have to be stopped for the backup process to run?
•: If the application doesn't have to stop, will users see performance degradation while backups are running?
•: How are backups scheduled and launched?
•: What drives, directories, and files are being backed up?
•: What drives, directories, or files are exempted from being backed up?
•: Is a full backup done every day or are full backups combined with incremental backups?
•: Can the backup software copy a file if another process has it open?
•: Can regularly scheduled backups be suspended or avoided during critical times of the month, quarter, or year to ensure processes that take longer than normal will complete?

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123985453000170