Access Profile Errors

This article covers issues that occur when an end user opens an Access Profile bound to Cloud Manager and the connection fails or produces an unexpected result. Most Access Profile errors trace back to one of four root causes: the profile was never saved properly, the user lacks permissions, no instance is available, or the broker cannot route to the target.

For setup procedures, see Create an Access Profile for Managed VMs and Create an Access Profile for a VDI/DaaS Model.

Common Symptoms and First Checks

Verify the Access Profile Was Saved Correctly

Access Profile changes go through a two-stage commit: Save in the profile editor confirms the changes to that profile, and Apply in the Access Profiles list publishes all pending changes. A common cause of “profile does nothing” reports is that Save was clicked but Apply was never clicked, so the configuration was never committed.

Verification:

1. Open the Access Profile in the editor.
2. Confirm the Cloud Manager source is set correctly (Managed VM or VDI/DaaS Model).
3. Confirm the target VM or Model is selected.
4. Confirm users and groups are assigned in the Permissions section.
5. Click Save in the editor.
6. In the Access Profiles list, click Apply in the floating “n section modified” dialog to commit the changes.
7. Close and reopen the profile to verify all fields persisted.

If fields revert or the profile behaves as if unsaved, check the event log for errors during the save operation and check broker connectivity to the Cloud Manager state store.

Verify User Permissions

A user can open an Access Profile only if they (or a group they belong to) are granted permission on it — either directly in the profile’s Permissions section, or inherited from a Label the profile is a member of, which the Effective Permissions area resolves and displays.

Verification:

1. Open the Access Profile in the editor and expand Permissions.
2. In the Users or Group table, confirm the user — or a group they belong to — is listed.
3. Expand Effective Permissions to check whether the user has access through a Label. The From column identifies which Label is granting the permission — it is empty for entries assigned directly to the profile. Label-inherited permissions grant access even when the user is not directly listed in the Users or Group table, and removing a user from the direct list does not revoke their Label-granted access.
4. If the user is missing from both, add them under User or Group, click Add, then Save and Apply.

If permissions look correct but the user still cannot access the profile:

• Check that group membership is correctly reflected in the identity provider.
• Confirm the user is authenticated with the right account (not a secondary account without group membership).

“No Instance Available”

For VDI/DaaS Access Profiles, this error means Cloud Manager could not find or provision an instance for the user.

Causes and Resolutions

Manual Pinning Check

For models with Allow Dynamic Assignment OFF, each user must be pre-bound to a specific instance. If the user is not on any instance’s assignment list, they will receive “No instance available” regardless of pool capacity.

1. In the Instances tab of the affected model, locate the target instances.
2. For each instance, click the Manage Users icon in the Actions column and check the assignment list.
3. If the user is not bound anywhere, bind them to an available instance.

“Failed to Connect to the Instance”

This error appears after Cloud Manager has identified the target instance but cannot establish the session. The instance is there; the path to it is broken.

Diagnostic Steps

1. Check instance status. Is it Active? If Inactive, power on and retry. If Error, resolve the error.
2. Check Connection Mode vs. instance network. If the Connection Mode is Public IP but the instance has only a private IP, the mismatch causes failure. Switch to Private IP or Agent Id.
3. Check broker-to-instance connectivity. See Connectivity Issues.
4. Check the Virtualization Agent. For Agent Id mode, the agent must be running and registered. See the “Instance Runs But Doesn’t Register” section of Provisioning Failures.
5. Check the OS session. The protocol server (RDP on Windows, SSHd on Linux) must be running and accepting connections.

Connection Opens But Wrong Instance

For models with Allow Dynamic Assignment OFF, users expect to always land on their bound instance. If a user lands on a different one:

• Verify the user has exactly one binding (Manage Users dialog).
• Check that the bound instance is in On (Active) status.
• If the bound instance is in Error state, Cloud Manager does not fall back to another instance — the user stays pinned to it and the connection surfaces the instance error instead of opening a different instance. Resolve the error on that instance, or delete it and re-bind the user to a healthy one. (Automatic assignment to another available instance happens only with Allow Dynamic Assignment ON.)

For models with Allow Dynamic Assignment ON, the user being matched to a different instance from session to session is expected behavior, not an error. Advise the user to store data on network or cloud storage.

Long Wait After Clicking Profile

A user-facing wait of several minutes after clicking a VDI/DaaS profile is expected in certain scenarios.

If the wait exceeds normal boot or provisioning time for your cloud and OS:

1. Open the affected instance’s View Log dialog to see the most recent lifecycle entries and any errors.
2. Check the Instances tab for a related Active/Inactive/Error state change.
3. If provisioning, open the model’s Deployments tab and click View Log on the in-progress deployment.
4. If everything looks stalled, see Provisioning Failures.

See Also

• Troubleshooting
• Create an Access Profile for Managed VMs
• Create an Access Profile for a VDI/DaaS Model
• Connectivity Issues
• Provisioning Failures
• Multi-Broker deployments
• Manually Assign an Instance to a User