Hey frands.
Has anyone explored using Windows Virtual Desktop as a remote and/or disaster recovery solution? If so, have you found it successful with a self-hosted instance of Tessitura? I would love to hear from you! Feel free to reply to this post or reach out to me directly at enash@2st.com.
Thanks so much!
I'm late to the discussion but can provide some of our experience so far.
We just recently went live with a Tessitura environment completely hosted in Azure. Our servers are running on Azure VM's, and the Tessitura Client is running in Windows Virtual Desktop via published Remote App in Remote Desktop. We're currently spreading our user load across 4 session hosts. So far performance has been as expected. We've scaled the servers up twice. Once after we went from pilot to full use testing and again when we went live last week.
As expected, our lingering challenges are with local ticket printing to Boca printers and saving of personal client preferences via personal .ini file. We have implemented FSLogix for profile management and believe that there will be a way to save the tessitura.ini file to a common location within everyone's profile so that their saved settings travel with them from session host to session host. However, we've not had time to get to that yet. Ticket printing was a bigger issue.
We expected to see the locally connected Boca printer show up as a redirected printer in the Tessitura Client Remote App. It shows up as a redirected printer in the remote desktop session itself and all other apps we've published can see the redirected printers. It seems the Tessitura Client simply can't recognize a redirected printer.
We also implemented Azure Universal Print and published our local Boca ticket printers as cloud printers. They too show up in the remote desktop environment but can't be recognized by the Tessitura Client.
We've worked around this by sharing the local Boca ticket printer on the local machine. When we set up the shared printer we enable the option to publish it in Active Directory and we are running Azure Active Directory sync in our local environment. The shared printers are also visible in the Remote Desktop sessions and fortunately the Tessitura Client is able to see shared printer objects. While not the most elegant solution it works for now.
We're hoping that someday something will change with the Tessitura Client so that it's able to recognize a redirected printer. Or better yet... a cloud printer.
On going challenges...
We need to "install" each shared ticket printer in each users remote desktop session. I suspect that these settings are getting saved in FSLogix somewhere but we've not had a chance to find that yet. Once we do, we'll look to put them into various users profiles via policy and group membership.
Always an interesting discussion!
Dan -- speesd@cso.org
Dan-
I figure you're running into the "benefit" of Universal printing. The no-driver nature usually means that documents are getting converted to PDF or some other markup for transfer before being printed, via driver or direct support, on the other end. This is usually a non-starter for the Generic/Text Only printers, and not easily overcome unless the developers specifically rectify it.If you want my IT answer to the problem it would be to set your BOCAs up on the network, publish/share/forward them using VPN/ZeroTrust/IPP or a combination, to the Virtual Desktops.
If you want my mad-scientist idea on this maybe there is a opportunity to use a combination of file-printing, winsock2 file handles/folder monitoring, and local printing that could keep the printers 1:1.
Christopher,
Thanks for the reply!
We were not able to get the Azure Universal Print option to work either. We ended up connecting the printers directly to a workstation, then sharing them from the workstation. We're able to see the shared printers on the WVD sessions and add them that way. Getting access to the printers is not a consistent problem with the Box Office staff using personal session hosts. They would encounter situations on the multi-user hosts where the shared printers were sometimes not available. However, we suspect that had more to do with timing of the connection sequence into the multi-user session. That doesn't seem to happen with the 1:1 session hosts.
Having the Tessitura client app burn through resources during the course of a session does seem to remain a problem. We're looking in to the network connected printer possibility now.
Thanks!
Dan
In a bit of micro-epiphany last night and remembered that RDP can do USB redirection, ostensibly this would apply to WVD as well.
While under normal circumstances this would be limited to those devices listed it is possible to redirect virtually any device with a few registry changes:https://docs.microsoft.com/en-us/troubleshoot/windows-client/remote/usb-devices-unavailable-remotefx-usb-redirection
Setting the key via a GPO should be easy enough for the first step. I'm not sure how you may be able to package the client for deployment (maybe a shared RDP template per computer?) but it does seem to be a potential option.
Of course this would all rely on a relatively low latency, though a Generic/Text printer shouldn't cause too much of an issue – it may need some tweaking on the driver end (one-way communication, etc) to ensure it works best.