Are you the publisher? Claim or contact us about this channel


Embed this content in your HTML

Search

Report adult content:

click to rate:

Account: (login)

More Channels


Channel Catalog


Channel Description:

Most recent forum messages

older | 1 | .... | 881 | 882 | (Page 883) | 884 | 885 | .... | 904 | newer

    0 0

    This is known issue with Windows 10 1709.

    See Horizon 7.5 Release Notes.

    Quote:

    "When you log into a VM configured with Persona Management for the second time, the Microsoft Edge browser crashes and an error message that states the OneDrive application has never been used appears. Additionally, the files and folders cannot be replicated properly. This happens only with Windows 10 build 1709 November 2017 update.

    Workaround: Disable the Persona Management setting Roam Local Settings Folders. When you disable this setting, the Microsoft Edge browser works properly but the OneDrive application is only available when you log in for the first time."


    0 0

    Problem resolved by upgrading to 7.5


    0 0
  • 06/14/18--05:36: UAG with Horizon/vIDM
  • Has anyone implemented UAG with both Horizon and vIDM on the same appliance? Or when pairing, do each technology require separate UAG appliances?


    0 0

    I have, doesn't ever seem to show. But it does look like the input is making it to the machine. If I remote view the virtual machine from my windows desktop I can see the mouse and keyboard inputs I'm doing on the mac.


    0 0

    We have 1 user who is seeing an issue when he attempts to go to a specific pool that used to work fine for him. Now though, when he clicks on the pool after authenticating with his Horizon client, he gets the message "This desktop is currently not available. Please try connecting to this desktop again later, or contact your system administrator.". If he switches to other endpoints (even even HTML Access), he gets the same message. If I use my account, from these same endpoints, I get in fine. I did verify that this user does NOT have any current sessions on the pool. Is it possible something in the ADAM DB is saying this user is signed on/hung up, and is not clearing?

     

    Horizon 7.3.2. Using Cloud Pod. 4.7 Client, 4.8 Client, Wyse ThinOS, and Chrome HTML Access clients have been attempted.


    0 0

    Same issue in our environment.  Removing AdBlock Plus resolved the issue.  For fun we tried uBlock Origin and did not see the bad behavior.


    0 0

    • Sounds like this is not applicable since you logged on from the same endpoint but I have seen this issue when:
      • The customers are using the Recent Connections as opposed to actually launch Server URL.
      • When there were actually no available Desktops in the Pool.
    • I would also suggest launching the Admin Console on all of your Connection Brokers and validate they numbers all look the same on the dashboard and status looks same across the board. This will rule out a sync issue with the ADAM Databases between the Connection Brokers.

    0 0

    Anyone else have this exact use case?


    0 0

    Sounds like you may need UEM Smart Policies to do this task. You can enable printing on-prem but disable for remote users coming through your APs.


    0 0
  • 06/14/18--19:28: Re: UAG with Horizon/vIDM
  • I was told by a VMware engineer that you can use the same UAG for both Horizon View and vIDM but you would need to enable "Enable Workspace One mode" and it must be set to required.

     

    In Horizon View admin page > Servers > Select connection server > Edit > Authentication tab > Delegation of authentication to VMware Horizon (SAML 2.0 Authenticator)


    0 0

    Has anyone been able to configure EV in non-persistent VDI environment?


    0 0

    I just found almost 9 GB of these files on my own VDI client. There must be a way to disable this


    0 0

    Yeah it's not the recent connections option for us. He's attempted from endpoints like a Wyse thin client, where it's a fresh started up connection. Not like a Windows or Mac client where it's even offering the recent connections.

     

    I did check the Brokers, we have 7, and one at a time, all are in sync.

     

    We also have plenty of available VMs. We have connections into this pool all throughout the day, with 10% of of the pool always powered up and available. Still, the only user with this issue is this ONE user consistently. Never anyone else.

     

    Support asked us to remove him from the global entitlement and entitle him manually to the pool. I did the manual entitlement but, I didn't remove the GE access as it's a bit convoluted. Still working that out. That being said, even with a local entitlement, he has the issue.

     

    I've attached a screenshot of what he gets when attempting to login via the Wyse thin client. I'd love to find out if that number (I assumed a GUID) is hung up somewhere. I've asked him to login again today, and see if the same VM is offered. This screenshot was from yesterday, June 14th.

     

    Thanks for your help.

     

    Untitled.png


    0 0

    Just had the user connect again, and he did indeed receive the same error with the same GUID (or what I assume is the GUID). These tests were performed over 24 hours apart.


    0 0

    Try and get him logon, have it fail, and get the logs from client. In the %programdata%\vmware\vdm\logs folder I think there is a debug log. Search for his name and there should be an error that might help narrow it down. I'm pretty sure that log should show him starting to logon but something interupts it. I'd look at using AD groups for entitlements too, I'm using ad groups for global and local entitlements. That way if I need to swap someone out its pretty straight forward.


    0 0

    Also is he connecting from an unique place, one that may have a firewall rule in the way?


    0 0

    Is there by chance a Problem Machine from that pool that has his session stuck?

     


    0 0

    Try running this in the View PowerCLI to see if you can locate the problem VM. If you find it, I'd delete it.

     

    Get-DesktopVM | ?{$_.machine_id -eq '17120395-4754-49a5-98eb-b56109326f3a'}


    0 0

    He has actually tried from outside our secure network, as well as inside it, both with the same results. I have actually logged in from the literal same thin client on his desk to this pool without issue. That kind of knocked the endpoint device out of the equation for me. It's just him, and it had been fine for about 2 years. We THINK this started about a month ago during a network failure we had. He was connected that day, we had a major issue with a network firewall, and he swears it's ever since then. That's why I'm not so sure about messing with the entitlements since nothing changed, but, I'll try anything when I get back together with him.


    0 0

    No problem desktops at all in that pool unfortunately. We also scanned through the pool to see if any were in an odd state that wouldn't show as a problem desktop, and nothing there either. I did run the command you provided, but, no results came back. That really throws me through a loop. I swore that would at least give me a VM back, even if not a PD, and I'd blow it away and have him test again. No such luck though, no return.

     

    I did correct the line though. You had 4754 as part of the GUID in your command, but it was actually 4745. Still, nothing. The search continues.


older | 1 | .... | 881 | 882 | (Page 883) | 884 | 885 | .... | 904 | newer