Just a couple tidbits regarding AWS WorkSpaces and WorkDocs…
An Error Restoring An Unhealthy WorkSpace when using PowerShell for AWS
In an effort to reduce the workload of your IT support staff and provide end users more control over their experience, AWS WorkSpaces provides some self-service WorkSpace management capabilities including the following:
- Increase the personal disk size
- Change the compute type should more or less CPU/RAM be required
- Switch the running mode of a Workspace to/from Always On and Autostop (on-demand)
- Rebuild a WorkSpace
- Restart a WorkSpace
Assuming the standard capabilities are available to end users, the self-service capabilities are available and initiated from the AWS WorkSpace Client. Let me say again, a user can perform self-service actions only if their WorkSpace is accessible via the client. But you may encounter a situation where a WorkSpace is not accessible to a user because it’s stuck on “Starting” or worse yet, “Unhealthy”.
A snapshot of each Workspace is taken every 12 hours for the purposes of restore and rebuild operations. In this case, the WorkSpace in question can be restored to its last successful snapshot by executing the command Restore-WKSWorkspace -WorkspaceId “ws-abcde123”
Though WorkSpaces can be managed using Windows PowerShell for AWS, you may see an error when attempting to execute the restore command and wonder, “What the heck, man!” I did…I mean I looked at the PowerShell for AWS documentation, reviewed the command, the options, checked my spelling, etc.
But I had to read all the way through to the end to see that this command required a specific PowerShell for AWS version, specifically 3.3.618.0. I did not have the latest version, thus my command failed so the first quick hit is to make sure you have the latest version of PowerShell for AWS if using it to manage AWS resources. This may be a no-brainer but it’s also easy to forget.
Perhaps a second quick hit could be that I ran PowerShell for AWS from an EC2 instance that had access to WorkSpaces via the IAM role assigned to it. If you do not have permissions to WorkSpaces, you’ll see an error when trying to execute commands so check your IAM policies/roles if you are unable to run the WorkSpaces commands.
Installing the WorkDocs Drive Client with MSIEXEC
If you are using/testing AWS WorkDocs, you will likely end up installing the WorkDocs Drive Client to provide users a Windows Explorer type experience. With the WorkDocs Drive Client installed, users will see, by default, a W: drive containing their personal and “shared with them” WorkDocs files. You may also want to deploy the WorkDocs Drive Client through a GPO or SCCM AND you may even want to change the drive letter from W to something else and I have good news for you. The WorkDocs Drive Client does support a couple installation switches that allow you set the Site ID and the drive letter mapping. Those options and their syntax are shown in a picture taken from the WorkDocs user guide:
If you try installing the WorkDocs Drive Client, you will only find frustration. I tried several times to install the client using syntax like:
- AWSWorkDocsDriveClient.msi SITEID:sitename DefaultDriveLetter:Z
- AWSWorkDocsDriveClient.msi /SITEID:sitename /DefaultDriveLetter:Z
- AWSWorkDocsDriveClient.msi -SITEID:sitename -DefaultDriveLetter:Z
….and nothing worked. I opened a case with AWS support and realized I never would have guessed the proper syntax because it’s wrong in the documentation. The WorkDocs quick hit here is that you do not use a “:” to separate the parameter and the value but an “=”. The proper syntax in this example is as follows:
- AWSWorkDocsDriveClient.msi SITEID=sitename DefaultDriveLetter=Z
Recap
- When using PowerShell for AWS to manage AWS resources, make sure you have the latest version installed to ensure you have the capability to use the latest commands with their fullest syntax.
- If using an EC2 instance to access PowerShell for AWS, attach an IAM role that provides the level of access you need. In this case, I was using PowerShell to manage WorkSpaces so the IAM policy/role needed to include those rights.
- If installing the WorkDocs Drive Client using setup switches, use an equal sign (=) to separate installation parameters from their values.
