For agent based tasks – like the defrag task – the call to run the task is passed to the agent via the existing communication channel, 5723 TCP.  This is opened FROM the agent TO the management server initially, and once opened, the communications are two-way.  The management server sends down the task instruction, and the monitoringhost.exe worker process calls it locally on the agent monitored machine.  It will run under the credentials of the default agent action account by default, unless you have configured the task to leverage an existing run-as profile/account, or supply alternate credentials at run-time.  This is why restricting tasks is important for operators… because THEIR user account might not have rights to run a specific task on a server – but OpsMgr enables them to execute these tasks, by sending an instruction for the agent to run it.  This is good because it enables your support desk to perform common tasks without having to grant specific user rights on all the servers.  It is bad if you don’t realize this – and are granting access to tasks to operators that you don’t want them to have.

For console based tasks – these always run under the logged in user account that is running the console – and the specific ports are totally dependent on the console application – it has nothing to do with SCOM because SCOM is simply calling some application like running a shortcut on a desktop.

==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/momlist/

==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/momlist/