Shawn
I am not sure what you mean by QUALYS scan.
Can you please provide more details?
Is it something that is hitting the EEM ports such that they are disrupted?
It would be advised to not try to write to the EEM ports via some external means while EEM is in use. (default EEM ports : 5250, 509)
Additionally
What are your versions for AE, WCC, EEM.
EEM configuration user store setup, internal or LDAP (single or multiple).
Are your policies defined based on usernames or global groups or dynamic user groups?
If they are based on actual usernames then even if EEM or ldap connections suffer
an interruption as the user's name is in the policies access can be granted as the applications
keep a cached copy of the policies.
If the policies are based on global group membership and the user store encounters
an interruption then access might be denied temporarily until EEM can again
access the user's details (group membership) so then they can be compared against the policies.
Is AE configured to use EEM?
both in autosys_secure and in WCC's AE definition for the instance?
WCC -> login -> Configuration -> Servers ->
<select your server> Preference -> EEM Enabled ?
Also in WCC is the following selected or not?
WCC -> Configuration -> Preferences -> Monitoring -> Job Level Security
-> Use CA Workload Automation AE policies in EEM
When the issue happens do the users lose the ability to see the jobs from AE too?
or just WCC?
Meaning if they go to an autosys command prompt or machine, can they see their jobs
via autorep -J jobname ?
Can users login to WCC or EEM during the time of the issue?
Have you reviewed the logs?
Anything of specific significance?
Can you replicate the issue at will?
If further analysis is needed, like diving into AE, EEM (igateway or dxserver), or wcc logs or webex sessions
then I would agree with Lars, I would recommend you open a support case so they can work with
you directly.
CA support
MarkW