/build/static/layout/Breadcrumb_cap_w.png

Since upgrading to v10 we can not reply to emails from our service desk to update the ticket.

When replying to a new servicedesk ticket via email we receive the following error since upgrading to version 10 on the k1000.
---------------------------------------------------------
Subject: [$ticket_number] ERROR

While handling your email to CARBO Helpdesk, the following errors occurred:
User is not allowed to update the ticket.
-----------------------------------------------------------


This is a huge problem because the majority of our techs do not log into the servicedesk to update their tickets.


Has anyone else had this issue since upgrading?


I have a ticket in with support but was wondering if this is just an issue with our system or with the upgrade itself.


15 Comments   [ + ] Show comments
  • We updated last night and have the same issue. Just noticed it. No solutions yet, but I'll check back if I find anything. :) - CNIamy 4 years ago
  • This is not good. This is the second update that has broken the functionality of our service desk. My group keeps hinting that we should switch to a different solution. We have been a kace (kbox) user since the very beginning of the product (even before dell owned them) and we haven't had these kind of issues until quest took over. - pbroussard 4 years ago
  • So... just got off the phone with support and they said it is designed that way and that they will try to fix it but it is not guaranteed. Reply your experience to see if you get the same answer. - pbroussard 4 years ago
  • So, just to be clear are you both saying that you are now unable to update tickets from incoming emails i.e. when a tech responds, the ticket is updated? - Hobbsy 4 years ago
  • If a ticket or email is generated, no one but the current owner of the ticket can update it via email. This includes other owners in the owners label for that queue. This is a issue for our group because we leave our tickets as unassigned so that we can grab them when we can. On weekends, I don't want to have to launch a vpn and browser every time I have to tell someone to reboot their computer. - pbroussard 4 years ago
  • This has caused many issues for us as well. we have Techs that go to lunch or have a day off and managers ask for updates, they get the error and then complain about the erroneous message.
    Also when trying to get additional details to assign to the correct Tech, we are being spammed with ERROR emails - Vfrancois 4 years ago
  • We received a hotfix from support. Please contact support to see if they can give it to you. I would give it but it might break something on your box. - pbroussard 4 years ago
  • We got the hotfix also and thought it resolved. Until today when we got a terrible loop between our 3 queues that we can't track down. Waiting to talk back to support now. - CNIamy 4 years ago
  • We updated our KBox a couple of weeks ago. I suppose it's been about that long since I've needed to update any other tech's tickets through email, but now I'm getting this same message as well. I'm the Help Desk Lead and I regularly monitor our other tech's tickets. I have full ability to edit the tickets from within KACE, but it is very useful to also be able to update tickets via email and I'm now rejected for any tickets that are not mine or unassigned. This last comment about the hotfix causing a loop seems more disastrous, so I think I'll hold off calling support for the hotfix right now. But I do hope this issue is resolved soon! - atoss 4 years ago
  • We were also having the same issue where only the Submitter could add to a ticket via email since the v10 upgrade. I reached out to Quest Support and they sent me the following link.
    https://support.quest.com/kb/309947/queue-owners-cannot-reply-to-tickets-they-do-not-own
    They are aware that queue owner (technicians) should be able to add via email and this "should be addressed in a future release." - nwareing 4 years ago
  • We have the same issue but if a ticket is moved to a different queue there is an error email created and then that email generates a ticket. The new ticket generates an error email which then creates a NEW ticket. This keeps going around and around creating new emails that create new tickets until you are either able to delete the email from the inbox before a ticket is generated or you clear the check box for "Use POP3 server for inbound emails". - bkmilyard 4 years ago
  • Are there any updates on this? I just updated to V10 last week and we have run into numerous problems with tickets being created with Subject: [$ticket_number] ERROR. Hotfix did not fix our issue. - chris.moore 4 years ago
  • we also have just recently upgraded and now can not have others reply to tickets if they are not the owner... Is there any fix for this yet? - sbaxter 4 years ago
  • This is ridiculous, but more to the point indicative of the mess that the KACE solution has become since Quest took over the product. They have been plagued by minor "annoyances" (custom designed portal pages breaking, links not working...) that have been more hassle than anything, but this is a failure of core functionality. Even as the System Admin I cannot reply or comment via email on any ticket of which I am not the owner. And this is by design? Who designed it, a drunken elf?

    We have been using the K1000 appliance since shortly after Dell acquired the product and I have never had a major complaint. Attending Bootkamp just made me like it even more, then Quest happened.

    We operate a multi-organization environment servicing SMBs in a large metropolitan area. We have been able to maintain enterprise level support across these disparate user groups in large part because of the flexibility of the Service Desk solution. Quest has not only impaired that flexibility...they have flat out broken it. Our field techs have always been able to comment on tickets to give our Service Desk personnel "eyeballs" at the client site. Now they are restricted to using their cells phones to "update" the SD personnel so the SD personnel can then "update" the ticket. If this weren't so detrimental to efficient service it would be laughable. As it is it is just another case of the incompetence of the Quest programmers. To add insult to injury, we just ponied up over 14K to renew our contract and get some more bells and whistles. The fact that this has been going on for over a month and all they have to show is a broken hotfix is indicative the lack of leadership and foresight at Quest. - dkoch@griffinnet.com 4 years ago
  • Dealing with this now as well. We utilize ticket emails and replies to them to manage 4 different request queues, with divisional controllers/HR folks tied to Location assets. All built lovingly with Quest Pro-Services over a month or so. Worked great, my users love it because they can "approve" requests with just an email reply thanks to ticket rules which process said email comments.

    All broken with 10.0 - and none of this is documented ANYWHERE in the release notes, which is incredibly frustrating. Just logged a ticket with support. lets hope for the best. - Asevera 4 years ago

Answers (2)

Posted by: k8s 4 years ago
Orange Belt
1

We had this problem even with 10.1, so not from quite the same bug that was fixed with 10.1 and a special 10.0 hotfix. (See https://support.quest.com/kb/309947/queue-owners-cannot-reply-to-tickets-they-do-not-own, or reference Defect ID ESMAS-4710.)

In our case, we had two KACE users sharing an email address, only one of which was labeled as a queue owner. They belonged to the same human; one was an admin account for configuring the KACE SMA appliance, and had no actual mailbox, but the SMA requires an email address for every user for some (ridiculous) reason. Resetting that to a bogus address instead of the human's address works to fix the problem and allow the human to update tickets via HTML email, which is also the only way to insert inline (embedded) attachments or multiple attachments in one comment (also ridiculous).

I hope this helps someone in a similar situation. I just deduced all this as I was creating a service request with Quest; maybe I'll make one for these issues anyway, as a bug report / known-issue documentation request.

Posted by: sam240 4 years ago
Second Degree Blue Belt
0

This was resolved for us with 10.1 upgrade. You also have to make sure that the POP3 Username (email address): you use in Ticket queue email settings, You have to add that as owner of the queue which you do under settings --> users--> find the pop3 username email address, select and apply label and choose the queue owner label. This user will also show under your "Ticket owner" going forward. 



Comments:
  • This is promising. We have just upgraded to v10.1 in our DEV system where everything works as expected, but are hesitant to put into production. - Frankii 4 years ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