Azure Jane Lunatic (Azz) 🌺 (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
azurelunatic) wrote2015-07-29 11:42 pm
azurelunatic) wrote2015-07-29 11:42 pm
Entry tags:
One! One profanity in scathing critique of helpdesk performance! Ah, ah, ah!
Problem (paraphrased): when user clicks $NEW-PROCUREMENT icon in unified login menu, a new tab opens with only the $NEW-PROCUREMENT favicon, and a blank screen.
User has tested in three browsers, obliterated cookies from the beginning of time in two of them, rebooted once, and gets the same fucking result. User has previously had access to $NEW-PROCUREMENT obliterated by apparent expiration of contract and has had to ask for it (and every other fucking account) back, individually. User is not very fucking happy.
Subject: Escalation: handling of TKT---
Body: Hi $ESCALATION-MANAGER,
First, TKT--- has been successfully resolved as of 7/28. However, there are certain indications that it might have been able to be solved on the very day it was filed, without the excruciatingly painful 23 minute and 59 second phone call with $INCOMPETENT-HELLDESK-DEMON.
I would like some review of what happened with my ticket and why it remained with $MAIN-HELLDESK as long as it did.
I would like some review of how well known some “known issues” actually are, and whether the people who need to know this actually know it.
I would like some training in what constitutes effective textual communication via ticket notes, as it seems that more than one person has failed this badly.
I would like someone to remind $INCOMPETENT-HELLDESK-DEMON that bullshitting the end-user is a bad plan in general, and specifically terrible in a technical company, and see if his training needs updating, particularly on $NEW-PROCUREMENT, $OLD-PROCUREMENT, Java, and Windows 8.
I filed TKT--- on 7/23. I see in the audit history that $NEW-PROCUREMENT-DEMON who seems to have been monitoring the incoming queue for $NEW-PROCUREMENT tasks, remarked “Access related” on my ticket, then reassigned it to $MAIN-HELLDESK.
At this point, had someone who touched this ticket been aware that a change in [company global, as mentioned in resolution notes] profile will result in loss of access to $NEW-PROCUREMENT, and that the symptoms look exactly like what I described, that person might have been able to look up whether I had $NEW-PROCUREMENT access and maybe grant it to me. That would likely have resolved the issue with only confirmation needed from me.
I was not available to respond to the issue on Friday, 7/24.
$INCOMPETENT-HELLDESK-DEMON contacted me on Monday, 7/27, and we had a WebEx session. He took the liberty of pinning Internet Explorer to my taskbar. He replicated that when I clicked on the $NEW-PROCUREMENT icon in Horizon, I got an essentially blank tab. He performed several operations that I wasn’t paying particularly close attention to, as it was internet explorer and I don’t care what destruction is wreaked upon the browser. I know he examined the permission settings for various internet zones, although he did not attempt to place the $NEW-PROCUREMENT site in a more trusted zone. I did not suggest this to him, in a large part because I did not particularly think the problem was on my end after the “Access related” comment on my ticket.
At some point in this, $INCOMPETENT-HELLDESK-DEMON started clicking on the “$OLD-PROCUREMENT” icon in the [single sign-on] menu. This resulted in an error:
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
javax.servlet.ServletException: IDM SSO Cookie is NULL! Either user does not exist in IDM(AD) or OAM policy is missing
com.virtualh.idm.fedlet.fedletapp.doPost(Unknown Source)
javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
note The full stack trace of the root cause is available in the [location with link]
My first thought was that I was expecting some type of error, as I am a contractor and tend to be granted access to things when I realize that lack of access is getting in the way of me doing my job, and then apply to my manager that I should probably get access to that thing. I vaguely remember having to ask for $OLD-PROCUREMENT tool access at the beginning of my time at Virtual Hammer, and after The Great Event (my contract’s end date was entered wrongly, causing all sorts of terrible effects on my accounts, on my very birthday to boot) I have had to re-request access to a great number of things. (I had already asked for access back to $NEW-PROCUREMENT, but according to the resolution there must have been some sort of change between then and now.) So this error from $OLD-PROCUREMENT did not alarm me or indicate anything to me in relation to my $NEW-PROCUREMENT account. Particularly, the line “Either user does not exist in IDM(AD) or OAM policy is missing” suggested that some form of AD permissions for my account weren’t forthcoming.
$INCOMPETENT-HELLDESK-DEMON explained that since the exception said “java” in it, it meant that there was no Java installed on my machine; he said that he was trying to load that program because it has Java built into it and would automatically install Java on my computer. However, it was failing. But, he said, I still needed Java, and we would have to get it on my machine manually. [My machine is in fact newly deployed and didn't have Java.] I figured this was fair, and he went off to install Java on my machine, the fun way. [The way reasonable people do it: by going to the site, not trying to launch an app that requires Java.] We got as far as running the installer when a dialog box appeared: “Error – Java Installer: Uncompression of downloaded file failed.” $INCOMPETENT-HELLDESK-DEMON tried again. Same error. He then explained that this error was because we were not running the installation as administrator. I have only been using Windows 8 for a few months between home and work, so I am not completely up on all the possible errors a Windows 8 machine can throw, but something about this explanation seemed unlikely to me. I decided to search for the error message on my phone to see what other people had done to resolve this error (apparently not a step that $INCOMPETENT-HELLDESK-DEMON was taking, as he had decided to try to run the installer as administrator while I was googling).
According to that most reliable of sources, the internet, “Error – Java Installer: Uncompression of downloaded file failed.” often meant that the file downloaded to install had been corrupted in some way, sometimes attributed to particularly nosy antivirus programs. [We have some particularly nosy antivirus programs.] A possible remedy was to try the offline installation and see if that worked. $INCOMPETENT-HELLDESK-DEMON meanwhile told me that since we couldn’t get Java on my computer, we would have to turn it over to local desktop, my building’s dear and overworked Chip. I anticipated that it would take Chip a few days to get around to me, and I was convinced that the true solution was outside of my ability to remedy. I announced my findings, and that I could attempt to install Java myself if $INCOMPETENT-HELLDESK-DEMON was giving up. [If that was the barrier to getting help with my *real* problem, by god I would clear it in style.] This was agreeable to him. We disconnected the call. The WebEx remained running, so it was entirely possible that he saw my success at installing Java using the offline installer. That is the only explanation I can come up with for the comment he left.
2015-07-27 16:50:52 $INCOMPETENT-HELLDESK-DEMON - Changed: Additional comments
$NEW-PROCUREMENT not working on any browser found out there is no java installed and i am unable to install java aswell
Attached is the error message Attached is the error message
Jave is also installed
Once Java was installed, I enabled it in Chrome and made sure it was enabled in Internet Explorer. I tested $NEW-PROCUREMENT again. Same null result. I made sure to check $OLD-PROCUREMENT as well, and got the same error 500, although I did not mention this in my subsequent update to the ticket to attempt to clarify $INCOMPETENT-HELLDESK-DEMON’s incoherent comment.
It appears that $INCOMPETENT-HELLDESK-DEMON assigned the ticket back to the initial group, IT Apps $NEW-PROCUREMENT Global Support; this time instead of bumping the ticket back to $MAIN-HELLDESK, the technician assigned it to FIN BTA - $NEW-PROCUREMENT GLOBAL. $NEW-PROCUREMENT-DEMON-2 took the ticket at this point and asked me to use a different version of Internet Explorer. [Specifically, 8 or 9.] I read this response before heading to bed on 7/27. I debated many possible responses to this, but ultimately when I arrived at work in the morning, I decided to decline to use the 2009 version of my least favorite browser (and I include 1998’s Lynx in this assessment of preferred browsers).
At this juncture, someone miraculously discovered that I did not have access, and that apparently it’s a vaguely known issue.
If it’s known, why didn’t my ticket get transferred to the right department on the first go? Why did I have to wait around for $INCOMPETENT-HELLDESK-DEMON to do unmentionable things to my IE? Why did $INCOMPETENT-HELLDESK-DEMON threaten to send it to the already overworked local desktop team?
Regards,
Azure
(follow-up message sent five indignant minutes later)
And you know, the thing that really chafes is that $NEW-PROCUREMENT doesn’t require Java enabled in the browser to actually run. After regaining access, I turned it off in Chrome just for fun, and $NEW-PROCUREMENT runs just fine.
-ajl
User has tested in three browsers, obliterated cookies from the beginning of time in two of them, rebooted once, and gets the same fucking result. User has previously had access to $NEW-PROCUREMENT obliterated by apparent expiration of contract and has had to ask for it (and every other fucking account) back, individually. User is not very fucking happy.
Subject: Escalation: handling of TKT---
Body: Hi $ESCALATION-MANAGER,
First, TKT--- has been successfully resolved as of 7/28. However, there are certain indications that it might have been able to be solved on the very day it was filed, without the excruciatingly painful 23 minute and 59 second phone call with $INCOMPETENT-HELLDESK-DEMON.
I would like some review of what happened with my ticket and why it remained with $MAIN-HELLDESK as long as it did.
I would like some review of how well known some “known issues” actually are, and whether the people who need to know this actually know it.
I would like some training in what constitutes effective textual communication via ticket notes, as it seems that more than one person has failed this badly.
I would like someone to remind $INCOMPETENT-HELLDESK-DEMON that bullshitting the end-user is a bad plan in general, and specifically terrible in a technical company, and see if his training needs updating, particularly on $NEW-PROCUREMENT, $OLD-PROCUREMENT, Java, and Windows 8.
I filed TKT--- on 7/23. I see in the audit history that $NEW-PROCUREMENT-DEMON who seems to have been monitoring the incoming queue for $NEW-PROCUREMENT tasks, remarked “Access related” on my ticket, then reassigned it to $MAIN-HELLDESK.
At this point, had someone who touched this ticket been aware that a change in [company global, as mentioned in resolution notes] profile will result in loss of access to $NEW-PROCUREMENT, and that the symptoms look exactly like what I described, that person might have been able to look up whether I had $NEW-PROCUREMENT access and maybe grant it to me. That would likely have resolved the issue with only confirmation needed from me.
I was not available to respond to the issue on Friday, 7/24.
$INCOMPETENT-HELLDESK-DEMON contacted me on Monday, 7/27, and we had a WebEx session. He took the liberty of pinning Internet Explorer to my taskbar. He replicated that when I clicked on the $NEW-PROCUREMENT icon in Horizon, I got an essentially blank tab. He performed several operations that I wasn’t paying particularly close attention to, as it was internet explorer and I don’t care what destruction is wreaked upon the browser. I know he examined the permission settings for various internet zones, although he did not attempt to place the $NEW-PROCUREMENT site in a more trusted zone. I did not suggest this to him, in a large part because I did not particularly think the problem was on my end after the “Access related” comment on my ticket.
At some point in this, $INCOMPETENT-HELLDESK-DEMON started clicking on the “$OLD-PROCUREMENT” icon in the [single sign-on] menu. This resulted in an error:
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
javax.servlet.ServletException: IDM SSO Cookie is NULL! Either user does not exist in IDM(AD) or OAM policy is missing
com.virtualh.idm.fedlet.fedletapp.doPost(Unknown Source)
javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
note The full stack trace of the root cause is available in the [location with link]
My first thought was that I was expecting some type of error, as I am a contractor and tend to be granted access to things when I realize that lack of access is getting in the way of me doing my job, and then apply to my manager that I should probably get access to that thing. I vaguely remember having to ask for $OLD-PROCUREMENT tool access at the beginning of my time at Virtual Hammer, and after The Great Event (my contract’s end date was entered wrongly, causing all sorts of terrible effects on my accounts, on my very birthday to boot) I have had to re-request access to a great number of things. (I had already asked for access back to $NEW-PROCUREMENT, but according to the resolution there must have been some sort of change between then and now.) So this error from $OLD-PROCUREMENT did not alarm me or indicate anything to me in relation to my $NEW-PROCUREMENT account. Particularly, the line “Either user does not exist in IDM(AD) or OAM policy is missing” suggested that some form of AD permissions for my account weren’t forthcoming.
$INCOMPETENT-HELLDESK-DEMON explained that since the exception said “java” in it, it meant that there was no Java installed on my machine; he said that he was trying to load that program because it has Java built into it and would automatically install Java on my computer. However, it was failing. But, he said, I still needed Java, and we would have to get it on my machine manually. [My machine is in fact newly deployed and didn't have Java.] I figured this was fair, and he went off to install Java on my machine, the fun way. [The way reasonable people do it: by going to the site, not trying to launch an app that requires Java.] We got as far as running the installer when a dialog box appeared: “Error – Java Installer: Uncompression of downloaded file failed.” $INCOMPETENT-HELLDESK-DEMON tried again. Same error. He then explained that this error was because we were not running the installation as administrator. I have only been using Windows 8 for a few months between home and work, so I am not completely up on all the possible errors a Windows 8 machine can throw, but something about this explanation seemed unlikely to me. I decided to search for the error message on my phone to see what other people had done to resolve this error (apparently not a step that $INCOMPETENT-HELLDESK-DEMON was taking, as he had decided to try to run the installer as administrator while I was googling).
According to that most reliable of sources, the internet, “Error – Java Installer: Uncompression of downloaded file failed.” often meant that the file downloaded to install had been corrupted in some way, sometimes attributed to particularly nosy antivirus programs. [We have some particularly nosy antivirus programs.] A possible remedy was to try the offline installation and see if that worked. $INCOMPETENT-HELLDESK-DEMON meanwhile told me that since we couldn’t get Java on my computer, we would have to turn it over to local desktop, my building’s dear and overworked Chip. I anticipated that it would take Chip a few days to get around to me, and I was convinced that the true solution was outside of my ability to remedy. I announced my findings, and that I could attempt to install Java myself if $INCOMPETENT-HELLDESK-DEMON was giving up. [If that was the barrier to getting help with my *real* problem, by god I would clear it in style.] This was agreeable to him. We disconnected the call. The WebEx remained running, so it was entirely possible that he saw my success at installing Java using the offline installer. That is the only explanation I can come up with for the comment he left.
2015-07-27 16:50:52 $INCOMPETENT-HELLDESK-DEMON - Changed: Additional comments
$NEW-PROCUREMENT not working on any browser found out there is no java installed and i am unable to install java aswell
Attached is the error message Attached is the error message
Jave is also installed
Once Java was installed, I enabled it in Chrome and made sure it was enabled in Internet Explorer. I tested $NEW-PROCUREMENT again. Same null result. I made sure to check $OLD-PROCUREMENT as well, and got the same error 500, although I did not mention this in my subsequent update to the ticket to attempt to clarify $INCOMPETENT-HELLDESK-DEMON’s incoherent comment.
It appears that $INCOMPETENT-HELLDESK-DEMON assigned the ticket back to the initial group, IT Apps $NEW-PROCUREMENT Global Support; this time instead of bumping the ticket back to $MAIN-HELLDESK, the technician assigned it to FIN BTA - $NEW-PROCUREMENT GLOBAL. $NEW-PROCUREMENT-DEMON-2 took the ticket at this point and asked me to use a different version of Internet Explorer. [Specifically, 8 or 9.] I read this response before heading to bed on 7/27. I debated many possible responses to this, but ultimately when I arrived at work in the morning, I decided to decline to use the 2009 version of my least favorite browser (and I include 1998’s Lynx in this assessment of preferred browsers).
At this juncture, someone miraculously discovered that I did not have access, and that apparently it’s a vaguely known issue.
If it’s known, why didn’t my ticket get transferred to the right department on the first go? Why did I have to wait around for $INCOMPETENT-HELLDESK-DEMON to do unmentionable things to my IE? Why did $INCOMPETENT-HELLDESK-DEMON threaten to send it to the already overworked local desktop team?
Regards,
Azure
(follow-up message sent five indignant minutes later)
And you know, the thing that really chafes is that $NEW-PROCUREMENT doesn’t require Java enabled in the browser to actually run. After regaining access, I turned it off in Chrome just for fun, and $NEW-PROCUREMENT runs just fine.
-ajl
no subject
no subject
I think Jave might be different than java, or something.
(I just can't even.)
no subject
no subject
no subject
no subject
no subject
But training takes time and costs money, and your, presumably outsourced, IT support people will hate to spend any money they don't need to. :o(
If they're in-house, then someone needs fired. Maybe that support demon, maybe someone's boss.
no subject
The person who is cc:ed on the escalation manager's acknowledgement message has the title of Manager - Process Assurance Intelligence, IT: Automation Service Center.
no subject