How to enable detailed errors for remote client - IIS7

By default IIS 7.0 (Internet Information Service), shows the detailed error when you're browsing locally, but if you are remoting as a normal web client to the webserver, you won't be able to see the error, except the default '500 - Internal server error'.
Here is the guide to enable the detailed error, within IIS 7.0
First of all, you need access to IIS controlpanel, and the Webconfig from the specific website, you want's to see the detailed error from. In the Webconfig, it's very important that you have specified the CustomError mode to Off, otherwise your local configs would overwrite the server default settings. Please check you got the same setup as the example below.
<system.web>
<customErrors mode="Off" />
</system.web>
If you still receive the default error, you have to change the server custom error module settings. You can do this from the IIS7 Admin tool by running the server manager, or writing inetmgr.exe from the Run command.

1. Select your website, at the left menu
2. Click on the "Error Pages" button
3. Click on the action "Edit Feature Settings" at the right menu
4. Pick the "Detailed errors" option
5. Confirm the change by clicking "OK"

You should now be able to see the detailed error from the IIS7 webserver, from your remote location. Check the picture below, to verify you got the same settings.

http://dnohr.dk

Application Pool Identities

Introduction

Whether you are running your site on your own server or in the cloud, security must be at the top of your priority list. If so, you will be happy to hear that IIS has a security feature called the application pool identity. This feature was introduced in Service Pack 2 (SP2) of Windows Server 2008 and Windows Vista. An application pool identity allows you to run an application pool under a unique account without having to create and manage domain or local accounts. The name of the application pool account corresponds to the name of the application pool. The image below shows an IIS worker process (W3wp.exe) running as the DefaultAppPool identity.

Application Pool Identity Accounts

Worker processes in IIS 6.0 and in IIS 7 run as Network Service by default. Network Service is a built-in Windows identity. It doesn't require a password and has only user privileges; that is, it is relatively low-privileged. Running as a low-privileged account is a good security practice because then a software bug can't be used by a malicious user to take over the whole system.
However, a problem arose over time as more and more Windows system services started to run as Network Service. This is because services running as Network Service can tamper with other services that run under the same identity. Because IIS worker processes run third-party code by default (Classic ASP, ASP.NET, PHP code), it was time to isolate IIS worker processes from other Windows system services and run IIS worker processes under unique identities. The Windows operating system provides a feature called "virtual accounts" that allows IIS to create a unique identity for each of its application pools. Click here for more information about Virtual Accounts.

Configuring IIS Application Pool Identities

If you are running IIS 7.5 on Windows Server 2008 R2, or a later version of IIS, you don't have to do anything to use the new identity. For every application pool you create, the Identity property of the new application pool is set to ApplicationPoolIdentity by default. The IIS Admin Process (WAS) will create a virtual account with the name of the new application pool and run the application pool's worker processes under this account by default.
To use this virtual account when running IIS 7.0 on Windows Server 2008, you have to change the Identity property of an application pool that you create to ApplicationPoolIdentity. Here is how:

1. Open the IIS Management Console (INETMGR.MSC).
2. Open the Application Pools node underneath the machine node. Select the application pool you want to change to run under an automatically generated application pool identity.
3. Right click the application pool and select Advanced Settings...
4. Select the Identity list item and click the ellipsis (the button with the three dots).
5. The following dialog appears:
6. Select the Built-in account button, and then select the identity type ApplicationPoolIdentity from the combo box.

To do the same step by using the command-line, you can call the appcmd command-line tool the following way:
%windir%\system32\inetsrv\appcmd.exe set AppPool <your AppPool> -processModel.identityType:ApplicationPoolIdentity

Securing Resources

Whenever a new application pool is created, the IIS management process creates a security identifier (SID) that represents the name of the application pool itself. For example, if you create an application pool with the name "MyNewAppPool," a security identifier with the name "MyNewAppPool" is created in the Windows Security system. From this point on, resources can be secured by using this identity. However, the identity is not a real user account; it will not show up as a user in the Windows User Management Console.
You can try this by selecting a file in Windows Explorer and adding the "DefaultAppPool" identity to the file's Access Control List (ACL).

1. Open Windows Explorer
2. Select a file or directory.
3. Right click the file and select Properties
4. Select the Security tab
5. Click the Edit button and then Add button
6. Click the Locations button and make sure that you select your computer.
7. Enter IIS AppPool\DefaultAppPool in the Enter the object names to select: text box.
8. Click the Check Names button and click OK.

By doing this, the file or directory you selected will now also allow the DefaultAppPool identity access.
You can do this via the command-line by using the ICACLS tool. The following example gives full access to the DefaultAppPool identity.
ICACLS test.txt /grant "IIS AppPool\DefaultAppPool":F For more information, see ICACLS.
On Windows 7 and Windows Server 2008 R2, and later versions of Windows, the default is to run application pools as the application pool identity. To make this happen, a new identity type with the name "AppPoolIdentity" was introduced. If the "AppPoolIdentity" identity type is selected (the default on Windows 7 and Windows Server 2008 R2, and later), IIS will run worker processes as the application pool identity. With every other identity type, the security identifier will only be injected into the access token of the process. If the identifier is injected, content can still be ACLed for the ApplicationPoolIdentity, but the owner of the token is probably not unique. Here is an article that explains this concept.

Accessing the Network

Using the Network Service account in a domain environment has a great benefit. Worker process running as Network Service access the network as the machine account. Machine accounts are generated when a machine is joined to a domain. They look like this:

<domainname>\<machinename>$,

For example:

mydomain\machine1$

The nice thing about this is that network resources like file shares or SQL Server databases can be ACLed to allow this machine account access.

What about Application Pool Identities?

The good news is that application pool identities also use the machine account to access network resources. No changes are required.

