Timer job fails when farm account does not have permissions on outgoing e-mail server


The timer job will always fail when the farm account does not have the (read perf counter) permissions on the box that is used as outgoing e-mail server. Outgoing e-mail server is treated as a server in the farm (as an invalid one) and the farm account does not have permissions by default to read the necessary perf counters which causes an exception in the timer job. The exception is taken care of but sets string values instead of double values in the data that is pushed in to the list, which causes the list update to fail.
A workaround is to change the AddServerDetails() method to have this check:
Double result = 0;
if (Double.TryParse(taskMgrInfo.CPUUsage, out result)) {
            spFarmTopologyListItem[Global.cpuUsageColumnName] = taskMgrInfo.CPUUsage;
            spFarmTopologyListItem[Global.freeSpaceDetailsColumnName] = taskMgrInfo.SystemDirectorySpaceUsage;
            spFarmTopologyListItem[Global.freeDiskSpace] = taskMgrInfo.DiskFreeSpace;
            spFarmTopologyListItem[Global.diskSpaceCapacity] = taskMgrInfo.DiskCapacity;
            spFarmTopologyListItem[Global.freeSpacePercentColumnName] = taskMgrInfo.SystemDirectoryFreeSpaceInPercentage;
            spFarmTopologyListItem[Global.memoryUsageDetailsColumnName] = taskMgrInfo.MemoryUsage;
            spFarmTopologyListItem[Global.freeMemorySpace] = taskMgrInfo.FreeMemory;
            spFarmTopologyListItem[Global.memoryCapacity] = taskMgrInfo.TotalMemory;
            spFarmTopologyListItem[Global.memoryUsagePercentColumnName] = taskMgrInfo.MemoryUsageInPercentage;


AravindKS wrote Oct 13, 2011 at 5:49 PM

Can you try configuring the SharePoint timerjob windows service to run in domain administrator credentials? The timerjob will try to execute with the credentials which has been used for it configuration. Probably the domain administrator credentials should have permission to make WMI calls to the SMTP server machine. I will surely make a note of it and will take care of it in my next version.

Thanks for logging the issue.

wictor wrote Oct 13, 2011 at 6:26 PM

Seriously? That is no solution you could use in any other scenarios than testing. Running the timer service as domain admin is as worst practice as you can get. My code change listed above does the trick just fine, and I'll use that for now. It works great and we have a visual representation of the farm health.

AravindKS wrote Oct 13, 2011 at 8:37 PM

Good to hear about your work around but I'm still not convinced why its evil to run SharePoint timerjob with domain account credentials. Timer Job is a secured windows services which runs in your environment. Timer job executes the operation which you have trusted and have scheduled. So I dont find any security threat or evil in running the SharePoint timerjob with Domain admin credentials.

Moreover to solve all (many) permissions issues only, we came out with timerjob rather than other options.

wictor wrote Oct 14, 2011 at 7:26 AM

Running the timer service as domain administrator is still not recommended (by anyone). Yes it's a "secured" Windows service, but when running this using domain admin creds you give it far to much power and no granularity in control.

My suggestion is that for the SMTP server (which is actually not a part of the farm, even though it's listed as an SPServer) is treated differently than the other servers. It's interesting to see if it exits and is alive (a ping might be sufficient).

brianlala wrote Oct 15, 2011 at 5:17 PM

I agree with @wictor. Running the timer service as a local admin is generally agreed to be bad practice; suggesting we run it as a domain admin is just... crazy.

On the positive side though, this add-in has huge potential though, looking forward to a proper fix/workaround!


wrote Feb 14, 2013 at 1:49 AM