A user can get a message like “Loading Failed“ (Unable to Connect to Desktop).
In most cases you will check if the user:
- Has the correct access
- If there is enough capacity
- Perhaps restart some desktops
If non of the basic steps will help to get the user connected the user could have the problem described her.
Login into the Horizon DaaS admin portal
- Go to the global “Activity“ – “Users“ under “Monitor“. (not the assignment!!)
- At the right side of the page you can export data, choose “ALL DATA“
- This will give you lots of information and try to sort the data for the problem user and correct date
This shows us that the user tries to login into a desktop with patternID “S.1022.995.26“
(Failed to find template for patternID=’S.1022.995.26′)
And the correct logon is a manual assignment to a dedicated desktop to make sure the work like it should be (for testing off course).
As we see in the user activity log there is an error. When looking into the desktone.log (this log file is located on the tenant appliances. And only your cloud provider can access this log) you will see another error as well.
2022-07-25 11:19:22,589 INFO [com.desktone.fabric.login.impl.ClientLoginMgrImpl]-[https-openssl-apr-4443-exec-3] [SESSION:7aac-***-468e] retrieveAndAssignPatternFromPool, poolId=1108, userGuid=436bd0c937fda943b3e7990a29b53d1e
2022-07-25 11:19:22,593 INFO [com.desktone.fabric.login.impl.ClientLoginMgrImpl]-[https-openssl-apr-4443-exec-3] [SESSION:7aac-***-468e] retrieveAndAssignPatternFromPool, poolId=1108, userGuid=436bd0c937fda943b3e7990a29b53d1e, static pool.
2022-07-25 11:19:22,593 INFO [com.desktone.server.accessFabric.FabricDelegateImpl]-[https-openssl-apr-4443-exec-3] [SESSION:7aac-***-468e] assignNextPatternFromPool, userGuid:436bd0c937fda943b3e7990a29b53d1e, poolId:1108, autoAssignUserPattern:true, persistUserPattern:true
2022-07-25 11:19:22,604 INFO [com.desktone.server.accessFabric.FabricDelegateImpl]-[https-openssl-apr-4443-exec-3] [SESSION:7aac-***-468e] assignNextPatternFromPool, userGuid:436bd0c937fda943b3e7990a29b53d1e, poolId:1108, returning pattern:S.1022.995.26
2022-07-25 11:19:22,604 INFO [com.desktone.fabric.login.impl.ClientLoginMgrImpl]-[https-openssl-apr-4443-exec-3] [SESSION:7aac-***-468e] retrieveAndAssignPatternFromPool, poolId=1108, userGuid=436bd0c937fda943b3e7990a29b53d1e, got patternId=S.1022.995.26
2022-07-25 11:19:22,604 INFO [com.desktone.fabric.login.impl.ClientLoginMgrImpl]-[https-openssl-apr-4443-exec-3] [SESSION:7aac-***-468e] allocateDesktop, guid=436bd0c937fda943b3e7990a29b53d1e patternId=S.1022.995.26
2022-07-25 11:19:22,604 INFO [com.desktone.fabric.login.impl.ClientLoginMgrImpl]-[https-openssl-apr-4443-exec-3] [SESSION:7aac-***-468e] allocateDesktop, allocating managed vm, guid=436bd0c937fda943b3e7990a29b53d1e patternId=S.1022.995.26
2022-07-25 11:19:22,606 INFO [com.desktone.fabric.allocator.impl.ClientDesktopAllocatorImpl]-[https-openssl-apr-4443-exec-3] [SESSION:7aac-***-468e] Getting allocator service stub from element '7FC7C58B51' instance URL '169.254.17.117'
2022-07-25 11:19:22,626 ERROR [com.desktone.view.broker.ViewClientServlet]-[https-openssl-apr-4443-exec-3] [SESSION:7aac-***-468e] allocateDesktop, caught AllocationException for userId='436bd0c937fda943b3e7990a29b53d1e', desktopId='1108'. Cause='SYSTEM_ERROR'.
2022-07-25 11:19:22,626 ERROR [com.desktone.view.broker.ViewClientServlet]-[https-openssl-apr-4443-exec-3] [SESSION:7aac-***-468e] Allocation Error:SYSTEM_ERROR
2022-07-25 11:19:22,627 WARN [com.desktone.view.broker.ViewClientServlet]-[https-openssl-apr-4443-exec-3] [SESSION:7aac-***-468e] Unhandled Allocation Error:SYSTEM_ERROR
2022-07-25 11:19:22,627 WARN [com.desktone.view.broker.ViewClientServlet]-[https-openssl-apr-4443-exec-3] [SESSION:7aac-***-468e] handleResponseTransmission, AllocationException=SYSTEM_ERRORSolution
This solution can only be done by youre service provider admin.
So, we know that the user works, because he or she can login after a manual assignment to a dedicated desktop or other assignment. In that case it has something to do with the mapping of the user.
I found a table in the fdb database where the user pattern mapping / assignment is stored
fdb=# select * from user_pattern_mapping where user_guid = '436bd0c937fda943b3e7990a29b53d1e';
pattern_id | pool_id | user_guid | displayname | deleted | auto | alternate_protocol | date_created | date_updated
---------------+---------+----------------------------------+-------------+---------+------+--------------------+-------------------------+-------------------------
S.1022.1035.7 | 1108 | 436bd0c937fda943b3e7990a29b53d1e | | f | f | | 2022-07-28 13:05:00.939 | 2022-07-28 13:05:00.939
S.1022.995.26 | 1108 | 436bd0c937fda943b3e7990a29b53d1e | | t | t | | 2022-06-03 09:20:03.592 | 2022-06-03 09:20:22.686
(2 rows)There you see 2 (or maybe more…) mapping for this user which could be correct when the user has more than one desktop assigned to the user. But in our case the second assignment is the one what gives us issues.
We can fix this in the fdb database by deleting the problem row.
fdb=# delete from user_pattern_mapping where user_guid = '436bd0c937fda943b3e7990a29b53d1e' and pattern_id = 'S.1022.995.26';
DELETE 1
fdb=# select * from user_pattern_mapping where user_guid = '436bd0c937fda943b3e7990a29b53d1e';
pattern_id | pool_id | user_guid | displayname | deleted | auto | alternate_protocol | date_created | date_updated
---------------+---------+----------------------------------+-------------+---------+------+--------------------+-------------------------+-------------------------
S.1022.1035.7 | 1108 | 436bd0c937fda943b3e7990a29b53d1e | | f | f | | 2022-07-28 13:05:00.939 | 2022-07-28 13:05:00.939
(1 row)Now the user should be able to login the way it should be.
