In today’s post of my WorkSpaces series, I will show you what administration tasks await you if your organization decides to run a VDI in Amazon’s cloud.

Michael Pietroforte

Michael Pietroforte is the founder and editor in chief of 4sysops. He has more than 35 years of experience in IT management and system administration.

Administrator rights ^

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

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.

Active Directory ^

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

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.

Password reset ^

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

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

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

Please reset your WorkSpaces credentials

WorkSpace rebuild ^

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.

Rebuild WorkSpace

Rebuild WorkSpace

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.

Rebuilding WorkSpace

Rebuilding WorkSpace

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.

Advanced options ^

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

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.

In the next post of my WorkSpaces series, I will summarize my overall impression and outline why I think that Amazon’s DaaS, for the first time, makes VDI an interesting option.

Are you an IT pro? Apply for membership!

Your question was not answered? Ask in the forum!

1+
Share
Articles in series

Amazon WorkSpaces

1 Comment
  1. Magheswari 2 years ago

    i am getting error in AWS Workspace while login like """ Directory unavailable  your directory  could not be reached at this time . Please contact your administration for more details"""" could you please tell whats the issues and solution for this error.

    3+

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2019

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account