SCOM 2012 Linux agent update fails with no tty present and no askpass program specified

While I was upgrading a bunch of SCOM 2012 Unix/Linux agents to a higher rollup level the other day I noticed an error on one of them. I need to quickly say that upgrading the agents was otherwise a breeze by just selecting a few of them and using the update agent option and using stored credentials and waiting for about 15 seconds. Was a great experience. However one of them was resisting and threw the following error:
Failed to update the cross platform agent. Exit code: 1
Standard Output: Sudo path: /etc/opt/microsoft/scx/conf/sudodir/
Standard Error: sudo: no tty present and no askpass program specified
Exception Message:

That is strange, because an agent was already installed on that machine so something must have changed somehow. It needs the same rights and settings to upgrade the agent.
So we checked the /etc/sudoers file on the machine.
First we check if the requiretty line is commented out:
#Defaults requiretty
Next we check if the account we are using for the monitoring and updating has the use of a password to elevate to sudo turned off (am using a different account of course):
Hmmm, that is set correctly as well. Alright lets test these settings.
Login with this user through ssh. Give the command sudo bash. If it asks for a password something is wrong.
And it did ask for a password in our case.
As it turns out this settings file is read top to bottom and unlike some firewall for instance it doesnt evaluate the first match, it evaluates the last match. Scrolling down there was another line in this config file where the wheel group got sudo rights with the following setting:
%wheel ALL=(ALL) ALL
Aha, so the NOPASSWD setting was different there and because our monitoring/management account was also a member of the wheel group and this line was further down the sudoers file it got evaluated last and won.
Simply move the line with your monitoring account to below the wheel group line in this example and it will work. Simply checked by testing again.
The update of the agent went fine after this.
Happy monitoring!
Bob Cornelissen