Sometimes I wish I could create a bridge. Like a bridge to my house to turn my commute from 60 minutes to 40. How about a bridge to make the trip to my in-laws faster so the visit can feel less painful? On second thought, maybe no bridge to the in-laws is a good thing…
Why build bridges? To make something quicker? To make a task you perform more efficient? How about just to make life easier? Yes, Yes, and Yes! For me at least.
Bit Of History:
Problem: The chain of barrier islands called the Outer Banks (OBX) is a beautiful strip of sand, which many people fell in love with. If you lived in Maryland or Delaware you could only get there two ways. Take a road around the (very large) Chesapeake Bay or take a ferry ride. Depending on exactly where you live, that “round about” or ferry adds hours to your trip.
Solution: The 1952 opening of the Chesapeake Bay bridge tunnel. This allowed a smooth ride from point A to point B. Outside of traffic congestion now and then, it has simplified life for many, and trimmed hours off the trip.
Managing remote devices like desktops, laptops, or netbooks is not always the simplest task. Sure, if you’re already on the island it’s not a big deal. But, what happens when you’re not. What happens when that device is 3,000 mile away? You likely already have the means to identify or see the device in order to understand what’s wrong. You also likely have a system to remotely connect to that device and take action on it. Just like prior to 1952, someone could get to OBX by avoiding the Chesapeake Bay or taking a ferry over it. It’s not that you can’t manage the device. It’s just the long way.
If point A to point B takes 3 minutes one way as opposed to 1 minute using a different way, would IT take the longer way? Of course IT will choose the faster way. So why does IT continually settle for status quo for remote control applications?
In many organizations this typical scenario takes place multiple times a day:
- A call comes into the Help Desk.
- Help Desk looks up the user’s device support information in one application.
- Help Desk thinks they know the problem but need to connect to the device to fix it.
- Help Desk launches a separate application to find the user IP address or, in many cases, walks the end user through multiple steps to find the information.
- Help desk launches a third application which is usually a PC remote control application like VNC, DameWare, Microsoft Remote Desktop, etc.
- Help Desk enters the necessary IP information in the application.
- Help Desk initiates the session with the remote device to continue the problem resolution.
Think about an alternate method--without any additional tools or end user involvement:
The first three steps above are the same—but then a bridge is provided to span steps 4 through 7. In the same application your help desk is already using, just click a button to see the IP address of the device and all the available applications which can be used to connect. Click again to continue the problem resolution by automatically connecting and taking control of the device. Now wasn’t that easy?
Using a bridge on those last four steps resolves the problem in a much faster way. Sometimes desktop management does not have to be that hard. At least not when you use bridges!