I think there are some misunderstandings here that we need to clear up before we can talk about the potential viability of any new feature request.  The behavior of the command line passed to 30agent.exe actually depends on whether or not it is already running. In normal conditions where MSP is being used as designed, 30agent.exe WOULD be running.  So, when you run it with a command line, it is launching a SECOND INSTANCE of the same program.  In such a case, the second instance detects that it IS the second instance and sends a message to the first instance asking it to do whatever the command line said.  But since the first instance might be busy doing something else at the time, it may not respond to that message right away.  The second instance exits as soon as it has sent the message, without waiting for the requested action to be performed.  So, there is no way it can return what the result of that action was, since it may or may not have even happened yet when it returns. There is an alternate way to use this where 30agent.exe is not generally running and is only run programmatically when needed.  This is called external control and is NOT a supported use case, although on rare instances we have worked with customers to make it work when there is a sufficient business case.  But unless you have approval and committed support for such a solution, attempts to use it, and any problems that occur as a result, would NOT be supported.  In such a mode, if 30agent.exe is run with a command line when it is NOT already running, then it will be the FIRST INSTANCE and hence it will execute the command line immediately and then EXIT.  In such a case, it COULD (but doesn't) return full information about the result. Having explained all that, there may be an oppotunity for a new feature here, but it may not be what you were thinking.  It is likely NOT practical to support launching a SECOND INSTANCE that returns information about the result of an action requested oft the FIRST INSTANCE.  If an action is requested of a first instance from a second instance, the second instance CANNOT practically wait for the action to finish and hence it cannot return the result.  But what MIGHT be possible is to have a programmatic way to request status of the FIRST INSTANCE.  This could be performed in a loop to watch the progress of the first instance and the results of what it does.  If there was a need to programamatically initiate a check-in, for example, after REQUESTING that check-in, it might then be possible to programmatically WATCH that check-in happen and determine the result(s) of that check-in.  Results might include a wide variety of things, including: Results of Evaluation of Check-In Conditions, Results of Connection to Relay Server, Whether Jobs were Pending, Whether Jobs were Deferred or Detached, Whether Jobs were Executed and the Results of Job Execution, Whether a Discovery Document was Sent, etc. DevCentral is a forum for informal discussion, which is what we are doing.  But DevCentral is not a forum for the formal request of new features.  If, based on this discussion, you want to formallly request a new feature, the GRIP process is the proper way to do that.  But hopefully, discussion of the details of current operation and the merits of new ideas may lead to better new feature requests that are more likely to be practical to implement and to be deemed value and worthwhile to add to the product. Allan

Kjell; It would help us provide a more complete reply if you provided more information about exactly what you are trying to do. As stated in the MSP User Guide, the -J command line argument does the following: Start the MSP Agent, if it is not already running, contact the Relay Server, if allowed by connectivity and check-in conditions, process all pending Jobs, in sequence order, up to the first Job that becomes blocked, and then exit.What error code were you expecting to get back.  Even if there was some sort of error executing something within a specific Job, that would not stop the MSP Agent from executing other Jobs.  So, there is no ONE error code that it would make sense to return.  And if the MSP Agent is unable to check-in due to connectivity, that is also not an error, since the MSP Agent is designed to retry the next time.  So, unless the MSP Agent found something fatal that was wrong that prevented it from even trying to perform the requested command (e.g. disk errors, folders missing, etc.), I would not expect any error to be returned.If you are looking to find out if something specific succeeded or failed, then looking into the log file may be the only way, since how could the MSP Agent know which of the many operations it may have performed that you were interested in knowing about?If there is some specific situation you are trying to solve, please provide more details and we will try and help you out, if possible.Thanks,Allan

I guess what Kjell wants to retrieve are NOT 30agent execution actual errors, but the potential ones reported by the UI. It would be good to know if uploading->installing did succeed, wouldn't it? Those "errors" (well, let's better call them "results") are all of the -8XX and most -10XX ones. If UI is well printing them on the display I do not see why 30agent could not return the same value to the OS (or CreateProcess). Obviously, success should return 0. I am pretty interested in this too.