All of a sudden we must have touched something because we can't log in with stock agent loginIDs, e.g. 50015.

TSAPI trace and GENERIC_OPERATION suggest bad state but the agent ids aren't in use anywhere.

Was the Security Database for TSAPI supposed to be enabled out-of-the-box? I disabled it but it didn't seem to help.

06/14/2012 05:24:20.075:TSAPI:cmsim: Received CSTA Msg (CSTAREQUEST)(3) (CSTA_SET_AGENT_STATE)(49)
06/14/2012 05:24:20.075:TSAPI:cmsim: msgoff(24)msglen(196)privoff(24)privlen(0)
06/14/2012 05:24:20.075:TSAPI:cmsim: invokeID(15)monXref(1492189184)sessionID(6)clsOfServ(0)
06/14/2012 05:24:20.075:TSAPI:cmsim: device(40015)
06/14/2012 05:24:20.076:TSAPI:cmsim: agentMode(AM_LOG_IN)(0)
06/14/2012 05:24:20.076:TSAPI:cmsim: agentID(50015)
06/14/2012 05:24:20.076:TSAPI:cmsim: agentGroup()
06/14/2012 05:24:20.076:TSAPI:cmsim: agentPassword(50015)
06/14/2012 05:24:20.076:TSAPI:cmsim: Sent ASAI Message AgtLogin
06/14/2012 05:24:20.076:TSAPI:cmsim: cap,prim,sao_id C_RF_REQ,C_REQUEST,14
06/14/2012 05:24:20.076:TSAPI:cmsim: split_ext *
06/14/2012 05:24:20.076:TSAPI:cmsim: agent_id 50015#50015
06/14/2012 05:24:20.076:TSAPI:cmsim: agt_ext 40015
06/14/2012 05:24:20.076:TSAPI:cmsim: rf_item 2
06/14/2012 05:24:20.076:TSAPI:cmsim: work_mode 1
06/14/2012 05:24:20.081:TSAPI:LinkThread01: Received ASAI Message RFNak
06/14/2012 05:24:20.081:TSAPI:LinkThread01: cap,prim,sao_id C_RF_CONF,C_NEG_ACK,14
06/14/2012 05:24:20.081:TSAPI:LinkThread01: cause_value CS3/12
06/14/2012 05:24:20.081:TSAPI:LinkThread01: Sent CSTA Msg (CSTACONFIRMATION)(5) (CSTA_UNIVERSAL_FAILURE_CONF)(53)
06/14/2012 05:24:20.081:TSAPI:LinkThread01: msgoff(24)msglen(4)privoff(0)privlen(0)
06/14/2012 05:24:20.081:TSAPI:LinkThread01: invokeID(15)monXref(2989)sessionID(6)clsOfServ(0)
06/14/2012 05:24:20.081:TSAPI:LinkThread01: error(GENERIC_OPERATION)(1)

"but the agent ids aren't in use anywhere" how do you know that? Have you checked the SAT 'list agent"

Is x40015 still in-service (status station 40015). If it has gone out of service Communication manager has lost communication with the virtual gateway for the hardware, and your recourse is to restart the Communication Manager virtual machine. remember to save any configuration changes you may have made before restarting (save translation). then reboot the virtual machine from linux.. 'sudo reboot' or "sudo shutdown -r now"

The aessim/Aessim12# user has unrestricted SDB privileged... so disabling the SDB is not needed.

Correct, I ran "list agent" and "status station 40015" before posting. The station shows "in service".

have you rebooted Communication Manager? and afterwards do you still have the problem?

If I take the device off-hook via DADs softphone I can log in.

This wasn't always the case... why???

Did you enable auto-answer at the agent or station?

An auto-answer agent must be in an off-hook state all the time or they will be logged out.

Yes, both set to Auto Answer = acd

Should I turn auto-answer off on station level?

I've been looking at this thread too:

https://devconnect.avaya.com/public/forum/d_forum_3.jsp?t=8991&f=26

It implies:

Agent Auto-Answer = acd
Station Auto-Answer = none

but I want to be "off-hook" when were logged into an agent-loginID

for an agent to be logged in, and auto-answer set to acd, they must be in an off-hook state. I have not played infinitely with permutations between station and agent, but my guess is the agent setting trumps station setting.

Question is when using the simulator how do we simulate an agent being "off-hook" since we don't have any hardware and headsets to "plug-in"?

you use the simulated DCP stations in the 40xxx (or 7xxxxxx, or 9xxxxxxxx) range. use the dads console to launch them, and then use the go off-hook button on the station. I'd use the 40xxx stations

Yes, we're using 40xxx thanks.

John, was the default for those out-of-the-box simulator?

Agent Auto-Answer = none?
Station Auto-Answer = station?