Sending Emails with File Server Resource Monitor (FSRM)

I’ve been working with the Dynamic Access Control stack in Windows Server 2012 for a while now. A part of FSRM has always been (even prior to Windows Server 2012) that you can send Emails with reports to administrators.

Now that this gains more relevance with new File Server capabilities in Windows Server 2012 (Access Denied Assistance), I thought I’d invest some time to configure it and see what I can come up with. I ran into an issue that I’d like to share. Easy to fix, I promise.

I created a new user account “FSRM” in AD and assigned it a mailbox on Exchange and configured the thing just like this:

Exchange-Error Message-2

When I hit the “Send Test E-mail” button, I was expecting to see an “all fine” message. Instead, it barked that sending email failed. Great. Looking at the Event Viewer, I saw this message logged:

Exchange-Error Message

The vital message is “5.7.1 Client does not have permission to send as this sender”. This seems to come from Exchange directly – that’s what I suspected given the NDR Code of 5.7.1. I thought about it and probably FSRM tries to send the email with its own account (computer account?) and not being allowed to do this. After all, I said it should say the email came from fsrm@<domain>.

Looking at the configuration of the FSRM service, it ran as the Local System, which convinced me that I was on the right track. So – I’d better see how I can allow the dropbox-1$ user account in AD (the computer account of the file server) to send mail as fsrm.

Exchange knows this concept and allows this using an Active Directory Extended Right called “Send-As”. You grant a principal the right to send mail as a different principal. Search in my favorite search engine for this revealed a neat Powershell command I could fire on my Exchange box:

Add-ADPermission -Identity “fsrm” –user “DOMAIN\dropbox-1$” -ExtendedRights “Send-as”

Note the trailing $ sign after the computer account name. This is a standard in Active Directory – all computer accounts have a trailing $ sign. This allowed my dropbox-1 machine to send email under the fsrm account I created earlier. Yay!

Since I have more file servers that need this functionality – and this might apply to you as well, if you’re running a fancy DFS implementation – more of these delegations of Extended Rights might be required.

The fix isn’t rocket science to be honest – all it takes is the command above fired on an Exchange Powershell and you’re good to go. I marked the parts you most likely would need to change in bold. If you feel more like clicking, the Exchange Administration Console allows for “Send-As” permission delegation via GUI. But I gave Powershell a go here.

1 Comment so far

  1. Patyi on January 5th, 2013

    Nice one, but this wouldn’t work when the administrator recipient – to whom the test mail sent – is not a public account (the ‘require that all senders are authenticated’ is checked)