AWS Public Sector Blog

Reporting on Amazon WorkSpaces deployments to gain data insights

Reporting on Amazon WorkSpaces, a managed, secure desktop as a service (DaaS) solution, allows you to capture information about your Amazon WorkSpaces deployment and the relationships to Active Directory users. It helps capture important details that can help with chargeback, general utilization of Amazon WorkSpaces, and confirming consistency of what is deployed in your environment.

In a previous post, I showed you how to automate the deployment of Amazon WorkSpaces using a simple PowerShell script. The post walked you through how to simplify the deployment of virtual desktops to users based on Active Directory group membership. In this post, I look at reporting on small to large-scale deployments of virtual desktop solutions. You will learn how to export Amazon WorkSpaces deployment information combined with Active Directory and virtual private cloud (VPC) properties by executing a PowerShell script. This script can help you gain insight into what is deployed in your environment more easily and at scale for hundreds or thousands of WorkSpaces.

This post shows you how to:

  • Understand and validate the prerequisites necessary to run the PowerShell script
  • Execute the script and review the information it captures
  • Look for inconsistencies in your deployment, unused or orphaned WorkSpaces, and additional information about the users of WorkSpaces

Prerequisites

Make sure you have the following before getting started:

Walk through

Download and save the script to a location on the system configured to meet the prerequisites. Execute the script by typing “.\FILENAME.PS1” where FILENAME is the name you gave the downloaded file to begin the reporting process (see Figure 1).

The script requires three inputs as part of execution: the path to store the log file, which defaults to C:\temp and creates the folder if it doesn’t exist; the AWS Region; and the number of days to query CloudWatch metrics to validate unused WorkSpaces.

Begin the WorkSpaces reporting process

Figure 1

After entering an appropriate path, Region, and number of idle days before considering WorkSpaces to be unused, the script executes and counts down as it loops through each WorkSpace and captures the details of the WorkSpace, Active Directory user, and VPC.

Figure 2 shows what was captured during the execution and has had the username stripped to obfuscate the output.

WorkSpaces reporting script deployment

Figure 2

When the script is finished executing, the path entered at the start contains a CSV file export of the WorkSpace. You can run the script serially against multiple Regions and capture the output in a single file and then filter it later.

Let’s review the output of the script and show some meaningful data about each WorkSpace (see Figure 3). I won’t go through every field in this output file, but I will review some common fields of interest. For example, in the first line the username is “Grant.Joslyn” and the “ADUserFullName” attribute captured from Active Directory is “Grant Joslyn.” In many organizations, these attributes may contain different values.

The ADComputerCreated field tells the date/time when the system was created and joined to Active Directory. The ADComputerOperatingSystem contains the operating system pulled from Active Directory. In this example, that is a Windows Server 2016 operating in the Windows 10 desktop experience mode.

output of the script and show some meaningful data about each WorkSpace

Figure 3

The script also captured connection related information (see Figure 4), which can be an indicator of unused WorkSpaces. You can use this data to support reducing the costs of the WorkSpace deployment. If the WorkSpace creation date (see the ADComputerCreated column in Figure 3 above) isn’t recent and the LastKnownUserConnectionTimeStamp is “1/1/0001,” the WorkSpace may be unused. The WorkSpaceUnusedForDefinedPeriod column (see Figure 4) uses the Amazon CloudWatch data queried to capture whether a successful login has occurred within the period specified at script execution. These would be candidates for removal, which would eliminate the cost of WorkSpaces and simplify the deployment.

Other filters could include the use of the ADEnabled column (see Figure 6). If the value of the ADEnabled column is FALSE that indicates the user is disabled, which may be a sign of an orphaned WorkSpace.

connection related information

Figure 4

Networking and availability zone placement fields are also captured by the script as shown in Figure 5, including:

  • SubnetLabel: The name tag pulled from the VPC tag for the subnet assigned to the WorkSpace. This shows that the Region is us-west-2, the availability zone is “B,” and the subnet the WorkSpace is deployed to is private, which means it flows through a NAT Gateway.
  • SubnetId: The GUID or unique ID assigned by AWS.
  • SubnetAZ: The availability zone for the subnet, in this case duplicated within the name tag above.
  • SubnetAZId: The identifier for the actual subnet location as availability zones are mapped on the backend.
  • SubnetAvailableIpAddressCount: The count of available IP addresses within the VPC subnet to allow for monitoring subnets filling.
Networking and availability zone placement fields

Figure 5

There are a number of Active Directory attributes for each user included in the report to filter the export on values (see Figure 6), including:

  • ADUserDepartment: The department property from Active Directory, which may be useful for billing or understanding counts of WorkSpaces by department.
  • ADUserEnabled: The enabled or disabled property from Active Directory, which may be useful for finding unused or orphaned WorkSpaces left behind after employees depart an organization.
  • ADUserEmailAddress: The email address for the user pulled from Active Directory, which may be useful for scripting or notifications for upcoming changes or maintenance.
  • ADUserManager: The Manager field from Active Directory, which may be useful for contacting the leaders of WorkSpaces users.
  • ADUserMobilePhone: The mobile/cell phone property from Active Directory, which may be useful for contacting users either individually or in batches.

Also useful are the last two columns:

  • TagsJoin: A joined column for tag Name:Value pairs pulled from the AWS WorkSpaces console. This can be used for billing, departments, automating tasks, determining purpose for a WorkSpace, or other custom use cases. Multiple tags are supported and a further separator for each key value pair is included to allow formatting the output into multiple columns.
  • Region: The field included for customers who have multi-Region deployments of WorkSpaces. This script appends to the output so running it against two Regions like us-east-1 and us-west-2 creates a single file and allows for filtering of the data based on Region.
Active Directory attributes for each user included in the report to filter the export on values

Figure 6

Summary

In this post, you used PowerShell to run a reporting script to export Amazon WorkSpaces, Active Directory, and VPC information for your virtual desktop deployment. You then reviewed the extracted data to find useful information on the state of your Amazon WorkSpaces deployment and the users assigned to them.

Learn more about end user computing (EUC), Amazon WorkSpaces, and AWS in the public sector. Read other stories about end user computing on the AWS Public Sector Blog or the AWS Desktop and Application Streaming Blog.