I have a TFS Azure DevOps Express server running at home - last night I updated it to latest version, since I wanted to start developing some .NET 6 application and I thought it was best to run the latest version of the build server.

When I logged onto my computer today I saw a bunch of mails in my inbox, where the Azure Devops service had sent me information about transaction log backups being successful - one email every 15 minutes.

I did not remember having received these mails so often before, so I wanted to reconconfigure the backup to see if I could change the backup to not send me mail every time it succeeded in doing a transaction log backup.

Unfortunately it seems like there is only two settings: Do not send mails - or send mails.

So I decided to change the schedule from every 15 minutes for transaction logs to something more sane for my purpose - to get rid of the email spam.

But when I reconfigured the the backup settings I got the following message TF254027 - which was just a general - something is wrong - but the real culprit was TF400997 - which basically is TFS thinks my sql server is running with an account it cannot grant permissions on the backup path:

Of course in my case it was a bogus error, since the account had been running previously happily taking backups.

Looking up the error message you get all kinds of errors about its because the account should be a real user account and not a LOCALSYSTEM or similar account - but since that was not the case I digged a little more and then I found this post.

Which explains basically that there is a BUG in how they resolve the account type if you have configured your Service account using username@domain syntax - instead of using the old fashioned DOMAIN\username.

So when I reconfigured my service to using DOMAIN\USERNAME.

I got this nice message instead:

The weird part is that the backup was running fine and has been running fine forever, but somehow their validation code has this bug.

The sad part about this is that the microsoft person just closed the issue as “Not a bug” - which in my opinion is just silly - if windows allows service accounts to be specified as user@domain then of course their code should be able to handle that as well.