BillClark

Our current Citrix environment uses Ivanti Workspace Control to manage shortcuts, printers and user-specific application settings (Chrome settings/bookmarks, Word Quickparts, etc.). Our new user environment will be Horizon VDI using Windows 11 and DEM(hopefully). We were wanting to make the switchover as easy on the end-user as possible, so we thought we could install DEM & Ivanti Workspace on the master image and use this in a separate Desktop Pool. The thought process is that a user logs into this pool, Ivanti kicks in like normal and loads all the familiar settings from their previously saved Ivanti Workspace profile. Meanwhile, since this would be a new user to DEM, it has nothing to do and sits there. Because we have most of the same capture settings from Ivanti replicated in DEM, we were thinking that those folders, files and registry keys have been restored by Ivanti, that when we sign out, DEM will kick in and copy all those settings the users new DEM profile. Sadly this is not the case. At the initial login, I see the DEM profile being created and when we signout from the session, I see some DEM settings being captured, but not all. I guess my first question is, has anyone else attempted something like this? Are we trying to achieve something that simply isn't going to work due to how DEM functions? I was thinking that since DEM is configured to look at certain folders/files, that it would see stuff there and save it on exit, but maybe I'm wrong in how it senses what to save. Any help or guidance is greatly appreciated. Thanks!

So to wrap this all up. At some point, with the "old" domain account, a desktop pool became corrupted behind the scenes and was causing the lockout issues. Once I added a new domain account, then rebuilt the desktop pools with this new account, the locking issue went away. The reason I'm still seeing the "old" account in the logs is because that account is used in the Edge Gateway appliance. I wasn't able to change that account on my own, and have opened a case with Omnissa to investigate it. At this point, the "old" account is gone from the Horizon Console, and all the Desktop Pools have been rebuilt and are functioning normally. Thanks all!

Jon, upon closer inspection this "old" account IS being used in the Edge Gateway. I've initially tried to update that with a different account, but I've been thwarted by the IT Gods again. It keeps saying the credentials are incorrect, which I know they are not, but it might be something else going on. I've opened a case with Omnissa regarding this and hopefully we can get it worked out soon.

We do have the Horizon Edge Gateway deployed and I looked at it this morning, but I'm not sure where that possible credential could be. I'm almost 100% sure that if it was asking for creds of some sort, we wouldn't have used that account. On a side note of interest, working with Tom at Omnissa, he found the "old" account was still listed as a Security Principal for 3 out of the 4 Desktop Pools. As a test, I deleted, then re-added two that were unused and after that, the "old" account isn't getting locked out anymore. This was several hours ago and it is still unlocked. I still see that account being used in the Event log on the Horizon Console, but it's all been Audit Success status since then. I'm going to do the delete/re-create to the other 2 Desktop Pools in hopes that it eliminates ALL references to that "old" account.

To my knowledge, no, we are not. At least for any 3rd party software or monitoring outside of the basic Horizon Console, (x2) Connection servers and the Standard Edition of DEM. We have a very basic setup with the few items listed.

When we started our Horizon environment I chose an existing service account as the "domain account" (Settings\Domains\Domain Accounts). The issue I'm running into is that something happened and Connection servers are locking out this account, which in turns creates problems for all the other applications this account is used for. I've created a new domain account to be used just for VDI purposes and have added it to the Horizon Console. I've gone in and modified the existing Desktop Pools to use this new account and then re-published each Pool and everything went well. I then deleted the original domain account from the Horizon Console, but I keep getting the following errors in the Events screen of the Console. Source: Server1.domain Message: User <domain>\<OriginalAccount> has failed to login to Horizon Server REST API Somewhere Horizon is still clinging onto this old account even after multiple reboots and continues to lockout the original account. How do I reset the account that the API is using? Thanks.

Rob, thanks for reaching out. Late yesterday afternoon we finally got our official licenses! Progress!! We got the Horizon Edge gateway setup and configured(don't get me started on this topic...not happy). Late last night it finally synced and I see my Horizon Console has updated the licensing information and everything checks out. Last bit of the puzzle is that I'm still missing the vSphere licenses. I don't see anything downloadable through the Omnissa Cloud Services and checking our Broadcom account this morning, i don't see any new licenses there either.

Thanks everyone for the time and replies. I see several options to play with and see what works best for us in our environment. For sure, I'll get the printer drivers installed on the master image to reduce overhead on that aspect of printer creation.

Been over a month now, and still no official licenses from Omnissa for our Horizon licenses we want to purchase (new customers). Same river, different boat, I can't get Broadcom to reply to my requests for extended trial licenses as they recently expired and our whole soon-to-be production Horizon environment has been dead in the water for 3 days now. I don't understand how hard it is to take a pile of money and convert it to a simple license key. Our software partner says they are trying their hardest to get the licenses but no luck yet. Not sure what to believe at this point.

@Clifford O Rourke Can I open an SR without a valid license? That is another issue we are currently facing...been trying to get licenses for 2+ months now. Thanks.

Experimenting with a new VDI environment and how best to setup printers on the guest workstations (using Instant Clones in Horizon). Using DEM Printer Mappings under the User Environment tab, I have setup several printers that are hosted on our internal print server. I'm using the conditions option to only install the printer if a user is a member of an AD Group. Initially, this is working well but has a bit of a delay in installing the printer to the session. I'm wondering would it be better/quicker if I pre-installed the necessary print drivers to the golden image so when DEM is installing the printer it doesn't have to drag the driver files across the network each time? Or does this even matter and it will always install the printer driver from the print server during the install? In our testing the delay isn't horrible, but that is with 1-5 users and I have a feeling that delay will get worse when 150+ users are all firing up sessions and printers are being installed.

@Clifford O RourkeI do see some of those entries, but they appear to be showing a normal logout, like I had clicked the button. I know for a fact that at this particular point in time, the logs show a "normal" logout yet the console timed out and disconnected by login.

@Anobix67That's exactly what is happening to us. Trying to create new desktop pools and if you aren't quick about it then we are timed out and have to start over from scratch. Irritating to say the least.

I see several entries like this: "(SESSION:9381_***_6921) Client supports idle session handling. User idle timeout set to: never. Desktop SSO: enabled. Application SSO: enabled." Not sure if that is referencing the admin console or not.

Horizon Connection server v8.11.0.22629722 w/ the Horizon Admin Console showing v2309. Currently the console session times out too quickly. I've seen several articles about adjusting the "Horizon Console Idle Session Timeout" and "Horizon Console Session and API Timeout" values in Global Settings, which I've done, and have set them both to 60 minutes. I've restarted the connection servers but those settings seem to be ignored and at best I get 10 mins of idle time on the console before I have to login again. Is this a known issue or am I missing a different way to configure the idle timeout value?