nda

Thanks -- this is helpful. Now just have to wait for the HPE ThinPro devs to catch up.

Can you be more specific? There is nothing in the Horizon Client for Linux v2503 release notes that references this -- Omnissa Horizon Client for Linux Release Notes

Is that an undocumented parameter? I don't see it listed on documented options? What does this parameter do exactly?

Our support case for this issue is 01146092 -- it was originally opened for a keystroke repetition issue that we see in Horizon Client for Linux (basically this issue, and also detailed in this thread which was supposedly resolved in newer Horizon Client releases), but I'm adding the keyboard disconnect symptom to it now, and asking to piggyback on the following other support cases opened by the community for the same: 00887438, 010011401, 01045884

Our environment has also seen this issue and we have been struggling with it for a while now. I have open tickets with HPE for our ThinPro clients and with Omnissa directly but haven't gotten much traction on either side yet. We have seen that our 'Client to Remote Session' connection is always UDP in these cases, and even though we have a very strong backbone and we can absolutely guarantee that UDP packets are not being dropped, we are testing disabling UDP in BLAST and forcing TCP everywhere to see if that helps resolve the issue. Unfortunately I don't have feedback on the success of this yet but I'll keep you posted once I know more.

Just food for thought -- our Page File is currently statically set at 8GB, which may not provide enough Commit Charge for our larger VMs. We are increasing our PF to 20GB today -- we'll see if that makes any difference.

Our environment also experiences this issue -- in our case, our standard VMs have ~4GB-6GB of RAM, which users will occasionally consume when running lots of browser tabs (Edge, Chrome, etc). Our power users more frequently experience this issue when doing things like opening large PDFs or things like Bluebeam Revu, which can rapidly consume large segments of RAM. It would be nice if we could reserve a certain RAM footprint for the BLAST worker or otherwise increase its criticality so Windows would not ask to reclaim RAM from it. We can reserve bandwidth for Blast, but not RAM?

Hi @Greg New -- sadly the Omnissa Support team, including their 'very knowledgeable' escalation engineer, have stopped responding to my (still open) support case for this issue, so I haven't made much headway on it lately. It does appear that you've stumbled onto the same issue though, as I imagine the data reported within in the Performance Tracker is just a reflection of the data received by the Connection Server, either directly or passed by the UAG. I am still under the impression that the UAGs are not retaining true remote IPs of authenticating clients in the logs, and are instead erroneously replacing the client IPs with 127.0.0.1 per my original post. I've extracted the support bundles from my UAGs and run full-text searches and I don't find remote WAN IPs anywhere in them. I would enjoy being proven wrong here.

Same issue here, still have an open ticket for it. If you're not using native HA then this issue may not be relevant for you. Out of curiosity, does your esmanager.log contain the public IPs of the clients making the attempts?

I believe the entries in the bsg.log only appear after successful authentication, once the client connects to the pool and BLAST starts up and connects to the desktop. I don't believe failed authentications or attempts would be present in the bsg.log. The support technician assigned to my case is telling me that I'm trying to make a feature request for this functionality, despite the page here clearly and precisely detailing fields like 'ClientIP': "IP Address of the component (such as Horizon Client, load balancer, and so on) that sends a request to Unified Access Gateway appliance." and example log snippet output such as: On my UAG the "Client_Machine_IP_Address" for all log entries is 127.0.0.1, which is obviously erroneous -- is it a feature request to have this field report the actual client IP? I'd argue not.

I agree with the recommendation in principal and in general. But it's not appropriate for all environments -- hence 'recommendation' and not 'requirement'. Sadly, in a sufficiently complex and diverse environment, full automation of such a deployment is not even possible. We utilize a variety of applications that don't support scripted installation, and\or don't support scripted or file- or registry-based configuration. As such, even if we could automate >80% of the build, we'd still be spending many hours installing and configuring additional software, and then testing and troubleshooting the whole stack. Such as it is, we are burdened with supporting older and\or highly niche and specialized and tailored software, and there is not much to be done about it. Anyone who has worked in healthcare, municipal environments that support public services (e.g. police or fire), manufacturing, defense contracting, etc, are likely to understand this predicament. I fully resonate with the feeling of apprehension here. I've seen plenty of upgrades go sideways in large and small ways, leading to catastrophic failure, system instability or just general weirdness. But I think the risks of such failures are largely mitigated in virtual environments (e.g. cloning, snapshots). And like I said, sometimes you just have to trust the process -- in-place upgrades have become the norm for workstation OSs (and increasingly so for Server OSs lately), and if Microsoft supports it then we should at least try and have some faith. Maybe faith in Microsoft is displaced for some, but Windows is still ~70% of global market share. I'd also like to point out that, in my environment and this instance specifically, this issue would not have been resolved with a fresh build. Since my issue was driven by DEM, as soon as I installed the agent and recomposed I would very likely have been faced with the same error message again. In this case I'm glad I didn't burn untold hours on the process of building from scratch, and instead remediated the issue with appropriate troubleshooting methodology.

