My team was recently working on a configuration for an OrcsWeb hosting client with a very large web root folder in order to provide a load balanced web redundant solution. The clients users are able to upload files via the web interface so the data has to be synchronized rather than just a one-way replication. Due to data and HDD size constraints, DFS-R is not a viable option. As a workaround, we decided to configure a UNC share and point both nodes to the same location. We created the same share on both servers so that we could use robocopy to sync data to the standby share. This will require manual administrative work in the event of a necessary failover to the standby UNC share but it provides the data redundancy that the client desires.
Since this is a process we have done many times, we were already aware of the need to grant access to the share using the caspol command. If you need to do this in your configuration, here is a blog post that explains the process and steps to implement it. After configuring the share, the website was updated to point the the UNC share and testing began. When testing from the server that the share was hosted on, everything worked as expected. We then tested from the second server and quickly received the following error:
Exception Details: System.Security.SecurityException: Request for the permission of type ‘System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089′ failed.
To verify that the appropriate permissions were available, we created a test website and pointed to a new web root UNC share that only contained a default.aspx file. We ran the caspol command to grant access remotely and were able to browse the new site from both servers.
We used procmon.exe to determine if there were any access denied errors being logged to try to narrow down the root cause of the failure. No errors were reported. I then remembered reading about the changes that were implemented with the AppPoolIdentity in IIS7; specifically that the Application Pool identity uses the machine account to access network resources. Even though we were using a domain based user account for the application pool, we decided to add the computer account with read permissions to the share. Voila, we were then able to browse the site successfully from either web node. I can not explain why this was necessary but it resolved the error we were encountering. Hopefully this will save you some time in troubleshooting UNC share access issues with IIS if you decide to implement this configuration.
Terri is a Microsoft MVP (ASP .NET/IIS), an MCSA: Windows Server 2012, and a Support Specialist at OrcsWeb, a hosted server company providing managed hosting solutions
IIS and More 