In this article I want to expose a problem (and a solution 🙂 ) that I encountered in my customer that use TFS 2018.2
The client reported the following problem to me: since he upgrade from TFS 2018.0 to TFS 2018.2, he no longer receives all notifications emails that are sent either when a pull request is created, or when there is a change on a Work item on the “Assigned To” field. Sometimes users receive emails (but it’s rare) but in most cases emails are not sent.
Before this upgrade, sending emails by TFS worked very well.
My investigation focused on different topics:
- The configuration of the smtp server informations in the TFS Administration Console. In this side, the configuration is correct and has not been changed with the upgrade.
- Investigate on the job agent history for try to get a raison of the failure:
In the TFS Configuration database I executed this query :
SELECT TOP (1000) [HistoryId],[JobSource] ,[JobId],[QueueTime] ,[StartTime] ,[EndTime] ,[AgentId],[Result],[ResultMessage] ,[QueuedReasons] ,[QueueFlags],[Priority] FROM [Tfs_Configuration].[dbo].[tbl_JobHistory] WHERE ResultMessage LIKE '%mail%' order by StartTime desc
and I get this result
When I open a provider link in ResultMessage column I get a Json with the some details of the job history, here a sample of this json
I can see the status : “Send failed”, but not any more informations with the reason of the error.
So, I sended this context to Microsoft VSTS/TFS product team…. and after few hours they answered me with the solution.
The provided solution:
“The only one reason that user’s may not be receiving email notifications it’s the timeout. This timeout error is not actually that common of a problem unless latency is high because Smtp is a very chatty protocol.
The timeout value is 10 seconds so I highly suspect that is the problem.
The timeout value is in milliseconds. To extend the timeout to 60 seconds, run this command in the configuration DB:
exec prc_SetRegistryValue 1, '#\Service\Integration\Settings\SendTimeout\', 60000
To revert back to the default timeout value:
exec prc_SetRegistryValue 1, '#\Service\Integration\Settings\SendTimeout\', null
I applyed this and now all working fine the customer receive all emails notification.
Thanks to Microsoft Product Team 😉