What Helpdesk Platforms are IT Service Providers Using
-
@scottalanmiller They revamped the RDP process, here's a screenshot. Supposed to be some other improvements, but I haven't dove into those yet.
-
@Bill-Kindle I looked at that but it still requires that you be on the same network which makes it make no sense. The interface is web based and can be accessed anywhere. But then there is just normal RDP. It's a confusing and nearly useless mismatch.
Just further solidifies how disconnected from their customers they are and how little they listen to feedback. They don't think about actually using the product at all.
-
@scottalanmiller said:
Just further solidifies how disconnected from their customers they are and how little they listen to feedback.
You are thinking of their users, not their customers. That is the problem.
-
@JaredBusch said:
@scottalanmiller said:
Just further solidifies how disconnected from their customers they are and how little they listen to feedback.
You are thinking of their users, not their customers. That is the problem.
Very true.
-
@scottalanmiller Yeah, which means its still not a MSP tool, and still pretty limited. The RDP download is just fine, but I get the feeling they are about to remove the functionality in place of this solution. Why is LMI even an option still if this is the route they are going?
-
@Bill-Kindle said:
@scottalanmiller Yeah, which means its still not a MSP tool, and still pretty limited. The RDP download is just fine, but I get the feeling they are about to remove the functionality in place of this solution. Why is LMI even an option still if this is the route they are going?
Well LMI never did anything, it was never integrated. Just a pointless link. But LMI works way better than RDP for SW. It fits the architecture. RDP is a mismatch. Even non-MPSs. Anyone using Spiceworks, connecting to one tool over a published webpage and then needing an unrelated RDP connection just makes no sense. SMBs just get confused by this because it is jarring and unlike anything else. It just appears that the product is broken.
Think about a normal SMB. They are logged in from "somewhere" and they are looking at SW. How often will the be in a place where any arbitrary RDP connection will work? I know shops that use SW only internally, and not external at all, and still the RDP won't work reliably. Only the rare shop that uses SW purely internal on a network that has 100% live connection to every host. Other than those of us using Pertino and actually having a full mesh VPN everywhere, it is hard to imagine the customer where this would work.
-
@scottalanmiller said:
Think about a normal SMB. They are logged in from "somewhere" and they are looking at SW. How often will the be in a place where any arbitrary RDP connection will work? ** I know shops that use SW only internally, and not external at all, and still the RDP won't work reliably. Only the rare shop that uses SW purely internal on a network that has 100% live connection to every host. Other than those of us using Pertino and actually having a full mesh VPN everywhere, it is hard to imagine the customer where this would work.**
That last part is where some of my confusion is starting to come from. You can click the tools menu and click "Remote Control" which will cause a pre-configured RDP shortcut to download. I've used this (granted only internally and on the same LAN) and it works 100% of the time unless there's some other problem with the workstation I'm trying to get to.
What I showed in the above screenshots is totally different. They've taken that process of downloading the pre-configured RDP shortcut, and decided to integrate it into the browser via this "Troubleshooting" window. I think just calling MSTSC.exe would work but there seems to have been some additional effort put into putting this all into a web interface. Instead of doing that they could have just integrated something along the lines of TeamViewer or even LMI (bleh) or even RemoteUtilities. I'm just still a little surprised at this move and intrigued by it at the same time. Where is this going?
-
I see that you quoted me but nothing from you showed up.
-
Was still editing my quote fail #redheadITguyproblems
-
@Bill-Kindle said:
Was still editing my quote fail #redheadITguyproblems
LOL, I see.
-
@Bill-Kindle said:
@scottalanmiller said:
Think about a normal SMB. They are logged in from "somewhere" and they are looking at SW. How often will the be in a place where any arbitrary RDP connection will work? ** I know shops that use SW only internally, and not external at all, and still the RDP won't work reliably. Only the rare shop that uses SW purely internal on a network that has 100% live connection to every host. Other than those of us using Pertino and actually having a full mesh VPN everywhere, it is hard to imagine the customer where this would work.**
That last part is where some of my confusion is starting to come from. You can click the tools menu and click "Remote Control" which will cause a pre-configured RDP shortcut to download. I've used this (granted only internally and on the same LAN) and it works 100% of the time unless there's some other problem with the workstation I'm trying to get to.
What I showed in the above screenshots is totally different. They've taken that process of downloading the pre-configured RDP shortcut, and decided to integrate it into the browser via this "Troubleshooting" window. I think just calling MSTSC.exe would work but there seems to have been some additional effort put into putting this all into a web interface. Instead of doing that they could have just integrated something along the lines of TeamViewer or even LMI (bleh) or even RemoteUtilities. I'm just still a little surprised at this move and intrigued by it at the same time. Where is this going?
So say you are at home, like right now, and you log into your Spiceworks remotely since it is a secure web application. If you use the RDP tools, does it work?
-
What if the person you are trying to reach is working from home or from a hotel room? LMI works in all those situations, just as SW does. Only the RDP connection breaks.
-
@scottalanmiller I don't use it in that fashion. And I rarely have to log in from home. I have a VPN client on my machine and can use plain RDP if needed. USED TO USE LMI (bleh) but had to remove that from most systems just prior to their killing the "Free Forever" offering. My boss got a little irrate at me that I fixed his computer remotely (while he knew that I was) and was able to reboot and log back in. He was concerned that I saw his "personal" stuff on his company laptop. I was actually shocked by the reaction. And there I went off on a tangent......
I'm going to have to try this now, you gave me an idea , something I may have to document.
-
@Bill-Kindle said:
@scottalanmiller I don't use it in that fashion. And I rarely have to log in from home. I have a VPN client on my machine and can use plain RDP if needed. USED TO USE LMI (bleh) but had to remove that from most systems just prior to their killing the "Free Forever" offering. My boss got a little irrate at me that I fixed his computer remotely (while he knew that I was) and was able to reboot and log back in. He was concerned that I saw his "personal" stuff on his company laptop. I was actually shocked by the reaction. And there I went off on a tangent......
I'm going to have to try this now, you gave me an idea , something I may have to document.
Right, you are advanced enough that you know when it will and will not work. You are not the average SMB IT Pro. But it doesn't mean that the interface works, it is just that you can sense when it will and will not work and only attempt to use it when you already know that it will work and you avoid it when you know it won't work. But most people think that because their application is connected, and because their is an agent installed and the system can be contacted and because other applications of this nature (Meraki, LogMeIn, Teamviewer, Pertino, etc.) all would work transparently and don't require "knowing" when which component of the interface will route transparently through the server and which parts require a peer to peer connection.
That's really the issue.... part of the application is a client/server app and other parts, all in the same interface, are peer to peer. The interface makes you feel like the RDP will be tunneled through the SSL channel that is already established, but it doesn't. That's confusing that they are tied together.
-
@scottalanmiller said:
**The interface makes you feel like the RDP will be tunneled through the SSL channel that is already established, but it doesn't. ** That's confusing that they are tied together.Ding. That right there. That is why I'm not understanding why it's being tied directly to the browser. In theory it's neat, but sometimes just because you can, doesn't mean you should.
-
@Bill-Kindle said:
@scottalanmiller said:
**The interface makes you feel like the RDP will be tunneled through the SSL channel that is already established, but it doesn't. ** That's confusing that they are tied together.Ding. That right there. That is why I'm not understanding why it's being tied directly to the browser. In theory it's neat, but sometimes just because you can, doesn't mean you should.
I'm not sure what you are saying. There is an interface and it isn't consistent. Some parts of the interface work at some times, others work at other times. There is no connection between them and no clues (other than knowing the underlying network) to tell you when things will work. It's like a Windows 8 and all the weird stuff with no on screen clues as to what is going to happen.
-
Imagine any other application. Imagine you are using SalesForce to do some work. You are working along and suddenly some button on the screen just fails, no warning, no reason. You call support and they say "oh, even though this is a web app, for that one feature to work you have to drive to our offices and sit in our lobby."
-
Try to remember the first time that you tried to use the troubleshooting tools. Didn't it seem odd that some buttons in the interface worked and some required special conditions under which to work - conditions with no connection to when the rest of the application worked?
When this feature was new, everyone was so confused because it looked like SW was making a remote access application which people needed (a la LogMeIn) but it didn't have any functionality that people didn't already have. And if you aren't on Windows, it REALLY doesn't work. Try it from Linux, for example, it does nothing. From a web interface perspective, it is broken in every imaginable way.
-
@scottalanmiller said:
@Bill-Kindle said:
@scottalanmiller said:
**The interface makes you feel like the RDP will be tunneled through the SSL channel that is already established, but it doesn't. ** That's confusing that they are tied together.Ding. That right there. That is why I'm not understanding why it's being tied directly to the browser. In theory it's neat, but sometimes just because you can, doesn't mean you should.
I'm not sure what you are saying. There is an interface and it isn't consistent. Some parts of the interface work at some times, others work at other times. There is no connection between them and no clues (other than knowing the underlying network) to tell you when things will work. It's like a Windows 8 and all the weird stuff with no on screen clues as to what is going to happen.
My point was that the RDP session being displayed in a browswer like that could fool you into thinking it's a secure connection.
-
@scottalanmiller Troubleshooting tools? lol
I am the tool
Yeah I under stand what you are saying and yes, I've seen that condition where you can't pull purchase history when not online (gawd that drives me nutz still). But really, how many places are there left that have 0 internet connectivity? I don't think the app ever took that into consideration because of that.