You say "That is not a non-existing login...", then why SQL is not finding it as you you can notice in the following alerts I am receiving?
Sorry, for some reason i read your post as you were thinking that this login does not exist in Windows. Which it does. Except that Windows does not really use the term "login", so that was bad reading on my part.
It was running under NT SERVICE\SQLAgent$SQL2K12 and not SQL2K12$.
But that account is a local account, so when connecting to another machine, connection will be by the machine account.
Also, I visited your thread, in step 4, you indicate "On the first page, set sa or some other non-person who is sysadmin as the job owner...." but this does not exist in the interface
But the screenshot is for setting up a proxy. The screenshot below shows which box I'm talking about:
However, that box will not work with access to linked server with self-mapping. (Which is what you have.)
on local and the 2 remote servers, when I execute as CMDexec the job I get
Message
Executed as user: salam\ApplJobRunner. Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : Login failed for user 'SALAM\ApplJobRunner'.. Process Exit Code 1. The step failed.
Obviously, you need to create a login for that Windows user on the other server.
I have just noticed that you say in your article "and adds it to the AD group(s) needed for the application in question.....", which AD groups, I have no specific app for this it is just a sql agent job trying to access a table on a remote server
Well, "the AD group(s) needed for the application in question". That is, I'm assuming that you already have an AD group for users accessing the application. Although what I have in mind here is the local database. The key point is that the login, and thus the job, should run with elevated permission. When it comes to the linked server, I would suggest that the same thing applies, although exactly how you do it, depends on your local situation.