3 ms·

Show HN: I found a crazy way to stream audio from Windows Server without RDP

4 points by keepamovin 3y ago

This is too intricate and niche most people will probably not even know what it means, so I can't just post a link to the code, but I've included that below. Basically I wanted to set up my project BrowserBox on Windows Server, and went down the long and tangled rabbit hole of: Yes but how do you stream audio from Windows Server? It turns out that there's no good way to do it. It used to be you could just use a "Virtual Sound Card", or "Virtual Audio Cable" as developed my many independent software shops that seem to have developed an entire business around offering such products. However, the recent security-focused Windows kernel driver signing requirements meant these little utilities often no longer worked. In addition, they were, for the most part, commercially licensed. And as BrowserBox was an open-source product that was AGPL-3.0 with commercial available, figuring out how to include a sub-licensed per-seat component like a VAC was too confusing to bother with. Not to mention potentially expensive. With VAC vanquished by Windows security updates, a new option was required. Well, it seems that RDP itself comes with the ability to either use or, enable a dedicated Microsoft-authored virtual sound card driver, already present in Windows Server or RDP, then RDP itself may be a good option. Indeed it is. Or rather, it was. Until of course you need to disconnect that RDP connection (to save bandwidth or simply because you don't want the additional unnecessary overhead of a remote desktop when you're really just interested in, and already streaming, a remote browser more efficiently). Long story short: there seemed no way to keep the audio, once you had disconnected from RDP. This was a well trodden (if now cobwebbed) path. Many had passed by these ways before, there skeletonized remains visible in the endless early-2000s style Windows-focused "tech forums" that dot the web. Most of these posts suggested the, now impossible to use, VAC et al family of solutions. Well, it seemed like BrowserBox on Windows was dead. If I couldn't stream audio, the app would be far inferior to how it worked on other platforms. But, I loved Windows, or at least what it stood for (which to me is: Hi, I'm Windows, I work everywhere and run everything. Everybody uses me. At least some of the time). I figured, that if BrowserBox couldn't work on Windows, then, well, it wasn't really a real application. And I did not feel happy about that. But this was already around a week of 10 hour days in to the overall windows port, and hundreds of lines of PowerShell would end up wasted. I wasn't ready to let it go. So I persisted. Story of my life when faced with some tech challenge. But it seemed like there was no path forward. Part 1/2. Continued below...

keepamovin 3y ago
Part 2/2. Continuing below... Then, I happened upon the quaint idea of using tscon %sessionId% /dest:console to "repoint", or reorient an active RDP session to instead targe the "console", a sort of persistent virtual terminal session that the computer always has. From the days of when people actually sat in front of the machines they were using. Physically, like. I thought that if I could send my RDP session to console then it would live. It would be alive! And it was. But the audio still died. All the while, I was context switching out of RDP back to my macOS desktop, to check my BrowserBox connection open in a regular browser tab. Every time, no matter what weird configurations, registry settings, or supposed ways to change various settings related to RDP, nothing worked. Every time audio still died. This was quite possible the biggest, craziest bug I ever worked on. (Interestingly enough the second biggest, craziest bug I ever worked on was also audio related). But maybe it wasn't a bug. Maybe it just wasn't to be. Perhaps the gods willed it to be not so. None shall ever, from now until the ashes fall upon the ghost of the world, and time stands finally still, stream audio from Windows Server without a real RDP connection. It was during this period I also discovered the idea of a Windows Session Host server with Client Access Licenses. Turns out, you need to purchase a RDP license from Windows if you want more than 2 RDP sessions (approximately) to the same OS instance/VM. Turns out, too, that this notion was not related at all to getting audio to work. It really seemed like I'd never get there. I was starting to think: Cut my losses, abandon it. It was a nice dream, shame it didn't work out, but that's what happens sometimes. One day, I woke up with a hunch, that if I could someone use VNC at the same time as RDP, perhaps I could trick the repointed console session into staying alive. I didn't know how or why this should happen, but it just seemed like: it should, somehow. As if through all my intense working with Windows, it was somehow whispering to me, telling me how it wanted to be treated. As if Windows itself wanted this to occur, and somehow through all the interacting with it, I'd absorbed that message. And figured it out. I knew I was onto something with this. Momentum, and optimism, returned. I felt re-energized. I began to feel like this was possible. But still, I had no idea how to do it. Turns out, I eventually figured it out. And made it repeatable. And further that it worked on: Windows Server 2022, Windows Server 2019. It also, IIRC, worked on Windows 10 and Windows 11. I formalized it all into a ridiculous PowerShell script where nothing now seemed impossible (so I went so far as to even use crazy C#-in-PowerShell hacks to close windows automatically as part of the install process, just to ensure that all that epic work, 10 hour days, maybe for over two weeks or more, were not wasted. And finally I ended up with a script that actually managed to both install BrowserBox, and set up the required VNC/RDP dance needed to keep the Windows audio drivers active, even when I do not have an RDP connection. It was kind of complex, and like synchronized swimming, depended crucially on the order of the orchestrated VNC and RDP connections, and what was done in each session, but roughly, the process the enable audio on Windows versions, went like this: - Create an initial RDP connection to the Windows based server for setup. - Set up the application by performing a normal install of BrowserBox - Open up registry key settings enabling: multiple (the maximum allowed for free, which is 2) sessions; and connecting to localhost - Also set up a login script that will perform "The Magic Task" described below. - Install VNC, and configure it with a password. From within that RDP session, create a VNC connection from that Windows server to itself, and ensure that VNC window is open and not minimized. - From within that loopback VNC session just created, execute the logon script (which will happen automatically) to perform the Magic Task. The Magic Task is: use tscon to repoint the current main active RDP connection (from my local computer to this remote Windows machine) to instead point at console, disconnecting me, and creating a ourobouros-double-loopback-VNC-RDP-ying-yang super session that is self-stabilizing and crucially (Crucially! because at that point it had been 3 weeks of effort!), keep the audio streaming The music might die one day. But not today. I managed to factor out this code into a relatively reusable-esque script that I called Thunderbird (because I was so in awe of myself at that point haha!) You can see the code here: https://github.com/BrowserBox/BrowserBox/blob/boss/windows-scripts/BrowserBox-Installer/Thunderbird.ps1 https://github.com/BrowserBox/BrowserBox/blob/boss/windows-s... Postscript Turns out tho, despite all that effort, Windows was never a very popular target for BrowserBox. Sure, good to prove that it works there and provide a first blush at support, but in the end, not that many people use Windows to run BrowserBox. As proud as I am of that achievement, I can't even guarantee the method described still works today. The script had so many moving parts, I imagine it would be pretty fragile. Also, I have a suspicion that, as of this post today, Microsoft may hear this and want to lock down this seeming workaround because, even tho I don't think there's a way to use it to get more RDP connections that licensed, it sort of seems like something that shouldn't be possible, so I'm kind of worried they will just stamp it out.

4 points by keepamovin 3y ago

keepamovin 3y ago

Part 2/2. Continuing below... Then, I happened upon the quaint idea of using tscon %sessionId% /dest:console to "repoint", or reorient an active RDP session to instead targe the "console", a sort of persistent virtual terminal session that the computer always has. From the days of when people actually sat in front of the machines they were using. Physically, like. I thought that if I could send my RDP session to console then it would live. It would be alive! And it was. But the audio still died. All the while, I was context switching out of RDP back to my macOS desktop, to check my BrowserBox connection open in a regular browser tab. Every time, no matter what weird configurations, registry settings, or supposed ways to change various settings related to RDP, nothing worked. Every time audio still died. This was quite possible the biggest, craziest bug I ever worked on. (Interestingly enough the second biggest, craziest bug I ever worked on was also audio related). But maybe it wasn't a bug. Maybe it just wasn't to be. Perhaps the gods willed it to be not so. None shall ever, from now until the ashes fall upon the ghost of the world, and time stands finally still, stream audio from Windows Server without a real RDP connection. It was during this period I also discovered the idea of a Windows Session Host server with Client Access Licenses. Turns out, you need to purchase a RDP license from Windows if you want more than 2 RDP sessions (approximately) to the same OS instance/VM. Turns out, too, that this notion was not related at all to getting audio to work. It really seemed like I'd never get there. I was starting to think: Cut my losses, abandon it. It was a nice dream, shame it didn't work out, but that's what happens sometimes. One day, I woke up with a hunch, that if I could someone use VNC at the same time as RDP, perhaps I could trick the repointed console session into staying alive. I didn't know how or why this should happen, but it just seemed like: it should, somehow. As if through all my intense working with Windows, it was somehow whispering to me, telling me how it wanted to be treated. As if Windows itself wanted this to occur, and somehow through all the interacting with it, I'd absorbed that message. And figured it out. I knew I was onto something with this. Momentum, and optimism, returned. I felt re-energized. I began to feel like this was possible. But still, I had no idea how to do it. Turns out, I eventually figured it out. And made it repeatable. And further that it worked on: Windows Server 2022, Windows Server 2019. It also, IIRC, worked on Windows 10 and Windows 11. I formalized it all into a ridiculous PowerShell script where nothing now seemed impossible (so I went so far as to even use crazy C#-in-PowerShell hacks to close windows automatically as part of the install process, just to ensure that all that epic work, 10 hour days, maybe for over two weeks or more, were not wasted. And finally I ended up with a script that actually managed to both install BrowserBox, and set up the required VNC/RDP dance needed to keep the Windows audio drivers active, even when I do not have an RDP connection. It was kind of complex, and like synchronized swimming, depended crucially on the order of the orchestrated VNC and RDP connections, and what was done in each session, but roughly, the process the enable audio on Windows versions, went like this: - Create an initial RDP connection to the Windows based server for setup. - Set up the application by performing a normal install of BrowserBox - Open up registry key settings enabling: multiple (the maximum allowed for free, which is 2) sessions; and connecting to localhost - Also set up a login script that will perform "The Magic Task" described below. - Install VNC, and configure it with a password. From within that RDP session, create a VNC connection from that Windows server to itself, and ensure that VNC window is open and not minimized. - From within that loopback VNC session just created, execute the logon script (which will happen automatically) to perform the Magic Task. The Magic Task is: use tscon to repoint the current main active RDP connection (from my local computer to this remote Windows machine) to instead point at console, disconnecting me, and creating a ourobouros-double-loopback-VNC-RDP-ying-yang super session that is self-stabilizing and crucially (Crucially! because at that point it had been 3 weeks of effort!), keep the audio streaming The music might die one day. But not today. I managed to factor out this code into a relatively reusable-esque script that I called Thunderbird (because I was so in awe of myself at that point haha!) You can see the code here: https://github.com/BrowserBox/BrowserBox/blob/boss/windows-scripts/BrowserBox-Installer/Thunderbird.ps1 https://github.com/BrowserBox/BrowserBox/blob/boss/windows-s... Postscript Turns out tho, despite all that effort, Windows was never a very popular target for BrowserBox. Sure, good to prove that it works there and provide a first blush at support, but in the end, not that many people use Windows to run BrowserBox. As proud as I am of that achievement, I can't even guarantee the method described still works today. The script had so many moving parts, I imagine it would be pretty fragile. Also, I have a suspicion that, as of this post today, Microsoft may hear this and want to lock down this seeming workaround because, even tho I don't think there's a way to use it to get more RDP connections that licensed, it sort of seems like something that shouldn't be possible, so I'm kind of worried they will just stamp it out.