When starting xcomtcp.exe, it will first query the status of the xcomdsrv service, by using the OpenService and QueryService Windows functions. These requests might fail because of insufficient rights.
The xcom service 'xcomdsrv', like other Windows Services, has been assigned particular rights, so that only specific users are allowed to issue only particular commands against the service. This is defined in the Security Descriptor of the XCOM service. To display these rights, issue the command:
sc sdshow xcomdsrv
This will show output similar (or equal) to this:
The Output starts with a couple of strings in parenthesis after D:. This is the Service Discretionary Access Control List (DACL) for the Service XCOMDSRV. The Section starting with S: is for auditing purposes and of no interest in this context (A detailed explanation of the contents of a DACL can be found here: https://support.microsoft.com/en-us/kb/914392).
The data in a parenthesis specifies the particular rights for different groups of users. These groups are specified with a two-character code before the right parenthesis .
So 'BA' represents Builtin-Administrators, 'SY' local system accounts, ‘IU’ Interactive Users and 'SU' is for Super Users.
In the middle are a couple of two-Character Codes like:
As the LC can be found in the above listed codes, All Admins, Local System Accounts, Super Users and Interactive Users are allowed to query the status of the XCOMDSRV Service, but why might xcomtcp.exe fail when being called by a Job Scheduler?
It will fail when the Job Scheduler runs the xcomtcp command for a non-admin user being specified. In this situation the user will not be interactively logged on, but will act as a Batch User. (That’s why the Job Scheduler will fail generally, when this user has not been assigned the right to ‘log on as batch job’ in the machine’s local security policies). Since this DACL does only allow interactive Users (IU) to query the status of the Server, this will cause the error messages when using a Scheduler.