Guest Post: The Case of the FrontPage Error

Welcome to the first guest "Case Of" blog post! I've received numerous great troubleshooting cases over the last two months and have selected this one, submitted by Troy Wolbrink, a corporate web master, as the first to share with you.

 

Troy ran into a problem with his web server and instead of rebooting, reinstalling, or calling Microsoft Product Support Services (who would have undoubtedly suggested the same steps Troy followed on his own, but cost Troy an incident), he used basic troubleshooting techniques to solve it in a few minutes. Like for everyone else that's submitted a well-documented case with screenshots and log files, I sent Troy a signed copy of Windows Internals as a thanks.

 

I'm including some of the cases I've received in my "Case of the Unexplained..." talk again at TechEd/IT Pro in June. In fact, even if you've watched the webcast from last November's TechEd/ITForum, be sure to come to the session as it consists of entirely new new cases.

 

Before I present the case, I want to share a clever user-produced video that serves as both a tutorial and demonstration of Zoomit, a screen magnifier and annotation tool I developed as an aid for my presentations. You can find the video here.

 

Enjoy Troy's post and the Zoomit video and please keep submitting your troubleshooting cases!

 

-Mark

 

The Case of the FrontPage Error

by Windows Detective Troy Wolbrink

I recently transitioned my website from shared hosting to my own dedicated server. Parts of my website were using FrontPage Server Extensions (FPSE), such as the page which collected data and logged the results to a text file:

 

I installed FPSE using the Add/Remove Windows Components control panel applet, and then I did my best to configure them correctly with IIS. But for some reason I could not get FPSE configured correctly such that my data collection form would work. The error message from the browser was very vague:

 

I looked for more information in the Event Log on the server, but it had nothing relevant.

My plan was to eventually replace this site with one built on ASP.NET and SQL Server, so I wasn’t feeling motivated to become a FPSE expert just to solve this one problem. But since other priorities are preventing this move to ASP.NET from happening for another year, so I had no choice but to investigate. I had just seen Mark’s talk on “The Case of the Unexplained...”, and I was inspired to run Process Monitor on my server to see if any clues to the problem might appear. I excluded events from some obvious processes that had nothing to do with the problem. This removed a lot of the noise. Since my web page was “TntWebLog.htm” and since it was writing to “TntWebLog.csv” I configured it to highlight anything with a Path containing “TntWebLog”.

To reproduce the problem, I pulled up my web browser and tried to submit the form. Then back in Process Monitor I told it to stop capturing events. I then scrolled down through the list looking for highlighted entries. It was astonishing how quickly I found the problem. FPSE was trying to create the file with the same name as the existing file:

 

Obviously something was up with file permissions here. I checked the file permissions for TntWebLog.csv and it didn’t have a listing for the IUSR_WEBBOARD account which is what is configured in IIS for anonymous access:

 

 

So I clicked Advanced, checked the box for “Allow inheritable permissions from the parent to propagate…” and clicked “OK”:

 

Doing this caused the proper security permissions to be configured for the file. I ran another test and the problem was solved!

Looking back I believe that this problem occurred because I used Windows Explorer to “Move” and not “Copy” the csv file into place. I did some more tests to confirm this. When you “Move” a file within the same volume using Windows Explorer, the file permissions are moved with it. When you “Copy” a file using Windows Explorer, it creates a new file that inherits permissions from the target folder. If I had originally performed a “Copy” this problem would have never happened.

Now my first reaction to unexplained problems will be to run Process Monitor and see what’s going on under the hood!

 

-Troy Wolbrink

Comments

• Anonymous
  January 01, 2003
  The blog says to keep submitting your troubleshooting cases along with screenshots and log files... but there's no address, and the e-mail page doesn't allow for attachments. I'm sure it's an open secret to regulars, but might be worth mentioning for those not in the know ;)

• Anonymous
  January 01, 2003
  Joel, there is an KB article about the not inherited permissions when moving folders on NTFS Partitions: http://support.microsoft.com/kb/320246/en-us/ It also states that this behaviour has changed in Vista and Windows 2008. This sometimes also happens on Win2000/2003 fileservers when Users are moving folders on the same share. To prevent problems I'm using Mark's AccessEnum to make regular checks for permissions that are not inherited correctly within the shares. Mark, thank you very much for your tools. :)

• Anonymous
  January 01, 2003
  Tony did get a signed book (I indicate that in the introduction). Thanks for the feedback and the correction, Erwin.

• Anonymous
  January 01, 2003
  Hi Wayne, That's not really a correction, but a clarification. I've modified Tory's text to note that he moved the file within the same volume. -Mark

• Anonymous
  January 01, 2003
  Thanks for the feedback and the correction, Erwin.

• Anonymous
  January 01, 2003
  G'day Mark, just one small correction: "When you “Move” a file using Windows Explorer, the file permissions are moved with it.  When you “Copy” a file using Windows Explorer, it creates a new file that inherits permissions from the target folder." This is only true when moving files that reside on the same volume (or partition), moving between NTFS volumes inherit permissions. A small correction but very crucial to understanding how NTFS permissions differ when moving and copying within or between volumes. Wayne McGlinn Brisbane, Oz

