Did you have to do anything special to make that work? With audio redirection on, I can get lot of lag, especially if the server is in a datacenter far away from me. What do you do about remote machines, say on other continents? Ryan

On Sep 17, 2015, at 5:57 AM, Troy Hergert wrote:

I'm able to get away with using NVDA without it's remote access component. I've created a group policy for PC audio redirection across the domain. NVDA gets me through my remote sessions most of the time, unless the application in the session is challenging and requires Window-eyes mouse control.

-----Original Message----- From: Blind-sysadmins [mailto:blind-sysadmins-bounces@lists.hodgsonfamily.org] On Behalf Of Ryan Shugart Sent: Wednesday, September 16, 2015 6:24 PM To: Blind sysadmins list Subject: [Blind-sysadmins] NVDA remote VS Window-Eyes or JAWS remote access in a datacenter environment

Hi all: I was wondering what the experiences here were using NVDA remote access as apposed to JAWS or Window-Eyes offering specifically in a datacenter environment managing remote servers. I have Window-Eyes set up on just under 200 servers, about 60 or so of which I access regularly and the others from time to time if ever (Window-Eyes is in our base image so its ready to go if needed.) With Window-Eyes, I know I can just RDP in, once a desktop comes up press ctrl+alt+w and am good to go. If I were to use NVDA in this same situation, I know it uses its own remote access protocol and not RDP, which is both good and bad, but was wondering what you have found the ideal setup for that is? Thanks a lot. Ryan _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins

_______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins

I don't experience the lag in my small non-profit too much. I see that your MUCH LARGER environment may not find this efficient. I connect a vpn to our server, then I can use local computer names or Ip's to connect to servers and PCs. NVDA works quite nicely with a minor lag. I guess I just learned to live with it. It may not be practical for you. I also had to edit the hosts file ON MY HOME PC with the server and its ip so I could rdp by computer name. I think that enabled DNS TO PASS THROUGH THE VPN. -----Original Message----- From: Blind-sysadmins [mailto:blind-sysadmins-bounces@lists.hodgsonfamily.org] On Behalf Of Ryan Shugart Sent: Thursday, September 17, 2015 9:06 AM To: Blind sysadmins list Subject: Re: [Blind-sysadmins] NVDA remote VS Window-Eyes or JAWS remote access in a datacenter environment Did you have to do anything special to make that work? With audio redirection on, I can get lot of lag, especially if the server is in a datacenter far away from me. What do you do about remote machines, say on other continents? Ryan

On Sep 17, 2015, at 5:57 AM, Troy Hergert wrote:

I'm able to get away with using NVDA without it's remote access component. I've created a group policy for PC audio redirection across the domain. NVDA gets me through my remote sessions most of the time, unless the application in the session is challenging and requires Window-eyes mouse control.

-----Original Message----- From: Blind-sysadmins [mailto:blind-sysadmins-bounces@lists.hodgsonfamily.org] On Behalf Of Ryan Shugart Sent: Wednesday, September 16, 2015 6:24 PM To: Blind sysadmins list Subject: [Blind-sysadmins] NVDA remote VS Window-Eyes or JAWS remote access in a datacenter environment

Hi all: I was wondering what the experiences here were using NVDA remote access as apposed to JAWS or Window-Eyes offering specifically in a datacenter environment managing remote servers. I have Window-Eyes set up on just under 200 servers, about 60 or so of which I access regularly and the others from time to time if ever (Window-Eyes is in our base image so its ready to go if needed.) With Window-Eyes, I know I can just RDP in, once a desktop comes up press ctrl+alt+w and am good to go. If I were to use NVDA in this same situation, I know it uses its own remote access protocol and not RDP, which is both good and bad, but was wondering what you have found the ideal setup for that is? Thanks a lot. Ryan _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins

_______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins

_______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins

