Tweet
Just took a call from this guy, who was slightly sucky.
His workstation had frozen up on him, so he did a hard reboot to get it unstuck. But after the reboot, it stalled on the log-in, so he had to reboot it again. He called ITSD (and got me) to see if his previous log-in session was still running, and maybe causing the problem.
I ask if he's using the virtual desktop environment that The Client uses, and he says no, he's logging in normally. This means, unfortunately, that I don't have any way to 'see' his previous log-in session, if it's still running. (Generally, however, the session isn't still running in cases like this.)
When this sort of problem arises at The Client, the SOP is that we have the user try logging onto another workstation, to determine if there's a problem with his network profile. Logging onto another workstation than one's regular terminal, however, will take longer, because the profile data has to be loaded onto the new terminal first.
So I ask the SC if he's tried logging onto another machine. He admits there is one, but knows it will take "about 20 minutes" (slight exaggeration) and would really rather log into his regular workstation, because he has "a big project" that he's working on.
I tell him that I really can't proceed further until and unless he tries another workstation. The problem may be with his network profile, or it could be a problem with his workstation, but there's literally no way for us to tell from the ITSD until he tries logging in at another terminal. He said he understands, "I know you IT guys like to have us try another workstation," but he doesn't want to lose 20-some minutes waiting for it to log him in somewhere else.
We went around like this a few times, with him repeating his reluctance because of that long log-in time, and not having many other terminals to try at his location, so I finally tell him, "Well, if your choice is a non-working workstation, or a 20-minute log-in at another one, then..."
He finally grudgingly accepted this, and said he'd call back if he had any further problems.
Ugggh. It's not that we "like" having you log into other terminals, it's just that's part of our diagnostic process. If he hadn't been able to log into another terminal, then that could have been a network profile problem. If he had been able to, then the problem was most likely workstation-specific. We're not just asking you to do these things to inconvenience you or make you jump through hoops for the sake of doing it, we're trying to narrow down the problem.
His workstation had frozen up on him, so he did a hard reboot to get it unstuck. But after the reboot, it stalled on the log-in, so he had to reboot it again. He called ITSD (and got me) to see if his previous log-in session was still running, and maybe causing the problem.
I ask if he's using the virtual desktop environment that The Client uses, and he says no, he's logging in normally. This means, unfortunately, that I don't have any way to 'see' his previous log-in session, if it's still running. (Generally, however, the session isn't still running in cases like this.)
When this sort of problem arises at The Client, the SOP is that we have the user try logging onto another workstation, to determine if there's a problem with his network profile. Logging onto another workstation than one's regular terminal, however, will take longer, because the profile data has to be loaded onto the new terminal first.
So I ask the SC if he's tried logging onto another machine. He admits there is one, but knows it will take "about 20 minutes" (slight exaggeration) and would really rather log into his regular workstation, because he has "a big project" that he's working on.
I tell him that I really can't proceed further until and unless he tries another workstation. The problem may be with his network profile, or it could be a problem with his workstation, but there's literally no way for us to tell from the ITSD until he tries logging in at another terminal. He said he understands, "I know you IT guys like to have us try another workstation," but he doesn't want to lose 20-some minutes waiting for it to log him in somewhere else.
We went around like this a few times, with him repeating his reluctance because of that long log-in time, and not having many other terminals to try at his location, so I finally tell him, "Well, if your choice is a non-working workstation, or a 20-minute log-in at another one, then..."
He finally grudgingly accepted this, and said he'd call back if he had any further problems.
Ugggh. It's not that we "like" having you log into other terminals, it's just that's part of our diagnostic process. If he hadn't been able to log into another terminal, then that could have been a network profile problem. If he had been able to, then the problem was most likely workstation-specific. We're not just asking you to do these things to inconvenience you or make you jump through hoops for the sake of doing it, we're trying to narrow down the problem.
Comment