to what local account you are mapping your role/user, you can check this in export,users,users.local files and check if that user is in Administrator group.
The answer is in the error message: Connection timed out
This means the app server was unable to reach the agent at the time of the job run. This could be due to the one of the following:
- Network timeout
- The agent is unable to answer the request due to high cpu usage on the remote server. I have seen cases where a server would give this error in BladeLogic because its CPU was used at 100% by another application. The RSCD agent runs with a normal processor affinity so if someone else takes all the juice, it won't be able to answer and it's normal.
This is why you don't see anything in the agent's log, it never gets there to begin with.
Thanks for the replies.
I finally discovered the issue:
This particular server is behind it's own firewall. I knew that the firewall was allowing connections over 4750 from the "main" BLAPP server. However, there are 4 different BLAPP server instances which the BL Administrator had set up. Whenever I ran the analysis job, it was using one of the other instances, thus not coming from the "main" BLAPP server. Once I created a new analysis job, specifying the server to be the "main" BLAPP, the job succeeded. This explains why I could do things such as live browse without issue, which threw me off.
I'm not sure I'm making sense with my terminology of "server instances" and "main" BLAPP because I'm not the BLAPP Administrator. Each BLAPP instance apparently has it's own IP address, thus the firewall deny when the job isn't coming from the "main" one.
"Once I created a new analysis job, specifying the server to be the "main" BLAPP, the job succeeded."
-> so you setup a job routing rule for this job to run from the 'main' appserver ?
you need to make sure all appservers can connect to all targets on 4750, otherwise you defeat the purpose of having multiple appservers.
Thanks for the reply.
This is the only server out of about 300 Windows servers for which we need to use this workaround. All of the others are reachable over 4750 from all of the blapp servers.
This is an oddball machine which is not in our data center (like all of our other servers). Because of this it's behind its own Pix firewall and nobody seems to have had responsibility for maintaining the FW rules since they were set originally. So once I discovered what the problem was, I realized it was easier to do this workaround than to try and chase down the person responsible for the FW.