Every so often, as most system administrators know, a problem arises on a server, which is interesting, frustrating, time consuming and, ultimately, extremely satisfying to solve. I had this kind of problem recently on one of my Windows Server 2003 boxes. I installed Microsoft Data Protection Manager 2007 to provide snapshots of my other Windows servers, and also wanted this machine to serve some internal web pages. [Note: yes, I know that Microsoft's guidelines state that a DPM server should be single use, and not an application server, but we're only talking about serving 4 or 5 pages generated from a PHP script on my internal network - not exactly taxing!!]
IIS appeared to be set up correctly. I copied in the web pages, tried to access them from my workstation and received “Error 403.2 Forbidden – Read Access Forbidden”. I checked all the things you usually check – user permissions, file and directory permissions, IIS permissions through the MMC snap-in. Everything seemed to be correct.
I checked forums, newsgroups and the Microsoft Knowledge Base, all of which said to check the same things. Oddly, I could view the pages if I opened Internet Explorer on the IIS machine itself, which led me on another wild goose chase of checking firewall settings.
Finally, a newsgroup post led me into the murky world of the IIS Metabase – an XML file of IIS metadata. Much of the data contained here cannot be modified from the IIS user interface snap-in. To view or modify these settings, install the Metabase Explorer from the IIS Resource Kit.
In Metabase Explorer, I expanded the LM/W3SVC/1/ROOT key and checked the AccessFlags property. This was set to 30209, which means that AccessNoRemoteRead and AccessNoRemoteScript bits were set. Resetting them to the normal value of 513 (AccessScript and AccessRead bits set true) for each virtual directory listed in Metabase Explorer, and restarting IIS solved the problem.

IIS 6 Metabase Explorer
The question is…how did these flags, which are not accessible through the standard UI, get set in the first place? Although I haven’t seen it written anywhere, I suspect it’s an undocumented feature of the DPM set-up. Given the warnings about not using the DPM server as an application server, it would appear that DPM modifies the metabase directly and hardens IIS by preventing remote reads.
After that initial few hours of frustration, my slightly expanded use of the DPM server seems to be working fine.
Reference: Microsoft IIS AccessFlags property