Blue status, no agent nodes available, waiting on resource could be due to service not started, firewall, cluster, etc. The first thing to do is go to the box in question and check the service. If the Control-M Agent Listening service is started, go to a command prompt and run "ag_diag_comm" the output should indicate a few primary things, the agent node will display and should match what you have in the job, authorized Control-M server matches the correct server, the ports are accurate and the success of the listening port return. Ensure there are no firewalls between the server and agent. If this is a clustered box, there maybe other issues and I have not had the chance to troubleshoot a cluster, but when I do I'll be sure to add it.
If the ag_diag_comm returns what you expect and is accurate, a firewall is not involved and it's not a clustered box, check from the Control-M server side by running "ctm_diag_comm". In the output you should find agent node available or unavailable and the two pings at the bottom should finish successfully. If the UNIX ping failed, there maybe an issue with DNS. If the pings returned successful, but the agent node status is 'not', go to ctm_menu, option9 and in the menu delete the node (this will remove whatever corrupted setting there are), then run the discover option to re-identify the agent and run the availability tests from either the menu or the command line.
If the Windows agent is giving you a problem from Unix server, run "nslookup" to the host in question. This also needed to resolve for the agent to work properly. If this fails, contact you SA and explain to them the issue, they should be able to handle it from there.
If none of this works, return to the agent and review the files in the ~/data directory. You may or may not see anything glaring, but a call to BMC support is probably your next step.
SQL job runs from command line but not from Control-M and the user is set in the job.
Try changing the properties of the Control-M agent service "log on" tab to the user/password, restart the service and rerun the job. If this works, then the system account is not authorized to run the job and there are a few things that can be done.
A.) For those jobs that require more then system permissions and need to be added to the agent password list use the utility “ctmpwd” (or ctmcpt depending on the version) and adjust the local policies. The policies that need the user account added are:
- Act as part of the Operating System
- Debug Program
- Increase Quotas
- Logon as Batch job
- Logon as service
- Replace process level token
This information can be found in the PDF Control-M Agent for Windows Administrator Guide (pg 20).
To remove a user, go to the ctmagent home directory /DATA and locate the passwrds.dat file and remove the line for that user.B.) The setting in the services "log on" tab can remain, but all jobs executed using this agent will run as that user.
C.) Create a generic local admin account and set the service to run as that account.
'mode' is not recognized as an internal or external command, operable program or batch file. This is one of those gotcha's of the control-m agent on windows. The solution for this silly little sysout message (that doesn't actually affect the job) is to simply copy the "mode.com" file from the c:\windows\system32 directory to the control-m agents home\EXE directory.
Agent Status = not is usually caused by the agent name matching. Go to the agent home directory/ctm/data/CONFIG.dat file and locate the LOCALHOST. The agent name will be listed here and if it's not correctly named to the node you have in the job, you will get agent status equals not in the ctm_diag_comm command or agent not found in agent database.
Blue status, no agent nodes available, waiting on resource could be firewall or box being down. Always check that you can ping the box. Next thing to do is go to the box in question (as the agent user) run "ag_diag_comm" the output should indicate a few primary things, the agent node name will display and should match what you have in the job, authorized Control-M server matches the correct server, the ports are accurate and the success of the listening port returns. Ensure there are no firewalls between the server and agent. If this is a clustered box, there maybe other issues and I have not had the chance to troubleshoot a cluster, but when I do I'll be sure to add it.
If the ag_diag_comm returns what you expect and is accurate, a firewall is not involved and it's not a clustered box, check from the Control-M server side by running "ctm_diag_comm". In the output you should find agent node available or unavailable and the two pings at the bottom should finish successfully. If the UNIX ping failed, there maybe an issue with DNS. If the pings returned successful, but the agent node status is 'not', go to ctm_menu, Agent Status (option9), using the menu delete the node (this will remove whatever corrupted setting there are), then run the discovery option to re-identify the agent and run the availability tests from either the menu or the command line.
If none of this works, return to the agent and review the files in the ~/data directory. You may or may not see anything glaring, but a call to BMC support is probably your next step.
Control-M Option for Oracle Applications (OAP) at the agent level requires certain configuration. After installing the OAP on the agent, depending on your version you need to run ctmoapcfg or oapconfig. In both cases you need to pass parameters:
ctmoapcfg <instance name>
class="bodyText">oapconfig -OAP_INSTANCE <name> -CM_APPL_TYPE <OAP_10 | OAP_11 | OAP_11I >
[NOTE: If parameters are NOT being passed in the job, change the autoedit to “Y” in the ctmagcfg.]