Why are you going with NSH script/EO approach? No need of either of approach you have mentioned. Also we cant have a smart group for
"No authorization to access host". Agent status property can only have below values.
agent is alive.
agent is not responding
agent is not licensed
agent is not installed.
so in your case it is agent is not responding(this value will be set once USP job is executed against the server)
Just execute Update server properties Job(recommended to execute on daily basis, at least twice a day). This will change the server property called agent status to as below.
AGENT_STATUS agent is not responding
creating a server smart group with AGENT_STATUS equals to agent is not responding will do here.
Once the USP job is completed all the servers will be available under one group.
Great, but "agent is not responding" status is too general. Agent is not responding status means that:
- agent is down
- machine is down
- no authorizations to host
I need divide 'Agent is not responding' into sub statuses. Would be great to archive it using extended AgentStatus values set in smart groups creation.
I've work around this already by using nsh script (type 2) and in loop I check agentinfo respond which is the base for choosing StaticGroup for checking server.
yeah, If you really need to create sub status for Agent is not responding' then both the options are open. Its up to one's strength and skill to design and adopting to an approach.
1. NSH Script Job
execute the script against servers and then capture the appropriate agent status message(update any server property and then create a smart group using that server property)-- to me this looks a good approach
2. Extended Object
create a EO to capture agent status and use then create a component template using the EO and run a discover job. Based on the discovery job result you may create some smart server group as required. -- looks little complex.