Compatibility Issues with Application Pool Identities

Guidance Documentation

The biggest compatibilty issue with application pool identities is probably earlier guidance documents which explicitly recommend that you ACL resources for Network Service, that is, the default identity of the DefaultAppPool in IIS 6.0 and IIS 7.0. Customers will have to change their scripts to ACL for "IIS AppPool\DefaultAppPool" (or another application pool name) when running on IIS 7.5 or later (see the example above for how to do this).

User Profile

IIS doesn't load the Windows user profile, but certain applications might take advantage of it anyway to store temporary data. SQL Express is an example of an application that does this. However, a user profile has to be created to store temporary data in either the profile directory or in the registry hive. The user profile for the Network Service account was created by the system and was always available. However, with the switch to unique Application Pool identities, no user profile is created by the system. Only the standard application pools (DefaultAppPool and Classic .NET AppPool) have user profiles on disk. No user profile is created if the Administrator creates a new application pool.
However, if you want, you can configure IIS application pools to load the user profile by setting the LoadUserProfile attribute to "true".

Summary

Application pool identities are a powerful new isolation feature introduced for Windows Server 2008, Windows Vista, and later versions of Windows. It will make running IIS applications even more secure and reliable.

http://www.iis.net

Synchronize IIS

This quick guide will guide you through the process of using the Web Deployment Tool to synchronize a Web site on an IIS source computer to an IIS destination computer. You can do this by "pushing" data to a remote destination, or by "pulling" data from a remote source. This guide will show both methods, as well as an option to use a package file so that you do not have to install the Web Deployment Agent Service (MsDepSvc, or "remote agent service".)
What are the ways you can synchronize using the Web Deployment Tool?

• Push (synchronize from a local source to a remote destination)
• Pull (synchronize from a remote source to a local destination)
• Independent Sync (initiate a synchronization from a computer where both destination and source are remote)
• Manual Local Sync (create a package file of the source and copy it to the destination, then run it locally)

Prerequisites

This guide requires the following prerequisites:

• .NET Framework 2.0 SP1 or greater
• Web Deployment Tool 1.1

Note: If you have not already installed the Web Deployment Tool, see Installing and Configuring Web Deploy.

Part 1 - View your site's dependencies

1. Get the dependencies of the Web site by running the following command:

msdeploy -verb:getDependencies -source:apphostconfig="Default Web Site"

2. Review the output of the dependencies and look for any script maps or installed components that are in use by the site. For example, if Windows Authentication is in use by the Web site, you will see <dependency name="WindowsAuthentication" />.
3. If your site is inheriting any script maps, these will not be listed in the dependencies and you should also review the script maps for your site manually.
4. Compile a list of the components needed on the destination.
For detailed steps on analyzing the output of getDependencies, see Viewing Web Site Dependencies.

Part 2 - Configure the target (destination)

1. Review the list of dependencies and install them on the destination server.
For example, let’s assume you had the following in use for your Web site:

• ASP.NET

• Windows Authentication

• Anonymous Authentication

Based on analyzing your dependencies, you would install those components on the destination server before performing the synchronization.

Part 3 – Synchronize your site to the target

1. Always make a backup of the destination and source servers. Even if you are just testing, it allows you to easily restore the state of your server. Run the following command to backup an IIS 7 or above server:

%windir%\system32\inetsrv\appcmd add backup "PreMsDeploy"

2. Install the remote agent service on the source or the destination depending on if you want to "pull" the data from a remote source or "push" the data to a remote destination.
3. Start the service on the computer.

net start msdepsvc 

4. Run the following command to validate what would happen if the synchronization were run. The -whatif flag will not show every change; it will just show an optimistic view of what might change if everything succeeds (for example, it won't catch errors where you can't write to the destination.)

Pushing to remote destination, running on source computer (the computerName argument identifies the remote destination computer).
msdeploy -verb:sync -source:apphostconfig="Default Web Site" -dest:apphostconfig="Default Web Site",computername=Server1 -whatif > msdeploysync.log
Pulling from a remote source, running on destination machine (the computerName argument identifies the remote source computer).msdeploy -verb:sync -source:apphostconfig="Default Web Site",computername=Server1 -dest:apphostconfig="Default Web Site" -whatif > msdeploysync.log

5. After verifying the output, run the same command again without the -whatif flag:

Pushing to remote destination, running on source machine
msdeploy -verb:sync -source:apphostconfig="Default Web Site" -dest:apphostconfig="Default Web Site",computername=Server1 > msdeploysync.log
Pulling from a remote source, running on destination machinemsdeploy -verb:sync -source:apphostconfig="Default Web Site",computername=Server1 -dest:apphostconfig="Default Web Site" > msdeploysync.log

{Optional - Synchronize your site to the target by using a package file}

If you don't wish to use the remote service, you can use a package (compressed file) instead.
1. Run the following command on the source server to create a package of the Web site for synchronization:

msdeploy -verb:sync  -source:apphostconfig="Default Web Site" -dest:package=c:\site1.zip

2. Copy the package file to the destination server.
3. Run the following command on the destination server to validate what would happen if the synchronization were run:

msdeploy -verb:sync -source:package=c:\site1.zip -dest:apphostconfig="Default Web Site" -whatif > msdeploysync.log

4. After verifying the output, run the same command again without the -whatif flag:

msdeploy -verb:sync -source:package=c:\site1.zip -dest:apphostconfig="Default Web Site" > msdeploysync.log

You are now done synchronizing your site. To verify, test browsing to the Web site on the destination server. For troubleshooting help, see Troubleshooting Web Deploy.

Summary

You have now synchronized a web site from a source IIS server to a destination IIS server, including viewing the dependencies, configuring the destination IIS server and performing the synchronization.

faith_a