Our environment has a pair of Unified Access Gateways running in the native High Availability mode. Recently we are seeing high numbers of failed logon attempts and we would like to correlate these attempts back to the source IPs so we can start blocking the attempts on our perimeter firewall. However, the UAGs do not appear to be recording the true Client IP of the connecting system. From the Connection Server we see: <162>1 2024-10-17T14:51:46.127-07:00 VIEWCON2.<domain.local> View - 158 [View@6876 Severity="AUDIT_FAIL" Module="Broker" EventType="BROKER_USER_AUTHFAILED_RADIUS_WRONG_STATE" UserDisplayName="backup" ClientIpAddress="<removed for opsec but it's the UAG's public IP>" ForwardedClientIpAddress="127.0.0.1"] RADIUS access denied for user backup because of incorrect state From the UAGs we see: <13>Oct 17 15:12:52 ipv6-localhost uag-esmanager_:[nioEventLoopGroup-11-2]INFO utils.SyslogManager[putUserNameInMDC: 405][127.0.0.1][backup][Horizon][182e-***-7451-***-e3b6-***-c8bc] - UAG sessionId:182e-***-7451-***-e3b6-***-c8bc username:backup In both cases the reported Client IP is 127.0.0.1 , not the publicly routable\Internet IP of the connecting client. I have dug through the log bundles generated by the UAGs but I'm not finding the true client IP stored or reported anywhere. This seems like a major oversight. I suspect that the failure lies in having the HA mode configured, and that the HA NLB process is forwarding the client request internally but not maintaining the "ForwardedClientIpAddress" attribute. Our environment does utilize RADIUS on the connection server (not on the UAGs), and we do not NAT the incoming traffic across from the firewall (the UAGs have publicly accessible IPs configured directly on them). I do have an Omnissa Support ticket open for the issue but so far the technician is spinning his wheels and asking for all sorts of irrelevant information. Any insight into this behavior would be appreciated. I really need the true Client IP reflected in the syslog traffic so I can correlate and aggregate the data on my SIEM, and I'd like to get this done without dropping the native HA mechanism and putting these units behind my actual full-fledged NLB.

I am familiar with the article here which details OS upgrade support, including support for leaving the Horizon Agent installed for Full Clones during the upgrade. However this article does not reflect that OS upgrades are prohibited for IC pools or other Horizon use cases, just that the Agent should be removed before and reinstalled afterwards. I am not familiar with any Horizon documentation that expresses a prohibition on in-place upgrades. The recommendation is always 'start fresh', of course, and again I agree that this is the best route overall. But sometimes the juice isn't worth the squeeze.

Every iteration of application layering that we have implemented and tested (ThinApp, Unidesk before it was Citrix-owned, AppVolumes) has been a comical dumpster fire of added complexity. It certainly does not reduce administrative overhead -- it is just another solution to maintain and another point of contention to troubleshoot. The issues with these solutions revolve around interdependency and common\shared features between layered applications. With a large and complex application set, eventually you will find a set of two (or more) layered applications that have conflicting binaries, shared dependencies (Visual C++ or Crystal Reports, for example), or conflicting registry keys, and then you'll spend inordinate time troubleshooting these conflicts so you can attach all your possible layer combinations without breaking things. 'Layer Priority' -- I don't miss it. Not to mention the significant loss of performance that can occur when attaching another file system filter driver that has to 'think' about where to direct your I/O. Again, solutions like AppVolumes are certainly not one-size-fits-all. You're right that most users don't need most apps -- we restrict their access via AppLocker, and we don't mind that they can see the application shortcuts in the Start Menu. It's hard to understate the ease of management that comes with managing everything with a single image and no layering -- OS updates, application updates, recomposing... everything is dead simple with this approach and it's easily the lowest complexity approach for a small team to manage.

Citation Needed. Gentlemen, I'm all for constructive criticism, but at some point you just have to trust the process. I generally agree that starting from scratch and deploying programmatically leads to the most reliable platform, however this deployment methodology is not appropriate for everyone -- and deferring to it as knee-jerk panacea-style solution for every issue isn't conducive to successful troubleshooting. Try to stay on topic please. In our case, we have 195 applications installed on the Gold, and years of deep customization and troubleshooting to make everything work nicely. Maybe this is technical debt, hard to say really. But building a new image is no small feat for us. We are a small team supporting a large and complex user environment, so resolving issues is preferable to starting from scratch in almost every scenario. Cattle vs Pets maybe, again, hard to say. For anyone else experiencing this issue ( @Super6VCA ) , I was able to resolve this today with some additional troubleshooting. In our environment, we found that the UEM\DEM profile for 'Start Menu' was causing the issue. We had made some OS-specific profiles for various things but we had left the default 'Start Menu' archive applied to both Windows 10 and Windows 11. By limiting the default 'Start Menu' profile to just Windows 10 via condition, and creating a new profile for Windows 11 (also limited via condition), we no longer see the issue occur. I suppose there is some old junk in the Windows 10 Start Menu archive that no longer play nice. The loss of Start Menu customization between Win10/Win11 environment transitions is acceptable for us, so this solution is a good one long-term.