Best practices for joining a Cameyo server to a domain/Active Directory

Now that you’ve heard the warning, Cameyo will work in your Active Directory. To support Active Directory in a Cameyo environment, here are the steps as well as some additional information on how to troubleshoot common issues.
 

1. Join the server to your domain

Connect to the server through “Connect as Admin” in the Cameyo console or through RDP. Change the name of the server to something unique. Then use the typical Windows method of adding the server to the domain.
 

2. Change to Native Windows Accounts.

To configure Native Windows Accounts in the Cameyo console, go to the Server page and select the name of the server. Under Server Cluster > General, find User profiles and change it to Native Windows Accounts

This will require you to restart the Cameyo service (not reboot the server). Simply select “Restart service” button on the right.

When the server becomes available again, you can launch your app from the app page. You will now be prompted for your AD credentials.

These are your Active Directory credentials, not what you used to login to Cameyo through your SSO. Since Cameyo is not currently passing through credentials, your end-users will need to enter their AD credentials separately.
 

You have the option to cache these in the browser using the !NWASAVELOGIN=1 PowerTag.

You may also need to define the domain so the user will not have to use username@domain.com or domain\username formats. Do that on the server page. Select Server, then select the name of the server in the list.
(Note: Be aware that if you are using a big forest with multiple trusted domains, setting the domain here will lead to login issues.)

You may also have to give it a domain admin or service account that will have permissions to run the Cameyo health monitor. 

Troubleshooting

Now that you’ve gone against our advice (see above), you WILL have issues. Here are the most common

Getting a “connecting” screen after inserting credentials

If you get a “connecting” screen but never reach the app, here are some potential issues.
 

Restricted use or Terms of Use blue message screen.

Group Policy has an option to create a “Restricted” or blue message screen when users log on. Since Cameyo is waiting for the app to start, this will never happen until the user interacts with this message screen. You can see it by clicking on the “eyeball button” on the Cameyo splash screen on the bottom right corner.

The best option is to disable the Group Policy. In your Group Policy Management Editor, find Security Options and look for “Interactive Logon: Message text for users attempting to log on”. Either disable this or exclude the Cameyo Servers from this policy.

You can also disable this with a registry key. 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System 

Delete the values for “legalnoticecaption” and “legalnoticetext” keys.

In most organizations, the registry setting fix will only work until the group policy is applied.
 

Domain users not included in Remote Desktop Users local group

Another potential hazard is when a domain user logs into Cameyo, it creates a user profile on the server. Since Cameyo is using local users, your domain/AD users will not have permissions. You will need to add your domain users to the “Remote Desktop Users group under Local Users and Groups on the Cameyo Server.

Application slow load times

Again, a good case for using Temporary User Profiles over Native Windows Accounts and AD. Slow load times are generally caused by the years of group policy management created by an organization. When using Native Windows Accounts, Cameyo is forced to create a matching domain user profile on the server.

Depending on what is defined in your Group Policy, creating a user profile on a Windows Server takes time. Then once the profile is created, it applies the policy and starts installing any software that you’ve defined for your configuration management. Then it installs printers and applies security policies.

This process will not be seen by the end-user who will have to wait until it is complete before getting to an app.

Data does not persist when using Native Windows Accounts in a cluster

Cameyo is designed to be ephemeral. When changing to Native windows Accounts to support Active Directory, you are creating a profile on a Windows Server, much like a VDI solution or RDS. If you wish for data to persist, you should consider using Temporary User Profiles and data persistence designed for Cameyo.

If you need Active Directory and persistent data, you will need to introduce a data management service such as FSLogics or others. This is outside of the scope of this discussion but can cause issues with user expectations.

Conclusion

If you can avoid it, don’t use Active Directory with Cameyo. There are many methods for supporting an app including mapping drives and using the native Cameyo functions to support printers or provide the Windows session what it needs with PowerTags. Those are discussions for the next series of articles.

If your app absolutely needs it. I hope I have provided a good guide to support Active Directory. Leave me comments on other issues you have encountered so we can create some additional content to help others.