We restarted the server and still have the same issue: FSRM user quota determines the owner of a file is "NT Authority\System" yet NTFS shows the owner of the file is the original user. This causes the notification email to go to a blank 'TO:' field because "NT Authority\System" has no email address. ALL our user accounts have email addresses though. We have verified many of these instances and found that in every randomly chosen case the NTFS security differs from the Event log, which shows Event 12324; "User NT AUTHORITY\SYSTEM has exceeded the limit for the quota on D:\DFSRoots\user\userhome\%username% on server FILE1." Yet the NTFS owner is %username%.
The truly odd part is that the 'error' arises in _most_ cases, but in some cases the Event log and FSRM shows the correct username and the email goes out just fine! It seems though that if it's working for a single user, it works every time; where if it's broken for a user it's broken every time a file is saved. What can cause the Event log to capture the wrong file owner??? TIA (Thanks In Advance!) On Sat, Sep 19, 2009 at 9:03 AM, Stephen Wimberly <riverside...@gmail.com>wrote: > We have been using the Quota system in Windows Server 2003 R2 FSRM and it's > been working perfectly up until Thursday of this past week when we applied > two updates via our WSUS server, "update Microsoft Silverlight 3.0.40723.0" > and "update Microsoft .NET Framework 3.5 SP1 update KB963707" and restarted. > > During the restart though the closest domain controller was in the process > of restarting as well and was not responding 'correctly' and needed a hard > reset. The file server displayed the following error: > > "File Server Resource Manager failed to enumerate share paths or DFS > paths. Mappings from local file paths to share and DFS paths may be > incomplete or temporarily unavailable. FSRM will retry the operation at a > later time." > > Now each time a user saves a file that they have ownership of, FSRM > captures the 'owner' as NT AUTHORITY/SYSTEM rather than the user. The email > goes out, but the TO line is blank! (NT AUTHORITY/SYSTEM has no email > address.) It might be helpful to know that we have configured the > Additional Email Headers to include a few emails within the BCC line, this > is how we were 'notified' that the emails are going out without a TO listed. > > NTFS Security: Looking at the files that are causing these notifications; > the user is saving files to their home directory in most cases, the user is > listed as the owner and the user has a valid email address in the Active > Directory. In most cases these are users that used to receive quota > notifications! > > I am tempted to just restart the server again, but it's a production server > that hosts some 7x24 applications and the notification period for a restart > is 'complicated.' If I was sure a restart would fix the issue I'd be all > for it. > > I've done some searching, but I haven't found anything helpful yet. Anyone > seen this before??? > > Thanks! > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
