- Pip install Boto3 - Thu, Mar 24 2022
- Install Boto3 (AWS SDK for Python) in Visual Studio Code (VS Code) on Windows - Wed, Feb 23 2022
- Automatically mount an NVMe EBS volume in an EC2 Linux instance using fstab - Mon, Feb 21 2022
By default, a WorkSpaces user is a local administrator and a domain admin. However, you can change this default setting. In my test, a WorkSpace worked fine with standard user rights. However, if you remove the WorkSpaces user from all administrator groups, you can no longer log on with administrator rights.
WorkSpace user is administrator by default
I wasn’t able to log on with a domain admin I created in the WorkSpaces Active Directory. You also can’t log on as a local administrator. Thus, if you have to perform administration tasks on a WorkSpace, you have to add the WorkSpaces user to the domain admin group again and then log on with the user’s account.
You can’t RDP to the domain controllers that provide the WorkSpaces Active Directory. However, it is possible to manage Active Directory with the standard Windows administration tools. You either use a dedicated WorkSpaces machine for your administration tasks or you install your admin tools on an EC2 Windows server for this purpose. I will explain in a separate post how you can join an EC2 Windows server to a WorkSpaces Active Directory domain.
WorkSpaces Active Directory domain controllers
You can essentially do everything in the WorkSpaces AD as in your on-prem AD domain. You have access to Group Policy, you can install WSUS for patch management, and you can also install third-party management tools for software deployment or whatever you need to manage your WorkSpaces.
By the way, it appears Amazon pre-provisions WorkSpaces. I saw several computer objects of workstations in the computer’s containers I didn’t provision through the WorkSpaces interface. I was even able to connect to those machines with the Computer Management console. I also saw two domain controllers, but access was denied when I tried to connect to them with the Computer Management console.
Of course, there are also differences if you run virtual desktops in the cloud. I am afraid that many of those differences will become obvious only when you work a while with WorkSpaces. For instance, when I tried to reset the password of my WorkSpaces user in Active Directory, I could no longer log on. I figured that problem was related to the “User must change password at next logon” option of the password reset applet. After I reset the password without this checkbox enabled, I could log on again.
Reset password of WorkSpace user
I guess the WorkSpaces client simply doesn’t allow the user to enter a new password. However, users can change their password once they log on using the common methods. For example, a user can send a “CTRL+ALT+Del” through the WorkSpaces menu and then select the “change password” option. Users who forget their password can reset it by clicking a link in the WorkSpaces client.
Forgot WorkSpaces password
After the user solves a captcha, an email with a link for resetting the password is sent to the user’s email address.
Please reset your WorkSpaces credentials
There are some obvious differences in the way things work with WorkSpaces. For instance, you can’t deploy desktops with your imaging tools. Instead, you use the Amazon web interface to add new WorkSpaces. If a user messed up a desktop, you can rebuild the WorkSpace through Amazon’s management console.
Data in the user profile will be restored after the desktop is rebuilt; however, user data that was saved within the last 12 hours may be lost. Thus, if you have to rebuild a WorkSpace and want to ensure that all user data is restored, you should wait at least 12 hours after the user last logged on, or you should create a backup of the user data yourself. Also notice that data stored in locations other than the user profile, for example in a folder on C, will not be restored.
Some directory-related settings will not be affected when you rebuild a WorkSpace. For instance, the user name and password of the WorkSpace will stay the same. The user object will remain in the Active Directory container to which you moved it. However, after the rebuild, the computer will have a different name and will appear in the computer’s OU. Thus, if you moved the computer object to another container, you have to change the OU again. WorkSpaces also doesn’t remove the old computer object from Active Directory; you have to delete it manually.
In my tests, rebuilding a WorkSpace took between 12 and 20 minutes. As expected, applications I previously installed disappeared. However, since the user profile was restored, the corresponding shortcuts were still on the desktop. Thus, installing applications manually after provisioning a WorkSpace is not really advisable. You can use a software deployment solution that ensures that applications are automatically deployed after you provisioned a new WorkSpace, or you create your own WorkSpaces bundles with all your applications installed.
In the WorkSpaces interface, the Custom WorkSpace Bundles feature is listed under Advanced Options. However, when I contacted Amazon about it, I was informed that it is not yet available in the limited preview.
Amazon WorkSpaces - Advanced Options
Another advanced option that is still unavailable will allow you to use your on-prem Active Directory instead of Amazon’s directory. You will also be able to run your own “cloud only” Active Directory. I suppose you will then have to install your own domain controllers on EC2 instances.
The third advanced option is about “on-premise administration tools” that “allow you to monitor the health of your WorkSpaces, approve patches, and schedule updates.” I will have a closer look at these advanced options as soon as they are available.