Hey everyone thanks for the input. I didn't fix the problem but I no longer
think it has anything to do with Guacamole. I think it is just Windows
being picky and overly sensitive as I was getting similar issues from other
RDP clients from every machine on the network. After playing around with
Windows and Guacamole settings there are really only two ways that I get
locked out which are either a page reload or if I select disconnect from
RDP from inside Windows. A few times it actually didn't lock me out
completely on reload but just logged me out instead. I am curious what
Guacamole is "supposed" to do on reload (as most RDP clients don't have a
comparable functionality). The other possibility is that it is a problem
that has to do with Vbox.
Does any anyone have a similar setup? What happens when you reload the page?

Also just to clarify Guacamole is running in an LXD container not Vbox. I
have a bridge set up that the LXD containers use and a connected tap
interface that Vbox VMs use. This makes all the containers and VMs appear
on the LAN.

Thanks :)

On Tue, Oct 22, 2019 at 12:58 PM ivanmarcus <[email protected]>
wrote:

> That's interesting Joachim,
>
> FWIW in the scenario I described earlier for my Win10 VM instance I block
> all M$ connections at the edge router, so the Win10 install cannot change -
> in which case I wouldn't notice if they broke anything.
>
> I also do the same thing with a 60+ user instance of native Win machines I
> have connecting via Guacamole.
>
> Having M$ automatically eff around with your systems is not ok IMV! At
> least if you apply a patch yourself and something stops working afterwards
> you've got a clue as to why, but it's much more difficult to fault find if
> it happens without you knowing.
>
> Anyway, the upshot of this is that if what you say is correct then I would
> anticipate other people should have the same issue, whereas I may not.
> However I've not heard of any widespread problems (other than Peter's
> earlier) - is your flaky connection just to one machine or do you have it
> across multiple?
>
>
> On 22/10/2019 8:02 p.m., Joachim Lindenberg wrote:
>
> I am experiencing ???flaky??? connections recently with plain mstsc RDP
> connections, w10pro to w10pro. I suspect Microsoft introduced a regression
> recently.
>
> Regards, Joachim
>
> ??
>
> ??
>
> *Von:* Peter Gui <[email protected]> <[email protected]>
> *Gesendet:* Tuesday, 22 October 2019 01:14
> *An:* [email protected]
> *Betreff:* Windows 10 flaky RDP
>
> ??
>
> Hello everyone.
>
> I was just wondering if any one has experience with remote desktop in
> Windows 10 pro.
>
> I am running Windows 10 pro in a VirtualBox VM. I have Guacamole
> configured to work with remote desktop but I am frustrated with the
> connection. The most reproducible version of this problem is a simple
> browser refresh of Guacamole's Windows connection, on reload I get the
> error message "The connection has been closed because the server is
> taking too long to respond..."?? The worst part is that I have to reboot
> the VM to get it working again. I have Windows configured with the
> following settings:
>
> modified registry keys
> <https://mangolassi.it/topic/17846/make-windows-10-server-2016-rdp-work-with-guacamole>
>
> ignore cert and security
> <http://guacamole.apache.org/doc/gug/configuring-guacamole.html#rdp>
>
> I also have a Linux VM running VNC works much more consistently. And VRDE
> <https://www.virtualbox.org/manual/ch07.html#vrde>??(VirtualBox's RDP
> client) also works consistently.
>
> ??
>
> I see 4 potential solutions to this problem:
>
>    - Spend more time trying to configure remote desktop in Windows.
>    - Install Windows Server (which would have the added benefit of
>    allowing multiple connections.
>    - Install and use TightVNC instead of remote desktop (also may allow
>    multiple connections)
>    - Switch to purely using VRDE for my Windows connections (most
>    limiting and hacky feeling solution)
>
> Let me know what you think of these options or if you have another
> solution.
>
> Thanks
>
>
>

Reply via email to