Thanks a lot everybody. I too am really surprised the server component hasn’t been released. However, my guess is NVDA remote was more designed with the primary vision of remote technical support, like a remote assistance thing and perhaps remote management of a machine second. Possibly very reasonable, I don’t know what the push to come up with this was. I don’t think the nvdaremote.comhttp://nvdaremote.com people would like 200 or so servers suddenly connecting up to their server for remote management, and considering that you’re basically sending key strokes and getting responses back, I’d imagine that the corporate security types around would really not sleep well at nights knowing that was going on. Today, I spun up a Windows 2012R2 VM in Azure and put NVDA on there and set up a remote connection between the VM and my computer. I wanted to simulate managing a remote server without setting up a test server at a remote office. One problem I ran into quickly was that while I could configure the NVDA remote session in my logon session to auto connect to nvdaremote.comhttp://nvdaremote.com, I couldn’t make the same change to the NVDA that ran at the logon screen. Because its Azure, you don’t have console access to the VM, just RDP access, so there’s no way to get to a logon screen to configure the NVDA there. That may be what Blake’s solution fixes, but I basically ended up needing to establish an RDP connection to the VM which started NVDA and then I could connect using the NVDA remote add-on. Blake, is this the problem you were referring to that you put in a request to get changed? For whatever reason I couldn’t actually send keystrokes through, when I tried nothing happened, but I could hear speech output, so it was kind of working, which was cool. By the way, to Troy’s point, RDP audio actually functioned a lot better than I thought it would, I think MS has cleaned that up a lot in 2012R2. There was still a noticeable delay, and I’m sure Azure VMs get really high-bandwidth connections, but it was still very usable. Would I want to rely on it when connecting to one of our remote offices in Australia or South Africa, probably not, but still, credit where its due. So, so far, I’m really liking NVDA Remote, and I think it meets a need, but I still finding myself wishing NVDA had RDP/Citrix virtual channel synthesizers like JFW and Window-Eyes do. The ability to just start a regular old RDP session, launch the screen reader and have speech just be piped through the channel is really cool, and considering how lean NVDA is compared to JFW or Window-Eyes it actually would make a decent screen reader in heavy use Citrix environments, so I’m a little surprised they haven’t gone down that road. But that’s just me. Ryan On Sep 17, 2015, at 9:49 AM, Blake Oliver mailto:oliver22213@me.com> wrote: Hello. I'm new to this mailinglist, but I think I can help here. Though the team that released NVDA Remote hasn't officially released a server component, thus (supposedly) limiting us to nvdaremote.comhttp://nvdaremote.com which I find slightly heavy handed, the open source community has risen to the challenge. https://github.com/Technow-es/NVDARemoteServer It's completely open source, with packages for lots of operating systems. I run several of these servers and have found no problems yet. I've also submitted a pull request to the NVDA remote team that allows the add-on to automatically self-host a server at startup. I like this approach because it means you're computer doesn't have an open connection to a potentially unsafe server as soon as you start NVDA, rather it starts a server instance with a key you configure. I haven't updated it in a while, but if you're interested... https://github.com/Oliver2213/NVDARemote/tree/autoconnect Hope this helps On 9/17/2015 11:35 AM, Andrew Hodgson wrote: Hi, For me the NVDA remote option has been made less useful because we don't have the actual server component which makes things work a lot easier. I was hoping to be able to set up a local server on the network which could be used for central connections. I don't want to have to open up ports from my workstation to the other servers. I have a controlling admin host which I wanted to install the server onto. Also it is a lot easier if machines connect once logged into the central server. Thanks, Andrew. ________________________________________ From: Blind-sysadmins [blind-sysadmins-bounces@lists.hodgsonfamily.org] on behalf of Ryan Shugart [rshugart@ryanshugart.com] Sent: 17 September 2015 00:24 To: Blind sysadmins list Subject: [Blind-sysadmins] NVDA remote VS Window-Eyes or JAWS remote access in a datacenter environment Hi all: I was wondering what the experiences here were using NVDA remote access as apposed to JAWS or Window-Eyes offering specifically in a datacenter environment managing remote servers. I have Window-Eyes set up on just under 200 servers, about 60 or so of which I access regularly and the others from time to time if ever (Window-Eyes is in our base image so its ready to go if needed.) With Window-Eyes, I know I can just RDP in, once a desktop comes up press ctrl+alt+w and am good to go. If I were to use NVDA in this same situation, I know it uses its own remote access protocol and not RDP, which is both good and bad, but was wondering what you have found the ideal setup for that is? Thanks a lot. Ryan _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins

