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

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!

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!