Disclaimer: All postings are provided "AS IS" with no warranties, and confer no rights. This weblog does not represent the thoughts, intentions, plans or strategies of Microsoft. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.
With IIS7, we have a little bit more isolation with AppPool Identities
For example, if you’re using the the DefaultAppPool, if you need to assign permissions to NTFS, SQL, etc., what you’d use instead is as follows:
Where “DefaultAppPool” ends up being the name of your AppPool as shown in IIS Manager…
That is if you’ve set the identity to the “ApplicationPoolIdentity” instead of something else, such as Network Service, Local System, or something other…
Let’s face it, during development, managing all the certificates if you’re doing anything with validating SSL/TLS traffic is a pain.
Now with Windows Identity Foundation (fka Geneva) we really have to get crackin on getting used to managing certificates, setting up SSL sites, etc.
So, here’s great post on setting up IIS7 to use wildcard certificates…
This gives you 1 certificate rooted at some common domain (eg. mydev.local) where all sites would be site1.mydev.local, site2.mydev.local, etc. The CN in the certificate ends up being *.mydev.local – just wire up in your hosts file (..\drivers\etc\hosts) and you’re golden…
During an installation issue, a client followed the TechNet article (http://technet.microsoft.com/en-us/library/cc298447.aspx) and those instructions are misleading.
It indicates to copy the “web.config” to the Layouts directory – what if fails to specify is it should be the “layoutsweb.config” file instead.
While following the article does get you passed the issue that brought you there in the first place, you eventually end up with issues on provisioned sites that reference anything in _layouts are there are sections “<system.web>” that don’t make sense in a IIS path.
Just recopying that correct config file fixes all.
I’ve been writing one off methods that apparently are handled quite well for a few things in the type System.Web.VirtualPathUtility.
For example, if you just want the page name or the extension, you have this utility to quickly get that from the current request path.