Hi, One of the things that excited me about this addon is that it doesn't need any Citrix or RDP drivers installed on the host to get the support enabled, therefor I could use a portible version with the add-in installed and configured and just copy it to the server when I needed to use it. If I had my own server I could set it up to connect to that server at startup. Yes like you I wouldn't put the servers anywhere near ndaremote.com due to the keystroke issue. Still a bit upset that after being on the beta list, then the server component wasn't released, there was absolutely no communication from the guys after this happened and the list closed. Any communications with the guys now about this just results in no response, and there reasons for doing this (i.e, someone could be tricked into connecting to a spoof server) I think would be the same for any remote solution. We now have another component that emulates the nvdaremote.com functionality, but this has now caused fragmentation in the community. Andrew. ________________________________________ From: Blind-sysadmins [blind-sysadmins-bounces@lists.hodgsonfamily.org] on behalf of Ryan Shugart [rshugart@ryanshugart.com] Sent: 18 September 2015 00:50 To: Blind sysadmins list Subject: Re: [Blind-sysadmins] NVDA remote VS Window-Eyes or JAWS remote access in a datacenter environment Thanks a lot everybody. I too am really surprised the server component hasn’t been released. However, my guess is NVDA remote was more designed with the primary vision of remote technical support, like a remote assistance thing and perhaps remote management of a machine second. Possibly very reasonable, I don’t know what the push to come up with this was. I don’t think the nvdaremote.comhttp://nvdaremote.com people would like 200 or so servers suddenly connecting up to their server for remote management, and considering that you’re basically sending key strokes and getting responses back, I’d imagine that the corporate security types around would really not sleep well at nights knowing that was going on. Today, I spun up a Windows 2012R2 VM in Azure and put NVDA on there and set up a remote connection between the VM and my computer. I wanted to simulate managing a remote server without setting up a test server at a remote office. One problem I ran into quickly was that while I could configure the NVDA remote session in my logon session to auto connect to nvdaremote.comhttp://nvdaremote.com, I couldn’t make the same change to the NVDA that ran at the logon screen. Because its Azure, you don’t have console access to the VM, just RDP access, so there’s no way to get to a logon screen to configure the NVDA there. That may be what Blake’s solution fixes, but I basically ended up needing to establish an RDP connection to the VM which started NVDA and then I could connect using the NVDA remote add-on. Blake, is this the problem you were referring to that you put in a request to get changed? For whatever reason I couldn’t actually send keystrokes through, when I tried nothing happened, but I could hear speech output, so it was kind of working, which was cool. By the way, to Troy’s point, RDP audio actually functioned a lot better than I thought it would, I think MS has cleaned that up a lot in 2012R2. There was still a noticeable delay, and I’m sure Azure VMs get really high-bandwidth connections, but it was still very usable. Would I want to rely on it when connecting to one of our remote offices in Australia or South Africa, probably not, but still, credit where its due. So, so far, I’m really liking NVDA Remote, and I think it meets a need, but I still finding myself wishing NVDA had RDP/Citrix virtual channel synthesizers like JFW and Window-Eyes do. The ability to just start a regular old RDP session, launch the screen reader and have speech just be piped through the channel is really cool, and considering how lean NVDA is compared to JFW or Window-Eyes it actually would make a decent screen reader in heavy use Citrix environments, so I’m a little surprised they haven’t gone down that road. But that’s just me. Ryan On Sep 17, 2015, at 9:49 AM, Blake Oliver mailto:oliver22213@me.com> wrote: Hello. I'm new to this mailinglist, but I think I can help here. Though the team that released NVDA Remote hasn't officially released a server component, thus (supposedly) limiting us to nvdaremote.comhttp://nvdaremote.com which I find slightly heavy handed, the open source community has risen to the challenge. https://github.com/Technow-es/NVDARemoteServer It's completely open source, with packages for lots of operating systems. I run several of these servers and have found no problems yet. I've also submitted a pull request to the NVDA remote team that allows the add-on to automatically self-host a server at startup. I like this approach because it means you're computer doesn't have an open connection to a potentially unsafe server as soon as you start NVDA, rather it starts a server instance with a key you configure. I haven't updated it in a while, but if you're interested... https://github.com/Oliver2213/NVDARemote/tree/autoconnect Hope this helps On 9/17/2015 11:35 AM, Andrew Hodgson wrote: Hi, For me the NVDA remote option has been made less useful because we don't have the actual server component which makes things work a lot easier. I was hoping to be able to set up a local server on the network which could be used for central connections. I don't want to have to open up ports from my workstation to the other servers. I have a controlling admin host which I wanted to install the server onto. Also it is a lot easier if machines connect once logged into the central server. Thanks, Andrew. ________________________________________ From: Blind-sysadmins [blind-sysadmins-bounces@lists.hodgsonfamily.org] on behalf of Ryan Shugart [rshugart@ryanshugart.com] Sent: 17 September 2015 00:24 To: Blind sysadmins list Subject: [Blind-sysadmins] NVDA remote VS Window-Eyes or JAWS remote access in a datacenter environment Hi all: I was wondering what the experiences here were using NVDA remote access as apposed to JAWS or Window-Eyes offering specifically in a datacenter environment managing remote servers. I have Window-Eyes set up on just under 200 servers, about 60 or so of which I access regularly and the others from time to time if ever (Window-Eyes is in our base image so its ready to go if needed.) With Window-Eyes, I know I can just RDP in, once a desktop comes up press ctrl+alt+w and am good to go. If I were to use NVDA in this same situation, I know it uses its own remote access protocol and not RDP, which is both good and bad, but was wondering what you have found the ideal setup for that is? Thanks a lot. Ryan _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins

