Windows Virtual Desktop? Remote Solution?

Hi Emily, we have been using VDI within a Citrix environment at the Met for the past 3 years and have been very happy with it.  It really has been helpful during these times as we were able to give many of our users (especially call center users) access to the same desktop they are used to in the office but at home.  It definitely helped to lessen the work from home curve.  Its a very scalable and flexible solution as well.  There have been no issues with running Tessitura whatsoever.

If you want further details or to discuss just let me know.

Scott - strapani@metopera.org

Emily,

We are self hosted (our Tessitura stack runs in AWS) and all access to Tessitura is via the web. Our box office / call center staff utilize VDI's (VMWare Horizon View) which is also accessable via the web. Having our box office / call center staff running on VDI's definitely has its benefits as its the same desktop anywhere they go (same as Scott). If you have any questions let me know.

Mike Tiernan

tiernan@trustarts.org

Thanks for the quick replies, Scott Trapani and Mike Tiernan! How do your VDI instances handle the Tessitura .ini file for each users' Tessitura defaults? From my understanding of the Windows VDI, each session could live on any one of multiple host servers depending on the size of the environment. The users' profile is stored in terms of their default desktop views, but I'm curious how the Tessitura defaults would save to that user's profile. We're currently setup with a GPO that saves a local instance of Tessitura to the user's personal computer. If the user's personal computer keeps changing (in terms of host VMs), how can I get the local .ini file to stick to each individual user's VDI instance?

Additional question regarding cloud hosting - How/where are your file server(s) hosted? We're looking at Azure File Storage vs. Sharepoint, but are concerned about some of Marketing's massive files and egress traffic to load those files, as well as general performance speeds.

Thoughts?

P.S. Larry Becker and Eugene Karyakin, you might find this thread useful as well. Any updates you can provide on your end with Windows VDI?  

For our call center and BO staff we use persistent desktops so they get the same machine everytime.  WHen it comes to our Citrix servers themselves (multi sessions) we have their Tess shortcut point to s specific tessitura.ini which has their settings saved.  We don't have lots that require this setup lucky for us.

While we've only setup a single session host thus far, we've been able to publish Tessitura on the session desktop itself, as well as an application as part of the Application Group (pictured below). Since the release of the WVD "Spring update" a couple weeks back, it's much easier to deploy/assign permissions rather than messing with PowerShell.

The .ini doesn't come into play for us as each person still needs to login each time since we don't pass through Windows auth and rely on a separate login to Tessitura. I would imagine that if you need user specific ini files per user/profile you can employ FSLogix, but we haven't gone down that path yet.

The outstanding issue for us remains being able to select a default ticketing printer in the VDI session but fortunately, that's only a small portion of the population.

The selection of the default ticketing printer directly relates to the users' individual .ini file, as that is where that information is stored. I would think using windows authentication vs. not has nothing to do with the individual's .ini file - that's carried over from the master .ini as true/false if "integrated security" is setup in your environment. 

Emily,

Like I mentioned before we run VMWare Horizon View and our BO staff use persistent desktops. Our Tessitura environment is running on Windows RDS and we have multiple shortcuts that point to their specific Tessitura ini files (Live, Test, Dev, etc...) Below is a screenshot of what someone could have access to.

As for your file server question I am currently spearheading that same project. We have discussed Azure File Storage, Amazon FSx and SharePoint. Azure File Storage and Amazon FSx are both good alternatives (but could be costly depending on your storage requirements)  we just decided that we already have SharePoint online and the integration with the other office products helped with the decision (plus it is included in our Office365 Subscription). We are also moving users personal drives to One Drive for Business. Currently our Marketing design team has their own storage appliance independent from our file server for their files and I have the same concern as you regarding performance & traffic. We are currently testing SharePoint as our file server for our department currently so i'll keep you posted on how that goes.

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.