• Anonymous
  January 01, 2003
  Nice piece if sleuthing. Although the error message is still an indication of just how bad software developers are at writing meaningful error handling code. It's still insane how we have to instantly dive down to the bottom layer to solve these simple problems. And don't even get me started in the bubbling up of a 32-bit error number to the end user...

• Anonymous
  May 14, 2008
  Cool, and better for Tony if the prize was a signed book! Just a little typo: "from the parent to propoage"

• Anonymous
  May 14, 2008
  The comment has been removed

• Anonymous
  May 14, 2008
  Joel Peterson, I think "Desktop" file is different,i reproed your saying.

• Anonymous
  May 15, 2008
  I think the matter of permissions and their intricacies needs to be clarified a bit. Here is what I have learned: As mentioned above, Windows API, by default, retains all of the file and folder permissions when you move them from one parent folder to another parent folder on the same NTFS volume. For copy operation and move operations to another volume, the destination file always have a new set of permissions, all inherited from its parents. The reason is obvious to a developer: When you move a file within a volume, no physical data transfer seems to occur; Apparently, Windows only changes the volume Master File Table so that the intended files and folders belong to a new directory entry. This means that Access Control Lists (ACLs) remain unaltered, so even if your Access Control Entries are acquired from a parent. Now, it is arguable whether or not the inherited permissions should be updated with the new parent or not, and whether there is a bug here or not. However, during a copy operation, or a move operation to another volume, a physical data transfer from one location of the hard disk to another is inevitable. Therefore, Windows API has to build a new ACL for each file and folder entry. These new entries turn out to have permissions inherited from parent. As demonstrated by Joel Peterson, .NET Framework has the same behavior as Windows API. Windows Explorer (Windows Shell) tends to deviate from this behavior. According to Microsoft Knowledge Base:

1. On Windows XP, when Simple File Sharing is enabled (default), Windows Explorer always makes sure that all ACLs are reset. This an intended feature that makes using Standard User Accounts in homes and small-business environments more convenient. Note that this only applies to Windows Explorer and Windows Shell, so file operation behavior of programs like Command Prompt are not affected by Simple File Sharing setting.
2. Windows XP, when Simple File Sharing is disabled (domain default) and on Windows Server 2003, Windows Explorer does not alter file and folder permission. This is meant to be an intended defense-in-depth security feature. So far I don't know the exact behavior of Windows Vista and Windows Server 2008. The KB article which WDoser introduced indicates that Windows now updates ACEs which are inherited from parent but does not explain whether it is a Windows API behavior or only a Windows Shell behavior. To make matter worse, the Applies To section says this article is applied to all editions of Windows Server 2008 but not Windows Vista. (I think it's time I investigate this matter a bit more.) Unfortunately, the example posted by Joel Peterson also does not help clarify matter with these two new versions of Windows, since it is in C# and therefore uses .NET Framework not Windows API. .NET Framework is supposed to have the same behavior on all versions of Windows; unless otherwise documented in its documentations.

• S. Mahdi Veradi (MCP)

• Anonymous
  May 17, 2008
  This move problem for site content is not limited to FrontPage, I find it's a common problem when moving any site content.   I get a lot of sites come as installers that install to C:Program Filesblah and don't offer an option to set that folder nor set permissions correctly.  When moving to the managed site content folder (C:Inetpub or C:Sites or whatever), weird things happen. 90% of these weird things are because the content was moved, not copied.  This is now our first step in troubleshooting.  Our second step as always is Process Monitor. Pre-emptive rebuttal - this isn't an issue of your content is on a different volume following best practices, if you move from C:blah to E:Sites the move is a copy.

• Anonymous
  May 19, 2008
  I'm still waiting for the "Case of the mysterious idle 12:10am Vista csrss related disk activity that lasts 20 minutes and doesn't show up in procmon even with filters turned off and isn't defrag, system restore, indexing, windows update, superfetch, thumbnail cache updates, trustedinstaller, swap usage, or the drive's idle self test."

• Anonymous
  May 19, 2008
  Apologies to Troy for reading too fast and using the wrong name in my post. I'd still like to get some clarification why the behavior is different between right-click plus drag-move from the Desktop to a folder versus right-click plus drag-move from within a single Windows Explorer window.

• Anonymous
  May 24, 2008
  "I wasn’t feeling motivated to become a FPSE expert just to solve this one problem." should read "I wasn’t feeling motivated to become an FPSE expert just to solve this one problem."

• Anonymous
  May 25, 2008
  The comment has been removed

• Anonymous
  May 26, 2008
  Since copy resets the permissions, it looks like you just need to move files to a new folder then delete the original folder and rename the new folder. Managing permissions is like herding snakes... tOM

• Anonymous
  May 26, 2008
  The comment has been removed

• Anonymous
  May 30, 2008
  Hi All, I am just wondering where the anonymous account gets added in this example, as in the sample images I see no addition of the IUSR_XXXX account (which I assume would need write permissions to create the log file) before forcing inheritance - or am i missing something obvious?

• Anonymous
  August 16, 2009
  Excellent instructions. I tested the Process Monitor and it solved my problem of missing security settings!