Hi Blake: I will give your server a try next week and see how it works. For what its worth, I did try setting up the remote plugin properly then copying those settings to the secure desktop using the NVDA general settings, but that didn’t work too well. It seemed to copy the actual plugin but not its settings, not sure if that’s by design or not. Ryan

On Sep 18, 2015, at 6:56 AM, Blake Oliver wrote:

Hi

@Shugart, I think I have a solution to you're problem. [First though, I really recommend you iether try my self-hosted server addon copy, or use an externally hosted NVDARemote server]. You might find that if you set NVDA Remote up to connect to a remote machine on startup, then click "Use currently saved settings on the logon and other secure screens (requires administrator privileges)" in NVDA general settings, it will copy that configuration to where you can use it on secure screens. Oh, and FYI, my pull request was to add a "self-hosted" server feature, where upon startup, you could configure NVDARemote to set up it's own server instance with a key you provide, instead of connecting to a server not under you're control. This would be useful in many situations, especially for the more security-concious among it's users. Unfortunately I haven't heard anything from the developers about integrating my pull request into the main project, so I'll probably continue to develop my own open source copy of the addon.

Also, regarding community fragmentation, I feel it's inevitable with the way the developers are treating pull requests at the moment. Fortunately though, the project is open source, so people are free to improve upon it.

On 9/18/2015 3:59 AM, Andrew Hodgson wrote:

...

Hi,

One of the things that excited me about this addon is that it doesn't need any Citrix or RDP drivers installed on the host to get the support enabled, therefor I could use a portible version with the add-in installed and configured and just copy it to the server when I needed to use it. If I had my own server I could set it up to connect to that server at startup. Yes like you I wouldn't put the servers anywhere near ndaremote.com due to the keystroke issue.

Still a bit upset that after being on the beta list, then the server component wasn't released, there was absolutely no communication from the guys after this happened and the list closed. Any communications with the guys now about this just results in no response, and there reasons for doing this (i.e, someone could be tricked into connecting to a spoof server) I think would be the same for any remote solution. We now have another component that emulates the nvdaremote.com functionality, but this has now caused fragmentation in the community.

Andrew. ________________________________________ From: Blind-sysadmins [blind-sysadmins-bounces@lists.hodgsonfamily.org] on behalf of Ryan Shugart [rshugart@ryanshugart.com] Sent: 18 September 2015 00:50 To: Blind sysadmins list Subject: Re: [Blind-sysadmins] NVDA remote VS Window-Eyes or JAWS remote access in a datacenter environment

