This was involved in that headless debacle but I am past that. I put monitors on all the remote computers and this is a later problem that arose after this machine was in service for 24-48 hours. Quite clearly I was able to connect to the machine and even get the full control mode opened up, but I was unable to force a reboot. I think this demonstrates that even though RU can get into the machine and even show its desktop, you can't depend on RU to be able to reboot the machine. This is forcing me to consider obtaining power management equipment that I can control over the web in order to power cycle a computer. Bummer. I was hoping that RU would be able to reset the machine if I was able to connect to it. Perhaps consider employing a software reset mechanism that is not dependent on a windows API... bios call maybe?
I have not used that procedure. But nearly every time I've updated I've been left with this scenario. I did not do an unistall, I allowed the installation to replace the current version. Windows 10, fairly fresh install.
BTW: you asked about whether the other thread was one in question about not being able to connect- yes - and I left a response on that post saying that I thought the reason for the inability to connect was due to monitor less stations- the monitor being moved between three hosts at points where I needed a physical head attached to do a configuration or BIOS change.... or install a new version of RU because I couldn't get the host to connect remotely. (now I have to read up on doing an install remotely, something about msi...)
I think the mysteries of this exercise are solved. Some stations saw hosts as offline because IDs were wrong. Some stations could connect to hosts when some can't was because I would move the cable of a shared monitor around (the intention was that the three playout stations would be "headless) and so at different times when accessing at one station I could connect to a host. Then I'd move the monitor and later sit at another remote station and the host the I just accessed prior from the other remote state would not connect to this station (because the monitor had moved and connections were no longer accepted at the monitorless host). Now I know all hosts have to have monitors for the host to allow a connction.
Hi, thanks yes I can try the legacy capture mode. I have attached monitors in the meantime and I do plan to get a set of those dummy plugs in each signal variety that makes the PC think there is a monitor attached. I think thats ultimately the best solution especially if it mimics a monitor so well that I can set resolutions as desired in windows.
In fact this was part of a problem I was talking about on this forum with connection issues and I received some very kind and timely help but even that person failed to recognize that it might be a "no monitor" scenario and ask if one was attached. Should it be obvious to someone new to this technology that a monitor would be required? I don't think so, not until they have though through that without one maybe WIndows can't report what the screen attributes are and without that info the screen sharing that programs like RU will likely be precluded from doing said sharing. I see it now, but not before knowing it was a problem.
I have been using remote utilities for sometime with computers with monitors. Then I started introducing a set of computers which I expected to be "headless" I had all kinds of rashes of problems that were masked because I cleverly was sharing a monitor from one station with the rest of the computers that were headless when I * really needed * a screen. The monitor had both VGA and DVI, and I was moving a DVI cable around for weeks I chased problems of some these computers refusing to connect. You see, they are online, but they they will not finish the connect without a screen. Usually I was behind the computers moving the cable around and didn't notice the behavior change right away when I plugged it in. One day I just happen to be able to see the screen when I shoved the cable into the connecting computer and saw the other computer instantly connect.
So my recommendations are 1) plan to have some indication that a computer that is ONLINE does not in fact have a screen attached. Surely the host knows this, or else it would be connecting! Can't it say back to the viewer, I'd like to connect but there is no screen? Can't the viewer even know this as part of recognizing the host is online? OK, so that's a code change. So in the meantime, or if you do not intend to change the behaviour, then you must at least mention in the getting started that the remote machines must maintain have a monitor attached in order to function. And in the Knowege base, under the section "problem connecting with an Internet ID" (which is misnamed because there are a rash of items there not related to Internet IDs) One of thiose bold items needs to be "DO YOU HAVE A MONITOR ATTACHED?"
My post mortem on this whole debacle on how I wasted so much time chasing my time is because this fact was ommited from these sections and the software didn't include the smarts to let me know that a basic requirement for the system to function - a monitor- was not present.
There. Have at it. and watch a lot of noise go away from your Community. :)