I’d like to request ImmyBot either send an email on update failure or better yet log a service ticket in CWM. Feature to be on/off per customer, allowing us to be aware of, and manage the failures.
(sorry, I know we use Immy for more than deployment so it’s a different one)
I agree this needs to happen. What I’d like to discuss is whether these failures should be rolled up into 1 ticket and if so should the ticket be created against the client and attach a configuration for the machine? Should a ticket be created per computer and per failing action? Should there be one ticket created with all failures from a session? Should we instead wait for maintenance to be over and open one ticket for the item in question and show all the computers it failed for versus the machines it worked for?
If a specific item failed for every machine, should we not even bother opening a ticket because it’s probably something we need to address globally?
I too would like this sending an email to Autotask would solve a lot of managements concerns about visibility of issues with Immybot.
regarding the distinct device vs distinct item failure, maybe make that a choice when setting up the alerts?
Perhaps as a starting point, one report per schedule gets generated. The design of this “report” would essentially be a matrix style report of machines along one axis and maintenance items along the other. The schedule should include the time to send the report–if there are machines pending connectivity that did not run maintenance, then that should be indicated in the report at the time of send. One method of controlling what appears on the report can be a setting on the deployments themselves. I think out of this will come further ideas and refinements that will ultimately suit the majority of common use cases.
Same boat, this would be a great feature.
For us we’d rather the end users not get these email but as us the MSP be notified when immy does take actions or if further action is required if Immy can’t resolve.
For a deployment/onboarding I would think single ticket with all actions taken for the single machine.
For a schedule a single ticket per client/tenant with all computers actioned in that tenant 's schedule.
Hey Darren and team,
So an onboarding would be a single ticket and a failed session would be a single ticket with an aim to resolve on a per device basis.
Every MSP will handle tickets differently, but rolling up into one ticket across multiple devices never works well. Providing optional flexibility would work wonders for different organisations.
I wouldn’t separate each individual software failure as a single ticket. If a session fails, the team member would go and see why and attempt resolution.
Just my brainstorm and concept behind it. At this point any scheduled visibility would help us identify where machines are falling over on their updates.
UPDATE: 100% to be assigned to the customer so we can manage effectively.
Amazing idea. Hope the devs implement it.
I’m not certain everyone would want 1 ticket per endpoint. I have a client that has 200 endpoints–imagine that there is a deployment that failed because the version on the website could not be downloaded or properly installed to ANY machine–that’s an instant 200 tickets.
I’m starting to lean toward either 1 ticket per schedule, or 1 ticket per deployment. I think ticket per endpoint is just asking for mayhem.
Appreciate the feedback.
How will teams be able to identify a problem machine?
Could you not create a rule in the alert to say if there are more than % amount of failures for that deployment, log a single ticket?
How do you know the machine is the problem? (Forest vs Tree).
The idea would be that you have a list of compliant/non compliant machines within the ticket.
Agreed. We use Connectwise as our PSA.
A single ticket per deployment, attaching the configuration item would be amazing. in reducing unnecessary ticket creation.
Came to ask for exactly this. I’m working on using Rewst to do this with some logic, but some “dumb” ticket generations would be great.
Have you made if far building it out in Rewst? Happy to work with you. I haven’t got to that yet but awesome idea
Not far. Immy has an API, but its not well documented (if at all). I’ve put it on a backburner pending Rewst’s refactoring of the CWM Integration.