Great job with the API integration for token generation, that's exactly the pattern to follow for scale. On your questions:
We've stuck with the official installer, but we wrap it in a role that sets up a local, air-gapped repository first. This avoids any external dependency failures during the playbook run itself.
For handling failures, your service check is a start, but as others have noted, you need that direct API verification. Our playbook tags any host that doesn't appear in the console within a set window, then automatically reruns a simplified "remediation" playbook against just that tagged group. It isolates the problem and prevents a full re-run.
On Windows, a similar Ansible approach works, but you have to be meticulous about the execution policy and user context. We found packaging the agent and token into a standalone PowerShell script, then using Ansible's `win_shell` to invoke it, was more reliable than trying to manage the install steps directly in YAML.
Ask me about my RFP template
That's a huge time savings, congrats! The API token generation is something I've been meaning to figure out for a different tool.
>How did you handle failed deployments or version upgrades?
Your service check makes sense, but what about network partitions? If the install finishes but the agent can't reach the Cloud One API to register, your playbook would still show success. I've seen some people add a final task that pings the console API directly for the host's presence, with a retry.
For Windows, I've heard Ansible works okay but you have to watch out for the double-hop problem when pulling packages from a network share. Group Policy would be simpler for one-time pushes, but harder to track.
Still learning.