Windows Virtual Desktop? Remote Solution?

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

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

Hi Dan -

I've run into issues with redirected Boca printers in terminal servers before and it usually has to do with Microsoft's "Easy Print" functionality. It is usually necessary to disable Easy Print on the terminal server before the Boca appears in Tessitura.

Thanks,

Patrick

Thanks Patrick.

I'm refreshing this thread partially to see if there would be interest in discussing holding an ad-hoc technical discussion on this topic sometime during TLCC2022 in Denver.  We continue to run into problems.  The "Easy Print" solution had no impact.  

At this point - our issues are being experienced exclusively by those Tessitura users who have a need to print tickets to our Boca ticket printers.  This impacts our Box Office to a significant degree.

In the process of troubleshooting this issue we determined that the underlying Windows OS was exhausting system resources.  This condition would degrade to a point where the OS was no longer able to fully "paint" a ticket print dialog box.  Fields would be missing and thus un-selectable, and eventually the process would simply abend without being able to be restarted.  

Since Windows 10 runs a multiuser version in the Windows Virtual Desktop environment, we thought that termination of the individual user's remote desktop session would resolve the problem.  We discovered that we needed to force them to reconnect to a different session host to get past the problem, and that once the issue occurred all users on that impacted session host would begin to have the problem until the session host itself was restarted.

To assist with troubleshooting by eliminating the multi-user version of Windows 10 as a possible variable, we implemented individual session hosts for each of our Box Office users and configured them to use personal session hosts in Windows Virtual Desktop.  This provided a single user Windows 10 environment and gave the user the ability to restart their individual Windows 10 session host to try and resolve the issue.  During peak times, when Box Office staff are doing a lot of ticket printing (in the half hour before concert time), the problem returns.  Box Office staff can restart their session host, but the restart can take several minutes which is difficult for them when faced with patrons standing at the window waiting.

It's notable that none of our other Tessitura users who don't print tickets have this problem.  It's definitely tied to the Tessitura client process that is called to print tickets.

I'd love to discuss this issue with ANYONE else who has experienced it or any similar issue with running the Tessitura client application in a selfhosted terminal server, multiuser environment.

Note: we've resolved the Tessitura.ini issue and figured out how to provide a personalized .ini file for each user during each user session.  That's no longer a problem.  We'd be happy to discuss that solution in a Windows Virtual Desktop environment with anyone interested. Now our issues are centered around users who print tickets and times when they are doing a lot of printing.  

I suspect that our problems are happening out of a combination of application issues, application use issues, and underlying operational environment issues.  We have another troubleshooting option that we will put in place to help reduce operational variables even more but would love to discuss this with others first.

Thanks!

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.