First off, I always tend to forget that setting Application Protection for a web app in IIS Admin to "HIGH" no longer causes another process to fire up (as it was in classic ASP). Rather, a new AppDomain is created in aspnet_wp.exe to host this application. So -- the "visibility" of the isolated web application is gone.

To illustrate, use SysInternals Process Explorer to view the aspnet_wp.exe process. In the .NET tab (using v8.52 of Process Explorer), it shows the AppDomains. You should see the "DefaultDomain", plus any others that are fired up on behalf of the IIS High Isolation applications! SWEET!

Semi-related to this, I'm trying to use impersonation on a web app to make network calls on behalf of the browser user. I *think* I remember from the COM days, that impersonation on a web site is ok for local NTFS access checks, but the impersonated account is not valid outside of the box. In other words, you can't use an impersonated account to hit a network share, login to SQL Server, etc.

Here's a link to remember about ASP.NET impersonation settings in web.config. You can impersonate as the browser user, or a fixed user/pwd. Instead of storing user/pwd in the web.config, use the aspnet_setreg.exe utility to store encrypted data in the reg. (then point to the reg key in the web.config file)

ASP.NET Web Application Security