BenTrojahn

True, i had vpshere/ms server licensing on my brain. Still, even with the all in one price from Omnissa, I'm pretty sure you are still paying the piper… you have no idea how much, yet. of course everyone's contract price is different so YMMV 😉

That just shows how every environment has unique workflows and most importantly license$$ agreements! My first reaction was 1.3 pcores/session is REALLY terrible. But it may be where you're at, IDK. I echo the others that you need to do a perf test and load up one of those servers while monitoring CPU RDY %. Since everything is now licensed by core, I'd look for the most cost effective which is *usually* the highest wattage = fastest base clock (all core turbo) cores in the fewest sockets/servers. For us, the special high freq cpus were prohibitively too expensive, nor could I justify the large cache cpus for our workflows. A spreadsheet racing will tell you which cpu wins at cost per session.

For us, this issue only happens on some 0365 with admin roles WHERE mfa was required. The clue was that the issue happens in the full Outlook client where we not have expected an MFA prompt on prem. Remove that role or MFA requirement and the issue went away. All O365 apps now login automatically.

EDIT: I read that with 2312 upgrade RDSH maintenance supposedly is fixed for this very issue! We are heavy RDSH with 50+ farms spanning multiple pods on 12 clusters . Farms page is typically for applying maintenance and disabling servers. Speaking of which Horizon handling of "Drain" mode needs work. Disabling Farms, or pools breaks reconnects, thus we disable RDSH to apply maintenance . Then we can be back in the FARMS page checking status again incase maintenance fails (not rare). We typically roll 1-2 image updates a week so that can be a significant time even though we don't typically drain but would reboot with 15min warning. The maintenance process should have an option to automatically disable RDSH servers at hh:mm so that new sessions are not started which maintenance is occurring or is about to. helpdesk Tool would be the next area followed by Global entitlements, application pools for troubleshooting. For instance: Ticket says "My Horizon is broke" Helpdesk Tool to find user's active sessions/app or which desktop or see session data (why cant you get to this tool from "Sessions tab"??>> then some combination of FARMs tab to disable server and Global entitlement tab to find how many pods and which local pools (sadly that the console cannot tell you about REMOTE pods/pools that are also in that global). Then from the pools, you can find the farm servicing that pool. Select your server and disable, or disable all RDSH if there's a larger issue.

I assume you are talking Linux client to Windows.... That seems to work the same as windows client except the linux com device source would be something like '/dev/ttyUSB0' . I think the 9600 baud limit is still a thing. If your having issues knock the speed down. Its been a few years and may be conflating issue, but i seem to recall an issue with USB 3.1 you can try another port.

iI the HZ console, I mostly in the "Farms" page. Not persisting column widths, column selections, and "Rows per page" setting is seriously hampering when you have more than 20 farms. (this has been a feature request from myself and others for years) The main all Sessions page would be infinitely more useful if column selections and widths could be used. I dont think I've ever used "ClientID" in 6 years and its taking up prime real estate. It would be great if you could get to the Help desk tool information for any session from this page. You cannot see "Applications" from this page either, for that you have go to the Farm and then see "Sessions" under that farm. Linking this data on one table view that can be filtered, selected and persisted would be a huge improvement. HZ console auth timeout shouldn't require a shift refresh of the page before you login again. This doesn't happen on the Appvol login page. For Global entitlements, it displays the number of pods are servicing that entitlement but not WHICH pod. being able to see pod\pool from any console would be handy.