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!
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?
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.