Remotely View Computer over not-the-most-reliable-LAN (24/7)
April 29, 2013 7:09 AM Subscribe
My company's LAN is fast and reliable, except for the connection to one building. Inside that building is an unattended WinXP-Pro system running basically one program 24/7, that we need to be able to monitor. Typically, we only need to interact with the computer >1% of the time, but we need to be able to make sure the software up and running, without problems, all the time.
For that small amount of the time that we need to interact, we know in advance, and can connect via VNC/RDC/Teamviewer/etc, and interact with the system for the 5 minutes or so that we need it. However, trying to use any of those programs to observe it, as soon as there is a hiccup in the connection or anything, they will either crash entirely, or freeze with the last frame still displayed. Crashing entirely sort of sucks, but we can just relaunch whatever remote monitoring solution we're using (typically VNC, but sometimes the others) and be back up and running. However, when it freezes with the last frame still displayed, and we glance at the screen, it "looks" like everything is still working - until we walk across the room and move the mouse, or get close to the screen and see that the timestamp is frozen from 4 hours ago; and that is even worse than crashing.
I am not opposed to running multiple pieces of software if need be... if one program will "stream" the screen over a LAN but not allow interaction with it, and I need to run another program to allow me to interact with it, I do not have a problem with it.
Any suggestions would be appreciated. Thanks.
For that small amount of the time that we need to interact, we know in advance, and can connect via VNC/RDC/Teamviewer/etc, and interact with the system for the 5 minutes or so that we need it. However, trying to use any of those programs to observe it, as soon as there is a hiccup in the connection or anything, they will either crash entirely, or freeze with the last frame still displayed. Crashing entirely sort of sucks, but we can just relaunch whatever remote monitoring solution we're using (typically VNC, but sometimes the others) and be back up and running. However, when it freezes with the last frame still displayed, and we glance at the screen, it "looks" like everything is still working - until we walk across the room and move the mouse, or get close to the screen and see that the timestamp is frozen from 4 hours ago; and that is even worse than crashing.
I am not opposed to running multiple pieces of software if need be... if one program will "stream" the screen over a LAN but not allow interaction with it, and I need to run another program to allow me to interact with it, I do not have a problem with it.
Any suggestions would be appreciated. Thanks.
How about you also run some sort of stopwatch program or looping animation large enough so that you can tell if it's frozen from a distance?
posted by XMLicious at 7:16 AM on April 29, 2013
posted by XMLicious at 7:16 AM on April 29, 2013
And/or, you could install a web server on it and rig some sort of screen-shot-taking app to periodically save an image that's displayed in a web page that constantly refreshes itself. Then only log in to the desktop when you actually need to interact with the program.
posted by XMLicious at 7:22 AM on April 29, 2013
posted by XMLicious at 7:22 AM on April 29, 2013
My suggestion would be to do a cost-benefit breakdown of improving the physical connection. New cable run (or dedicated wireless link), new NIC if necessary, cheap switches along the way as needed, and maybe even updating the XP system. If this unit is wasting your time because of the flaky connection, the flakiness of the connection is costing the company money.
posted by Sunburnt at 7:49 AM on April 29, 2013
posted by Sunburnt at 7:49 AM on April 29, 2013
Response by poster: Have you tried the program in Windows 7's XP mode? - I don't understand where this would/could help with regards to connection issues.
How about you also run some sort of stopwatch program or looping animation large enough so that you can tell if it's frozen from a distance? - For something to be large enough to be visible across the room, it would be blocking the software that we need to monitor (this software only runs full-screen, and there are multiple locations around the screen that update in realtime based upon environmental conditions.)
And/or, you could install a web server on it and rig some sort of screen-shot-taking app to periodically save an image that's displayed in a web page that constantly refreshes itself. Then only log in to the desktop when you actually need to interact with the program. - Best option so far, thank you.
Animated screen saver on the server. - I assume you're meaning to connect using one of the ways I am, and that a screensaver on the remote system would give me an easier-to-see means to know when connectivity drops? If so, while I appreciate it, that doesn't help with the connectivity issues, and puts a screensaver over the information we need to visually monitor.
Any other ideas, please keep them coming.
posted by GuppieXX at 7:50 AM on April 29, 2013
How about you also run some sort of stopwatch program or looping animation large enough so that you can tell if it's frozen from a distance? - For something to be large enough to be visible across the room, it would be blocking the software that we need to monitor (this software only runs full-screen, and there are multiple locations around the screen that update in realtime based upon environmental conditions.)
And/or, you could install a web server on it and rig some sort of screen-shot-taking app to periodically save an image that's displayed in a web page that constantly refreshes itself. Then only log in to the desktop when you actually need to interact with the program. - Best option so far, thank you.
Animated screen saver on the server. - I assume you're meaning to connect using one of the ways I am, and that a screensaver on the remote system would give me an easier-to-see means to know when connectivity drops? If so, while I appreciate it, that doesn't help with the connectivity issues, and puts a screensaver over the information we need to visually monitor.
Any other ideas, please keep them coming.
posted by GuppieXX at 7:50 AM on April 29, 2013
Response by poster: My suggestion would be to do a cost-benefit breakdown of improving the physical connection. New cable run (or dedicated wireless link), new NIC if necessary, cheap switches along the way as needed, and maybe even updating the XP system. If this unit is wasting your time because of the flaky connection, the flakiness of the connection is costing the company money.
They are planning a dedicated fiber line to this building sometime in the near future (within the next 6 months), but they would not be doing an upgrade for this system alone - currently they want, but do not have flawless HD video from a security camera there, so if the connection were fine now, and the video were a higher priority on QoS, I'd be SOL, and they would see it as easier/cheaper for someone to physically go to this building for the few occasions that "business" actually needs to be done there.
Even with the new line though, from what I can tell, VNC/RDC/Teamviewer are not really designed to be an always-on monitoring solution (ie: even before connectivity issues, VNC would crash daily).
posted by GuppieXX at 7:58 AM on April 29, 2013
They are planning a dedicated fiber line to this building sometime in the near future (within the next 6 months), but they would not be doing an upgrade for this system alone - currently they want, but do not have flawless HD video from a security camera there, so if the connection were fine now, and the video were a higher priority on QoS, I'd be SOL, and they would see it as easier/cheaper for someone to physically go to this building for the few occasions that "business" actually needs to be done there.
Even with the new line though, from what I can tell, VNC/RDC/Teamviewer are not really designed to be an always-on monitoring solution (ie: even before connectivity issues, VNC would crash daily).
posted by GuppieXX at 7:58 AM on April 29, 2013
"Looking at the screen" is a poor test under any circumstances for validating functionality, unless the functionality you're verifying is that an image is being rendered. I'm assuming this program actually does something that you're concerned about. _That_ is what you should be testing.
Real companies use something like Nagios or Solarwinds for this, run an agent on the remote PC, and poll it intermittently to run scripts that check actual functionality.
posted by bfranklin at 8:02 AM on April 29, 2013 [1 favorite]
Real companies use something like Nagios or Solarwinds for this, run an agent on the remote PC, and poll it intermittently to run scripts that check actual functionality.
posted by bfranklin at 8:02 AM on April 29, 2013 [1 favorite]
You indicate the remote software runs only full screen but not that you can't have multiple screens or programs running on the remote computer. So,. . .
Could you set-up the Win-XP machine with two monitors? On one screen, you'll display the software that you need to keep an eye on. On the other screen you could do the stopwatch, or animated screensaver, or anything that will help you to notice when the first screen is frozen.
You then just view both from the remote location (via two monitors or two windows in the single viewing screen (if it's large enough this shouldn't make it impossible to see that relevant data).
(You might get the same effect by having the XP box run a virtual machine with a timer/screensaver/etc and that is visible (via VPN?) only to the remote monitor.)
posted by oddman at 8:04 AM on April 29, 2013
Could you set-up the Win-XP machine with two monitors? On one screen, you'll display the software that you need to keep an eye on. On the other screen you could do the stopwatch, or animated screensaver, or anything that will help you to notice when the first screen is frozen.
You then just view both from the remote location (via two monitors or two windows in the single viewing screen (if it's large enough this shouldn't make it impossible to see that relevant data).
(You might get the same effect by having the XP box run a virtual machine with a timer/screensaver/etc and that is visible (via VPN?) only to the remote monitor.)
posted by oddman at 8:04 AM on April 29, 2013
I'd also consider running a cost/benefit analysis of replacing/revising the program upon which you depend.
Because honestly, the program should have a way to alert that it's still alive.
There are a lot of ways to do this - the most obvious in web 2.0 is to post to a server it's current date/time. Even that, which has all kinds of things wrong with it, is better than what you have.
When I worked on Acrobat Catalog many moons ago, I built-in some functionality to conditionally fire "hey, I'm alive!" events every few minutes that could be picked up by another system. If a configurable number of events failed to arrive, the listening machine would fire an email, make a noise, make a phone call with an attached modem, contact a pager, or damn near anything else.
In 1993 technology this took me something like 3 days. With current software technology, that should take something like 1/2 day.
The people who worked on Acrobat Distiller had a closet full of systems that ran nightly/continuous unit tests. If a test hung the machine, then a similar system would catch it and trigger hardware that forced a hard reboot of the machine to let it log the problem and move on.
If this is mission critical software (and was meant to be so), then the software is wrong.
Oh, and just to give you an idea that I understand when you can't really help things, I worked at Bell Communications research at a facility that had two buildings separated by 100 yards and connected underground by access tunnels. Instead of running a fiber between the buildings (which wasn't allowed - don't even ask), the choices were a 2400 baud modem in one building out to the nearest phone switch a mile away and then back to the other building to another modem, or a higher speed laser connection between buildings through a pair of facing windows. That system worked great until the geese started nesting there. Recovering packets from a beam of light interrupted by rain or songbirds was easy, but by a small flock of geese? Guh.
posted by plinth at 9:43 AM on April 29, 2013
Because honestly, the program should have a way to alert that it's still alive.
There are a lot of ways to do this - the most obvious in web 2.0 is to post to a server it's current date/time. Even that, which has all kinds of things wrong with it, is better than what you have.
When I worked on Acrobat Catalog many moons ago, I built-in some functionality to conditionally fire "hey, I'm alive!" events every few minutes that could be picked up by another system. If a configurable number of events failed to arrive, the listening machine would fire an email, make a noise, make a phone call with an attached modem, contact a pager, or damn near anything else.
In 1993 technology this took me something like 3 days. With current software technology, that should take something like 1/2 day.
The people who worked on Acrobat Distiller had a closet full of systems that ran nightly/continuous unit tests. If a test hung the machine, then a similar system would catch it and trigger hardware that forced a hard reboot of the machine to let it log the problem and move on.
If this is mission critical software (and was meant to be so), then the software is wrong.
Oh, and just to give you an idea that I understand when you can't really help things, I worked at Bell Communications research at a facility that had two buildings separated by 100 yards and connected underground by access tunnels. Instead of running a fiber between the buildings (which wasn't allowed - don't even ask), the choices were a 2400 baud modem in one building out to the nearest phone switch a mile away and then back to the other building to another modem, or a higher speed laser connection between buildings through a pair of facing windows. That system worked great until the geese started nesting there. Recovering packets from a beam of light interrupted by rain or songbirds was easy, but by a small flock of geese? Guh.
posted by plinth at 9:43 AM on April 29, 2013
You could try a 3G modem instead of a wired connection, if there is good enough cell service inside the building.
posted by monotreme at 9:59 AM on April 29, 2013
posted by monotreme at 9:59 AM on April 29, 2013
if I was in the same situation I would use some sort of software to verify that the program is running and send notifications of some sort if it's not. A cheap program is Servers Alive.
posted by dgeiser13 at 10:00 AM on April 29, 2013
posted by dgeiser13 at 10:00 AM on April 29, 2013
Response by poster: I think the responses have gotten a bit off-track with one adding on to the previous.
The problem I have is not with the software that I need to monitor. That software works fine, we just need to keep an eye on what it is showing... currently utilizing VNC/RDC/Teamviewer/etc isn't allowing realtime monitoring 100% of the time.
posted by GuppieXX at 10:08 AM on April 29, 2013
The problem I have is not with the software that I need to monitor. That software works fine, we just need to keep an eye on what it is showing... currently utilizing VNC/RDC/Teamviewer/etc isn't allowing realtime monitoring 100% of the time.
posted by GuppieXX at 10:08 AM on April 29, 2013
Write a script that runs on the remote machine to take a screensnap every X minutes (and timestamp it in the corner) and then copy or upload that to your local machine.
posted by wongcorgi at 10:24 AM on April 29, 2013
posted by wongcorgi at 10:24 AM on April 29, 2013
Response by poster: I'd also consider running a cost/benefit analysis of replacing/revising the program upon which you depend.
Because honestly, the program should have a way to alert that it's still alive.
The software we're monitoring isn't the problem though, we depend on it for a small amount of business, but we can (if need be) walk to the building, see that it is functioning, perform what is necessary, and leave... but it is about a 1/2 mile walk each way, and our goal when we set it up was to be able to remotely monitor/access the system - for 6+ years, it has performed without fail... but recently the LAN connection to that building has gotten worse (and is due to be replaced with fiber sometime within the next 6 months), so getting constant communications are impossible.
I'm looking for software that can cope with minor network interuptions without crashing/freezing for the current problems, but I'm also looking for something that is designed for 24/7 monitoring, even if it doesnt allow for interacting.
posted by GuppieXX at 10:27 AM on April 29, 2013
Because honestly, the program should have a way to alert that it's still alive.
The software we're monitoring isn't the problem though, we depend on it for a small amount of business, but we can (if need be) walk to the building, see that it is functioning, perform what is necessary, and leave... but it is about a 1/2 mile walk each way, and our goal when we set it up was to be able to remotely monitor/access the system - for 6+ years, it has performed without fail... but recently the LAN connection to that building has gotten worse (and is due to be replaced with fiber sometime within the next 6 months), so getting constant communications are impossible.
I'm looking for software that can cope with minor network interuptions without crashing/freezing for the current problems, but I'm also looking for something that is designed for 24/7 monitoring, even if it doesnt allow for interacting.
posted by GuppieXX at 10:27 AM on April 29, 2013
Response by poster: You could try a 3G modem instead of a wired connection, if there is good enough cell service inside the building.
Trying to stream, in real-time, everything displayed on a monitor, plus a HD security camera feed over 3G - even with good data speeds would cause other problems (or be prohibitively expensive). Thank you though
posted by GuppieXX at 10:29 AM on April 29, 2013
Trying to stream, in real-time, everything displayed on a monitor, plus a HD security camera feed over 3G - even with good data speeds would cause other problems (or be prohibitively expensive). Thank you though
posted by GuppieXX at 10:29 AM on April 29, 2013
If vnc and other such programs tend to lock up on your system and your need is to have a reliable real time view of the screen have you thought of getting a cheap IP webcam - putting it in front of the screen and monitoring the webcam remotely?
posted by Podkayne of Pasadena at 3:20 PM on April 29, 2013
posted by Podkayne of Pasadena at 3:20 PM on April 29, 2013
A quick and dirty method would be a scheduled task set to run every 10 minutes to just kill the VNC viewer session and start up a new one.
posted by Lanark at 3:58 PM on April 29, 2013
posted by Lanark at 3:58 PM on April 29, 2013
Does it have to be on that box? Could you run that software instead on a virtualPC instance on another box in a more convenient physical location?
posted by softlord at 6:45 PM on April 29, 2013
posted by softlord at 6:45 PM on April 29, 2013
Probably an obvious question, but does the XP box really and truly need to be running unattended in that other building? Can it be moved? Say, into a place that has better connectivity? Or can you string a separate network connection to it?
posted by dws at 8:20 PM on April 29, 2013
posted by dws at 8:20 PM on April 29, 2013
So there's a HD security camera feed? Does that go over a separate network, or I guess the question is does it get disrupted to the same degree as the VNC connection? My thought is that if there's an open "channel" or whatever in the security camera system maybe there's a way with some cheap hardware to get the video output of the computer converted to an input to the security camera system so that it's treated as a second camera and be able to monitor it through the same interface, whatever that may be.
posted by XMLicious at 9:20 PM on April 29, 2013
posted by XMLicious at 9:20 PM on April 29, 2013
Response by poster: If vnc and other such programs tend to lock up on your system and your need is to have a reliable real time view of the screen have you thought of getting a cheap IP webcam - putting it in front of the screen and monitoring the webcam remotely?
I was considering this - my thinking being that a webcam like that is designed to deal with occasional network hiccups.
A quick and dirty method would be a scheduled task set to run every 10 minutes to just kill the VNC viewer session and start up a new one.
I thought of this too, and it would help, but sometimes our connection works just fine for hours on end, and sometimes, it is literally seconds and things freeze up.
Does it have to be on that box? Could you run that software instead on a virtualPC instance on another box in a more convenient physical location?
Probably an obvious question, but does the XP box really and truly need to be running unattended in that other building? Can it be moved? Say, into a place that has better connectivity? Or can you string a separate network connection to it?
Yeah, it has to be that specific box and in that specific location (it connects to sensors that are at that location and cannot be moved) - they are looking to run a new fiber connection to this building, but for the time being (and with a current budget crunch) - you know how it is, I have to deal with what I have (in this case, about a 500' DSL line connected to our closest network closet).
posted by GuppieXX at 11:57 AM on April 30, 2013
I was considering this - my thinking being that a webcam like that is designed to deal with occasional network hiccups.
A quick and dirty method would be a scheduled task set to run every 10 minutes to just kill the VNC viewer session and start up a new one.
I thought of this too, and it would help, but sometimes our connection works just fine for hours on end, and sometimes, it is literally seconds and things freeze up.
Does it have to be on that box? Could you run that software instead on a virtualPC instance on another box in a more convenient physical location?
Probably an obvious question, but does the XP box really and truly need to be running unattended in that other building? Can it be moved? Say, into a place that has better connectivity? Or can you string a separate network connection to it?
Yeah, it has to be that specific box and in that specific location (it connects to sensors that are at that location and cannot be moved) - they are looking to run a new fiber connection to this building, but for the time being (and with a current budget crunch) - you know how it is, I have to deal with what I have (in this case, about a 500' DSL line connected to our closest network closet).
posted by GuppieXX at 11:57 AM on April 30, 2013
This thread is closed to new comments.
posted by zamboni at 7:13 AM on April 29, 2013