Thanks a lot everybody. I too am really surprised the server component hasn’t been released. However, my guess is NVDA remote was more designed with the primary vision of remote technical support, like a remote assistance thing and perhaps remote management of a machine second. Possibly very reasonable, I don’t know what the push to come up with this was. I don’t think the nvdaremote.comhttp://nvdaremote.com people would like 200 or so servers suddenly connecting up to their server for remote management, and considering that you’re basically sending key strokes and getting responses back, I’d imagine that the corporate security types around would really not sleep well at nights knowing that was going on. Today, I spun up a Windows 2012R2 VM in Azure and put NVDA on there and set up a remote connection between the VM and my computer. I wanted to simulate managing a remote server without setting up a test server at a remote office. One problem I ran into quickly was that while I could configure the NVDA remote session in my logon session to auto connect to nvdaremote.comhttp://nvdaremote.com, I couldn’t make the same change to the NVDA that ran at the logon screen. Because its Azure, you don’t have console access to the VM, just RDP access, so there’s no way to get to a logon screen to configure the NVDA there. That may be what Blake’s solution fixes, but I basically ended up needing to establish an RDP connection to the VM which started NVDA and then I could connect using the NVDA remote add-on. Blake, is this the problem you were referring to that you put in a request to get changed? For whatever reason I couldn’t actually send keystrokes through, when I tried nothing happened, but I could hear speech output, so it was kind of working, which was cool. By the way, to Troy’s point, RDP audio actually functioned a lot better than I thought it would, I think MS has cleaned that up a lot in 2012R2. There was still a noticeable delay, and I’m sure Azure VMs get really high-bandwidth connections, but it was still very usable. Would I want to rely on it when connecting to one of our remote offices in Australia or South Africa, probably not, but still, credit where its due. So, so far, I’m really liking NVDA Remote, and I think it meets a need, but I still finding myself wishing NVDA had RDP/Citrix virtual channel synthesizers like JFW and Window-Eyes do. The ability to just start a regular old RDP session, launch the screen reader and have speech just be piped through the channel is really cool, and considering how lean NVDA is compared to JFW or Window-Eyes it actually would make a decent screen reader in heavy use Citrix environments, so I’m a little surprised they haven’t gone down that road. But that’s just me. Ryan On Sep 17, 2015, at 9:49 AM, Blake Oliver mailto:oliver22213@me.com> wrote:

Hello.

I'm new to this mailinglist, but I think I can help here. Though the team that released NVDA Remote hasn't officially released a server component, thus (supposedly) limiting us to nvdaremote.comhttp://nvdaremote.com which I find slightly heavy handed, the open source community has risen to the challenge.

https://github.com/Technow-es/NVDARemoteServer

It's completely open source, with packages for lots of operating systems. I run several of these servers and have found no problems yet.

I've also submitted a pull request to the NVDA remote team that allows the add-on to automatically self-host a server at startup. I like this approach because it means you're computer doesn't have an open connection to a potentially unsafe server as soon as you start NVDA, rather it starts a server instance with a key you configure. I haven't updated it in a while, but if you're interested... https://github.com/Oliver2213/NVDARemote/tree/autoconnect

Hope this helps On 9/17/2015 11:35 AM, Andrew Hodgson wrote: Hi,

For me the NVDA remote option has been made less useful because we don't have the actual server component which makes things work a lot easier. I was hoping to be able to set up a local server on the network which could be used for central connections. I don't want to have to open up ports from my workstation to the other servers. I have a controlling admin host which I wanted to install the server onto. Also it is a lot easier if machines connect once logged into the central server.

Thanks, Andrew.

________________________________________ From: Blind-sysadmins [blind-sysadmins-bounces@lists.hodgsonfamily.org] on behalf of Ryan Shugart [rshugart@ryanshugart.com] Sent: 17 September 2015 00:24 To: Blind sysadmins list Subject: [Blind-sysadmins] NVDA remote VS Window-Eyes or JAWS remote access in a datacenter environment

Hi all: I was wondering what the experiences here were using NVDA remote access as apposed to JAWS or Window-Eyes offering specifically in a datacenter environment managing remote servers. I have Window-Eyes set up on just under 200 servers, about 60 or so of which I access regularly and the others from time to time if ever (Window-Eyes is in our base image so its ready to go if needed.) With Window-Eyes, I know I can just RDP in, once a desktop comes up press ctrl+alt+w and am good to go. If I were to use NVDA in this same situation, I know it uses its own remote access protocol and not RDP, which is both good and bad, but was wondering what you have found the ideal setup for that is? Thanks a lot. Ryan _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins

_______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins

_______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins

_______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins

_______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins

_______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins