# Welcome to WorkSpaces Manager WorkSpaces Manager provides a full Amazon WorkSpaces management portal. Containing a user self-service and an administration portal in a browser-based environment, without using the AWS Console. {% hint style="info" %} **Custom Agent:** The **WSM Agent** by Nuvens collects hourly metrics on processor and memory usage, available disk space for root and user volumes, logon and logoff events, periods of inactivity, disconnect times, and more. This data helps monitor and optimize WorkSpaces performance effectively. {% endhint %} ## Overview **WorkSpaces Manager** is available as a standalone product and operates with a 3-tier architecture: 1\) **The Back-end tier:** Powered by MS-SQL, it supports various versions (Express, Web, Standard, and Enterprise) and can be deployed on AWS using either EC2 or RDS. 2\) **The Application tier:** Known as the **Management Portal**, this layer utilizes .NET on a IIS web server running on Microsoft Windows. 3\) **The Presentation tier:** This tier delivers the application interface to users. It can leverage a Microsoft Windows Web Server or an AWS Network Load Balancer, and can include DNS configuration, SSL certificate offloading, and enhanced security features such as Web Application Firewalls (WAF) or honeypots. ## Guides Access documentation to help you **install**, **configure**, and **manage** WorkSpaces Manager: * [**Installation Guide**](/install/workspaces-manager-installation-guide) * [**Administration Guide**](/admin/workspaces-manager-administration-guide) * [**Architecture Guide**](/architecture/workspaces-manager-architecture-guide) # WorkSpaces Manager Installation Guide The WorkSpaces Manager Installation Guide provides step-by-step instructions for deploying and configuring the platform within your AWS environment. It covers the initial setup of the appliance, ensuring a secure and scalable foundation for managing Amazon WorkSpaces. WorkSpaces Manager is delivered as a pre-configured appliance via the AWS Marketplace, deployed as an EC2 instance. It can also be provisioned using a Packer AMI for more advanced or automated deployment scenarios. This guide walks through both approaches, along with prerequisites and best practices. Authored by Nuvens experts, this guide is designed to help you achieve a smooth and efficient deployment, ensuring the platform is ready for production use. Key areas covered include: * AWS prerequisites and environment preparation * Deployment via AWS Marketplace and Packer AMI * Network and security configuration * Initial system setup and access * Integration with Active Directory * Licensing and activation * Post-installation validation and health checks # Change Log The **Change Log** page provides a detailed record of updates, improvements, and bug fixes for the software or installation process. It is divided into two main sections: **1.** [**Stable**](/install/change-log/stable) The **Stable** section lists changes that have been thoroughly tested and are considered fully functional and reliable for production environments. These updates have undergone comprehensive testing and are suitable for general use. It includes: * New features that are now available in the stable release. * Bug fixes and improvements that have been resolved and validated. * Any changes to the installation or configuration processes that impact the overall stability of the system. This section is ideal for users who are running the current stable release and need to track changes that have been implemented for their environment. **2.** [**Beta**](/install/change-log/beta) The **Beta** section includes updates that are in the testing phase and not yet fully verified for production use. These changes may introduce new features, optimizations, or experimental fixes that are being tested and are subject to change. This section is intended for users who are testing pre-release versions and want to stay informed of ongoing updates. It includes: * Features or functionality that are still being validated or refined. * Known issues or limitations in the current beta release. * Changes that may require additional testing or feedback from users before being included in the stable release. This section is ideal for developers, testers, or early adopters who are working with the beta version and contributing feedback. # Stable **Version 6.3.5 (2026-08-06 14:00)** * Improved agent data processing by batching statistics, activity, startup and process updates for greater reliability under heavy load. * Added an API queue monitor so administrators can view queued, processed and failed agent updates. * Added automatic removal of duplicate WorkSpace records caused by synchronisation issues. **Version 6.3.4 (2026-08-04 09:00)** * Added WorkSpace Advisor to identify CPU, memory, storage, latency and connectivity issues, with clear severity ratings and recommended actions. * Added login IP address and location information to the seven-day user activity export. * Added an option to export WorkSpaces using each administrator’s selected report columns, including displayed AWS tag columns. * Added automatic configuration of the assigned EC2 WorkSpace user in the local Remote Desktop Users group after the instance joins the domain. * Added agent update timestamps to help administrators distinguish recently reporting agents from inactive installations. * Improved WorkSpace matching by supporting email-address lookups where the stored username and directory identity differ. * Fixed session timeout handling so expired sessions return users to the login page without background timer checks extending the session. * Fixed account, agent and date filters so WorkSpaces reports return the expected results. * Optimised WorkSpace processes data storage and reduced quantity stored. \ **Please note this optimization will remove any existing WorkSpace process data.** **Version 6.3.1 (2026-07-06 16:00)** * Bug Fixes * Fixed an issue which stopped Entra AP profiles checking existing WorkSpaces existed * Optimised WorkSpace popup loadtime, moved cloudwatch fetch to after the popup is visible * Removed an existing filter preventing certain directories from being visible * Added the ability to include Tag columnns dynamically on the WorkSpaces view * Added a new readonly permission for AutoProvision * Fixed an issue which stopped anomaly detection going back further **Version 6.3.0 (2026-06-18 15:30)** * Bugs Fixes * Introduced customer diagnostics which allows WSM to send diagnostic data to our API, enabling us to provide early warning support * Updated WorkSpace modal with a cleaner UI * Updated Task Queue with a simplified table and added tab categories. * Added link to WorkSpace modal from anomaly detection * Fixed issue which caused NoStandBy tag to get ignored * Added ability to stop/start auto provision profile * Reboot schedule now starts stopped WorkSpaces * Added ability to bulk enable/disable schedules for EC2 WorkSpaces **Version 6.2.39 (2026-06-08 12:30)** * Bugs and Fixes * Fixed issue causing missing directories for superadmin * Added new cloudwatch metrics to WorkSpace view * Fixed reports where some of the rows were not clickable * Added some EC2 WorkSpace QOL changes **Version 6.2.38 (2026-06-02 10:30)** * Bugs Fixes & Typos * Fixed issue with tag values truncating * Added some additional identifiers to the pricing resolver * Fixed issue where null value caused an issue in the cost breakdown * Fixed issue with create bundle (description is now mandatory) **Version 6.2.37 (2026-05-28 12:00)** * Bugs & Fixes * Added export button on Workspaces EC2 * Added filter persistence for Anomaly Detection * Added bulk actions (Supress, Close, Acknowledge) for Anomaly Detection * Added Tags as a field for API method GetAllWorkSpaces * Added a switch to enable Global Accelerator per directory **Version 6.2.36 (2026-05-11 12:00)** * Bugs & Fixes * Consolidated Cost Optimizer settings * Introduced LDAPS into more AD functions * Optimised AWS API retry handling * Reduce number of bundle updates * Added logging for Entra group member lookup **Version 6.2.35 (2026-05-05 10:00)** * Bugs & Fixes * Optimised the High Resource Usage Report * Fixed the Scheduled Terminate email template variables * Added Hangfire admin tile and linked report for background task monitoring * Added an export for client version on the Clients in use report * Moved external JavaScript libraries to local assets * Fixed a bug causing EC2 tags to duplicate on the management screen * Added additional search fields to query on Latency report * Consolidated Cost Optimiser fields for configuration * Fixed root/user volume on WorkSpace list * Added an API for EC2 info/fetch * Added additional RDS information to database health **Version 6.2.34 (2026-04-15 13:30)** * Bugs & Fixes * Fixed Workspaces Application report filtering * Added additional columns to AutoProvision List * Fixed issues with role restrictions incorrectly filtering WorkSpaces * Fixed issue with EIM authentication * Updated Cost Optimizer pricing resolver **Version 6.2.33 (2026-04-13 16:00)** * Added dedupe to error logs to stop bloating * Added additional columns to WorkSpaces export report * Quotas are now updated automatically * Added quotas status admin tile * Added new reporting to WorkSpaces Applications * Modified role required for Configuration Status page * Added more audit logging * Updated AWS dependencies **Version 6.2.32 (2026-03-25 16:00)** * Added dynamic WorkSpace quotas * Fixed an issue with alternate emails * Fixed an issue with Entra group membership within AutoProvision **Version 6.2.31 (2026-03-24 13:30)** * Bug Fixes * Added WorkSpaces Scheduling * Fixed a migration bug * Improved XSS protection on various pages throughout * Alternate emails now sent independently * Added Never Used column to Unused WorkSpaces report * OU configuration reads the AWS directory OU as a prompt * Intune integration retires devices on termination * Added ability to terminate a WorkSpace if user never connects within threshold * Improved Cost Optmizer pricing lookup for previous unsupported regions * Added enqueue protection in Hangfire when tasks begin to build up * Added ability to terminate a WorkSpaces Application session **Version 6.2.29 (2026-03-09 12:00)** * Security Update * Fixed issue with bulk process permissions for WorkSpaces * Fixed some precision warnings of several fields * Fixed AP group name length to prevent truncation **Version 6.2.28 (2026-03-05 11:40)** * Bug Fixes * Improved Service Now API error handling * Added ability to AutoProvision to best available directory from chosen list * Added the ability to customise WorkSpace columns * Added UI to show volume encryption status and related ARN **Version 6.2.27 (2026-02-26 15:20)** * Bug Fixes * Fixed an issue when trying to embed map for null IP * Added redundant directory removal * Fixed issue where alternate email sync were causing Hangfire tasks to fail * Added an API to fetch a list of WorkSpaces currently marked for legal hold * Added a legal hold column to the Tasks list * Added a database health/status page * Have optimised the stats/logs cleanup tasks and introduced new indexes * Reduced Hangfire retries to 2 to steady database load * Fixed issue with user/role auditing **Version 6.2.25 (2026-02-12 15:30)** * Added GeoLocation toggle * Switched GeoLocation provider to nuvens.info **Version 6.2.24 (2026-02-09 12:00)** * Bug Fixes * Add ability to change WorkSpace type via API * Fixed an issue which prevented alternate email from syncing with AD correctly * Fixed escalation bug issue with role assumption for additional accounts **Version 6.2.23 (2026-02-03 14:15)** * Bug Fixes * Live performance metrics for Pooled WorkSpaces * Approximate Location of End User to WorkSpaces Region on Location tab * Added BYOL Win 11 Reporting of processes/start-up time to WSMAgent * Link through to the User WorkSpace card on the Location Report * New Latency Report which compares latency against distance from End User to WorkSpaces Region **Version 6.2.21 (2026-01-06 13:00)** * Bug Fixes * Entra Gov Cloud has different endpoint to Commercial version * The Create WorkSpace Email will now consume alternate email addresses * IdP for Entra ID toggle is now visible when creating a new AP Profile * New WorkSpaces Bundle Manager allows the creation of AWS Bundles **Version 6.2.19 (2025-12-02 12:00)** * Bug Fixes * Prevented auto provisioning for disabled users * Fixed sync/timing issue affecting missing email address in WorkSpace creation * Added startup metrics to WorkSpace details popup * Updated missing AppStream references to WorkSpaces Applications * Modified user confirmation email to warn of use within a WorkSpace * Replaced CloudWatch image stream graphs with locally rendered version **Version 6.2.18 (2025-11-25 14:00)** * Bug Fixes * Beta Release of Anomaly Detection * Capture of WorkSpace start up metrics * Live display of key performance metrics when Viewing a WorkSpace * Rename AppStream to WorkSpaces Applications * Support for US GovCloud * Remove Auto-Update button and provide link to instructions **Version 6.2.17 (2025-11-17 12:30)** * Bug Fixes * Added report to display WorkSpaces client version in use * Added CSV export for user WorkSpace activity * Added drilldown on cost savings report * Added directory and compute type to Cost Optimization report search * Added report to display directories with invalid Cost Optimizer configuration * Rebranded AppStream to WorkSpaces Applications * Fixed orphaned users tile link on admin dashboard **Version 6.2.16 (2025-11-05 09:30)** * Bug Fixes * Create WorkSpace email template will use connection alias where available * Fixed icon in users section * Partial search for connected status on WorkSpaces Personal fixed * Fixed Self Service Restore * Added Primary/Secondary to Unused WorkSpaces report * Fix error feedback for WorkSpace image copying * Fixed cost discrepancy between detailed and overview on WorkSpace Pools * Fixed error feedback during user creation * Changed email template dates to use long string to avoid date formatting issues * Fixed date range bug on log download page * Capped tag values to 50 chars to match database and avoid truncation **Version 6.2.15 (2025-10-23 16:00)** * Bugs & Fixes * Updated AWS packages * Added EC2 management support * Fixed date formatting to culture in numerous places * Fixed Task Queue link * Fixed the button to remove a scheduled rebuild * Added ability to terminate a WorkSpace if removed from a group * Strengthened permission security * Added ability for a user to change their WorkSpace reboot hour * Added log download button * Added new provisioning API for SNOW * Fixed issue with IPv6 addresses and the location report * Added Automated Reminders for unused WorkSpaces **Version 6.2.14 (2025-10-06 13:45)** * Bugs & Fixes * Bundle report now groups by bundle and allows user to drill down into bundle * Location report has country drilldown to show user per country * Separated orphaned report and disabled user report * LDAP validation now is wrapped with a timeout during setup process * Added additional filters for logs * Introduced common variables for email templates * Added some additional auditing for scheduled rebuilds * Removed reboot scheduled template * Skip auto delete now requires to contain false (not just be present) * Fixed issue with SQL disk space warning tile on admin dashboard **Version 6.2.13 (2025-09-23 15:30)** * Bug Fixes * Added link for Scalar to support menu for SuperAdmin role * Fixed issue with session cookies * Fixed login date issue for user * Fixed glitch for role permissions and counting select all boxes * Refactored logging into 2 pages (Error and EventLog - Audit, Warning, Info) * Added badge to show WorkSpace cost breakdown using blended mode * Automated compute type lookup for various dropdowns * Added logging for protocol changes to a WorkSpace * Cleaned up the bundle dropdown for scheduled start * Custom logos no longer override the original, and have their own file * Removed surplus columns for Activity Log * Improved WorkSpace matching for domain users account (self service) * Fixed Bundle lookup for non AP created WorkSpace in Users section * Fixed dashboard WorkSpace actions for self service * Prevented tasks being created for simulated auto delete * Fixed bug causing scheduled start to fail * Fixed missing tag columns on the export WorkSpace export * Audit logs have been improved to show affected WorkSpace ID and user where possible **Version 6.2.12 (2025-09-09 14:00)** * Bug Fixes * Added ability to override Secrets Manager for connection string * Increased AppStream Fleet update frequency, polling occurs every 5 minutes (instead of 10) * Added AppStream reporting * Fixed reported discount pricing on unused session within Pools * Added new GetAllWorkSpaces API * Fixed Account Settings page * Replaced standby text field with directory dropdown * Email templates now include their respectable variables for use * Started work updating scalar with parameter descriptions * Optimised WorkSpace Tag sync **Version 6.2.11 (2025-09-03 08:30)** * Bug Fixes * Fixed bug which was causing a rebuild when a restore was selected * Added ability to manually request a workspace created email * QOL - Changed Workspace modal options button colour * Creating a user with AP enabled adds the user to the AP group * Fixed an issue with variable template mapping for Create WorkSpace * Optimised get configuration * Optimised some queries to avoid high memory usage * Added ability to change result size on ajax tables * Added Primary/Secondary column to Reboot Report * Added audit event to template changes * Added database warning tile when disk space is low **Version 6.2.10 (2025-08-12 12:00)** * Bug Fixes * Fixed an issue which caused a rebuild when restore was selected on the WorkSpace bulk process * Added metrics for CPU/Ram/Disk/Network to WorkSpaces Pools * Added ability to export session logs for Workspaces Pools * Added ability to resend a WorkSpace created email **Version 6.2.9 (2025-07-28 08:30)** * Bug Fixes * Fixed cost summary breakdown savings * Added simple username variable to CreateWorkSpaceTemplate * Fixed typo on Location report * Fixed an issue with loading wrong date on Pools heatmap * Fixed missing row tag on TaskQueue **Version 6.2.8 (2025-07-24 10:30)** * Bug Fixes * Fixed missing Account column in WorkSpaces CSV * Added additional states in the WorkSpaces filter * Added missing AutoProvision menu option in Update options * Added the RetryProxy to all available clients * Tweaked retry logic to help mitigate API throttling * Fixed Auto Provision flag on View WorkSpace modal **Version 6.2.7 (2025-07-09 14:00)** * Bug Fixes * Updated WorkSpace Pools efficiency calculation and heatmap colouring * WorkSpace processes now allows for application history via date change * Added username to process for a WorkSpace * Added new Temporary Workspace Termination email template * Added ability to extend Temporary WorkSpace as an admin * WorkSpaces table has new icons for Temporary Workspace and New WorkSpace * WorkSpaces table now highlights any column headers in purple when used in a filter * Enabled dark mode and tweaked some areas for better visuals **Version 6.2.6 (2025-07-02 12:45)** * Bug Fixes * Replaced user location map with Google maps * Removed some redundant plugins * Split the application resource report into CPU and Mem tabs * Split the WorkSpace resource usage into CPU and Mem tabs * Moved the stat and completed task removal into the log cleanup scheduled task **Version 6.2.5 (2025-06-30 13:00)** * Bug Fixes * Corrected API label * Added replacement Insights dashboard for Reports * Improved the cost summary report with additional information * Added ability to report application CPU/Mem usage via agent * Changed Data Protection keys to use SSM Paramater Store * Pool efficiency report now provides complete month on heatmap * Changed certain reports to download only * Fixed issue with labels on CostOptimization report **Version 6.2.4 (2025-06-10 11:00)** * Bug Fixes * Added ability to brand the login screen * Reclassified some logs * Added a tile which alerts when tasks are not runnning * Email address resolved during autoprovision * Settings page reloads after modal save * Automatically flush API queue after 2 minutes * Volume warning tile now shows user and root **Version 6.2.3 (2025-05-22 18:04)** * Fixed bug which stopped WorkSpace tags from syncing correctly during update **Version 6.2.2 (2025-05-22 11:07)** * Bug Fixes * Added ability to switch off Identity login when using Single Sign On * Added additional exponential backoff on top of Amazon default * Added ability to create a temporary provisioned WorkSpace * Added ability to extend a temporary provisioned WorkSpace via email **Version 6.2.1 (2025-05-09 11:21)** * Bug Fixes * Updated AWS SDK to v4 * Fixed issue causing the setup page not to load when the database had not been built * Fixed issue with JsonTableViewer duplicating the "Showing x Results" label. **Version 6.2.0 (2025-05-06 15:06)** * **REQUIRES .NET 9 HOSTING BUNDLE** * Bug Fixes * Optimised WorkSpace update * Fixed account settings link in profile * Fixed location report map pins * Added changelog link in licensing page * Fixed audit/error/all name on logs * WorkSpace pools session usage format changed * Fixed issue with last login time * Added ability to query Entra ID for groups during AutoProvision * Fixed issue with one way trust and optimised the users page * Added button labels to WorkSpace details modal * SSO now imports user groups for role assignment * Updated Cost Optimiser report with new graphs and more functional data * WSM Updater has .NET 9 installer built in **Version 6.1.18 (2025-04-10 08:33)** * Bug Fixes * Added some diagnostic text to database setup pages * Renamed WSP protocol on WorkSpaces page * Secured Information API with an API key * Added CloudWatch background task to optimise the admin dashboard * Updated AWS and .NET dependencies to latest release * Fixed graphing bug on admin dashboard * WSM now uses database to store secure cookie data * Fixed a bug which stopped directory properties from saving **Version 6.1.16 (2025-04-01 10:49)** * Bug Fixes * New external updater (includes database migrations) * Added legal hold API * Added audit log API * Added ability to assign roles to portal users based on AD group membership * Modified users and roles to use a GUID instead of string **Version 6.1.15 (2025-03-26 10:46)** * Bug Fixes * Fixed role permission on various controllers * Fixed table viewer ordering colour direction * Stats and Activity API queues now use a timer based flush * Added error logging for unhandled general errors * Status page checks are now row level instead of account or directory level * The error log exception is now cleaner with line number highlighting and symbol encoding * Admin dashboard now uses a tile based data fetch instead of entire page load * Secure Browser dashboard now has error logging * Added additional keywords for configuration pages on global search * Added workspace removal when an account is removed. * Logs now display event and user columns **Version 6.1.14 (2025-03-21 10:13)** * Bug Fixes * Optimised the stats API controller for faster request handling * Fixed issue with Orphaned workspaces not being removed when reconnected **Version 6.1.13 (2025-03-11 13:53)** * Bug Fixes * API queuing system to reduce database burden on client updates **Version 6.1.8 (2025-03-04 11:13)** * Bug Fixes * Updated dependencies to latest version * Fixed WorkSpace Secure Browser portal status * Added session usage reporting to WorkSpace Pools * Added new breakpoints for screen resolutions **Version 6.1.7 (2025-02-18 16:32)** * Bug Fixes * Added clipboard facility to MRSA (https only) * Added data structure for Pools instance changes * Added data structure for Pools users * Added user roles list to WSM users in admin * Added ability to remove a role * Added additional filters to the WorkSpaces page * Added username to Cost Estimator report * Adjusted settings page to fix for smaller resolutions * Added 2.7.5 Cost Optimizer option in settings. **Version 6.1.6 (2025-01-30 10:22)** * Bug Fixes * Updated dependencies/packages * Provided migration command for manual upgrades * Added LDAPS validation in Active Directory setup * Added ability to search tags on WorkSpaces page * Added more functionality in Pools (discounted pricing) **Version 6.1.5 (2025-01-23 14:54)** * Bug Fixes * Fixed bulk processing on Running Hours report * Fixed bug resetting the custom reboot time for WorkSpace * Added discount mechanism to Workspaces Pooled * Added a badge for billing and performance status on WorkSpace popup * Added WorkSpace user structure * Created a tile for Cost Optimizer to check it's running properly * Added Cost optimizer status to directory listing in Support Status * Added Event Viewer * Updated MSRA labelling **Version 6.1.2 (2025-01-03 15:19)** * Bug Fixes * Added ability to check configuration status * Fixed missing background tasks * Added low disk space alert for WorkSpaces * Fixed bug with username domain on WorkSpaces listing, now highlights erroneous directory config * Fixed graphic issue in rebranding page icon * Fixed bulk process CONFIRM case insensitivity * Updated dependencies to latest version **Version 6.1.0 (2024-11-25 13:38)** * Updated packages to latest versions * Bug Fixes * Improved settings page with new field descriptions * Added WorkSpace Pools to settings * Added ability to create image from a WorkSpace * Added ability to copy images (incl. region to region copy) * Added ability to update bundle image * Added Pools Reporting * Fixed issue with WorkSpace Pools page not loading when no data has been collected V**ersion 6.0.24** * Bug fixes * Fixed an Active Directory validation check during setup which caused Service Limit errors **Version 6.0.23** * Bug fixes * Introduced a new update mechanism to replace the older IIS ADSI method **Version 6.0.22** * Background scheduler now removes all tasks (except license check) when disabled * Disable Scheduler setting now applies changes to background scheduler on save **Version 6.0.21** * Fixed add/update button on config/settings-directories * Added additional information to error log for AD user updates **Version 6.0.20** * Bug fixes * Added additional environment variable to handle region due to Metadata v2 issue on EC2 instance * Added missing IP location cache routine * Fixed update page for correct patch notes * Added additional parameters for connection string to support Encrypted and Trust Server Certificate flags **Version 6.0.19** * Bug fixes * Removed legacy log group setting * Added some resilience to migration script * Set username and real name to ON by default **Version 6.0.17** * Bug fixes * Moved Workspaces Web into it's own settings page * Renamed email templates * Added missing Standby WorkSpaces tile to customise tile view on Admin page * Removed some legacy fields from settings page **Version 6.0.16** * Bug fixes * Fixed the migration script **Version 6.0.15** * Removed directory cards for WorkSpace Pools directories * Fixed broken link on WorkSpaces Web * Updated dependencies to latest versions * Moved logging to support menu **Version 6.0.14** * Bug fixes * Fixed state column on WorkSpaces Personal report * Fixed broken modal on Stopped WorkSpaces report * Settings now has a fixed sidebar, so page can be scrolled independently **Version 6.0.13** * Bug fixes * Improved service limit report with highlighting * Improved WorkSpaces Web log report * Change "WorkSpaces" to WorkSpaces Personal" **Version 6.0.11** * Bug fixes **Version 6.0.10** * Improved bulk process error feedback * Improved upgrade routine, now supports high availability using internal version instead of database version **Version 6.0.9** * Bug Fixes * Made improvements to WorkSpaces modal **Version 6.0.8** * Bug Fixes * UI Fixes * Added WorkSpaces Secure Browser (Web) **Version 6.0.7** * Bug Fixes * UI Fixes * Added ability to login with windows credentials in Self Service **Version 6.0.6** * Added Swagger for API descriptions * Added AutoDelete settings for AutoProvision * Bug Fixes **Version 6.0.5** * Bug Fixes * UI Fixes * Reversed Service Log, most recent now at the top * Added process selected button to Various reports for bulk operations **Version 6.0.4** * Built with .NET Core 8 * Latest AWS SDK integration * New UI * Optimised WorkSpaces search * New .NET Identity account and role system # Beta **Beta channel is not currently in development. All changes have migrated to stable.** # Portal Requirements **WorkSpaces Manager** is available either as a standalone product or as a 3-tier deployment, consisting of three main components: 1\) **Data Back-End:** Based on an MS-SQL database. 2\) **Management Portal Application:** Developed using the .NET Core Runtime. 3\) **Management Portal Presentation:** Deployed on IIS (Internet Information Services) on Windows. The deployment can be executed in various ways by decoupling these three components or combining some of them. The most common deployment scenarios are: {% tabs %} {% tab title="All-in-One" %} A **single Windows EC2 instance** that includes both IIS and MS-SQL Express can be deployed directly on AWS from the Marketplace as a **CloudFormation Project**. In this setup, all tiers (data back-end, application, and presentation) run on the same instance, offering the most cost-efficient solution. This deployment is compatible with an external **Network Load Balancer** to offload SSL certificates and establish a unified entry point with a common DNS name. {% endtab %} {% tab title="External Database" %} One or more **Windows EC2 instances** running IIS and the portal application can be configured to use an external **RDS MS-SQL database**. This deployment can start as an all-in-one appliance from the Marketplace, after which the database component can be modified to separate the database from the Windows instance using the **RDS Console** in AWS. {% hint style="info" %} Nuvens has already established the necessary infrastructure for deployments based on **Infrastructure as Code (IaC)**, utilizing modern technologies such as **Terraform**, **Packer**, **Git**, and **CloudFormation**. For assistance, please contact support at ****. {% endhint %} {% endtab %} {% tab title="Network Load Balancer" %} A **Windows EC2 instance** hosting both the portal and the database can be configured with a **Network Load Balancer (NLB)** to manage presentation, act as an entry point, and offload the SSL certificate. The NLB can be either internal or external, though it's recommended to use an internal NLB unless administrators are fully aware of the responsibilities involved in securing a publicly accessible application. {% endtab %} {% tab title="3-Tier" %} This deployment model decouples all components by creating one or more **Windows EC2 instances**, a single **RDS MS-SQL database**, and a **Network Load Balancer** distributed across all availability zones where the EC2 instances are hosted. For basic information, please refer to the [HTTPS/TLS Encryption section](/install/appendices/https-tls-encryption). Each function operates independently while collaborating to create an efficient setup. For guidance on deploying as a **High Availability (HA)** cluster, please consult the [High Availability](/install/high-availability-ha) section. {% hint style="info" %} Nuvens has created all the requirements for a deployment based on Infrastructure as Code (IaC) by using modern technologies like Terraform, Packer, Git, CloudFormation, etc. Please contact support at for assistance. {% endhint %} {% endtab %} {% endtabs %} {% hint style="success" %} For more detailed information, please refer to the [**Architecture Guide**](/architecture/workspaces-manager-architecture-guide). {% endhint %} # Software Requirements The WorkSpaces Manager Portal is compatible with current version of **Windows Server 2016, 2019, 2022, and 2025**, but only supports 64-bit versions. Furthermore, only EC2 virtual instances hosted on AWS are supported. {% hint style="info" %} Windows Server 2016 reaches its official End of Life (EOL) on **January 12, 2027**. After this date, Microsoft will no longer provide essential security patches, bug fixes, or technical support, leaving systems vulnerable to cyberattacks and compliance issues. {% endhint %} The WorkSpaces Manager installer comes with all required software components for the solution, which are as follows: • **Microsoft® .NET Core Runtime 9.x** or higher\ • **Microsoft SQL Server** Express or higher {% hint style="danger" %} **WorkSpaces Manager** must be joined to the AD Domain prior to starting the configuration. If it is not properly joined, an error will appear when attempting to save the configuration during the first login. {% endhint %} Since the **WorkSpaces Management Portal** utilizes IIS with Single Sign-On, the appliance must be a member of the Active Directory Forest/Domain. If the WorkSpaces Manager Portal is used to provision user accounts in AD, an service account will be required with delegated access to the Organizational Units (OUs) where WorkSpaces accounts will be created. For more details, please refer to the [Administrator Active Directory Permission](/install/appendices/administrator-active-directory-permissions) section for details. {% hint style="info" %} **Supported Browsers (minimum version)**: * **Chrome**: 22.x * **Firefox**: 12.x * **Opera**: 12.x * **Safari**: 5.1.x * **Microsoft Edge**: 88.x {% endhint %} # Hardware Requirements **WorkSpaces Manager** requires a minimum of: * **2 vCPUs** * **8 GiB RAM** * **20 GB of additional storage** in D:\\ {% hint style="warning" %} Nuvens recommends using **t3.large** or **t3a.large** instance types. {% endhint %} # Installation Prerequisites Before installing WorkSpaces Manager, ensure that all prerequisites are met for a successful deployment. These prerequisites include: * [Active Directory Service Account](/install/installation-prerequisites/active-directory-service-account) * [Amazon WorkSpaces Cost Optimizer](/install/installation-prerequisites/amazon-workspaces-cost-optimizer) * [CloudWatch Log Group & Eventbridge Rule](/install/installation-prerequisites/cloudwatch-log-group-and-eventbridge-rule) * [Port Requirements](/install/installation-prerequisites/port-requirements) * [AWS Service Endpoints](/install/installation-prerequisites/aws-service-endpoints) # Active Directory Service Account Amazon WorkSpaces requires Active Directory LDAP for deploying virtual desktops (vDesktops). An **Active Directory Service Account** is necessary for connecting with Active Directory. **WorkSpaces Manager** shares this dependency to interact with Active Directory. Depending on the permissions granted to WorkSpaces Manager within Active Directory, this Service Account may need different permissions on the assigned Organizational Unit (OU). {% hint style="success" %} For details on [Administrator Active Directory Permissions](/install/appendices/administrator-active-directory-permissions), please refer to the appendix. {% endhint %} The **Active Directory (AD) Service Account** is also utilized to perform various actions, such as creating user accounts, adding or removing users from existing Active Directory groups, and deleting unused computer objects. {% hint style="warning" %} **WorkSpaces Manager** has the capability to remove orphaned computer objects from Active Directory. However, for this functionality to work and effectively clean up the LDAP directory objects, the Service Account must possess the necessary permissions to delete computer objects. {% endhint %} # Amazon WorkSpaces Cost Optimizer Cost Optimizer for Amazon WorkSpaces monitors the amount of time a WorkSpace is being used in the calender mo and automatically converts the WorkSpaces state to the most cost-effective billing option. **Cost Optimizer for Amazon WorkSpaces** monitors the usage duration of a WorkSpace throughout the calendar month and automatically adjusts the WorkSpace's state to the most cost-effective billing option. While this is not a mandatory requirement, we strongly recommend installing and initially configuring it in **"Dry Run" mode**, which lists recommendations and actions without executing them. This AWS service enables automatic switching of WorkSpaces between **Hourly (AUTO\_STOP)** and **Monthly Cost (ALWAYS\_ON)** modes on a monthly basis, ensuring optimized costs. In **"Dry Run" mode**, recommendations will be displayed in the WorkSpaces Manager Portal, but the suggested changes will not be applied. For more details and deployment instructions, please refer to the link below:\ {% hint style="warning" %} Please ensure that you are in the correct region before deployment of Cost Optimizer. {% endhint %} {% hint style="info" %} After deploying the **WorkSpaces Cost Optimizer**, two **S3 buckets** will be created: 1. **One bucket for logs** → This bucket includes `"logs"` in its name and is used for storing logs related to WorkSpaces usage and optimizations. 2. **One bucket for Cost Optimiser data** → This is the bucket **without "logs" in its name** and should be used to configure the **WorkSpaces Manager Configuration section**. {% endhint %} In AWS, when deploying network configurations, there are typically two deployment templates based on the **existing network configuration** of the **VPC**, for which we have a different CloudFormation template: * [Hub Template](https://docs.aws.amazon.com/solutions/latest/cost-optimizer-for-workspaces/launch-the-stack-hub-template.html)**:** A centralized network architecture where multiple spoke VPCs connect to a single central VPC (Hub). * [Spoke Template](https://docs.aws.amazon.com/solutions/latest/cost-optimizer-for-workspaces/launch-the-spoke-stack.html): A peripheral VPC that connects to the Hub via a Transit Gateway or VPC Peering. # CloudWatch Log Group & Eventbridge Rule {% hint style="success" %} The **CloudFormation template** for **WorkSpaces Manager** in the **AWS Marketplace** automatically creates an **EventBridge Rule** and a **CloudWatch Log Group** in the same region where the appliance is deployed. The default **CloudWatch Log Group** is called: **"/aws/events/WorkSpacesAccessLG"** {% endhint %} **Amazon EventBridge** is a serverless event bus service that allows you to respond to changes in your AWS environment or applications. It helps you build event-driven architectures by capturing real-time data from various AWS services, custom applications, or SaaS providers, and routing that data to different targets. **Amazon CloudWatch Logs**, a service that collects, monitors, and stores log data from AWS resources, applications, and services. A **Log Group** is a container for logs, grouping together logs from similar sources, such as specific applications or AWS services. Within each Log Group, logs are organized into **Log Streams** (individual log files). EventBridge can send event data to **CloudWatch Logs** for storage and analysis. EventBridge Rules can collect specific insights for Amazon WorkSpaces that are not available through standard APIs. ## Multi-Region Deployment When setting up **WorkSpaces Manager** to operate across multiple regions, it’s essential to have an **EventBridge Rule** linked to a **CloudWatch Log Group** in each region where WorkSpaces are deployed. The only caveat is that the **CloudWatch Log Group** must have the exact same name in every region: **"/aws/events/WorkSpacesAccessLG"**. To create new **Rules** and a **CloudWatch Log Group** in a different region from where WorkSpaces Manager was deployed via the **CloudFormation template**, navigate to EventBridge. Click on "Buses" > "Rules":

Amazon Eventbridge

Click **"Create rule".**
Rules can be created in two different ways: 1. Visual Rule Builder (selected by default) 2. Standard (preferred)
We recommend switching off the "**Visual Rule Builder**". If needed, it can still be used by applying the same logic described below for the "**Standard view**". The process is then divided in 5 steps: 1. Define Rule Detail 2. Build Event Pattern 3. Select Target(s) 4. Configure Tags 5. Review and Create In the **"Rule Detail"** section, add a **Name** and **Description** (e.g., **WorkSpaces\_Rule**) and leave the "default" configuration for the Event Bus, as displayed below:
In the **"Events"** section, select **"AWS events or EventBridge partner events"**:
Below, in the **"Sample event - optional"** drop down, select **"AWS Events"** and search for **"WorkSpaces Access."**
In the last step, under **"Event pattern,"** select the following options: * **Creation Method: "Use pattern form"** * **Event Source**: **"AWS Services"** * **AWS Service**: **"WorkSpaces"** * **Event Type**: **"WorkSpaces Access"**
Click on **"Next"**. In the Select Target(s)s section, for **"Target 1"**, choose: * Target Type: **"AWS Service"** * Select a target: **"CloudWatch Log Group"** * Log Group: **"/aws/events/WorkSpacesAccessLG"**
Configure the optional tags as required by your IT Policy.
And then review and create the rule:
A success banner should appear on top of the page.
On CloudWatch, click on **“Logs”** > **“Log Management”** > confirm that the new log group exists.
Now, in WorkSpaces Manager, click on the **“Configuration”** drop-down, select **“Settings”**, and then **“Amazon Web Services”** Scroll down to the Account settings and select account, fill in the **“Access Log Group”** field with the following information: `/aws/events/WorkSpacesAccessLG`.
# Port Requirements For the WorkSpaces Manager Appliance to function properly, the following ports must be accessible:
ServicePort
AWS APIsTCP/443
RDS MS-SQLTCP/1433
nuvens.infoTCP/443
DNSTCP/UDP 53
RDPTCP/3389
Active DirectoryTCP/UDP 88 (Kerberos authentication)
Active DirectoryTCP/UDP 389 (LDAP) or TCP/UDP 686 (LDAPS)
Active Directory Global CatalogueTCP/3268
Active Directory and SambaTCP/UDP 445
NetBIOSTCP/UDP 135 & TCP/UDP 138
NTPUDP/123
NNTPTCP/433
When WorkSpaces Manager is configured to display user location using Amazon CloudWatch Log Groups together with an Amazon EventBridge rule that detects the client IP address, the following URLs must also be added: | Service | Port | | ----------------------------- | ------- | | | TCP/443 | | | TCP/443 | The image below illustrates an example of a user’s location derived from their IP address and displayed in Google Maps:
# AWS Service Endpoints AWS Service Endpoints are URLs that enable network connectivity between AWS services and clients. They can be public (internet-accessible) or private (via AWS PrivateLink for secure VPC access). {% hint style="info" %} Official information about AWS Service Endpoints & Quotas can be found [here](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html). {% endhint %} WorkSpaces Manager (WSM) requires connectivity to various AWS services to manage WorkSpaces effectively across multiple accounts. Below is a list of essential AWS service endpoints used by WSM: #### **1. Amazon S3** * **Purpose:** Stores logs, configuration files, and cost optimization data. * **Endpoint Pattern:** `s3..amazonaws.com` #### **2. Amazon WorkSpaces** * **Purpose:** Manages WorkSpaces lifecycle, including provisioning, starting, stopping, and termination. * **Endpoint Pattern:** `workspaces..amazonaws.com` #### **3. AWS Key Management Service (KMS)** * **Purpose:** Encrypts WorkSpaces storage, backups, and sensitive data. * **Endpoint Pattern:** `kms..amazonaws.com` #### **4. Amazon AppStream 2.0** *(if applicable)* * **Purpose:** Supports streaming applications for users in place of traditional WorkSpaces. * **Endpoint Pattern:** `appstream2..amazonaws.com` #### **5. Amazon RDS** *(if applicable)* * **Purpose:** Hosts the database backend for storing WSM-related metadata and configuration. * **Endpoint Pattern:** `rds..amazonaws.com` #### **6. AWS Directory Service** * **Purpose:** Manages Active Directory connections for WorkSpaces authentication and policy enforcement. * **Endpoint Pattern:** `ds..amazonaws.com` #### **7. Amazon EC2** * **Purpose:** Runs the WSM appliance instances and manages underlying infrastructure. * **Endpoint Pattern:** `ec2..amazonaws.com` #### **8. AWS Secrets Manager** * **Purpose:** Securely stores credentials, API keys, and sensitive configuration details for WSM. * **Endpoint Pattern:** `secretsmanager..amazonaws.com` #### **9. AWS Systems Manager Parameter Store** * **Purpose:** Centralized storage for runtime configuration parameters, environment-specific values, and operational flags used by WorkSpaces Manager. * **Endpoint Pattern:** `ssm..amazonaws.com` #### **Configuring Endpoints** Ensure that the necessary endpoints are accessible in your AWS environment, particularly in environments with strict network policies, such as private VPCs or on-premises setups. #### **Regions** AWS Region Endpoints are unique URLs specific to an AWS service within a particular region, enabling API requests to be directed to the correct regional infrastructure. They follow the format `..amazonaws.com`. AWS services are available across multiple regions worldwide, each identified by a unique code. Below is a list of AWS regions along with their corresponding codes: | Region Name | Region Code | | --------------------------- | -------------- | | US East (Ohio) | us-east-2 | | US East (N. Virginia) | us-east-1 | | US West (N. California) | us-west-1 | | US West (Oregon) | us-west-2 | | Africa (Cape Town) | af-south-1 | | Asia Pacific (Hong Kong) | ap-east-1 | | Asia Pacific (Hyderabad) | ap-south-2 | | Asia Pacific (Jakarta) | ap-southeast-3 | | Asia Pacific (Kuala Lumpur) | ap-southeast-5 | | Asia Pacific (Melbourne) | ap-southeast-4 | | Asia Pacific (Mumbai) | ap-south-1 | | Asia Pacific (Osaka) | ap-northeast-3 | | Asia Pacific (Seoul) | ap-northeast-2 | | Asia Pacific (Singapore) | ap-southeast-1 | | Asia Pacific (Sydney) | ap-southeast-2 | | Asia Pacific (Tokyo) | ap-northeast-1 | | Canada (Central) | ca-central-1 | | Europe (Frankfurt) | eu-central-1 | | Europe (Ireland) | eu-west-1 | | Europe (London) | eu-west-2 | | Europe (Milan) | eu-south-1 | | Europe (Paris) | eu-west-3 | | Europe (Spain) | eu-south-2 | | Europe (Stockholm) | eu-north-1 | | Europe (Zurich) | eu-central-2 | | Israel (Tel Aviv) | il-central-1 | | Middle East (Bahrain) | me-south-1 | | Middle East (UAE) | me-central-1 | | South America (São Paulo) | sa-east-1 | Each AWS service within a region has a specific endpoint that follows a standardized URL pattern: . For example, the Amazon S3 endpoint for the US East (N. Virginia) region is . For a comprehensive list of AWS service endpoints by region, and all the new regions that are created over time, please refer to the [AWS Service Endpoints documentation](https://docs.aws.amazon.com/general/latest/gr/rande.html). # Installation Procedure This section outlines the steps to: * [Subscribe to Nuvens WorkSpaces Manager on AWS Marketplace](/install/installation-procedure/subscribe-to-workspaces-manager-license-key) * [Request a License Key in nuvens.info](/install/installation-procedure/request-a-license-key) * [Subscribe to Nuvens WorkSpaces Manager Appliance on AWS Marketplace](/install/installation-procedure/subscribe-to-workspaces-manager-appliance) * [Deploy WorkSpaces Manager Appliance via CloudFormation](/install/installation-procedure/deploy-workspaces-manager-appliance-via-cloudformation) * [Configure WorkSpaces Manager](/install/installation-procedure/configure-workspaces-manager) * [Investigate alternate deployment options for WorkSpaces Manager Appliance](/install/alternate-deployment-options) # Subscribe to WorkSpaces Manager License Key Navigate to the [**AWS Marketplace**](https://aws.amazon.com/marketplace/search/results?searchTerms=Workspaces+manager) and search for **"Workspaces Manager"** by **Nuvens** as the vendor. Select the product titled **"Workspaces Manager License Key"**. Alternatively, you can use the following [link](https://aws.amazon.com/marketplace/pp/prodview-nv6lby2maoska).
Now, select "**View purchase options**"
You will see the product description displayed.
Scroll down and click on "**Subscribe"**.
Proceed to **"Set up your account"** to [request a license key](/install/installation-procedure/request-a-license-key). If you have already subscribed to WorkSpaces Manager but haven't set up an account, there will be a link provided to guide you to the registration page. # Request a License Key If prompted to set up an account, follow the instructions highlighted below. If you have already subscribed to WorkSpaces Manager but haven’t set up an account, a link will direct you to the registration area. ![](/files/mgUBNclgForUiWvHPHGv) {% hint style="info" %} Estimate the number of licenses required to cover your entire WorkSpaces estate, as the appliance will not function if too few licenses are requested. WorkSpaces Manager offers a trial period of 30 days, and you will only be charged after this period ends. You will be billed for the number of licenses you actually use, not the number of licenses you request. {% endhint %} Complete the registration form with the required information. The only necessary details for obtaining a license are highlighted below.
{% hint style="danger" %} For clarification: if you request 1,000 licenses but only have 600 WorkSpaces, you will only be billed for the 600 licenses, 30 days after your trial period ends. {% endhint %} Your license will be sent to you via email, allowing you to proceed with setting up the WorkSpaces Manager appliance by following the steps in the [Installing WorkSpaces Manager Appliance](/install/installation-procedure/subscribe-to-workspaces-manager-appliance) Section. Afterward, you'll receive an automated email containing a temporary key, which can be used during the installation process of WorkSpaces Manager. # Subscribe to WorkSpaces Manager Appliance Ensure that you are logged in to your AWS Console. Then, navigate to the AWS Marketplace and search for "WorkSpaces Manager Appliance." Once loaded, click on it:
On the next page, click "View purchase options":

WorkSpaces Manager Appliance in the AWS Marketplace

Next, subscribe to the software by clicking on "Accept Terms."
Next, click on "**Continue to Configuration**". # Deploy WorkSpaces Manager Appliance via CloudFormation Choose the region where you would like to deploy your WorkSpaces Manager appliance, then click on "**Continue to Configuration**".
Next, click on "**Continue to Launch**".
From the "**Choose Action**" dropdown, select "**Launch CloudFormation"**. Then, click on "**Launch**".
In the next section, accept all the default entries and click on "**Next**".
Now, specify the parameters for the CloudFormation stack configuration. Start by providing a **Stack Name** for the CloudFormation stack, such as "**CF-WSMv6**". It’s recommended to name the object using the acronym of the service being used in AWS, like starting with "CF" for CloudFormation.
Enter: * **VPC**: From the drop-down menu, choose the VPC where you want to deploy WorkSpaces Manager. * **Subnet**: Select a private subnet from the available options within your chosen VPC to host the WorkSpaces Manager. * **EC2 Instance Type**: From the drop-down menu, select an EC2 instance type from the drop-down menu. A minimum of **t3a.medium** is recommended. * **EC2 Key Pair**: Select the Key Pair you would like to associate with the instance from the drop-down menu. * **RDP Location CIDR**: Specify the CIDR block that will allow WorkSpaces users and administrators to access the WorkSpaces Manager. You can modify this setting later by navigating to **AWS Console > EC2 > Security Groups**. {% hint style="danger" %} You will need the associated PEM or PPK key file to decrypt the password later. It’s recommended to store the key in **AWS Secrets Manager** for future access and security. {% endhint %} Now, configure the additional options: 1. **Tags:** It's strongly recommended to tag your resources if desired. 2. **Permissions:** Leave this blank as the necessary permissions will be created automatically. 3. **Advanced Options:** Keep all settings at their default values. If you wish, you can enter an **SNS Topic ARN** to receive notifications when the stack is created, but this is optional. You'll know the process is complete when the WorkSpaces Manager appears as an EC2 instance in the console. After configuring the options, click on "**Next**".
You will now be on the **Review** screen. Scroll down to the bottom, check the acknowledgment box, and then click on "**Next"**.
A summary of your configuration will be displayed. Once you have reviewed it, click on "**Submit"** to begin the deployment.
You will be redirected back to the stack status screen, where you can track the progress of the WorkSpaces Manager stack creation.
You can monitor the tasks as they are being executed. Once the stack creation is complete, the status will change from **CREATE\_IN\_PROGRESS** to **CREATE\_COMPLETE**. The entire process typically takes around 3 to 4 minutes to finish.
If you now check your EC2 instances in the region where you installed WorkSpaces Manager, you should see the WorkSpaces Manager instance. Allow approximately 15-20 minutes for the status checks to complete and for the local administrator password to be automatically generated.
# Configure WorkSpaces Manager While WorkSpaces Manager is pre-configured in the appliance deployed via CloudFormation, some additional configurations are required to ensure optimal performance. {% hint style="danger" %} Join WorkSpaces Manager EC2 instance to Active Directory Domain. This is recommended for full functionaility. {% endhint %} Before proceeding with the upgrade procedure, ensure the following prerequisites are met: 1. **Access to the EC2 Instance**: You have access to the EC2 instance where **WorkSpaces Manager (WSM)** is configured. 2. **AWS CLI v2**: It is recommended to have **AWS CLI v2** installed for interacting with AWS services from the command line. 3. **Access to MS-SQL Instance and Database**: Ensure valid access to the **MS-SQL instance** and the associated database. 4. **EC2 Instance Role Permissions**: The EC2 instance role must have sufficient permissions to read from **AWS Secrets Manager**. 5. **Administrative Privileges**: Administrative privileges on the EC2 instance are available, to perform tasks such as joining the domain, configuring IIS, and creating environment variables. 6. **License Validation Endpoint**: Outbound HTTPS access to `https://nuvens.info` must be allowed during initial configuration to validate the WorkSpaces Manager license key. 7. **Secret Creation**: A secret must be created in **AWS Secrets Manager** to enable the application to securely connect to the database. ## Connect to Windows instance via RDP or Session Manager Fleet Manager To connect to a **WorkSpaces Manager Windows instance** using **RDP** or **Session Manager Fleet Manager**, follow these steps: {% tabs %} {% tab title="Connect via RDP" %} 1. **Retrieve the Private IP Address**: * Copy the **private IP** if you’re connecting through a VPN, a direct connection, a Jumpbox or a WorkSpace. 2. **Use Remote Desktop (RDP)**: * Open the **Remote Desktop Connection** application on your computer. * Enter the **IP address** of the instance. * Use the **Administrator username** and **password** to log in. * Click **Connect** to access the instance. {% endtab %} {% tab title="Connect via AWS Fleet Manager" %} 1. **Open Systems Manager**: * In the **AWS Management Console**, navigate to **Systems Manager** > **Fleet Manager**. 2. **Locate the Instance**: * In Fleet Manager, find the **WorkSpaces Manager** instance you want to access. * Select the instance and click **Node Actions**, then choose **Connect with RDP client** if RDP access is configured. 3. **Session Manager Connection** (if using an SSM agent and permissions): * If **Session Manager** is enabled, click **Connect** within Fleet Manager, and you’ll be able to manage the instance directly without needing an IP address or RDP client. {% endtab %} {% endtabs %} These options allow you to access and manage the **WorkSpaces Manager** instance depending on your network setup and access preferences. ## Join WorkSpaces Manager instance to the Active Directory Domain Before configuring **WorkSpaces Manager**, it is required to join it to an **Active Directory Forest**. This integration ensures that the manager can interact with user accounts, groups, and other resources within the directory, enabling full functionality and proper access control. To join **WorkSpaces Manager** to an **Active Directory (AD)** domain, you have several options. Joining it to AD requires a **service account** with appropriate permissions. Here are some common methods: {% tabs %} {% tab title="System Properties on Windows" %} * **Open System Properties** on the WorkSpaces Manager instance (right-click on **This PC** > **Properties** > **Change settings**). * Under the **Computer Name** tab, click **Change** to join a domain. * Enter the **domain name** and provide the **service account** credentials with permissions to add computers to the domain. * Restart the instance to apply changes. {% endtab %} {% tab title="PowerShell Commands" %} * Run PowerShell as an administrator on the WorkSpaces Manager instance. * Use the `Add-Computer` cmdlet to join the instance to the AD domain: ```powershell Add-Computer -DomainName "yourdomain.com" -Credential (Get-Credential) ``` * Enter the **service account** credentials when prompted. * Restart the instance after joining the domain. {% endtab %} {% tab title="AWS Systems Manager (SSM)" %} * If **AWS Systems Manager** is enabled, go to **Run Command** in the AWS Console. * Use the **AWS-JoinDirectoryServiceDomain** document to join the WorkSpaces Manager instance to an AD domain managed by AWS Directory Service. * Provide the **domain name**, **organizational unit (OU)**, and **service account** credentials. * Systems Manager will handle the domain join and restart if needed. {% endtab %} {% endtabs %} #### Required Permissions for the Service Account The service account should have: * Permissions to **join computers** to the AD domain. * **Read** and **write** permissions within the **Organizational Unit (OU)** where the WorkSpaces Manager will reside. * Access to **create computer objects** in AD, if necessary. These methods allow you to join WorkSpaces Manager to your Active Directory domain, ensuring it can integrate with your existing user and resource structures. ## Connect to **SQL Server Management Studio (SSMS)** {% hint style="danger" %} To connect to the **PortalCore** database using **SQL Server Management Studio (SSMS)**, ensure you are logged in as a Windows Administrator, as the BUILTIN\Administrators group is enabled. * For the **Server name**, leave the default hostname or use: `localhost\NUVENS`. This configuration enables direct access to the SQL Server instance on the local machine, allowing you to manage the **PortalCore** database and its users effectively. {% endhint %} By default, an account is available for connecting to the database to begin initial configuration. Use the following details to connect: * **Server name**: use `localhost\NUVENS`. * **Authentication**: Windows Authentication. Because the group BUILTIN\Administrators is part of the management setting of MS SQL, a local administrator will have access to the SQL Instance.
New Microsoft Connection Security requires to set an encryption level. Depending on the choise, this requires to have certificates installed, so if this issue is shown:
Make sure that **Encryption** is set to **Optional**:
Once connected to SQL Server Management Studio (SSMS): 1. In the **Object Explorer** panel on the left, locate the connected server instance. 2. Expand the **Databases** node by clicking the plus sign (`+`) next to it. 3. Scroll through the list to ensure the **PortalCore** database is present. If the **PortalCore** database is not listed, it may require additional steps may be required to set it up.
## Recommended: change password for Database administrator To change the password for the **NuvensDBA** account in the **PortalCore** database in **SQL Server Management Studio (SSMS)**, follow these steps: 1. **Open SQL Server Management Studio (SSMS)** and connect to your SQL Server instance. 2. **Navigate to Security**: * In **Object Explorer**, expand the **Security** folder under the server level. * Select **Logins**. 3. **Locate NuvensDBA**: * Right-click on **NuvensDBA** and select **Properties**. 4. **Change Password**: * In the **Login Properties** window, go to the **General** page. * Enter the new password in the **Password** and **Confirm Password** fields. 5. **Click OK** to save the changes. This updates the password for the **NuvensDBA** account in the **PortalCore** database.
## Optional: Download and Install AWS CLI v2 {% hint style="success" %} The **AWS CLI** is a valuable tool for ensuring that **WorkSpaces Manager** has access to essential AWS endpoints. Nuvens recommends installing it on the same appliance. {% endhint %} To download and install **AWS CLI v2** on Windows, follow these steps: 1. **Download AWS CLI v2**: * Download and install **AWS CLI v2** for Windows from the official AWS CLI v2 installation page: [Install AWS CLI v2 for Windows](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-windows.html). 2. **Run the Installer**: * Locate the downloaded **AWSCLIV2.msi** file and double-click it to start the installation. * Follow the on-screen prompts in the setup wizard to complete the installation. 3. **Verify the Installation**: * After installation, open **Command Prompt** or **PowerShell**. * Run the following command to verify the AWS CLI version: ```powershell aws --version ``` This should return the installed version of AWS CLI v2, confirming that it's successfully installed. You can now use the AWS CLI to manage your AWS resources from the command line. ## Configure Secrets for Database Access To securely store your database credentials in **AWS Secrets Manager** in the same AWS region in which your WorkSpaces Manager appliance is running, follow these steps: 1. **Log in to your AWS Account** and open **Secrets Manager**. 2. Click **Store a New Secret**. 3. Set the **Secret Type** to **Other type of secret**. 4. Choose the **Key/Value pairs** as **Key/Value** instead of **Plaintext**. 5. Enter the database credentials: * **username**: Your database username (e.g., NuvensDBA). * **password**: The password assigned to the username. 6. For the database configuration, enter the following details: * **engine**: `sqlserver` * **dbname**: `PortalCore` * **port**: `1433` * **host**: Enter the IP address of the **EC2 instance** and the SQL instance name (e.g., `localhost\NUVENS` if SQL is running locally). 7. **Complete the secret storage process** by following the remaining prompts to securely save the credentials in **AWS Secrets Manager**. 8. Click next, set the Secret name i.e. **prod/WSMv6** click Next and Store.
After entering the database credentials and configuration details, follow these steps to complete the process: 1. Click **Next**. 2. Set the **Secret Name** (e.g., `prod/WSMv6`). 3. Click **Next** to review your settings. 4. Once everything is verified, click **Store** to save the secret securely in **AWS Secrets Manager**. Your database credentials are now securely stored and ready for use in WorkSpaces Manager. {% hint style="warning" %} Ensure that the role attached to the instance has the necessary permissions to read secrets from AWS Secrets Manager. You can verify this using **AWS CLI v2**. {% endhint %} To create a secret via command-line using **AWS CLI v2**, execute the following commands: {% tabs %} {% tab title="Microsoft Powershell" %} ``` aws secretsmanager create-secret ` --name "prod/WSMv6" ` --description "prod/WSMv6" ` --region "eu-central-1" ` --secret-string '{\"username\":\"NuvensDBA\",\"password\":\"strongpassword123\",\"engine\":\"sqlserver\",\"port\":\"1433\",\"dbname\":\"PortalCore\",\"host\":\"localhost\\SQLEXPRESS\"}' ``` Please note, to properly store multiple key/value pairs instead of plaintext data, the backslash character (`\`) is used as an escape character. Since there is a backslash in the "host" key (`localhost\NUVENS`), you will need to use **two backslashes** (`\\`) to represent a single one. {% endtab %} {% tab title="Linux Bash" %} ```bash aws secretsmanager create-secret --name prod/WSMv603 --description "prod/WSMv6" --region eu-central-1 --secret-string "{\"username\":\"NuvensDBA\",\"password\":\"strongpassword123\",\"engine\":\"sqlserver\",\"port\":\"1433\",\"dbname\":\"PortalCore\",\"host\":\"localhost\\\\SQLEXPRESS\"}" ``` Please note, to properly store multiple key/value pairs instead of plaintext data, the backslash character (`\`) is used as an escape character. Since there is a backslash in the "host" key (`localhost\SQLEXPRESS`), you will need to use **four backslashes** (`\\\\`) to represent a single one. {% endtab %} {% endtabs %} This will securely store your database credentials in **AWS Secrets Manager**. After executing the command, you can verify that the secret was created by visiting **AWS Secrets Manager** in the **AWS Management Console** or by using the following AWS CLI command: ```powershell aws secretsmanager get-secret-value --secret-id prod/WSMv6 --query SecretString --output text ``` ## Verify Access to AWS Secrets Manager from WSM Appliance To verify that the role attached to a Windows EC2 instance has permissions to read secrets from **AWS Secrets Manager** using **AWS CLI v2**, follow these steps: 1. **Open PowerShell**: * Log into the EC2 instance via RDP. * Open **PowerShell** as an administrator and run command: * ```powershell aws secretsmanager get-secret-value --secret-id prod/WSMv6 ``` 2. **Verify Role Permissions Using AWS CLI v2**: * Run a command in PowerShell to check if the instance can retrieve the secret from **AWS Secrets Manager**. 3. **Expected Output**: * If the permissions are correct, the command will return the secret’s value. * If the permissions are not sufficient, it will display this error message.
4. **Add IAM Policy to the Instance Role**: * If the role attached to the instance does not have sufficient permissions, add the appropriate policy to the role via the **IAM Console** with the following JSON: * ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": "*" } ] } ``` 5. **Attach the Policy**: * Go to **IAM** in the **AWS Management Console**. * Locate the role attached to your EC2 instance. * Attach the policy that allows access to **Secrets Manager**. By running the **AWS CLI v2** command on your Windows instance through PowerShell, you can confirm if the instance has the necessary permissions to access secrets. ## Set Environment Variables On the server, follow these steps to access the environment variables and add two new ones: 1. **Search for "Environment Variables"**: * In the **Start Menu** search bar, type **"Environment Variables"**. 2. **Open System Properties**: * From the search results, click **"Edit the system environment variables"** to open the **System Properties** window. 3. **Access Environment Variables**: * In the **System Properties** window, click the **"Environment Variables..."** button at the bottom to view and edit the environment variables. This will allow you to view and modify system and user environment variables.
Click on **Advanced**, then select **Environment Variables** at the bottom of the window.
Under **System Variables**, click **New**. * **Variable Name**: `WSMCORE_SECRET_KEY` * **Variable Value**: Enter the name of the secret you stored (e.g., `prod/WSMv6`). Click **OK** to save the new environment variable.
Click again **New**. * **Variable Name**: `WSMCORE_REGION` * **Variable Value**: Enter the code for the AWS Region where WSM is running (e.g., `eu-central-1)`. Click **OK** to save the new environment variable.
This will set the `WSMCORE_SECRET_KEY` and `WSMCORE_REGION` environment variables with the right values, which we can verify by listing all environment variables executing the command: {% tabs %} {% tab title="Powershell" %} ```powershell Get-ChildItem Env: ``` {% endtab %} {% tab title="Command Prompt" %} ```bash set ``` {% endtab %} {% endtabs %} To create the system environment variable via PowerShell, use the following commands: ```powershell [System.Environment]::SetEnvironmentVariable('WSMCORE_SECRET_KEY', 'prod/WSMv6', [System.EnvironmentVariableTarget]::Machine) [System.Environment]::SetEnvironmentVariable('WSMCORE_REGION', 'eu-central-1', [System.EnvironmentVariableTarget]::Machine) # Verify that the environment variables were created Get-ChildItem Env: ``` {% hint style="info" %} During setup, WorkSpaces Manager attempts to determine the AWS region automatically. It first checks for environment variables (`WSMCORE_REGION`, `AWS_REGION`, or `AWS_DEFAULT_REGION`). If none are set, it retrieves the region from the EC2 instance metadata. If this cannot be determined, the system defaults to **us-east-1**. {% endhint %} ## Reset Internet Information Service (IIS) * **Open Command Prompt**: * Right-click **Command Prompt** and select **Run as Administrator**. * **Run the IIS Reset Command**: * In the Command Prompt window, type the following command and press **Enter**: ``` iisreset ```
This will reset IIS to apply any changes made. ## Configure Database for WSMv6 * **Open a Web Browser**: * Navigate to [**http://localhost**](http://localhost) to access the PortalCore site. * **Check for Database Connected**: * Check to see if the database is connected if it is not you will see an option to **Build Database** click and wait for the process to finish. * **Complete the Setup**: * Once the database build is complete, click **Continue** to proceed.
* **Identify Connection Errors**: * If you encounter any connection errors, they might be caused by misconfigured environment variables or missing roles for IIS. * **Recommended Reboot**: * To resolve this, it's recommended to perform a healthy reboot of the system by running the following command in **Command Prompt** (as Administrator): ```powershell shutdown /r /f /t 0 ``` 1. **Enter Administrator Account Details**: * Fill in the necessary information to create the **Administrator account** (e.g., username, password, email). * Click the **Create Account** button to finalize the creation of the Administrator account and move you to the next step. 2. **Click Continue**: * Once the Administrator account is created, click **Continue** to proceed with the setup process.
{% hint style="danger" %} During initial configuration, outbound HTTPS access to must be allowed to validate the WorkSpaces Manager license key. {% endhint %} 1. **Input Your License Key:** * Enter the license key provided for **Workspaces Manager**. 2. **Fill in the Required Information**: * Complete all necessary fields to configure **Workspaces Manager**, such as server details, admin credentials, or any other settings. 3. **Click "Create Configuration"**: * Once all the information is filled out, click **"Create Configuration"** to finalize the setup process.
1. **Check for Confirmation**: * If everything is configured correctly, a confirmation message will appear. 2. **Click "Continue"**: * After the confirmation appears, click **"Continue"** to proceed to the next step.
1. **Setup Complete**: * The configuration process is now finished. {% hint style="warning" %} Before logging in, perform another **IIS reset** on the WorkSpaces Manager server to ensure all services and configuration changes are fully applied. {% endhint %} 2. **Click "Login"**: * Click the **"Login"** button to access the **Workspaces Manager Portal** and begin using the system.
{% hint style="info" %} On your first login navigate to Update, select WorkSpaces to push an update to retreive data quicker. {% endhint %} # Upgrade Procedures This section applies to any of the releases of WorkSpaces Manager (WSM) appliances. The content is divided into three distinct upgrade processes: 1. [**Upgrade from Version 5 to Version 6**](/install/upgrade-procedures/upgrade-from-version-5-to-6): This process involves migrating from WorkSpaces Manager Version 5 to Version 6, which may include changes to infrastructure, configurations, or features. 2. [**Upgrade until Version 6.2.20**](/install/upgrade-procedures/upgrade-until-version-6.2.20): This process covers routine updates within Version 6, such as security patches, feature enhancements, or bug fixes, while staying within the same major version. 3. [**Upgrade to Latest Version**](/install/upgrade-procedures/upgrade-to-latest-version): This process involves downloading, extracting, running the WSM Update Tool and using the tool to apply the latest additions and configurations. Each process will have its own set of instructions and considerations to ensure a smooth upgrade. # Upgrade from Version 5 to 6 {% hint style="warning" %} Please ensure you are on version of 5.7 or higher of WorkSpaces Manager before upgrading. If you require assistance to upgrade to 5.7, please reach out to or contact your technical account manager. {% endhint %} Before proceeding with the upgrade procedure, ensure the following prerequisites are met: 1. **Access to the EC2 Instance**: You have access to the EC2 instance where **WorkSpaces Manager (WSM)** is configured. 2. **IIS Webserver Configuration**: The **IIS Webserver** is correctly configured and functioning. 3. **Administrative Privileges**: Administrative privileges on the EC2 instance are available. 4. **Access to MS-SQL Instance and Database**: Ensure valid access to the **MS-SQL instance** and the associated database. 5. **EC2 Instance Role Permissions**: The EC2 instance role must have sufficient permissions to read from **AWS Secrets Manager** and **AWS Systems Manager**. 6. **SSL Certificate**: A valid **SSL certificate** is available, especially if you are using **HTTPS** for secure communication. 7. **.NET Core 9 (Hosting Bundle)**: **.NET Core 9** (Hosting Bundle) is installed on the server. 8. **AWS CLI v2**: It is recommended to have **AWS CLI v2** installed for interacting with AWS services from the command line. Ensuring these prerequisites are met will help ensure a smooth and successful upgrade process. ## Create PortalCore directory on D: Log in to the EC2 instance where **WorkSpaces Manager (WSM)** is configured using your preferred method, such as **RDP** or **AWS Session Manager Fleet Manager**, depending on your network configuration and access settings. Once connected: 1. Open **File Explorer**. 2. Navigate to the **D:** drive. 3. Create a new folder and name it **PortalCore**. This folder will be used for the next steps in the upgrade process.
If you prefer to use **PowerShell** via the command-line as an administrator, you can use the following command to create the folder: ```powershell New-Item -Path "D:\PortalCore" -ItemType Directory ``` This command will create the **PortalCore** folder on the **D:** drive. ## Stop Portal Website To create the **PortalCore** website and application pool, follow these steps: 1. **Open IIS Manager**: * On the EC2 instance, open **IIS Manager** from the Start menu or by typing `inetmgr` in the Run dialog. 2. **Locate the Portal Site**: * In the **left-hand panel** of IIS Manager, expand the **Sites** node to locate the **Portal** site. 3. **Stop the Portal Site**: * Select the **Portal** site. * In the **right-hand Actions panel**, click **Stop** to temporarily stop the site. This ensures that the Portal site is stopped before making further changes to configure the **PortalCore** website and application pool.
To stop an IIS website called "Portal" using PowerShell, you can use the `Stop-Website` cmdlet: ```powershell Stop-Website -Name "Portal" ``` ## Create PortalCore Website and Application Pool To add the **PortalCore** website in **IIS Manager**, follow these steps: 1. **Open IIS Manager**: Ensure you're in **IIS Manager**. 2. **Add a New Website**: * Right-click on **Sites** in the **left-hand panel**. * Select **Add Website**. 3. **Configure the New Website**: * **Site Name**: Set the site name to **PortalCore**. * **Physical Path**: Set the physical path to the newly created **PortalCore** folder on the **D:** drive (`D:\PortalCore`). * **Port** and other bindings: Configure the bindings as necessary for your environment (e.g., HTTP or HTTPS). 4. **Stop the PortalCore Site**: * Select the newly created **PortalCore** site from the **left-hand panel**. * In the **right-hand panel**, click **Stop** to temporarily stop the site. This will prepare the **PortalCore** website for further configuration and deployment.
To ensure the **Identity** for the **PortalCore** instance in the IIS application pool is set to **LocalSystem**, follow these steps: 1. **Open IIS Manager**: If you're not already in **IIS Manager**, open it. 2. **Go to Application Pools**: * In the **left-hand panel**, select **Application Pools** under your server. 3. **Locate the PortalCore Application Pool**: * Find the **PortalCore** application pool in the list. 4. **Check the Identity**: * If the identity is not already set to **LocalSystem**, right-click on **PortalCore** and select **Advanced Settings**. 5. **Edit the Identity**: * In the **Advanced Settings** window, scroll down to the **Identity** field. * Click **Edit** next to the Identity field. 6. **Set Identity to LocalSystem**: * In the **Application Pool Identity** window, select **LocalSystem** from the dropdown menu. 7. **Apply the Changes**: * Click **OK** to confirm the selection. * Click **OK** again to apply the changes. This will set the **PortalCore** application pool to use the **LocalSystem** account for its identity, ensuring appropriate permissions for running the application.
To create the Website and associated Application Pool via Powershell, you can use the scripts below: ```powershell # Variables $siteName = "PortalCore" $appPoolName = "PortalCore" $physicalPath = "D:\PortalCore" $bindingInformation = "*:80:" # Adjust the port and hostname as needed # Create the Application Pool New-WebAppPool -Name $appPoolName # Set the Identity of the Application Pool to LocalSystem Set-ItemProperty IIS:\AppPools\$appPoolName -Name processModel.identityType -Value LocalSystem # Create the Website New-WebSite -Name $siteName -PhysicalPath $physicalPath -ApplicationPool $appPoolName -BindingInformation $bindingInformation ``` ## Add a Custom URL and HTTPS Binding {% hint style="danger" %} If you have a custom URL for **WorkSpaces Manager (WSM)**, you will need to add the corresponding **hostname** and associate it with the appropriate **SSL certificate**. This ensures secure communication over HTTPS and that the custom URL is properly configured for the site. {% endhint %} If you've assigned a URL to the site, follow these steps to add bindings: 1. Select the **PortalCore** site in IIS Manager, then click **Bindings** in the right-hand **Actions** panel. 2. Verify that there is a binding for **Port 80** (HTTP). If it's missing, add it. 3. Click **Add** to create a new binding: * Change the port to **443** for **HTTPS**. * Set the **hostname** (your custom domain). * Select the appropriate **SSL certificate** and ensure it’s valid by clicking **View**. 4. Click **OK**, then **Close** to finalize the changes.
## Configure Authentication Mechanisms Navigate back to **PortalCore** in **IIS Manager**. In the **Security** section, follow these steps: 1. Select **Authentication**. 2. Ensure that **Anonymous Authentication** is set to **Enabled**. 3. Confirm that **Windows Authentication** is **Disabled**. This configuration ensures that users can access the site without needing Windows credentials.
To execute this via **PowerShell** or command-line, you'll need to import the **IISAdministration** module and run a few commands to interact with IIS. Follow these steps: ```powershell Import-Module IISAdministration Set-WebConfigurationProperty -Filter "/system.webServer/security/authentication/windowsAuthentication" -PSPath "IIS:\Sites\PortalCore" -Name "enabled" -Value "False" (Get-WebConfigurationProperty -Filter "/system.webServer/security/authentication/windowsAuthentication" -PSPath "IIS:\Sites\PortalCore" -Name "enabled").Value Set-WebConfigurationProperty -Filter "/system.webServer/security/authentication/anonymousAuthentication" -PSPath "IIS:\Sites\PortalCore" -Name "enabled" -Value "True" (Get-WebConfigurationProperty -Filter "/system.webServer/security/authentication/anonymousAuthentication" -PSPath "IIS:\Sites\PortalCore" -Name "enabled").Value ``` ## Download and Install AWS CLI v2 To download and install **AWS CLI v2** on Windows, follow these steps: 1. **Download AWS CLI v2**: * Download and install **AWS CLI v2** for Windows from the official AWS CLI v2 installation page: [Install AWS CLI v2 for Windows](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-windows.html). 2. **Run the Installer**: * Locate the downloaded **AWSCLIV2.msi** file and double-click it to start the installation. * Follow the on-screen prompts in the setup wizard to complete the installation. 3. **Verify the Installation**: * After installation, open **Command Prompt** or **PowerShell**. * Run the following command to verify the AWS CLI version: ```powershell aws --version ``` This should return the installed version of AWS CLI v2, confirming that it's successfully installed. You can now use the AWS CLI to manage your AWS resources from the command line. ## Download and Deploy WorkSpaces Manager (WSM) version 6 Download the most recent **WSM ZIP** file from the following link: {% embed url="" %} Extract the contents of the ZIP file and copy them into the **PortalCore** folder located on the **D:** drive.
To perform the download, extraction and copy operation via PowerShell, run the following commands: ```powershell Write-Host "Download WSM onto a Temp folder..." powershell -NoProfile -ExecutionPolicy unrestricted -Command "(New-Object System.Net.WebClient).DownloadFile('https://nuvensworkspacesmanager.s3.eu-west-1.amazonaws.com/latest/stable/WSM.zip', 'C:\Windows\Temp\WSM.zip')" Write-Host "Uncompress the Portal on its folder..." Expand-Archive -LiteralPath C:\Windows\Temp\WSM.zip -DestinationPath D:\PortalCore ``` ## Configure Secrets for Database Access To securely store your database credentials in **AWS Secrets Manager** in the same AWS region in which your WorkSpaces Manager appliance is running, follow these steps: 1. **Navigate to the old Portal folder** on the **D:** drive. * Locate and open the **web.config** file. * Retrieve the **database username** and **password** from the file. 2. **Log in to your AWS Account** and open **Secrets Manager**. 3. Click **Store a New Secret**. 4. Set the **Secret Type** to **Other type of secret**. 5. Choose the **Key/Value pairs** as **Key/Value** instead of **Plaintext**. 6. Enter the database credentials retrieved from the **web.config** file: * **username**: Your database username from **web.config** (e.g., NuvensDBA). * **password**: The password from the **web.config** file. 7. For the database configuration, enter the following details: * **engine**: `sqlserver` * **dbname**: `PortalCore` * **port**: `1433` * **host**: Enter the IP address of the **EC2 instance** and the SQL instance name (e.g., `localhost\SQLEXPRESS` if SQL is running locally). * **encrypt:** true or false (if database is encrypted) * **trustservercertificate:** true or false (if database requires Trust Server Certificate to be enabled)
8. **Complete the secret storage process** by following the remaining prompts to securely save the credentials in **AWS Secrets Manager**. 9. Click next, set the Secret name i.e. **prod/WSMv6** click Next and Store.
After entering the database credentials and configuration details, follow these steps to complete the process: 1. Click **Next**. 2. Set the **Secret Name** (e.g., `prod/WSMv6`). 3. Click **Next** to review your settings. 4. Once everything is verified, click **Store** to save the secret securely in **AWS Secrets Manager**. Your database credentials are now securely stored and ready for use in WorkSpaces Manager. {% hint style="warning" %} Ensure that the role attached to the instance has the necessary permissions to read secrets from AWS Secrets Manager. You can verify this using **AWS CLI v2**. {% endhint %} To create a secret via command-line using **AWS CLI v2**, execute the following commands: {% tabs %} {% tab title="PowerShell" %} ``` aws secretsmanager create-secret ` --name "prod/WSMv6" ` --description "prod/WSMv6" ` --region "eu-central-1" ` --secret-string '{\"username\":\"NuvensDBA\",\"password\":\"strongpassword123\",\"engine\":\"sqlserver\",\"port\":\"1433\",\"dbname\":\"PortalCore\",\"host\":\"localhost\\SQLEXPRESS\"}' ``` {% endtab %} {% tab title="Linux Bash" %} ```bash aws secretsmanager create-secret --name prod/WSMv603 --description "prod/WSMv603" --region eu-central-1 --secret-string "{\"username\":\"NuvensDBA\",\"password\":\"strongpassword123\",\"engine\":\"sqlserver\",\"port\":\"1433\",\"dbname\":\"PortalCore\",\"host\":\"localhost\\\\SQLEXPRESS\"}" ``` {% endtab %} {% endtabs %} {% hint style="success" %} Please note, to properly store multiple key/value pairs instead of plaintext data, the backslash character (`\`) is used as an escape character. Since there is a backslash in the "host" key (`localhost\SQLEXPRESS`), you will need to use **two** (`\\`) **or four backslashes** (`\\\\`) to represent a single one. {% endhint %} This will securely store the database credentials in **AWS Secrets Manager**. After executing the command, you can verify that the secret was created by visiting **AWS Secrets Manager** in the **AWS Management Console** or by using the following AWS CLI command: ```powershell aws secretsmanager get-secret-value --secret-id prod/WSMv6 --query SecretString --output text ``` ## Verify Access to AWS Secrets Manager and AWS Systems Manager from WSM Appliance To verify that the role attached to a Windows EC2 instance has permissions to read secrets from **AWS Secrets Manager** and parameters from **AWS Systems Manager** (if using App Load Balancer) using **AWS CLI v2**, follow these steps: 1. **Open PowerShell**: * Log into the EC2 instance via RDP. * Open **PowerShell** as an administrator and run command: * ```powershell aws secretsmanager get-secret-value --secret-id prod/WSMv6 ``` 2. **Verify Role Permissions Using AWS CLI v2**: * Run a command in PowerShell to check if the instance can retrieve the secret from **AWS Secrets Manager**. 3. **Expected Output**: * If the permissions are correct, the command will return the secret’s value. * If the permissions are not sufficient, it will display an error message. 4. **Add IAM Policy to the Instance Role (if needed)**: * If the role attached to the instance does not have sufficient permissions, add the appropriate policy to the role via the **IAM Console** with the following JSON: * ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": "*" } ] } ``` 5. **Open PowerShell**: * Log into the EC2 instance via RDP. * Open **PowerShell** as an administrator and run command: * ```powershell aws ssm get-parameter --name [test] --with-decryption ``` 6. **Verify Role Permissions Using AWS CLI v2**: * Run a command in PowerShell to check if the instance can retrieve the parameter from **AWS Systems Manager**. 7. **Expected Output**: * If the permissions are correct, the command will return the parameter value. * If the permissions are not sufficient, it will display an error message. 8. **Add IAM Policy for AWS System Manager Parameter Store to the Instance Role** : * ```json {       "Version": "2012-10-17",       "Statement": [             {                   "Effect": "Allow",                   "Action": [                         "ssm:PutParameter",                         "ssm:GetParameter",                         "ssm:GetParameters",                         "ssm:DeleteParameter"                   ],                   "Resource": "*"             }       ] } ``` 9. **Attach the Policy**: * Go to **IAM** in the **AWS Management Console**. * Locate the role attached to your EC2 instance. * Attach the policy that allows access to **Secrets Manager** and **Systems Manager**. By running the **AWS CLI v2** command on your Windows instance through PowerShell, you can confirm if the instance has the necessary permissions to access secrets {% hint style="warning" %} It is necessary to attach the permissions for AWS Systems Manager Parameter Store if you are using a Application Load Balancer. {% endhint %} ## Install .NET Core 9 (Hosting Bundle) To ensure the **WorkSpaces Manager appliance** runs properly, the **.NET Core 9.x runtime (Hosting Bundle)** needs to be installed on your server. Follow these steps: 1. **Download .NET Core Hosting Bundle**: * Visit the official **.NET** download page and select the **Hosting Bundle** for **.NET Core 9.x**. 2. **Run the Installer**: * After downloading, open the installer and follow the on-screen instructions to install the **.NET Core Runtime** along with the required **IIS integration** components. 3. **Verify the Installation**: * To confirm the installation, open a command prompt and check the installed version of **.NET Core**. * ```powershell dotnet --info ``` 4. **Restart IIS** (if needed): * Once the installation is complete, restart IIS to ensure that all components are loaded properly. * ```powershell iisreset ``` After completing these steps, the **WorkSpaces Manager** appliance will be ready to run with the required .NET Core components. ## Set Environment Variables On the server, follow these steps to access the environment variables: 1. **Search for "Environment Variables"**: * In the **Start Menu** search bar, type **"Environment Variables"**. 2. **Open System Properties**: * From the search results, click **"Edit the system environment variables"** to open the **System Properties** window. 3. **Access Environment Variables**: * In the **System Properties** window, click the **"Environment Variables..."** button at the bottom to view and edit the environment variables. This will allow you to view and modify system and user environment variables.
Click on **Advanced**, then select **Environment Variables** at the bottom of the window.
Under **System Variables**, click **New**. * **Variable Name**: `WSMCORE_SECRET_KEY` * **Variable Value**: Enter the name of the secret you stored (e.g., `prod/WSMv6`).
Click **OK** to save the new environment variable. Repeat the process to add a new environment variable. * **Variable Name**: `WSMCORE_REGION` * **Variable Value**: Enter the region of the secret you stored (e.g., `eu-central-1`).
Click **OK** to save the new environment variable. To create the system environment variables via PowerShell, use the following commands: ```powershell [System.Environment]::SetEnvironmentVariable('WSMCORE_SECRET_KEY', 'prod/WSMv6', [System.EnvironmentVariableTarget]::Machine) # Verify that the environment variable was created Get-ChildItem Env: ``` ```powershell [System.Environment]::SetEnvironmentVariable('WSMCORE_REGION', 'eu-central-1', [System.EnvironmentVariableTarget]::Machine) # Verify that the environment variable was created Get-ChildItem Env: ``` This will set the `WSMCORE_SECRET_KEY` environment variable with the value `prod/WSMv6` and `WSMCORE_REGION` with the value `eu-central-1`. Verify its creation by listing all environment variables. ## Create and Configure **PortalCore** Database in **SQL Server Management Studio (SSMS)** Open **SQL Server Management Studio**: 1. **Right-click** on **Databases** and select **New Database**. 2. Set the **Database Name** to **PortalCore**. 3. For both **Database file paths**, point them to the new **PortalCore** folder. Click **OK** to create the database.
* **Navigate to Security**: * In **SQL Server Management Studio (SSMS)**, go to **Security > Logins**. * **Select NuvensDBA**: * Find and right-click on **NuvensDBA**. * **User Mappings**: * In the properties window, go to **User Mappings**. * **Select PortalCore Database**: * Check the box for the **PortalCore** database. * **Assign db\_owner Role**: * Under the **Database role membership** section, assign the **db\_owner** role. * **Click OK** to apply the changes.
* **Open Command Prompt**: * Right-click **Command Prompt** and select **Run as Administrator**. * **Run the IIS Reset Command**: * In the Command Prompt window, type the following command and press **Enter**: ``` iisreset ```
This will reset IIS to apply any changes made. ## Configure Database for WSMv6 * **Go back to IIS Manager**: * In the IIS Manager window, select the **PortalCore** site. * **Start the Site**: * Click **Start** in the right-hand **Actions** panel to start the PortalCore site. * **Open a Web Browser**: * Navigate to [**http://localhost**](http://localhost) to access the PortalCore site. * **Build the Database**: * Click the **Build Database** option on the site and wait for the process to finish. * **Complete the Setup**: * Once the database build is complete, click **Continue** to proceed.
* **Identify Connection Errors**: * If you encounter any connection errors, they might be caused by misconfigured environment variables or missing roles for IIS. * **Recommended Reboot**: * To resolve this, it's recommended to perform a healthy reboot of the system by running the following command in **Command Prompt** (as Administrator): ```powershell shutdown /r /f /t 0 ``` {% hint style="warning" %} #### Import Database (Optional) If you have an existing portal instance running **Version 5** on the same database server, follow these steps to import the database: 1. **Enter Existing Database Names**: * Provide the names of the databases that were used with your previous portal instance. 2. **Import Databases**: * Import the databases to continue using them with **WorkSpaces Manager v6**. This step ensures that your existing data from version 5 is migrated and remains accessible in version 6. {% endhint %} 1. **Enter Administrator Account Details**: * Fill in the necessary information to create the **Administrator account** (e.g., username, password, email). * Click the **Create Account** button to finalize the creation of the Administrator account and move you to the next step. 2. **Click Continue**: * Once the Administrator account is created, click **Continue** to proceed with the setup process.
1. **Input Your License Key**: * Enter the license key provided for **Workspaces Manager**. 2. **Fill in the Required Information**: * Complete all necessary fields to configure **Workspaces Manager**, such as server details, admin credentials, or any other settings. 3. **Click "Create Configuration"**: * Once all the information is filled out, click **"Create Configuration"** to finalize the setup process.
1. **Check for Confirmation**: * If everything is configured correctly, a confirmation message will appear. 2. **Click "Continue"**: * After the confirmation appears, click **"Continue"** to proceed to the next step.
1. **Setup Complete**: * The configuration process is now finished. 2. **Click "Login"**: * Click the **"Login"** button to access the **Workspaces Manager Portal** and begin using the system.
# Upgrade until Version 6.2.20 {% hint style="danger" %} Important: From version 6.2.20 onwards, software updates can no longer be performed via the interface. To update. Please use the [**Upgrade to Latest Version**](/install/upgrade-procedures/upgrade-to-latest-version) to apply future updates. {% endhint %} **Log in** to the **WorkSpaces Manager** console. \ Navigate to the **Configuration** dropdown and select **Settings**.
Under the **Licensing** section, you can view your current license and version information. If the version doesn't match the latest stable version available on the AWS Marketplace, a cloud icon will appear next to the version number, indicating an update is available.
In the **Update Portal** section, the latest available version will be displayed. {% hint style="warning" %} If using High Availability (HA): 1. Connect to both web servers individually. 2. Navigate to the **Update Portal** page on each server, but do **not** start the update yet. 3. Perform the update on one server at a time, ensuring both servers are on the **Update Portal** page before beginning the update process. {% endhint %} Click **Update** to start the update process.
The status will change to **Updating**. Please wait while the update is applied.
Once the update is complete, the page will confirm that your installation is up to date.
# Upgrade to Latest Version **1. Download and Extract** * Download the zip package from: * Extract to a folder on the IIS EC2 instance.\ Example: `D:\WSMUpdate` **2. Run the Updater** * Run an elevated Command Prompt as Administrator * Navigate to where the update tool has been extracted * Run the executable: `WSMUpdate.exe` {% hint style="info" %} **Note**: The updater will fetch the latest version automatically and apply the latest migrations using the connection string stored in the Amazon Secret defined by the `WSMCORE_SECRET_KEY` environment variable. Without additional arguments it will apply default parameters which are defined below. {% endhint %} **3. Optional Arguments** You can override the default behaviour by providing command-line arguments: * `-release [Beta/Stable]`\ Default: `Stable`\ Example: `WSMUpdate.exe -release Stable` * `-path ["D:\WSMDirectory"]`\ Default: `"D:\PortalCore"`\ Example: `WSMUpdate.exe -path "D:\PortalCore"` {% hint style="danger" %} **Do NOT include square brackets `[]` when entering argument values** {% endhint %} {% hint style="info" %} From Version 6.1.16 the update feature in WorkSpace Manager will automatically do all this for you. Previous versions have an issue applying migrations so the update tool is recommended {% endhint %} # Alternate deployment options WorkSpaces Manager deployment is flexible and can be adapted to multiple Infrastructure-as-Code (IaC) frameworks. This allows for automated and consistent deployment across various environments. While the preferred method is deploying from the AWS Marketplace, Nuvens has prepared alternative deployment methods to accommodate different scenarios, such as Custom VPC Configurations, Multi-Region Deployments, High Availability (HA) or Disaster Recovery (DR) Setups, IaC-Driven Deployments, etc. Some of these scenarios include: 1. Install WorkSpaces Manager [manually via EC2](/install/alternate-deployment-options/install-manually-on-ec2). 2. Share and [deploy the AMI](/install/alternate-deployment-options/deployment-from-shared-ami) using the preferred method. 3. [Create a new AMI via Packer](/install/alternate-deployment-options/create-ami-via-packer) and deploy using the preferred method. 4. [Deploy a database on AWS RDS](/install/alternate-deployment-options/deploy-an-rds-database-via-terraform) and use the Portal with methods #1 or #2. In any scenario, we recommend using a **Network Load Balancer** (NLB) with a custom DNS name. This setup allows you to offload SSL certificates for secure communication and present the application through a user-friendly, custom domain name. The NLB ensures high availability, better traffic distribution, and efficient SSL termination, enhancing both security and performance. # Install manually on EC2 {% hint style="info" %} For assistance with installing **WorkSpaces Manager v6** on an **EC2 instance** in your AWS account, please reach out to **** for further guidance and support. {% endhint %} # Deployment from Shared AMI Nuvens has adapted the deployment to several Git platforms with Pipelines and Actions and the code is already available in our GitLab repositories. Before publishing each version in the AWS Marketplace, Nuvens must create an AMI (Amazon Machine Image) in a secure environment. This AMI can be shared with other AWS accounts and regions, allowing it to be consumed through various deployment mechanisms, such as **Terraform**, **Git**, **CloudFormation**, or manual processes. When deploying Nuvens custom AMI, several AWS infrastructure requirements must be met. These are typically automated through the CloudFormation template deployed from the AWS Marketplace. These requirements include: 1. [Security Group:](/install/alternate-deployment-options/deployment-from-shared-ami/security-group) for the EC2 instance(s), with inbound and outbound rules. 2. [IAM Requirements: Custom Policies](/install/alternate-deployment-options/deployment-from-shared-ami/iam-requirements-custom-policies). 3. [IAM Requirements: Role and EC2 instance profile](/install/alternate-deployment-options/deployment-from-shared-ami/iam-requirements-role-and-ec2-instance-profile). 4. [Shared AMI](/install/alternate-deployment-options/deployment-from-shared-ami/shared-ami-amazon-machine-image) (Amazon Machine Image): it must be present in your AWS Account and Region prior to the deployment. For a real-world example of how to deploy an AMI via **Terraform**, please check this repository below for guidance and best practices: {% embed url="" %} {% hint style="info" %} For assistance in obtaining the AMI in your AWS account, please contact **** for further guidance and support. {% endhint %} # Security Group A Security Group for the EC2 instance hosting WorkSpaces Manager must be created prior to deployment so it can be associated with the instance. While the roles and policies were set up in the previous section, it's important to ensure that a Security Group is also configured. {% hint style="warning" %} If using the [Git Repo for Terraform](https://gitlab.com/nuvens-public/iam-role-terraform) from Nuvens' public site, the **Security Group**, **Policies**, **Role**, and **EC2 Instance Profile** will be created together as part of the automated deployment process. {% endhint %} Ensure that the AWS Security Group complies with your organization's internal governance policies. At a minimum, the Security Group should allow the following **inbound** access: * **TCP/80 (HTTP)** * **TCP/443 (HTTPS)** * **TCP/1433 (MS-SQL)** * **TCP/3389 (RDP)** For **outbound** access, configure the Security Group to allow: * **All traffic** (all ports and protocols) to **0.0.0.0/0**. We recommend naming this Security Group according to your organization's internal naming convention. If no specific naming convention is required, you can use **"SG-WorkSpacesManager"** as a suggested name. If you prefer to create the Security Group individually using Terraform, you can refer to the provided **.tf file** for guidance. This file contains the necessary configurations to define the Security Group and its rules. {% embed url="" %} # IAM Requirements: Custom Policies WorkSpaces Manager requires an **IAM Instance Role** to be associated with the EC2 instance(s), along with custom policies to enable access to other AWS services. The necessary policies should be created and attached to both the role and the EC2 Instance Profile. {% hint style="warning" %} If using the [Git Repo for Terraform](https://gitlab.com/nuvens-public/wsmv6-tf/wsm-iam-policies-role) from Nuvens' public site, the **Security Group**, **Policies**, **Role**, and **EC2 Instance Profile** will be created together as part of the automated deployment process. {% endhint %} Although you can name these policies based on your internal naming conventions, we recommend using the following names for better clarity and organization: * **WSMCloudwatchPolicy**: Grants access to AWS CloudWatch for monitoring and managing logs and metrics. * **WSMCostExplorerPolicy**: Provides access to AWS Cost Explorer to retrieve cost and usage reports. * **WSMEC2Policy**: Allows management and interaction with EC2 instances and related resources. * **WSMEUCPolicy**: Facilitates the management of Amazon WorkSpaces and other End-User Computing (EUC) services. * **WSMPricingPolicy**: Enables retrieval of pricing information from the AWS Pricing API. * **WSMS3Policy**: Grants access to S3 buckets used by WorkSpaces Manager, such as for storage and backups. * **WSMSecretsPolicy**: Allows retrieval of data from Secrets Manager for database connections. * **WSMParameterStorePolicy**: Enables access to Parameter Store for managing parameters on the Load Balancer sessions. The JSON definitions for these policies are available in our GitLab repositories and can be accessed in both **Terraform** and **CloudFormation** template formats. {% embed url="" %} For example, in **Terraform**, the policy might be structured as follows: ```json resource "aws_iam_policy" "WSMCloudwatchPolicy" { name = "WSMCloudwatchPolicy" description = "IAM policy for WorkSpaces Manager to access CloudWatch" policy = < Roles** in the AWS Management Console. 2. Click on **Create Role**. 3. Select **AWS Service** as the trusted entity. 4. Under **Choose a use case**, select **EC2** and click **Next**. 5. Attach the previously created policies (e.g., **WSMCloudwatchPolicy**, **WSMCostExplorerPolicy**, **WSMEC2Policy**, etc.) to the role. 6. Proceed through the remaining steps and provide a name for the role, such as **WorkSpacesManagerRole**. 7. Complete the role creation process by clicking **Create Role**.
# Shared AMI (Amazon Machine Image) At this stage, you'll launch the custom AMI shared by Nuvens to deploy WorkSpaces Manager. The AMI is based on **Windows Server 2019** and includes two volumes: * **C:\\** with 75GB of storage * **D:\\** with 20GB of storage When deploying WorkSpaces Manager from a shared AMI, ensure that you use the newly created **Security Group** and the appropriate **EC2 instance profile** with the correct policies attached. This setup will grant the instance the necessary permissions to interact with AWS services, while the Security Group ensures proper network access and security. For a real-world example of how to deploy an AMI via **Terraform**, please check this repository below for guidance and best practices: {% embed url="" %} # Create AMI via Packer HashiCorp Packer is a community tool for creating identical machine images for multiple platforms from a single source configuration. More info: https\://www\.packer.io/ [Packer](https://www.packer.io/) standardizes and automates the process of building system and container images, following the concept of **"Images as Code."** It allows for repeatable, consistent image creation. In the case of the WorkSpaces Manager Appliance, Packer takes a default **Windows AMI** from AWS and adds all the necessary requirements and configurations, creating a customized AMI ready for deployment. This approach ensures that the image-building process is automated, version-controlled, and aligned with infrastructure-as-code practices, resulting in a reliable and consistent image for the WorkSpaces Manager. Our Git repository provides an example of how to create an AMI via **Packer** for WorkSpaces Manager. The example includes the configuration files and necessary steps to automate the process of building a custom AMI based on a default Windows AMI from AWS, with all the required dependencies for WorkSpaces Manager. By following the example in the repository, you can streamline the AMI creation process using Packer's automation and "Images as Code" approach, ensuring consistency and efficiency in your deployments. This is the example for **WorkSpaces Manager (WSM)** v5: {% embed url="" %} This is the example for **WorkSpaces Manager (WSM)** v6: {% embed url="" %} {% hint style="danger" %} For assistance in configuring the Packer files to create a golden AMI for WorkSpaces Manager in your AWS account, please contact ****. The support team will provide guidance and help you with the necessary configurations to ensure a successful deployment. {% endhint %} # Deploy an RDS Database via Terraform Amazon Relational Database Service (Amazon RDS) is an easy-to-manage relational database service optimized for total cost of ownership. In scenarios where the **MS-SQL Database** is decoupled from the Portal Application, it's recommended to run the database using the **AWS RDS** managed service for better scalability, availability, and management. The database must use an **MS-SQL engine**, which can be deployed in any of its supported versions. There are multiple ways to deploy the MS-SQL database on AWS RDS, but to streamline the process, we provide an example of how to deploy it using **Terraform** in our Git repository. This example includes all the necessary configurations for setting up an RDS instance with MS-SQL, ensuring it integrates seamlessly with the WorkSpaces Manager environment. {% embed url="" %} Once the database has been deployed —whether via **Terraform**, **CloudFormation**, or manually on an EC2 instance— you need to configure the database to allow connections from the **WorkSpaces Manager Appliance**. At a minimum, this configuration should include: 1. **Database Access**: Set up a username and password for the WSM Appliance to connect to the database. 2. **Security Group Configuration**: Ensure that the database's security group allows inbound traffic on **TCP/1433** (MS-SQL) from the IP address or VPC of the WSM Appliance. 3. **Secrets Manager**: Store the database credentials (username and password) in **AWS Secrets Manager** for secure access by the WSM Appliance. By storing the credentials in **Secrets Manager**, the WSM Appliance can securely retrieve and use them during operations, reducing the need for hardcoded credentials and improving security. The retrieval of credentials is done in real-time by calling the **AWS Secrets Manager API**, ensuring that no sensitive information is stored or cached elsewhere. This process enhances security, as the credentials are only accessed when needed and are not exposed in any configuration files or logs, reducing the risk of unauthorized access. # WorkSpaces Manager Agent {% hint style="warning" %} **Recommended for Full Functionality:** The WSM Agent requires **.NET 4.6.2** or above. Ensure that this version or a later version of .NET is installed on the EC2 instance to enable all features of the WSM Agent. {% endhint %} The **WSM Agent** collects information related to both user activity and WorkSpace metrics. The latest version of the WSM Agent installer is always available at the following URL: For the agent to function correctly, certain **registry key values** must be configured so that the agent can identify and connect to the **Management Portal API**. An example of the required registry key format is shown below. The keys are structured as follows: ``` [HKEY_USERS\.DEFAULT\Software\Nuvens] "Portal"="https://portal.nuvens.co" "Frequency"=dword:00000005 "Visible"="true" "IdleMinutes"=dword:0000000f "DisconnectOnIdle"="false" "LiveBroadcastEnabled"="false" "LiveBroadcastFrequencyMs"=dword:00001388 "LiveHubUrl"="https://portal.nuvens.co/hubs/livestats" "RunElevated"="false" ``` *** The Portal value specifies the location of the **WorkSpaces Manager Portal** and the protocol used to access it. This value should be defined as a URL and can reference either an **IP address** or a **DNS hostname**. For example: ``` "Portal"="https://portal.nuvens.co" ``` {% hint style="danger" %} After deployment, update the **Portal** value in the registry key file with the **IP address** or **DNS name** of your WorkSpaces Manager Portal. Ensure that the correct protocol (**HTTP or HTTPS**) is specified, according to the configuration of your WorkSpaces Manager Portal. {% endhint %} *** The "**Frequency**" value specifies how often the **WSM Agent** reports metrics to the WorkSpaces Manager Portal. This value is expressed in **minutes**. For example: ``` "Frequency"=dword:00000005 ``` This means the agent reports every **5 minutes**. {% hint style="info" %} In environments with a large number of WorkSpaces, increasing this value can help reduce database load and improve overall system performance. For earlier versions of the WSM Agent (version 5), a legacy attribute named "**UpdateFrequency**" was used for the same purpose. {% endhint %} *** The "**Visible**" value determines whether the WSM Agent icon is displayed in the Windows system tray. This value accepts true or false. For example: ``` "Visible"="true" ``` When set to "**true**", the WSM Agent icon is visible in the **system tray**, allowing users or administrators to easily verify that the agent is running. When set to "**false**", the icon is hidden from the system tray. However, the WSM Agent continues to run normally in the background. Its execution can still be verified in Task Manager, where it appears as a process named **WSMAgent**. *** The "**IdleMinutes**" value defines the number of **minutes of user inactivity** before the WorkSpace is considered idle by the WSM Agent. For example: ``` "IdleMinutes"=dword:0000000f ``` This means the agent will treat the session as idle after **15 minutes** of inactivity. *** The "**DisconnectOnIdle**" value controls whether the agent should trigger a disconnect action when the session becomes idle. This value accepts true or false. For example: ``` "DisconnectOnIdle"="false" ``` When set to "**true**", the agent will disconnect the session after the configured idle threshold is reached. When set to "**false**", the session remains active even if the user is marked as idle. *** To enable **Live Stats** (Real-Time Metrics) and **Startup Metrics**, the following additional registry values must be configured: ``` "RunElevated"="true" "LiveBroadcastEnabled"="true" "LiveBroadcastFrequencyMs"=dword:00001388 "LiveHubUrl"="https://portal.nuvens.co/hubs/livestats" ``` The "**RunElevated**" value specifies whether the WSM Agent should run with elevated privileges. When set to true, the agent is allowed to collect Startup Metrics, which require higher privileges to measure system and login performance events during the user session initialization. These features require the WSM Agent to be executed through a Windows Scheduled Task running in the user context with elevated privileges. To ensure that only a single instance of the agent is running, the shortcut "**WSMAgent.lnk**" located in the Common Startup folder (**shell:common startup**) must be removed. When Live Stats are enabled, the agent should be started exclusively through the Scheduled Task. When enabled, the agent transmits Live Stats to the WorkSpaces Manager Portal in real time. These metrics provide detailed visibility into the user login process and system performance, including: * User login time * Time required to load the user profile * Time when Group Policies (GPOs) are applied * Time when the Windows shell becomes ready * Overall user login duration In addition to login performance metrics, Live Stats also monitor running processes and their CPU and memory consumption, allowing administrators to identify resource usage and potential performance bottlenecks within the WorkSpace. The "**LiveBroadcastFrequencyMs**" value controls how frequently these metrics are sent to the portal, expressed **in milliseconds**. An example of Startup Metrics and processes is shown below:
{% hint style="danger" %} If **Startup Metrics** are required, additional configuration is necessary to modify how the agent is started. Instead of launching from the **Windows Startup folder**, the agent must be configured to run as a **Scheduled Task at user logon**. Running the agent as a Scheduled Task allows it to start with the highest privileges, enabling the collection of startup and login performance metrics without granting elevated permissions to the user. For detailed configuration steps, refer to the [**GPO Scheduled Task Setup**](/install/appendices/gpo-scheduled-task-setup). {% endhint %} *** There are several ways to deploy the registry settings on your WorkSpaces. Some common methods include: * **Add Manually to Golden Images**: Apply the registry settings directly to your golden images, ensuring that all cloned WorkSpaces inherit the correct configurations. * **Group Policy (GPO)**: Distribute the registry settings via [Group Policy (GPO) using Active Directory](/install/appendices/gpo-and-values-for-workspaces-manager-agent), which automates the process for all WorkSpaces in the domain. * **Microsoft Intune (Entra ID Hybrid)**: Use Intune to distribute the registry settings when managing devices with Entra ID Hybrid for centralized control. * **Distribution Tool (e.g., SCCM)**: Leverage distribution tools like System Center Configuration Manager (SCCM) to push registry settings across your WorkSpaces fleet. * **AWS Systems Manager**: Use the AWS Systems Manager Run Command or State Manager to push the registry settings across your fleet of WorkSpaces. * **PowerShell Scripts**: Create a PowerShell script that modifies the registry with the required values. * **Logon Scripts**: Add a registry modification script to the logon process of the WorkSpaces, ensuring that each user gets the settings applied upon login. * **Configuration Management Tools**: Use tools like **Chef**, **Puppet**, or **Ansible** to automate the deployment of registry settings across WorkSpaces. # High Availability (HA) High availability in AWS refers to the ability of a system or application to remain operational with minimal downtime by using redundant resources across multiple Availability Zones within a region. The WorkSpaces Manager appliance is implemented as a single EC2 instance, incorporating both **IIS** and **MS-SQL Express**. However, it can be configured into 2-tier or 3-tier architectures to improve **High Availability (HA)**. The deployment options available include: 1. **2-Tier (Basic HA)**: * **Option 1:** A single EC2 instance hosting both IIS and MS-SQL, paired with a **Network Load Balancer (NLB)**. While this setup introduces some redundancy, it does not achieve full HA. * **Option 2:** A single EC2 instance running IIS, with the database migrated to **AWS RDS (MS-SQL)**. This configuration improves availability but still falls short of full HA. 2. **3-Tier (Full HA)**: * **Full HA Option:** The database (MS-SQL) is hosted in **AWS RDS**, and the IIS web application is load-balanced using a **Network Load Balancer (NLB)** across multiple EC2 instances. These instances are preferably organized in an auto-scaling group using a custom AMI. By separating the application and database tiers and incorporating redundancy at the application level, this configuration delivers comprehensive HA. Each option allows for different levels of scalability and resilience, with the 3-tier architecture offering the most robust High Availability solution. Focusing on the second option, which offers full **High Availability (HA)**, the architecture is divided into three distinct layers: 1. **Database in RDS**: * The database is hosted on **AWS RDS** using the **MS-SQL engine**. * You must create the appropriate schema for initialization to support the WorkSpaces Manager application. 2. **Network Load Balancer (NLB)**: * The **Network Load Balancer** manages traffic across multiple EC2 instances. * Ensure that you have a proper **DNS name** configured for the load balancer, along with a valid **SSL Certificate** to offload TLS/SSL encryption for secure communication. 3. **.NET Application in EC2**: * The **.NET application** is hosted on one or more EC2 instances running **IIS**. * Modify the environment variables to retrieve the connection details to the shared database on each EC2 instance, to ensure proper communication with the RDS database and load balancer. * Ensure that the EC2 instances use **Sysprep** to prepare them for deployment, making them reusable for scaling. * Configure **Ec2LaunchSettings** on each EC2 instance for proper initialization during boot-up, including tasks like setting the hostname, configuring networking, and ensuring the instances are ready to join the load balancer pool. This 3-tier architecture ensures high availability and scalability by separating the application, database, and load balancing layers, providing resilience and efficient resource management. {% hint style="danger" %} For any assistance on how to configure a Highly Available (HA) solution for WorkSpaces Manager on your AWS account, please contact ****. There is a guide that provides more details on the RDS configuration for WorkSpaces Manager [here](/install/appendices/rds-database-options). {% endhint %} # Appendices #### This section contains additional information that supports the main text. # Administrator Active Directory Permissions To administer user accounts, groups, and computers in **Active Directory** (whether globally or within selected Organizational Units (OUs)), refer to the following table for the key details:
OperationPermissions Needed
User Management
Create Users

To perform administrative tasks in Active Directory, the following permissions or group memberships are required:

  • You must be a member of the built-in Administrators group or the Account Operators group, OR
  • You must have specific permissions to create, delete, and manage user accounts or equivalent permissions within the relevant Organizational Unit (OU) or container in Active Directory.

These permissions ensure you have the necessary rights to manage user accounts, groups, and computers in the designated areas of the directory.

Modify Users
  • You must be a member of the built-in Administrators group or the Account Operators group, OR
  • You must have the necessary permissions to create, delete, and manage user accounts or equivalent permissions within the relevant Organizational Unit (OU) or container in Active Directory.

Note: It is also possible to grant permissions to modify specific attributes of an object, rather than granting full control over the entire object. This allows for more granular control over what aspects of the user accounts or other objects can be changed.

Delete Users
  • Must be a member of the built-in Administrators group or the Account Operators group, OR
  • Must have the necessary permissions to create, delete, and manage user accounts or equivalent permissions within the relevant Organizational Unit (OU) or container in Active Directory.
Computer Management
Create Computers
  • Must be a member of the built-in Administrators group or the Account Operators group, OR
  • Must have the ‘Computer Objects – Create selected objects in this folder’ permission, or an equivalent permission within the relevant Organizational Unit (OU) or container in Active Directory.
Modify Computers
  • Must be a member of the built-in Administrators group or the Account Operators group, OR
  • Must have the ‘Computer Objects – Create selected objects in this folder: with write permission’, or an equivalent permission in the relevant Organizational Unit (OU) or container in Active Directory.
Delete Computers
  • Must be a member of the built-in Administrators group or the Account Operators group, OR
  • Must have the ‘Computer Objects – Delete selected objects’ permission, or an equivalent permission in the relevant Organizational Unit (OU) or container in Active Directory.
Group Management
Create Groups
  • Must be a member of the built-in Administrators group or the Account Operators group, OR
  • Must have the ‘Create, manage, and delete user groups’ permission, or an equivalent permission in the relevant Organizational Unit (OU) or container in Active Directory.
Modify Groups
  • Must be a member of the built-in Administrators group or the Account Operators group, OR
  • Must have the ‘Create, manage, and delete user groups’ permission, or an equivalent permission in the relevant Organizational Unit (OU) or container in Active Directory.
Delete Groups
  • Must be a member of the built-in Administrators group or the Account Operators group, OR
  • Must have the ‘Create, manage, and delete user groups’ permission, or an equivalent permission within the relevant Organizational Unit (OU) or container in Active Directory.
# SES Configuration Amazon SES (Simple Email Service) is a scalable, cloud-based email service designed to send transactional, marketing, and bulk emails securely and cost-effectively. To configure **AWS Simple Email Service (SES)** as an **SMTP Relay** for WorkSpaces Manager, follow these steps: 1. **DNS Domain to be used as sender**: Identify the domain that will be used to send emails. 2. **Create DNS Records**: In your DNS provider’s console, create the necessary DNS records as requested by SES (such as DKIM, SPF, etc.). 3. **Create SMTP Credentials**: Generate SMTP credentials through SES to authenticate the sending of emails. 4. **Test Emails**: Send test emails to verify that SES is correctly configured as your SMTP relay. 5. **Configure WorkSpaces Manager (WSM)**: Input the SMTP details (SES credentials, endpoint, and port) in the WorkSpaces Manager configuration to enable email functionality. First, navigate to Amazon SES and click on “Get Started”:
As the identity type, select **'Domain'** and enter your correct DNS domain name. By default, **DKIM (DomainKeys Identified Mail)** will be enabled, ensuring that messages are authenticated and not altered during transit. After submitting the domain, the identity status will show as **“Verification pending”**, and Amazon SES will display the required **DNS records** (such as **CNAME**, **TXT**, or **MX**) that need to be created in your domain’s DNS settings for verification and DKIM setup. Ensure that these records are added to your DNS provider, as this is necessary for domain verification and to authenticate emails sent via SES. Once the DNS changes propagate, the domain status will update to **"Verified."** The **CNAME** records provided by Amazon SES for **DKIM** verification will be unique for each domain and verification request. These records are specific to your domain and are used to authenticate your emails by ensuring they are signed with the correct cryptographic keys. Once Amazon SES generates the CNAME records, you need to add them to your domain’s **DNS settings** at your DNS provider. These records will look something like this: * **CNAME Record 1**: `xxxxxxxx._domainkey.yourdomain.com -> xxxxxxxxxxxxxx.amazonses.com` * **CNAME Record 2**: `xxxxxxxx._domainkey.yourdomain.com -> xxxxxxxxxxxxxx.amazonses.com` * **CNAME Record 3**: `xxxxxxxx._domainkey.yourdomain.com -> xxxxxxxxxxxxxx.amazonses.com` The values will be different for each request. After these records are added, DNS propagation can take some time, and once completed, the domain status in SES will change to **"Verified"**.
After the DNS records are created, wait for about **10-15 minutes** for them to be published and fully replicated across the internet. Once replication is complete, AWS will automatically check the status of the DNS records. If everything is correct, SES will mark the domain as **“verified”**, and the domain will be able to send emails through SES. Additionally, **DKIM** will be successfully registered, ensuring that emails sent from your domain are properly authenticated.
Next, generate **SMTP credentials** in **AWS IAM** to consume the SES service from your application. 1. Navigate to the **SES dashboard** and click on the button labeled **“Create SMTP Credentials”**. 2. When generating the credentials, you will also see important information like: * **SMTP Endpoint**: This is the endpoint to which you will connect for sending emails (e.g., `email-smtp..amazonaws.com`). * **TLS Ports**: SES supports multiple ports, but it's recommended to use **587** for secure communication with **TLS**. Once the SMTP credentials are created, be sure to store them securely. These credentials will be required for configuring your email relay service in **WorkSpaces Manager**, allowing the application to send emails through **AWS SES**. Store them in a secure location, such as **AWS Secrets Manager** or another secure credential storage system, to prevent unauthorized access.
For the SMTP credentials, we are creating an **IAM User** in the AWS account with **SES Sending permissions**. It is crucial to save these credentials in a secure location, as they will only be displayed **once** during creation. You can choose to download them in a **CSV file** at this point for safekeeping. Ensure that the credentials are stored securely, such as in **AWS Secrets Manager** or another credential management system, as they will be needed to configure email services in your application. If lost, the credentials cannot be retrieved, and you will need to generate new ones.
You can verify that the email flow is working by clicking on the **“Send test email”** option in the **Configuration > Identities** section of the **SES dashboard**. This allows you to send a test email using the newly created SMTP credentials to ensure everything is correctly configured and that emails can be sent from your domain.
Fill out the necessary fields, such as the recipient's email address, subject, and body, and send the test email. If successful, you'll receive the test message, confirming that the SES setup and email flow are working properly. When sending a test email through the **SES dashboard**, there are several options you can explore to customize the test: * **Recipient Email**: Specify the email address where you want to send the test email. * **Subject**: Enter a subject line to test how it appears in the recipient's inbox. * **Body**: You can choose to send plain text or HTML content to see how the email is rendered. * **From Email Address**: Verify the sender domain and email format. * **Headers**: Test additional email headers like custom or reply-to fields. Feel free to investigate each of these options to better understand how the emails will appear to recipients and to confirm that everything is functioning as expected.
{% hint style="info" %} It is important to note that when a new SES Identity is created, it is initially placed in **"Sandbox" mode**. This means that the domain can only send emails **to and from** verified email addresses within the same registered domain. To remove these restrictions and send emails to any recipient, you will need to request **production access** from AWS. Once granted, your SES account will no longer be limited to the sandbox and can send emails to a broader audience. {% endhint %} If you need to send emails to different DNS domains, you must contact **AWS Support** and request to convert the domain from **“Sandbox”** to **“Production”** mode, as outlined in the AWS documentation: [Requesting Production Access for Amazon SES](https://docs.aws.amazon.com/ses/latest/dg/request-production-access.html). Once you have obtained production access, you can use the **SMTP credentials** generated earlier to configure **WorkSpaces Manager**. Populate the following fields in the WorkSpaces Manager configuration: * **SMTP Endpoint**: The endpoint provided by SES (e.g., `email-smtp..amazonaws.com`). * **Username and Password**: Use the SMTP credentials created in IAM. * **Port**: Typically 587 for TLS. * **Encryption**: Set to **TLS** to secure email communication. This will enable WorkSpaces Manager to send emails through SES with the newly configured SMTP relay.
# HTTPS/TLS Encryption HTTPS encryption secures data transmitted between a client and a server by encrypting the communication using TLS (Transport Layer Security), ensuring confidentiality and integrity of the information. To configure **HTTPS/TLS encryption** in front of the WorkSpaces Manager Appliance, you can add a **Network Load Balancer (NLB)** to split the presentation layer into a High Availability (HA) mode. Follow the steps below to set up encryption: 1. **Create a Network Load Balancer**: * Navigate to the **EC2 console** and select **Load Balancers**. * Create a **Network Load Balancer** with the appropriate settings and assign the correct **Target Group**. 2. **Add a Listener for HTTPS (Port 443)**: * In the **Listener** section, add a listener for **HTTPS** on port **443**. 3. **Select Target Group for Default Action**: * Under the **Default Action**, select the **Target Group** you created, which points to your EC2 instances running WorkSpaces Manager. 4. **Select the SSL Certificate**: * In the **SSL/TLS certificate** section, choose the appropriate certificate from **AWS Certificate Manager (ACM)**. * If you don’t have a certificate yet, generate one in ACM for your friendly hostname. 5. **Click ‘Add’**: * Complete the setup by clicking **‘Add’** to apply the HTTPS listener and associated settings. With this configuration, traffic between the client browser and the WorkSpaces Manager Appliance will be securely encrypted using **TLS**, ensuring secure communication across the network.
If you'd like to add a **Friendly Name** and **URL** to your WorkSpaces Manager Portal, please refer to [this appendix](/install/appendices/friendly-portal-url-address) for detailed instructions. This appendix will guide you through the steps required to configure a custom domain and associate it with your portal, enhancing accessibility and branding for users. # Friendly Portal URL Address A portal URL address is a web link that provides access to a specific online platform or resource. DNS (Domain Name System) translates human-readable domain names (URLs) into IP addresses. This section explains how to set up access to the WorkSpaces Manager portal using your **registered domain**. Instead of accessing the portal via the instance's IP address, you can add a DNS record to your domain. Here's how to configure it: 1. **Open DNS Manager**: Access your DNS management console, which is typically provided by your domain registrar or internal DNS service. 2. **Add an A Record**: * In **DNS Manager**, add a new **A record** to your domain. * Set the **hostname** (e.g., portal.yourdomain.com) as the subdomain for accessing the WorkSpaces Manager portal. * Reference the **IP address** of the WorkSpaces Manager EC2 instance in the record. 3. **Save and Apply**: Save the DNS changes. It may take some time for the new DNS record to propagate. Once the DNS record is active, you can access the WorkSpaces Manager Portal via the friendly domain name (e.g., **portal.yourdomain.com**) instead of the instance’s IP address. ![](https://manula.r.sizr.io/large/user/21827/img/ad.png) This setup will now allow you to reference the portal using a friendly domain name. In this scenario, we have used [**http://portal.nuvens.cloud**](http://portal.nuvens.cloud), but make sure to use your own domain in place of "Nuvens." Once you have configured a **Load Balancer**, you will need to: 1. **Add a CNAME Record**: * In your **DNS Manager**, add a **CNAME** record for your domain (e.g., **portal.yourdomain.com**). * Set this CNAME to reference the DNS name of your **Load Balancer**. 2. **Reference the Load Balancer's DNS Record**: * For example, if your Load Balancer’s DNS record is **lb-1234567890.us-west-2.elb.amazonaws.com**, you would use this as the target for the **CNAME**. This configuration will ensure that when users access **portal.yourdomain.com**, they are directed to the **Load Balancer**, which distributes traffic to your EC2 instances hosting the WorkSpaces Manager portal.
# GPO and values for WorkSpaces Manager Agent To deploy the **WSM Agent** software to AWS WorkSpaces via **Group Policy**, follow these steps: 1. **Open Group Policy Manager**: Create a new **Group Policy Object (GPO)** on the **Organizational Unit (OU)** containing your AWS WorkSpaces. 2. **Edit the Policy**: * Navigate to **Computer Configuration** > **Policies**. 3. **Expand Software Settings**: * Under **Computer Configuration**, expand **Software Settings**. 4. **Add a New Package**: * Right-click **Software Installation**, select **New** from the context menu, and then click on **Package**. 5. **Specify the Path**: * In the **Open** dialog, enter the full **UNC path** (e.g., `\\server\share\software.msi`) of the shared package you want to assign. 6. **Open and Assign**: * Click the **Open** button, then select **Assigned** and click **OK**. The package will be added to the right pane of the **Group Policy** window. This will deploy the software to all WorkSpaces associated with the selected OU when the policy is applied, ensuring the software is installed on startup. ![](https://manula.r.sizr.io/large/user/21827/img/gpolicy.png) To add the required **Registry values** through **Group Policy**, follow these steps: 1. **Open Group Policy Manager**: Edit the **GPO** created for the WorkSpaces. 2. **Navigate to Preferences**: * Under **Computer Configuration**, expand **Preferences** > **Windows Settings**. 3. **Create New Registry Items**: * Right-click **Registry** and select **New** > **Registry Item**. 4. **Add the Required Registry Keys and Values**: * **Portal**: * **Action**: Create * **Hive**: `HKEY_USERS` * **Key Path**: `.DEFAULT\Software\Nuvens` * **Value Name**: `Portal` * **Value Type**: `REG_SZ` * **Value Data**: The URL of your WorkSpaces Manager appliance (e.g., `http://wsmportal.nuvens.cloud` or `https://wsmportal.nuvens.cloud`). * **Frequency**: * **Action**: Create * **Hive**: `HKEY_USERS` * **Key Path**: `.DEFAULT\Software\Nuvens` * **Value Name**: `Frequency` * **Value Type**: `REG_DWORD (32-bit)` * **Value Data**: Set the frequency in minutes (e.g., `5` for reporting back every 5 minutes). * **UpdateFrequency**: * **Action**: Create * **Hive**: `HKEY_USERS` * **Key Path**: `.DEFAULT\Software\Nuvens` * **Value Name**: `UpdateFrequency` * **Value Type**: `REG_SZ` * **Value Data**: Leave empty or set accordingly. * **IdleMinutes**: * **Action**: Create * **Hive**: `HKEY_USERS` * **Key Path**: `.DEFAULT\Software\Nuvens` * **Value Name**: `IdleMinutes` * **Value Type**: `REG_DWORD (32-bit)` * **Value Data**: Set the idle time in minutes (e.g., `15` for 15 minutes of inactivity). * **Visible**: * **Action**: Create * **Hive**: `HKEY_USERS` * **Key Path**: `.DEFAULT\Software\Nuvens` * **Value Name**: `Visible` * **Value Type**: `REG_SZ` * **Value Data**: `False` (or `True` if you want the icon to be visible in the Windows tray). * **DisconnectonIdle**: * **Action**: Create * **Hive**: `HKEY_USERS` * **Key Path**: `.DEFAULT\Software\Nuvens` * **Value Name**: `DisconnectonIdle` * **Value Type**: `REG_SZ` * **Value Data**: `True` (to restart the PCoIP or WSP protocol when idle). 5. **Apply the Policy**: * Once all registry values have been added, apply the Group Policy. The changes will take effect during the next Group Policy update cycle on the WorkSpaces. # GPO and value for Disconnection after idle time In the context of Amazon WorkSpaces, "idle time" refers to the period during which a user is not actively using their virtual desktop or workspace session, but AWS does not measure it. The **WSM Agent** has been enhanced to allow users to be disconnected from their WorkSpace once they reach the defined idle time inside the virtual desktop (vDesktop). To configure the detection of "idle time" and the subsequent action (such as disconnection), follow one of these two methods to populate the necessary registry values: #### Mechanism 1: **On the Golden Image** 1. **Import the Registry File**: Ensure the registry file contains the required keys and values. 2. **Verify the Values**: Ensure that the following registry values are populated correctly for the WorkSpaces Performance Monitor Agent: * **IdleMinutes**: The amount of time (in minutes) after which the user is considered idle. * **DisconnectOnIdle**: A boolean value to indicate if the user should be disconnected after the idle time (True or False). Import the registry settings before creating new WorkSpaces from the golden image. #### Mechanism 2: **Via GPO (Group Policy)** 1. **Create or Edit a GPO**: * In **Group Policy Management**, create or edit a GPO applied to your WorkSpaces OU. 2. **Configure the Registry Entries**: * In the **Group Policy Editor**, navigate to **Computer Configuration** > **Preferences** > **Windows Settings** > **Registry**. * Right-click and select **New** > **Registry Item**. 3. **Add the Necessary Registry Keys**: * **IdleMinutes**: * **Action**: Create * **Hive**: `HKEY_USERS` * **Key Path**: `.DEFAULT\Software\Nuvens` * **Value Name**: `IdleMinutes` * **Value Type**: `REG_DWORD (32-bit)` * **Value Data**: Set the idle time in minutes (e.g., `15` for 15 minutes of inactivity). * **DisconnectOnIdle**: * **Action**: Create * **Hive**: `HKEY_USERS` * **Key Path**: `.DEFAULT\Software\Nuvens` * **Value Name**: `DisconnectonIdle` * **Value Type**: `REG_SZ` * **Value Data**: `True` (to disconnect the user after the defined idle time). #### Ensure Disconnection on Idle: The new registry entry allows you to define whether the user should be disconnected during periods of inactivity. Both methods ensure the necessary registry values are applied to the WorkSpaces, enforcing the idle time detection and disconnection policy. ![](https://manula.r.sizr.io/large/user/21827/img/idle1.png) **Policy Management for WSP**\ By default, WorkSpace users do not have the required permissions to start or stop services on their WorkSpace, which is essential for disconnecting a user based on idle time. We recommend modifying the Group Policy Object (GPO) used to deploy the WorkSpaces Performance Monitor Agent to grant these permissions. To do this, install the **Group Policy Management** remote tool on a WorkSpace and make the necessary changes, ensuring you have the appropriate Active Directory permissions. ![](https://manula.r.sizr.io/large/user/21827/img/idle2.png) {% hint style="danger" %} This modification cannot be performed from a Domain Controller or any other server in the domain. It must be done from an existing Windows WorkSpace, as it relies on the **PCoIP** or **WSP protocol** values specific to the WorkSpace environment. {% endhint %} To create a new **GPO** in the **OU** where the WorkSpaces are grouped (and reuse it if there are multiple OUs), follow these steps: 1. Open **Group Policy Management**. 2. Locate the OU where your WorkSpaces are grouped. 3. Right-click the OU and select **"Create a GPO in this domain, and link it here…"**. 4. Provide a name for the new GPO. 5. Click **OK** to create and link the GPO to the selected OU. This GPO can then be reused across other OUs as needed. ![](https://manula.r.sizr.io/large/user/21827/img/idle4.png) Name the GPO **"WorkSpacesDisconnect"** or any other name that aligns with your organization's security standards. This naming convention will help easily identify the purpose of the GPO within your Group Policy Management structure. ![](https://manula.r.sizr.io/large/user/21827/img/idle3.png) Once the **GPO** is created, right-click on it and select **"Edit…"** to open the **Group Policy Management Editor**, where you can configure the necessary settings for the **WorkSpacesDisconnect** policy. ![](https://manula.r.sizr.io/large/user/21827/img/idle5.png) In the **Group Policy Management Editor** window, navigate to: **Computer Configuration** > **Policies** > **Windows Settings** > **Security Settings** > **System Services**. Here, you'll need to modify the appropriate service based on the protocol in use: * **If WSP is in use**: Locate and modify the service called **"DCV Server"**. * **If PCoIP is in use**: Locate and modify the service called **"PCoIP Standard Agent for Windows"**. Adjust the security settings for the relevant service to allow users to start or stop it as needed for disconnection purposes. ![](https://manula.r.sizr.io/large/user/21827/img/idle6.png) Double-click the policy for the service that is **"Not defined"**, then: 1. Check the box for **"Define this policy setting"**. 2. Under **"Select service startup mode"**, choose the option **"Automatic"**. This setting ensures the service will start automatically and allows the WorkSpaces Performance Monitor Agent to manage user disconnection based on idle time. ![](https://manula.r.sizr.io/large/user/21827/img/idle7.png) Click on the **"Edit Security"** button, then: 1. In the **Security** window, click **"Add"**. 2. In the **Select Users, Computers, or Groups** dialog, type **"Domain Users"** and click **OK**. 3. Assign the necessary permissions for **Domain Users** to **start**, **stop**, and **restart** the service. 4. Click **OK** to apply the changes. This will ensure that the **Domain Users** group has the appropriate permissions to manage the service for user disconnections. ![](https://manula.r.sizr.io/large/user/21827/img/idle8.png) After clicking **"Add"**, follow these steps: 1. In the **Select Users, Computers, or Groups** dialog, type **"Domain Users"**. 2. Click the **"Check Names"** button to confirm the group is recognized in the domain. 3. Once confirmed, click **OK** to add **Domain Users**. This ensures that the **Domain Users** group is properly selected for security permissions on the service. ![](https://manula.r.sizr.io/large/user/21827/img/idle9.png) Once **"Domain Users"** is added, follow these steps to assign the required permissions: 1. In the **Permissions** window, locate the **"Domain Users"** group. 2. Under the **Permissions** section, check the box for **"Start, stop and pause"**. 3. Click **Apply**, then **OK** to save the changes. This will grant the **Domain Users** group the ability to start, stop, and pause the service as needed for managing user disconnection. ![](https://manula.r.sizr.io/large/user/21827/img/idle10.png) After assigning the permissions: 1. Click **"OK"**. 2. An alert will appear notifying you that the changes will apply to all users affected by the GPO. 3. Confirm by clicking **"Yes"** to agree. This will finalize the changes, applying the updated permissions to all users under the GPO. ![](https://manula.r.sizr.io/large/user/21827/img/idle11.png) After completing the steps, the service will now display as **"Configured"** in the **Group Policy Management Editor** under **System Services**. This indicates that the settings, including the startup mode and security permissions, have been successfully applied. ![](https://manula.r.sizr.io/large/user/21827/img/idle12.png) After closing the **Group Policy Management Editor**, return to the **Group Policy Management Console**. 1. In the **GPO** you've edited (e.g., "WorkSpacesDisconnect"), select the **"Settings"** tab. 2. Review the displayed settings to confirm that the new values, such as the modified service configurations and security permissions, have been successfully added. This step ensures that the changes have been applied and are reflected in the policy settings. ![](https://manula.r.sizr.io/large/user/21827/img/idle13.png) **Policy Management for PCoIP**\ If your WorkSpaces vDesktop Farm includes a mix of both **WSP** and **PCoIP** devices, you will need to modify both services. You can use the same GPO policy, but you must apply the changes from a WorkSpace running the specific protocol. In the example above, we used a WorkSpace with **WSP** to install the Group Policy Management applet. Similarly, you will repeat the process from a **PCoIP** WorkSpace. The steps remain the same, with the only difference being the service name, which changes from **"DCV Server"** to **"PCoIP Standard Agent for Windows"**. ![](https://manula.r.sizr.io/large/user/21827/img/idle14.png) To continue modifying the **WorkSpacesDisconnect** GPO, follow these steps: 1. **Open Group Policy Management** and right-click the **"WorkSpacesDisconnect" GPO**. Select **"Edit"**. 2. In the **Group Policy Management Editor**, navigate to: **Computer Configuration** > **Windows Settings** > **Security Settings** > **System Services**. 3. Locate the service named **"PCoIP Standard Agent for Windows"**. 4. Proceed with configuring this service as needed, following similar steps as with the **WSP** service. ![](https://manula.r.sizr.io/large/user/21827/img/idle15.png) Repeat the same process to enable the policy for the **"PCoIP Standard Agent for Windows"** service: 1. **Double-click** on the **"PCoIP Standard Agent for Windows"** service. 2. Check the box for **"Define this policy setting"**. 3. Under **"Select service startup mode"**, choose **"Automatic"**. 4. Click **"Edit Security"**. 5. **Add the "Domain Users"** group by clicking **"Add"**, then type **"Domain Users"**, and click **"Check Names"** to confirm. 6. Grant **"Start, stop, and pause"** permissions to the **Domain Users** group. 7. Click **"OK"** and confirm the alert by clicking **"Yes"**. Once completed, the service will be marked as **Configured**, just like for the **WSP** service. ![](https://manula.r.sizr.io/large/user/21827/img/idle16.png) Now, both protocols—**WSP** and **PCoIP**—will be enabled and configured in the **Group Policy**. You will see both services, **"DCV Server"** for WSP and **"PCoIP Standard Agent for Windows"**, marked as **Configured** under the **System Services** section of the GPO. This confirms that both protocols are set up to manage user disconnections based on idle time. ![](https://manula.r.sizr.io/large/user/21827/img/idle17.png) {% hint style="success" %} If the WorkSpace is not disconnecting as expected during idle time, you can troubleshoot by checking the log file. To do this, use **File Explorer** and navigate to: `%USERPROFILE%\AppData\Local\Temp\Nuvens` The log file in this folder will contain any errors that occurred during attempts to disconnect the WorkSpace. Typically, these issues are related to permissions that prevent the service from being stopped and started. {% endhint %} # GPO Scheduled Task Setup To enable **Startup Metrics**, the WSM Agent must run with elevated privileges. This requires configuring the agent to start as a **Scheduled Task at user logon** instead of launching from the Windows Startup folder. ### Create the Group Policy Object (GPO) 1. Open **Group Policy Management** (`gpmc.msc`). 2. Expand your domain. 3. Right-click the appropriate **Organisational Unit (OU)** containing the target users. 4. Select **Create a GPO in this domain, and Link it here**. 5. Provide a name for the GPO 6. Right-click the newly created GPO and select **Edit**.
Name the GPO **"WSMAgent"** or any other name that aligns with your organization's security standards.
### Configure the Scheduled Task Navigate to: ``` User Configuration └─ Preferences └─ Control Panel Settings └─ Scheduled Tasks ``` Right-click in **Scheduled Tasks** → **New** → **Scheduled Task (At least Windows 7)**. #### General Tab Configure the following: * **Name:** WSMAgent * **Description:** (optional) * **Run only when user is logged on:** Yes * **Run with highest privileges:** Yes * **Configure for:** Windows 10 / Windows Server 2016+
#### Triggers Tab * **Begin the task:** At log on * **Enabled:** Yes
#### Actions Tab * **Action:** Start a program * **Program/script:** ``` C:\Program Files (x86)\Nuvens Consulting Ltd\WSM Agent\WsmAgent.exe ```
#### Settings Tab * **Allow task to be run on demand**: Yes * **If the task is already running**: Do not start a new instance * **Stop the task if it runs longer than**: 3 days * I**f the running task does not end when requested, force it to stop**: Yes Click **OK** to save the task configuration.
{% hint style="danger" %} The original shortcut used to start the agent from the Windows **Startup** folder must be removed. {% endhint %} {% hint style="warning" %} A minimum of **one reboot** is required for the Group Policy to create the Scheduled Task. The agent will then start with elevated privileges at the next user logon. {% endhint %} # IAM Policies in JSON format If you cannot use Terraform automation, you can also use different method for the custom policies. {% hint style="warning" %} Updated 6th May 2026 {% endhint %} If Terraform automation is not an option, you can still use your preferred method to create the custom policies. This could include using the **AWS Management Console**, **AWS CLI**, or other Infrastructure-as-Code (IaC) tools like **CloudFormation** to create the required IAM policies can be created manually in the AWS Console and attached to the WorkSpaces Manager EC2 role. These policies provide the permissions required for WorkSpaces Manager to interact with AWS services used by the platform, including Amazon WorkSpaces, Directory Service, AppStream, tagging APIs, and KMS where encrypted WorkSpaces volumes are used. The JSON policy examples below can be copied directly into the AWS Console when creating the required customer-managed IAM policies. These policies are based on the WSM IAM policy and role deployment repository. We have defined a number of IAM Policies: 1. WSMCloudwatchPolicy to read from logs and alarms CloudWatch 2. WSMCostExplorerPolicy to access AWS Cost Explorer and Cost Optimizer features 3. WSMEC2Policy to read from EC2 Compute and manage some actions 4. WSMEUCPolicy to read from AppStream, Directory Services (AD Connectors also) and WorkSpaces services 5. WSMPricingPolicy to access AWS Pricing elements 6. WSMS3Policy to read from the Cost Optimizer Bucket 7. WSMSecretsPolicy to read from Secrets Manager 8. WSMSSMParameterStorePolicy to get data from Systems Manager Parameter Store Here is the JSON snippet for the custom policy **"WSMCloudwatchPolicy"**: {% tabs %} {% tab title="JSON" %} ```json { "Statement": [ { "Action": [ "cloudwatch:DescribeAlarmHistory", "cloudwatch:DescribeAlarmsForMetric", "cloudwatch:DescribeAlarms", "cloudwatch:Describe*", "cloudwatch:GetDashboard", "cloudwatch:GetMetricData", "cloudwatch:GetMetricStatistics", "cloudwatch:GetMetricWidgetImage", "cloudwatch:ListMetrics", "logs:GetLogEvents", "logs:FilterLogEvents", "logs:GetLogGroupFields", "logs:GetQueryResults", "logs:GetLogDelivery", "logs:GetLogRecord", "logs:StartQuery", "logs:StopQuery", "logs:TestMetricFilter" ], "Effect": "Allow", "Resource": "*", "Sid": "VisualEditor0" } ], "Version": "2012-10-17" } ``` {% endtab %} {% endtabs %} This policy grants permissions to interact with **CloudWatch Logs** and **CloudWatch Groups**, allowing the WorkSpaces Manager to record and retrieve necessary metrics and logs. You can apply this policy through your preferred method, whether it's the AWS Management Console, CLI, or automation tools. Here is the JSON snippet for the custom policy **"WSMCostExplorerPolicy"**: {% tabs %} {% tab title="JSON" %} ```json { "Statement": [ { "Action": [ "ce:*" ], "Effect": "Allow", "Resource": "*" } ], "Version": "2012-10-17" } ``` {% endtab %} {% endtabs %} This policy grants the necessary permissions for WorkSpaces Manager to access **Cost Explorer** and retrieve cost and usage data, as well as reservation and savings plan information. You can apply this policy using the AWS Management Console, CLI, or any automation tools like Terraform or CloudFormation. Here is the JSON snippet for the custom policy **"WSMEC2Policy"**: {% tabs %} {% tab title="JSON" %} ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "ReadInfrastructure", "Effect": "Allow", "Action": [ "autoscaling:Describe*", "ec2:Describe*", "elasticloadbalancing:Describe*" ], "Resource": "*" }, { "Sid": "ManageTags", "Effect": "Allow", "Action": [ "ec2:CreateTags", "ec2:DeleteTags" ], "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringEquals": { "ec2:ResourceTag/WSM-Managed": "true" } } }, { "Sid": "PowerControl", "Effect": "Allow", "Action": [ "ec2:StartInstances", "ec2:StopInstances" ], "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringEquals": { "ec2:ResourceTag/WSM-Managed": "true" } } } ] } ``` {% endtab %} {% endtabs %} This policy allows WorkSpaces Manager to manage **EC2** instances, including actions like starting, stopping, rebooting, terminating, and describing instances and tags. You can use this policy in the AWS Management Console, CLI, or automation tools such as Terraform or CloudFormation. Here is the JSON snippet for the custom policy **"WSMEUCPolicy"**: {% tabs %} {% tab title="JSON" %} ```json { "Statement": [ { "Action": [ "appstream:*", "ds:CheckAlias", "ds:CreateAlias", "ds:DescribeDirectories", "workspaces:DescribeWorkspacesPools", "kms:CreateGrant", "kms:Decrypt", "kms:DescribeKey", "kms:Encrypt", "kms:GenerateDataKey*", "kms:ListAliases", "kms:ListKeys", "kms:ReEncrypt*", "rds:DescribeDBInstances", "rds:DescribeEvents", "servicequotas:ListServiceQuotas", "tag:GetResources", "workspaces:*" ], "Effect": "Allow", "Resource": "*", "Sid": "VisualEditor0" } ], "Version": "2012-10-17" } ``` {% endtab %} {% endtabs %} This policy provides WorkSpaces Manager with the permissions needed to interact with **Amazon WorkSpaces**, including describing, creating, terminating, and managing WorkSpaces and their tags. You can apply this policy using the AWS Management Console, CLI, or tools like Terraform or CloudFormation. Here is the JSON snippet for the custom policy **"WSMPricingPolicy"**: {% tabs %} {% tab title="JSON" %} ```json { "Statement": [ { "Action": [ "pricing:*" ], "Effect": "Allow", "Resource": "*" } ], "Version": "2012-10-17" } ``` {% endtab %} {% endtabs %} This policy grants WorkSpaces Manager permission to retrieve pricing information using the **AWS Pricing API**. You can apply this policy using the AWS Management Console, CLI, or automation tools like Terraform or CloudFormation. Here is the JSON snippet for the custom policy **"WSMS3Policy"**: {% tabs %} {% tab title="JSON" %} ```json { "Statement": [ { "Action": [ "s3:GetLifecycleConfiguration", "s3:GetBucketTagging", "s3:GetInventoryConfiguration", "s3:GetObjectVersionTagging", "s3:ListBucketVersions", "s3:GetBucketLogging", "s3:ListBucket", "s3:GetAccelerateConfiguration", "s3:GetBucketPolicy", "s3:GetObjectVersionTorrent", "s3:GetObjectAcl", "s3:GetEncryptionConfiguration", "s3:GetBucketRequestPayment", "s3:GetObjectVersionAcl", "s3:GetObjectTagging", "s3:GetMetricsConfiguration", "s3:GetBucketPublicAccessBlock", "s3:GetBucketPolicyStatus", "s3:ListBucketMultipartUploads", "s3:GetBucketWebsite", "s3:GetBucketVersioning", "s3:GetBucketAcl", "s3:GetBucketNotification", "s3:GetReplicationConfiguration", "s3:ListMultipartUploadParts", "s3:GetObject", "s3:GetObjectTorrent", "s3:GetBucketCORS", "s3:GetAnalyticsConfiguration", "s3:GetObjectVersionForReplication", "s3:GetBucketLocation", "s3:GetObjectVersion" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::workspacescostoptimizer-costoptimizerbucket*/*" ], "Sid": "VisualEditor0" }, { "Action": [ "s3:GetAccountPublicAccessBlock", "s3:ListAllMyBuckets" ], "Effect": "Allow", "Resource": "*", "Sid": "VisualEditor1" } ], "Version": "2012-10-17" } ``` {% endtab %} {% endtabs %} This policy grants WorkSpaces Manager permission to interact with **Amazon S3**, including listing, getting, putting, and deleting objects in the specified S3 bucket. You can apply this policy via the AWS Management Console, CLI, or tools like Terraform or CloudFormation. Here is the JSON snippet for the custom policy **"WSMSecretsPolicy"**: {% tabs %} {% tab title="JSON" %} ```json { "Statement": [ { "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Effect": "Allow", "Resource": "*", "Sid": "VisualEditor0" } ], "Version": "2012-10-17" } ``` {% endtab %} {% endtabs %} This policy grants WorkSpaces Manager permission to retrieve and read secrets stored in **AWS Secrets Manager**, including database connection details and application credentials. This allows sensitive configuration information to be securely managed outside of the EC2 instance rather than being stored locally on the server. You can apply this policy using the AWS Management Console, CLI, or automation tools like Terraform or CloudFormation. Here is the JSON snippet for the custom policy **"WSMSSMParameterStorePolicy"**: {% tabs %} {% tab title="JSON" %} ```json { "Statement": [ { "Action": [ "ssm:PutParameter", "ssm:GetParameter", "ssm:GetParameters", "ssm:DeleteParameter" ], "Effect": "Allow", "Resource": "*", "Sid": "VisualEditor0" } ], "Version": "2012-10-17" } ``` {% endtab %} {% endtabs %} This policy grants WorkSpaces Manager permission to read, create, update, and delete parameters stored in **AWS Systems Manager Parameter Store**. This is used to securely manage application configuration values, operational settings, and integration parameters outside of the EC2 instance configuration for the Load Balancer. You can apply this policy using the AWS Management Console, CLI, or automation tools like Terraform or CloudFormation. JSON templates can also be downloaded from [this repo](https://gitlab.com/nuvens-public/wsmv6-tf/wsm-iam-policies-role/-/tree/main/json?ref_type=heads). # AWS CLI v2 AWS CLI (Command Line Interface) v2 is a powerful tool that allows to manage AWS services from the command line. {% hint style="success" %} Given that WorkSpaces Manager (WSM) runs on Windows, we are not adding specifics for Linux or MacOSX. {% endhint %} Below are the steps to install AWS CLI v2 on WSM (Windows-based) and perform basic troubleshooting to validate credentials and permissions. Use the official [AWS website](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) for information. ## **Step 1: Install AWS CLI v2** 1. From PowerShell, as an elevated user (Administrator), run the `.msi` installer with command: ```powershell msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi ``` 1. Follow the on-screen instructions to complete the installation. 2. Confirm the installation by opening a command prompt and running: ```powershell aws --version ``` The output should display the installed version of AWS CLI.
{% hint style="warning" %} If you don't have **Access keys**, you'll need to create them for some of these commands. To do this, navigate to your IAM user on the AWS console, go to the **Security Credentials** section, scroll down, and create a new set of access keys. Be sure to download and save the file securely, as the secret key will only be visible at the time of creation and cannot be retrieved later from the console. {% endhint %} ## **Step 2: Check AWS CLI configuration** * Run the configuration command to to display the current credentials, ensuring they are set to a type of "iam-role": ``` aws configure list ```
* This command will show: * **Configured credentials** * **Profile** * **Default Region Name** (e.g., `eu-central-1`) Run the configuration command to to display the current credentials, ensuring they are set to a type of "iam-role": * To see the active credentials and their source: ``` aws sts get-caller-identity ``` This command returns the AWS account ID, user/role ARN, and the user/role making the call. ## Step 3: Test Access to AWS Endpoints Run a simple command to verify connectivity to the relevant AWS services: * WorkSpaces: ``` aws workspaces describe-workspaces ```
* Directories: ``` aws ds describe-directories ```
* S3 (if applicable): ``` aws s3 ls ```
If the commands return valid results, your configuration and permissions are correct. ## Step 4: Debugging Permission Issues * If a command fails with a `403 Access Denied` or `You are not authorized to perform this operation` error, verify: * The IAM Policy and Instance Role attached to the EC2 Instance includes the necessary permissions. * The resource (e.g., WorkSpaces or Directories) exists in the configured region. * Use the `--debug` flag to get more details about the API call: ``` aws workspaces describe-workspaces --debug ``` Look for errors such as missing permissions or endpoint issues. ## Step 5: Verify Network Connectivity * Ensure your WSM instance can access AWS endpoints. * Test connectivity to the AWS WorkSpaces Service Endpoints via browser: ``` https://workspaces..amazonaws.com ``` Example: {% embed url="" %}
* If there is a response, even in form of error, we can assume that there is connectivity. * If connectivity fails, check the network settings, such as VPC, security groups, firewall and proxy configuration. # LDAP (Active Directory) Troubleshooting for WSM Active Directory is necessary for Amazon WorkSpaces to manage user authentication, apply security policies, and enable seamless access to corporate resources within a centralized directory. If you're experiencing issues with **LDAP (Active Directory) integration in WorkSpaces Manager (WSM)**, this troubleshooting guide will help you diagnose and resolve common authentication, connectivity, and configuration errors. Follow the steps below to ensure seamless directory synchronization and user access. ## Verify domain connectivity with nltest `nltest` is a command-line tool used to diagnose domain trust relationships, domain controller discovery, and network logon issues in Active Directory. We will verify the domain trust and connection from our WorkSpaces Manager appliance. ``` nltest /dsgetdc: nltest /sc_query: ``` Running the first command retrieves key information about the Active Directory domain by querying a Domain Controller.
The second command verifies the authentication service status.
## Verify domain connectivity with Test-Connection If multiple domain controllers exist, verifying connectivity to each ensures proper reachability and helps determine whether LDAP or LDAPS is being used. ``` Test-NetConnection -ComputerName -Port 389 # For LDAP Test-NetConnection -ComputerName -Port 636 # For LDAPS ``` This command will indicate whether the connection was successful or not.
Keep in mind that one of the LDAP protocols may not be enabled, so an error in one does not necessarily indicate a connectivity issue.
In our example, both LDAP and LDAPS are enabled. ## Install AD Management Tools Active Directory (AD) Management Tools, such as **RSAT-AD-Tools**, provide administrators with the necessary utilities to manage users, groups, and domain services. These tools include **Active Directory Users and Computers (ADUC), ldp.exe**, and PowerShell cmdlets for AD administration. We need to install the AD Tools on Windows Server using PowerShell with the following command: ``` Add-WindowsFeature RSAT-AD-Tools ``` For **Windows 10 or Windows 11**, the AD Tools installation commands differ slightly. Use the following PowerShell commands. List all the tools available: ``` Get-WindowsCapability -Name RSAT* -Online | Select-Object -Property Name, DisplayName, State ``` Install the AD Tools: ``` Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0 ``` Confirm that it is installed: ``` Get-WindowsCapability -Name RSAT* -Online | Select-Object -Property DisplayName, State ```
## **Validate LDAP Search and Authentication** Validating LDAP search and authentication helps ensure that users are located in the correct Organizational Unit (OU) within Active Directory. By running LDAP queries, administrators can identify the default OU where users are stored. To query LDAP objects using PowerShell, we can use the command: ``` Get-ADUser -Filter * -SearchBase "DC=yourdomain,DC=com" ``` This command will list users along with their **DistinguishedName**, which reveals their exact path in Active Directory:
To make a list easier to handle, we can add the following to the previous command. The **DistinguishedName (DN)** indicates the full LDAP path of each user, helping administrators confirm their correct placement within the directory structure. ``` Get-ADUser -Filter * -SearchBase "DC=yourdomain,DC=com" -Property DistinguishedName | Select-Object Name, DistinguishedName ``` ## **Check Service Account Permissions** To ensure WorkSpaces Manager (WSM) functions correctly, the service account used for LDAP authentication must have the necessary permissions in Active Directory. Verify that the account has read and bind permissions to query user objects and organizational units (OUs). You can check this using Active Directory Users and Computers (ADUC) or PowerShell: ``` Get-ADUser -Identity "WSMServiceAccount" -Properties * | Select-Object Name, Enabled, DistinguishedName ```
Here are some additional checks to ensure WorkSpaces Manager (WSM) Service Account can successfully connect to Active Directory (AD): * Ensure the WSM service account has read and bind permissions to query users and OUs in Active Directory. * Verify delegation settings to allow LDAP queries. * Check that the service account is enabled, not locked out, and has the correct group memberships. * Ensure password policies and expiration settings do not interfere with authentication. * Ensure the correct LDAP URL, credentials, and search base are set in WSM. * Check AWS Directory Service logs, Active Directory logs or Windows Event Viewer (Security & Directory Services logs) for failed authentication attempts. ## **Test Kerberos Authentication** **Kerberos** is a secure authentication protocol that uses ticket-based authentication to verify user identities within Active Directory. To test authentication, use the following `klist` command on PowerShell: ``` klist ``` This will display the **Kerberos tickets** for the current session, confirming successful authentication. To clear and renew tickets, use: ``` klist purge ```
## **Verify LDAP integrity with ldp** **LDP.exe** is a graphical **LDAP client tool** provided by Microsoft that allows administrators to connect to, browse, and query Active Directory (AD) and other LDAP directories. It is commonly used to verify LDAP connectivity, test authentication, and troubleshoot directory issues. Key Features of LDP.exe: * Connects to an LDAP server (Domain Controller) over LDAP (port 389) or LDAPS (port 636). * Allows binding to AD using different authentication methods. * Enables browsing and querying Active Directory objects and attributes. * Assists in troubleshooting LDAP authentication and configuration issues. Open **ldp.exe** to test LDAP binding and browsing: 1. Open **Run** (`Win + R`) and type `ldp.exe`. 2. Click **Connection > Connect** and enter the domain controller name or IP. 3. Use the port to connect, like LDAP 389. Click OK
It will show if we have successfully connected or not:
Once a connection is established, the next step is to **bind to LDAP** using the **WSM service account**. 1. Navigate to **Connection > Bind** and enter the **service account credentials**. 2. **Ensure that "Encrypt traffic after bind" is NOT checked**, as this can interfere with authentication if LDAPS is not configured. 3. Click **OK** and verify that the bind is successful without errors.
This confirms that the service account has the correct permissions and can authenticate against LDAP.
Once authenticated in **LDP.exe**, you can test the **Default OU** by following these steps: 1. **Go to** `Browse > Search`. 2. Click **Base DN** and enter the expected OU path (e.g., `OU=Users,DC=yourdomain,DC=com`). 3. Use a **filter query** such as: ``` (objectClass=user) ```
If the user is **not found** during the LDAP search, it may indicate one of the following issues: 1. **Invalid Default OU (Base DN)** * The specified **Base DN** may be incorrect or misspelled. * Verify the correct DN by checking with **Active Directory Users and Computers (ADUC)** or running: ``` dsquery user -name ``` 2. **Default OU (Base DN) Set at the Wrong Level** * The Base DN might be too high or too restrictive, preventing the search from reaching the intended objects. * Ensure that the Base DN **includes the correct organizational unit (OU)**. 3. **Search Timeout** * If the directory contains **many objects**, the query might exceed the time limit. * Increase the timeout settings or refine the search filter to return fewer results. 4. **Insufficient Permissions on Sub-Trees** * The **service account** may lack read permissions on all objects or sub-OUs under the Default OU. * Verify that the account has **read and bind permissions** at the appropriate level. * Use PowerShell to check permissions: ``` Get-Acl "AD:\OU=Users,DC=yourdomain,DC=com" ``` By addressing these potential issues, you can ensure successful LDAP searches and proper user discovery in WSM. 🚀 # RDS Database Options Amazon RDS for SQL Server is a managed relational database service that runs MS-SQL Server in the AWS cloud. It automates common tasks like provisioning, backups, patching, and high availability. WorkSpaces Manager (WSM) requires a SQL Server-compatible database for backend data storage. While the system supports both VM Databases on EC2 and Amazon RDS deployments, using **Amazon RDS for SQL Server** is recommended for most AWS-native deployments due to its ease of setup, automated backups, and managed maintenance features.
Use CaseRDS EditionvCPU/RAMStorageHigh Availability
Small/Medium DeploymentSQL Server Web

2 vCPU

4 GB RAM

20 GBNo
Large DeploymentSQL Server Standard

2 vCPU

4 GB RAM

20+ GBYes (Multi-AZ)
Enterprise EnvironmentsSQL Server Enterprise

2 vCPU

4 GB RAM

20+ GBYes (Multi-AZ)
**Guidance Based on Deployment Size** * **No HA Needed (Development/PoC or Small/Medium Deployments):**\ For smaller environments or proof-of-concept deployments, the **SQL Server Web Edition** with **4 GB RAM and 20 GB of storage** provides stable performance at a low cost. This setup does **not** offer high availability (HA), so it's not suitable for production-critical environments. * **Recommended for Production on Large Deployments:**\ For most production estates, especially those managing a large number of WorkSpaces, it is strongly recommended to use **SQL Server Standard Edition** with **Multi-AZ (HA)** enabled. This ensures database failover and availability in case of an instance or zone failure. * **Enterprise Edition on Large Deployments:**\ WorkSpaces Manager is compatible with **SQL Server Enterprise Edition**, though it is rarely necessary. The Enterprise tier provides features that typically go unused with WSM, making the cost unjustifiable for most customers unless they are already licensed or require Enterprise features for other integrated workloads. **Security & Networking Considerations** * Ensure the **RDS instance is in a private subnet**, with **appropriate security group rules** to allow access only from the WorkSpaces Manager server. * Enable **automatic backups**, **Multi-AZ**, and **encryption** for production environments. * SQL authentication is supported; ensure credentials are securely stored and rotated as per your internal policy. #### Multi-Region RDS Replication for WorkSpaces Manager If an organization spans multiple AWS regions or needs a **disaster recovery (DR)** strategy, **Amazon RDS Read Replicas** can be used to replicate the WorkSpaces Manager database across regions. Amazon RDS supports **cross-region read replicas** for **SQL Server Standard and Enterprise editions only**. This setup creates a **read-only copy** of the primary RDS instance in a different AWS region. Changes made to the primary database are asynchronously replicated to the replica using **SQL Server transactional replication**. For WorkSpaces Manager, this configuration can support: * **Disaster Recovery** (DR) readiness * **Cross-region reporting** * **Read-only dashboards in a secondary region** However, keep in mind that **read replicas are not writable**, and WorkSpaces Manager expects to connect to a **writable** database for core operations. This means replicas are primarily useful for **DR** and **analytics**, not for active-active regional usage. # Backup Backups are essential for WorkSpaces Manager ensuring recovery of configuration data, policies, and operational settings in case of failure or corruption. This also provides disaster recovery. WorkSpaces Manager (WSM) plays a vital role in automating and optimizing the lifecycle of Amazon WorkSpaces. As with any business-critical platform, ensuring a reliable backup and recovery plan is essential. In this blog post, we’ll walk through two supported deployment scenarios of WSM and how to back them up using AWS Backup. We’ll also touch on native mechanisms for Amazon RDS. ## EC2 Instance In the All-in-One or Application-only deployment models, WorkSpaces Manager is hosted on a single EC2 instance that contains the web application, logic, and embedded database (e.g., SQL Server Express). Why Back It Up: * Configuration settings * Workspace lifecycle policies * Local SQL Express database (if not using RDS) * Audit logs and operational metadata # WorkSpaces Manager Administration Guide WorkSpaces Manager provides a full Amazon WorkSpaces management portal. Containing a user self-service and an administration portal in a browser-based environment, without using the AWS Console. WorkSpaces Manager is deployed as an appliance from the AWS Marketplace as an EC2 instance. It can be also deployed as a Packer AMI onto AWS. More information in the Installation section. This guide has been authored by experts at Nuvens to provide information and guidance on using WorkSpaces Manager at full capacity. Product highlights: * WorkSpaces Environment Management with optional application self-service feature for domain group-based application deployment * Task driven User & WorkSpaces provisioning * Multi-AWS Account and multi-region * Forest-wide and Multi-Domain * Automatic reboot schedule defined on a per WorkSpaces basis * Cost reporting and Cost Optimisation * WorkSpaces Performance Monitor Agent to report on Processor, Memory, Disk and connection statistics # Introduction WorkSpaces Manager has three main sections for users and administrators to manage the the Portal: 1. [USER section](/admin/user-section): this is the user self-service portal that allows to manage your own WorkSpaces(s) and execute admin defined basic actions. 2. [ADMIN section](/admin/admin-section): provides an overview of all the WorkSpaces environment, along with an audit of actions carried out by portal admins and recommendations made. 3. [CONFIG section](/admin/configuration-section): to configure the WorkSpaces Manager appliance and add/remove features that users and administrators have permissions too. # USER Section The User self-service portal that allows a user to manage their own WorkSpaces(s) and execute admin defined basic actions. # User Dashboard End-Users can save time and reduce support tickets by accessing the WorkSpaces Manager User Portal. The self-service portal enables users to perform common actions without contacting the Service Desk, such as viewing WorkSpace information, stopping or restarting their WorkSpace, and resolving certain connectivity issues independently. Users can also configure their preferred **WorkSpace reboot hour**, allowing automated maintenance and scheduled reboots to better align with their working patterns and preferences. {% hint style="info" %} The User Portal uses the same URL as the administrator portal but presents a simplified interface tailored to the logged-in user. {% endhint %}
{% hint style="info" %} **User Restore** and **User Rebuild** are only available when these features have been enabled by an administrator. {% endhint %} # Change Password When this option is enabled, and the service account has the necessary permissions in the LDAP Active Directory, users can change their passwords directly within the portal. Password security requirements can be configured in the settings menu to align with corporate standards. Additionally, if enabled, users will receive an email with a link to the WorkSpaces Manager portal 10 days before their password expires. {% hint style="info" %} There are separate reset options for portal and Windows accounts. To reset your Windows password, log in to the portal using the format **domain\user**, then navigate to the "User" section to change your password. {% endhint %}
# ADMIN Section # Admin Dashboard The dashboard provides a unified view of the entire WorkSpaces environment and estate, including real-time health, usage, and activity metrics. The dashboard now features a tabbed interface, separating the main **Admin Dashboard** view from **Event Logs**, which serve as an audit trail of administrative actions and system events.

Admin Dashboard

{% hint style="info" %} The **Admin Dashboard** can be personalised by clicking **Customize**, allowing administrators to choose which **dashboard tiles** are displayed and tailor the dashboard to their requirements. Clicking a **tile** opens the associated **report** or **management page**. All dashboard features are intuitive and are explained throughout this document. {% endhint %} Available Tiles: * [Unhealthy WorkSpaces](/admin/admin-section/insights/unhealthy) * [Healthy WorkSpaces](/admin/admin-section/workspaces-personal) * [Stopped WorkSpaces](/admin/admin-section/insights/stopped) * [Unused WorkSpaces](/admin/admin-section/insights/unused-workspaces) * [Connected Users](/admin/admin-section/workspaces-personal) * Portal Licenses (in percentage of use) * Always On * AutoStop * [Disabled Users Account](/admin/admin-section/insights/disabled-users) * [Orphaned (WorkSpaces)](/admin/admin-section/insights/orphaned-workspaces) * [Available IP's](/admin/resources-section/directories) * Recently Disconnected * API Rate Exception * [Recommendations](/admin/admin-section/insights/recommendations) * Standyby WorkSpaces * [Disk Space Alert](/admin/admin-section/insights/low-disk-space) * [Anomalies Detected](/admin/admin-section/anomaly-detection) * [Quota Limits](/admin/admin-section/insights/service-limits) * [No User Email](/admin/admin-section/insights/no-email) * Hangfire Health * CO Directories (Cost Optimizer) {% hint style="success" %} WorkSpaces Manager has a auto-fix for Amazon WorkSpaces. However, in a very small amount of cases, **AWS Support** will be required to fix these and these will be shown under the **Unhealthy WorkSpaces** tile. {% endhint %} {% hint style="danger" %} When available disk space drops below 10% on the WSM SQL database, a **SQL Disk Space Warning** tile is shown to alert administrators. {% endhint %}

Event Logs

In the Event Logs tab you’ll find a chronological audit trail of key actions performed in WorkSpaces Manager including user logins, WorkSpace updates, system events, and admin activity. Use the search box in the top right corner to quickly locate specific events or filter actions by user just enter a keyword, event type, or username. You can also sort logs from newest to oldest or vice versa using the column sort controls. # Anomaly Detection **Anomaly Detection** automatically identifies unusual behaviour across your WorkSpaces environment by analysing performance metrics and comparing them against historical baselines and similar WorkSpaces. Anomalies are generated when a WorkSpace exhibits behaviour that significantly deviates from normal operating patterns, helping administrators proactively identify performance issues, resource bottlenecks, or potential user-impacting problems. To access **Anomaly Detection**, ensure the **Anomalies Detected** tile is enabled on the [**Admin Dashboard**](/admin/admin-section/admin-dashboard). Click **Customize** and verify the tile is selected. Once enabled, the tile will appear on the dashboard and can be used to access by clicking it.
The Anomaly Detection displays: * **Date (UTC)** – When the anomaly was detected. * **WorkSpace** – The affected WorkSpace. * **User** – The associated user account. * **Metric** – The metric that triggered the anomaly (**CPU**, **RAM**, **Latency**, **Disk**, **Process** or **Startup Time**). * **Observed** – The actual value recorded. * **Score** – The anomaly score calculated by the detection engine. * **Severity** – Indicates the significance of the anomaly (**Low**, **Medium** or **High**). * **Status** – Current anomaly status (**New**, **Acknowledged**, **Suppressed** or **Closed**). Administrators can filter anomalies by **metric**, **severity**, **status**, and **date range** to focus on specific events. {% hint style="warning" %} The actions next to the filters are bulk actiions that apply to all anomalies returned by the current filter. To manage a single anomaly, use the action buttons in the **Actions** column. {% endhint %}
{% hint style="info" %} Hover over an **Observed** value to view the evidence associated with the anomaly. This provides additional information about the specific condition that triggered the alert, such as a high latency or RAM spike {% endhint %} Click **Useful Information** to view detailed information on how anomaly scores and severity levels are calculated, including: * Severity thresholds * Z-Score calculations * P95 Spike detection * Low Disk alerts * Process Spike detection This information helps administrators understand why an anomaly was generated and how the severity was determined.
# User Preferences The Customise button on the right of the page allows the administrator to configure the tiles they would like displayed. Below we have selected to see a few options, but not all. This is highly configurable by the user in question to fit their needs. ![](/files/u0F3MjRZ1C8uG5wAkyAG) The options chosen will be available as tiles in the main [Admin Dashboard](/admin/admin-section/admin-dashboard) explained before: # WorkSpaces Personal The **WorkSpaces Personal** page displays a list of all existing **WorkSpaces** along with key information about each one. The list is **fully searchable**, allowing you to quickly locate WorkSpaces using any of the information displayed in the columns. You can search by attributes such as **Region**, **Computer Name**, **Username**, **WorkSpace ID** and more.
To narrow the **WorkSpaces** table, click **Filter** to open the available **Filter Options**. You can filter by **Account**, **Region**, **Directory**, **Compute Type**, **State**, **Running Mode**, and **Agent**. Multiple values can be selected within the same filter—for example, you can select both **eu-central-1** and **eu-west-1** to display WorkSpaces from both regions. Once you have selected your criteria, click **Apply** to update the results.
You can export the **WorkSpaces** table by clicking **Export CSV**. The following export options are available: * **All WorkSpaces (All Columns)** – Exports all WorkSpaces and every available column. * **All WorkSpaces (Selected Columns)** – Exports all WorkSpaces using only the columns currently displayed. * **Export Search Criteria** – Exports only the WorkSpaces that match the current **search** and **filter** criteria.
From this page, you can perform **bulk actions** by selecting the checkbox next to one or more WorkSpaces and clicking **Process** . This allows administrators to perform common actions, such as **Start**, **Stop**, **Change Running Mode**, and **Terminate**, across multiple WorkSpaces simultaneously.
You can also customise the view by selecting which columns are displayed using the **Columns** customisation option in the top right, which opens a drop-down menu allowing you to enable or disable specific attributes.
{% hint style="info" %} By clicking on a WorkSpace, you’ll be directed to the [WorkSpaces User Tab](/admin/admin-section/workspaces-user-tab), where you can view detailed information and performance metrics, as well as perform a variety of tasks. {% endhint %} You can add **custom columns** in **WorkSpaces Personal** by creating a [**Fixed Tag**](/admin/configuration-section/fixed-tags) with **Fixed Values** enabled. For example, create a tag named **Country**, then add the permitted values (such as UK and USA). Then enable **Display Column** option next to the Tag.
Once the tag has been assigned to a WorkSpace, enable **Dynamic Tags** in **Columns** The custom column will then appear, displaying the assigned tag value for each WorkSpace.
# WorkSpaces User Tab This information can be accessed by selecting a specific WorkSpace in the WorkSpaces section under the Admin tab. This will display a detailed overview of the WorkSpace and its associated user, including metrics such as: * **Client:** Displays the installed **WorkSpaces Client** version. A green indicator shows the client is running the latest supported version, while a yellow indicator shows the client is running an older version and may require an update. * **Volume Encryption:** Displays the encryption status of the WorkSpace volumes, indicating whether the root and user volumes are encrypted. * **Created:** The date the WorkSpace was provisioned. * **Related ARN:** Displays the **WorkSpace ID**, **AWS Account**, and **Region**, allowing the corresponding ARN for the WorkSpace to be derived. * **Billing:** Reflects the effectiveness of cost management. Clicking on this metric will take you directly to the **Cost Optimization Report**, where you can analyze detailed cost data and optimization opportunities. * **Performance:** Represents the operational efficiency of the WorkSpace. Clicking on this metric will take you to the **Underprovisioned WorkSpaces Report**, where you can review WorkSpaces that may require additional resources. You will find essential WorkSpace controls at the bottom of your screen, including icons for **Refresh**, **Stop**, **Reboot**, **Restore**, and **Rebuild**. {% hint style="info" %} Rebuilding vs Restoring Rebuild: Rebuilds the WorkSpace to its original bundle/image, retaining the D:\ drive (or /home in Linux) contents from the last backup, while resetting the C:\ drive (or root / in Linux). Restore: Restores the WorkSpace to the last known good backup (automatically taken by AWS every 12 hours). {% endhint %}
From the dropdown menu at the top right, you will see a list of possible actions, depending on your per * **RDP**: If RDP is enabled in the Configurations > Settings > Remote Services menu, this will download an RDP file with the necessary details to connect to a user’s WorkSpace. {% hint style="danger" %} Note: RDP is not a session that shadows the user. It simply allows administrators to connect to a WorkSpace for support purposes {% endhint %} * **Copy MSRA to Clipboard:** Copies the MRSA key to your clipboard. This key is typically used for authentication, encryption, or secure communication between systems. Once copied, you can paste it into a required field or document for further use, such as establishing a secure connection or verifying a device's identity. {% hint style="warning" %} For proper functionality of MSRA, an SSL certificate must be installed on the WSM appliance. {% endhint %} * **Terminate**: Permanently deletes a WorkSpace, resulting in the loss of all data. * **Schedule Termination**: Schedules a WorkSpace termination at a specified date and time. * **Change Type**: Allows switching to a different instance type (can only be changed every 24 hours). * **Change Mode**: Switches between ALWAYS\_ON and AUTO\_STOP modes. * **Change Volumes**: Increases the size of the C:\ and D:\ volumes (cannot decrease size). * **Change Protocol WSP**: If a WorkSpace was initially created with the PCoIP protocol, the 'Change Protocol' option allows you to switch between PCoIP and Amazon's WSP protocol, with a limit of two switches within 24 hours. The change of protocol will initiate an instant reboot * **Manage Tags**: Adds tags to a WorkSpace. {% hint style="info" %} You can also use [Fixed Tagging](/admin/configuration-section/fixed-tags) to provide consistent tagging on your WorkSpaces. {% endhint %} * **Change Reboot Hour**: If "Auto Reboot" is enabled in Options > Settings, this allows you to set a specific reboot time for individual WorkSpaces. By default, WorkSpaces do not reboot automatically, but this option enables scheduling a reboot at a time that best suits your users. * **Migrate:** to migrate a user from one bundle to another. * **Create Image:** Captures a custom image of the current AWS Workspace. * **Resend Welcome Email:** Resends email that is sent when a WorkSpace is created, contains registration code and link to download WorkSpaces client. {% hint style="info" %} If you prefer not to have your WorkSpace rebooted or rebuilt according to a schedule, you can set a user WorkSpace tag as `NoRebuild = True` and/or `NoReboot = True`. {% endhint %} #### [Other Metrics on the WorkSpaces User Tab](/admin/admin-section/workspaces-personal-metrics) # WorkSpaces Personal Metrics To extend the available metrics beyond those provided by AWS by default, **WorkSpaces Manager Agent** and a **CloudWatch Log Group** are required. When the WSM Agent is installed, additional performance insights become available. Administrators can view CPU and memory usage for a user’s WorkSpace, including **Live Stats** - a feature that provides real-time visibility into CPU, memory, disk I/O and network activity for instant performance monitoring. {% hint style="info" %} The available disk space for both the **root** and **user volumes** is always displayed, regardless of whether the WSM agent is installed. {% endhint %}
{% hint style="info" %} Use the **Statistics Retention Days** setting in the Enterprise section to define how many days statistics from WSM Agent are retained before being automatically cleared. {% endhint %} User activity can be reviewed by selecting the **Activity** tab, which displays session times and dates for the WorkSpace. Selecting Export All allows you to download a CSV containing the complete user activity log for the selected WorkSpace.
The **Startup Metrics** view provides detailed login performance insights, including profile load times, Group Policy processing, and shell readiness, helping to quickly identify login delays. This view also highlights the **Top 5 Highest Processes** exceeding resource usage thresholds. {% hint style="info" %} Selecting a process name opens a detailed history of its resource consumption. {% endhint %}
The **CloudWatch** tab displays Amazon CloudWatch metrics for **Sessions, Bandwidth, Connections, CPU, Memory, and Volumes**. These metrics provide insight into WorkSpace performance, user activity, resource utilisation, and storage consumption, helping administrators monitor and troubleshoot WorkSpaces.
Finally **User Location** displays the approximate geographic location of the user based on their public IP address and shows the estimated distance between the user’s device and the WorkSpace hosting region. This provides a high-level view of where the session originated.
{% hint style="info" %} This feature can be enabled or disabled using the **Enable Geolocation Lookup** toggle in [**Enterprise**](/admin/configuration-section/settings/enterprise) settings. {% endhint %} # WorkSpaces EC2 The **WorkSpaces EC2** tab provides a central view for managing EC2-backed WorkSpaces instances. You can see the instance name, state, AWS region, current user, IP address, compute type, and any configured power schedule. From this page you can also **start**, **stop** and **reboot** EC2 WorkSpaces instances, as well as **synchronise**, **enable**, or **disable schedules** in bulk. The current schedule assigned to each instance is displayed, making it easy to identify when instances are configured to automatically start or stop.
Each instance can also be opened in more detail by clicking its name. This brings you to the **Instance Details** page. Here you can view real time CPU and Memory Utilisation, check the availability of root and user volumes, and access additional metadata such as account ID, availablity zone and public/private IPs. You can also view, add or remove tags as needed.
{% hint style="warning" %} To view real-time metrics the [WSM Performance Monitor agent](https://install.nuvens.cloud/overview/workspaces-performance-monitor-agent) must be installed on the instance. Without the agent data will not be available in the Instance Details view. {% endhint %} You can also adjust scheduling by editing the **EC2 Schedule**, This allows you to define specific working hours (e.g., weekdays 09:00–19:00) to control when instances automatically start and stop. To configure a schedule for an EC2 WorkSpace, click the **Modify Schedule** icon in the **Actions** column for the required instance. Scheduled automation like this helps optimize performance and reduce unnecessary costs by ensuring EC2 instances only run when needed.
# WorkSpaces Pools In **WorkSpaces Pools**, you'll find a overview of the pools in your AWS account displaying information of the usage and cost. You also have a graph showing the active WorkSpace Pool sessions for all the pools. {% hint style="info" %} Selecting a pool takes you to more in-depth metrics and insights for that specific pool. {% endhint %}
Further down the page you will see the **latest logs** for WorkSpace Pools.
**Session Usage** provides insights into usage patterns across daily, hourly, and monthly intervals. It also includes a chart that visualizes the hourly efficiency of session provisioning, helping identify peak usage times and optimization opportunities.
**Active Sessions** will display any connected and not connected users with timestamps of the sessions
**Logs** provides a detailed record of WorkSpaces Pool session activity showing session start and end times, user details, instance information and session duration. Logs can be searched, filtered by by date range up to last 30 days, and exported for reporting or auditing purposes.
# WorkSpaces Pools Metrics Similar to WorkSpaces Personal to access process-level metrics, the **WSM Agent** and a **CloudWatch Log Group** are required. {% hint style="warning" %} The WSM Agent must be installed on the WorkSpaces Pools image. {% endhint %} {% hint style="warning" %} For WorkSpaces Pools, the WSM Agent runs without elevated privileges and must not be deployed via GPO. {% endhint %} The **Session Details** tab displays key information for an individual WorkSpaces Pool session, including the instance ID, computer name, user ID, session uptime, and processor count. This provides a quick overview of the session’s configuration and runtime status.
The **Metrics** tab provides detailed performance insights for the selected WorkSpaces Pool session, including processor and memory utilisation, disk I/O (read and write activity), and network traffic sent and received. It also displays available disk space for both the C: and D: volumes, giving a clear view of session performance and resource usage over time.
The **Activity** tab displays a visual timeline of the WorkSpaces Pool session, showing when the session was active, idle, disconnected, or inactive. It also provides a summary of total connected time (including and excluding idle), idle duration, and session start and end times. Selecting Export All allows you to download a CSV containing the full activity history for the session.
The **Processes** tab displays the top five processes on the WorkSpaces Pool session based on processor and memory usage. For each process, average and peak resource consumption is shown to help identify high-usage applications. Selecting a process opens a detailed history view, allowing you to review processor and memory usage trends over time.
# Secure Browser In Secure Browser you will see a dashboard for **WorkSpaces Web**. It provides an overview of activity and usage including portals, users, active sessions, latest logs, url's visited, total cost in reporting period and user hours in report period.
# WorkSpace Applications The **WorkSpace Applications** tab provides full visibility and control over your active fleets. Using the settings icon on the right you can start, stop, or edit a fleet as well as view active sessions and analyze session usage metrics in real time.
Within **Edit Fleet** view, you can modify key configuration settings such as the instance type and the number of desired instances. This allows you to scale your fleet appropriately based on user demand or performance needs. {% hint style="warning" %} The image, instance type, and maximum user session duration cannot be modified while the fleet is running. To change these settings you must first stop the fleet. {% endhint %}
The **Active Sessions** view allows you to see all currently live sessions across your fleet, including key details such as user, region, session start time, instance type, and connection state.
The **Session Usage** view provides a more detailed overview of your fleet’s performance including session efficiency metrics and monthly usage summaries. This helps identify usage trends, underutilised capacity and opportunities to optimise cost and scheduling.
# Users The **Users** tab displays user attributes from the Active Directory domain. {% hint style="warning" %} Only users with an email address in their attributes are visible, as this is required to provision a WorkSpace. {% endhint %} From the main menu, one action can be performed with the Users: * [Adding a single new user and creating them a WorkSpace](/admin/appendices/how-do-i-create-a-workspace-for-a-user/adding-a-single-new-user-and-creating-them-a-workspace) Additionally, when viewing a user's information and attributes, several other actions can be executed, such as: * [Copy an existing user and create a WorkSpace](/admin/appendices/how-do-i-create-a-workspace-for-a-user/copy-an-existing-user-and-creating-them-a-workspace) * [Create a WorkSpace for a user already in AD](/admin/appendices/how-do-i-create-a-workspace-for-a-user/creating-a-workspace-from-a-user-already-in-active-directory) # Task Queue The **Task Queue** provides administrators with visibility into all background tasks performed by **WorkSpaces Manager**. It allows you to monitor the progress of provisioning, scheduled actions, automated tasks, and completed tasks, helping you track the status of WorkSpace management processes. **All Tasks** displays every task currently known to **WorkSpaces Manager**, regardless of its **status** or **type**, providing a complete overview of provisioning, scheduled operations, terminations, AutoDelete tasks, and other background activities.
**Provisioning** displays WorkSpaces that are currently being provisioned, including the current **status**, **description**, and **next step**, allowing administrators to monitor the progress of new WorkSpace deployments.
**Terminations** displays WorkSpaces that are scheduled for deletion, including the current **status**, **next step**, and the **scheduled termination date**, allowing administrators to monitor the progress of the termination process.
**AutoDelete** displays WorkSpaces that are **scheduled for automatic deletion** based on the **AutoDelete** settings configured under **Configuration > Settings > WorkSpaces (Personal)**.
**Complete** displays tasks that have completed successfully, including the **completed action**, **completion status**, and **completion time**, providing a record of finished tasks.
**Scheduled** displays tasks that are queued to run at a future date or time, such as **scheduled rebuilds**, **reboots**, and other automated operations. It includes the **scheduled execution time**, **queue time**, and the current **task state**.
**Recurring** displays recurring background jobs managed by **Hangfire**, including **Auto-Provisioning**, **Active Directory Synchronisation**, **Anomaly Detection**, **Task Processing**, and other scheduled maintenance tasks. The page shows each job's **schedule**, **last run time**, **next run time**, and **current status.** To run a recurring job immediately, click **Trigger** next to the required task. This allows administrators to manually execute jobs such as **Auto-Provisioning**, **Active Directory Synchronisation**, **Check Tasks**, and other scheduled processes without waiting for the next scheduled run.
{% hint style="info" %} Use **Trigger** to manually execute a recurring background job for testing, troubleshooting, or to force an immediate synchronisation or maintenance task. {% endhint %} # Update The **Update** section allows you to refresh data from various APIs and repositories. You can select specific elements to force an update of their contents. Depending on the size of the estate and the update request, this process may take up to 20 minutes. A success message will be displayed upon completion.
The following elements can be updated: * WorkSpaces * WorkSpaces (Full) * Tags * Orphans * Directories * Check Tags * AutoStop Timeout # Insights On the **Insights** page (previously **Reports)** there are a variety of reports available grouped into four key section for easier navigation to help you understand costs and user behavior within your AWS WorkSpaces estate. {% hint style="info" %} If there is a specific report you would like to see, that doesn’t currently appear in the latest version, please reach out to to see if it is possible. {% endhint %}
The following reports that are currently available are as follows: * [Underprovisioned](/admin/admin-section/insights/underprovisioned) * [Overprovisioned](/admin/admin-section/insights/overprovisioned) * [UnHealthy](/admin/admin-section/insights/unhealthy) * [Stopped](/admin/admin-section/insights/stopped) * [Low Disk Space](/admin/admin-section/insights/low-disk-space) * [No Email](/admin/admin-section/insights/no-email) * [Bundle/Image in Use](/admin/admin-section/insights/bundle-image-in-use) * [WorkSpaces Clients in Use](/admin/admin-section/insights/workspaces-clients-in-use) * [WorkSpace Provisioning](/admin/admin-section/insights/provisioning) * [Hour Since Reboot](/admin/admin-section/insights/hours-since-reboot) * [WorkSpace Service Limits](/admin/admin-section/insights/service-limits) * [WorkSpace User Locations](/admin/admin-section/insights/user-locations) * [WorkSpace Latency](/admin/admin-section/insights/latency) * [High Resource Usage](/admin/admin-section/insights/high-resource-usage) * [Cost Optimization](/admin/admin-section/insights/cost-optimization) * [Cost Summary](/admin/admin-section/insights/cost-summary) * [Recommendations](/admin/admin-section/insights/recommendations) * [Unused WorkSpaces](/admin/admin-section/insights/unused-workspaces) * [Orphaned WorkSpaces](/admin/admin-section/insights/orphaned-workspaces) * [Disabled Users](/admin/admin-section/insights/disabled-users) * User Activity * WorkSpace Tag report * Orphaned Computer Objects # Underprovisioned The **Underprovisioned WorkSpaces** report highlights WorkSpaces that may require an increase in compute type based on performance metrics. This can indicate that the current resources are insufficient for the workloads being run.
# Overprovisioned The **Overprovisioned WorkSpaces** report highlights WorkSpaces that may be operating with more resources than required, based on low CPU and memory utilisation, and could be downsized to a lower compute type.
# Unhealthy The **Unhealthy WorkSpaces** report highlights WorkSpaces that are in an unhealthy state, which may indicate underlying issues affecting performance or availability and require further investigation.
# Stopped The **Stopped WorkSpaces** report displays WorkSpaces that are currently in a stopped state. From this page, you can perform bulk actions on selected WorkSpaces.
{% hint style="info" %} Clicking on a **WorkSpace** opens the [**WorkSpace User tab**](/admin/admin-section/workspaces-user-tab), where you can view detailed information and perform additional actions. {% endhint %} # Low Disk Space The **WorkSpaces with Low Disk Space** report highlights WorkSpaces that are running low on disk space. It shows total and available capacity, along with percentage usage, for both **root** and **user volumes**, helping identify WorkSpaces that may require attention.
# No Email The **WorkSpaces with No Email** report identifies WorkSpaces where the associated user account does not have an email address configured. This report helps administrators locate users who may not receive notifications, alerts, password expiry reminders, or other email-based communications generated by WorkSpaces Manager.
# Bundle/Image In Use The **Bundles in Use** report provides an overview of how many WorkSpaces are using each bundle across AWS accounts and directories configured in WorkSpaces Manager. This helps identify bundle usage and distribution across the environment.
{% hint style="info" %} Clicking on a **Bundle ID** allows you to view the users and WorkSpaces associated with that bundle. {% endhint %}
# WorkSpaces Clients In Use The **WorkSpaces Clients in Use** report provides visibility into the different client versions used by WorkSpaces across AWS accounts and directories configured in WorkSpaces Manager. This helps identify outdated clients and monitor version distribution.
{% hint style="info" %} Clicking on a **Client Version** opens the **Client Version Details** view, showing all WorkSpaces using that version, including details such as **last seen** and **last login** times. {% endhint %}
# Provisioning The **WorkSpace Provisioning Report** displays the number of WorkSpaces created and deleted each day for the selected month. You can navigate between months using the controls in the top right.
The **Raw Data** section provides a detailed view of provisioning activity, including the **WorkSpace ID**, the **action** performed (created or deleted), and the **timestamp** of when the action occurred. # Hours Since Reboot The **Hours Since Last Reboot** report provides visibility into all WorkSpaces and the time elapsed since their last reboot, helping identify WorkSpaces that may require a restart.
# Service Limits The **WorkSpace Service Limits** report provides an overview of service limits and current utilisation for each AWS account and region. It includes limits for different WorkSpace types (such as Standard and Graphics), helping identify capacity usage and potential constraints.
# User Locations The **User Location Report** provides an overview of where WorkSpaces are being accessed globally, showing the number of WorkSpaces per country along with a visual map.
Clicking on a **Country** displays a detailed view of all WorkSpaces in that location, including their approximate geographic distribution shown on the map.
{% hint style="info" %} Within the **User Location** view, clicking on a **Username** will take you to the **WorkSpaces Personal** tab for that user. {% endhint %} The **City Distribution** tab provides a breakdown of WorkSpaces by city, showing the number of WorkSpaces in each location.
# Latency The **Latency Report** provides visibility into latency performance for all WorkSpaces over the last 72 hours, including distance, and minimum, maximum, and average latency values. This helps identify potential performance or connectivity issues.
You can use the **search** function to find specific WorkSpaces, and the **Filter** in the top right to highlight WorkSpaces with latency warnings or define a minimum latency threshold, and filter by AWS account and region. # High Resource Usage The **High Resource Usage** report provides visibility into processes in a directory with high CPU or memory consumption across WorkSpaces, grouped by compute type over the last 7 days. This helps identify resource-intensive applications and potential performance bottlenecks.
Clicking on a **Process Name** opens a detailed breakdown view, displaying usage per WorkSpace, including average and peak CPU and memory metrics.
# Cost Optimization The **Cost Optimization** report shows how efficiently WorkSpaces are being utilised, identifying those that are **Optimized** or **Underused**. It includes estimated costs and potential savings, enabling you to identify opportunities to reduce costs and improve overall efficiency.
{% hint style="info" %} Clicking on a **WorkSpace** opens the [**WorkSpaces User Tab**](/admin/admin-section/workspaces-user-tab), where you can view detailed information and perform additional actions. {% endhint %} # Cost Summary The **Cost Summary** report provides an overview of WorkSpaces costs over time, displaying monthly cost history along with the number of WorkSpaces. {% hint style="info" %} An interactive line graph allows you to click and drag to select a specific date range and focus on that period. {% endhint %}
It also includes cost breakdowns by **Compute Type, Account,** and **Region**, and clicking into any of these will show a more detailed breakdown for deeper analysis.
{% hint style="info" %} Clicking on a WorkSpace ID will take you to the [**WorkSpaces Personal**](/admin/admin-section/workspaces-personal) tab. {% endhint %} # Recommendations The **Recommendations** report provides insights into suggested changes for WorkSpaces based on usage patterns. It highlights the **Current Compute** type alongside the **Recommended Compute** type, helping identify where performance can be improved or costs can be optimised.
The report also includes the **Recommendation Date**, **Alert Count**, and whether an **Auto Change** is pending, allowing you to track and act on recommendations effectively. # Unused WorkSpaces The **Unused WorkSpaces** page shows WorkSpaces that have not been used within a defined number of days. Set the threshold using the **Days** field and click **Update** to refresh the list.
You can filter results using **All**, **Used**, or **Never Used**, and search across all columns. WorkSpaces can be selected individually or in bulk for processing or export. {% hint style="info" %} Selecting a WorkSpace opens the [**WorkSpaces User Tab**](/admin/admin-section/workspaces-user-tab) in a pop-up. {% endhint %} # Orphaned WorkSpaces The **Orphaned WorkSpaces** report shows WorkSpaces that no longer have an associated Active Directory user. These WorkSpaces may no longer be required and can be reviewed for cleanup or termination.
# Disabled Users The **Disabled Users** report shows WorkSpaces where the associated Active Directory user account has been disabled. This helps identify WorkSpaces that may no longer be required and can be reviewed for further action.
# CONFIGURATION Section # Settings This is the main setup page. Key entries have already been populated during installation and initial setup. The top section provides a summary of essential system information, such as the version and licensing details. You can view the WorkSpaces Manager version (including any available updates), the number of licenses procured, the current number of licenses in use, and the license expiry date.
The settings page is divided into the following parts: 1. [Licensing](/admin/configuration-section/settings/licensing) 2. [Enterprise Settings](/admin/configuration-section/settings/enterprise) 3. [Active Directory](/admin/configuration-section/settings/active-directory-single-or-multiple-domains) 4. [WorkSpaces (Personal)](/admin/configuration-section/settings/workspaces-personal) 5. [WorkSpaces (EC2)](/admin/configuration-section/settings/workspaces-ec2) 6. [WorkSpaces (Secure Browser)](/admin/configuration-section/settings/workspaces-secure-browser) 7. [WorkSpaces (Pools)](/admin/configuration-section/settings/workspaces-pools) 8. [WorkSpaces (Applications)](/admin/configuration-section/settings/workspaces-applications) 9. [Amazon Web Services](/admin/configuration-section/settings/amazon-web-services) 10. [Remote Service Account](/admin/configuration-section/settings/remote-service-account) 11. [Email](/admin/configuration-section/settings/email) 12. [Auto Change Compute Type](/admin/configuration-section/settings/auto-change-compute-type) # Licensing In this section you will be able to view your WorkSpaces Manager Licensing information which consists of the following: * Version * Maximum Licenses * Licenses In Use * License Expiry
{% hint style="info" %} If an upgrade is available, an upgrade icon will appear. Follow the [**WSM Update Tool**](/install/upgrade-procedures/upgrade-to-latest-version) instructions to complete the upgrade. {% endhint %} # Enterprise The **Enterprise Settings** section allows administrators to configure how WorkSpaces Manager (WSM) integrates with enterprise authentication providers, Microsoft Entra ID, and self-service capabilities. These settings are divided into four main sections: * [Portal Settings](/admin/configuration-section/settings/enterprise/portal-settings) * [OpenID Connect Settings (SSO)](/admin/configuration-section/settings/enterprise/openid-connect-settings) * [Microsoft Graph (Entra) Settings](/admin/configuration-section/settings/enterprise/microsoft-graph-entra-settings) * [Self Service Settings](/admin/configuration-section/settings/enterprise/self-service-settings) {% hint style="danger" %} It is strongly recommended to create **two separate App Registrations** when integrating Microsoft Entra ID with both OpenID Connect (OIDC) for SSO and Microsoft Graph for group synchronisation. {% endhint %} This is because: * OIDC integrations use **Delegated API Permissions** operate in the context of a signed-in user * Microsoft Graph synchronisation uses **Application API Permissions** allow background server-to-server communication without user interaction Using separate App Registrations improves: * Security separation * Permission governance * Troubleshooting * Security approval workflows * Operational clarity # Portal Settings Portal Settings control how the platform operates, including: * Proxy and network configuration * Scheduling controls * Activity reporting * Audit log display and retention * Session timeout policies * Statistics retention configuration * Litigation Hold monitoring and daily checks * User Geolocation lookup * Diagnostic Reporting {% hint style="info" %} **Enable Sending Diagnostics** is enabled by default and allows WorkSpaces Manager to send anonymised diagnostic metrics to Nuvens. These metrics include numerical counts related to logs, background task issues, directory misconfigurations, and other service anomalies, helping our support team proactively identify and resolve potential issues before they impact users. **No customer data, user data, or WorkSpace content is transmitted.** The feature can be enabled or disabled at any time. {% endhint %}
These settings define the operational behaviour of the WSM platform and provide centralized control for administrative, compliance, and monitoring capabilities. # OpenID Connect Settings The OpenID Connect Settings section allows you to integrate WSM with an OpenID Connect (OIDC) identity provider to enable Single Sign-On (SSO), delivering secure and streamlined user authentication.
Supported providers include: * Microsoft Entra ID (Azure AD) * Okta * Duo * Ping Identity * Other standards-compliant OIDC providers When using Microsoft Entra ID for SSO, the App Registration should use **Delegated API Permissions**. ### Required API Permissions (Delegated)
PermissionType
User.Read.AllDelegated
Group.Read.AllDelegated
These permissions allow WSM to: * Authenticate users * Retrieve user profile information * Read user group membership during login * Apply role and entitlement mappings Typical OIDC configuration includes: * Client ID * Client Secret * Tenant ID / Authority URL * Redirect URI * Scopes * Claims mapping # Microsoft Graph (Entra) Settings The Microsoft Graph (Entra) Settings section allows you to integrate WSM with Microsoft Entra ID using the Microsoft Graph API for directory synchronisation and entitlement validation.
This integration enables the portal to: * Retrieve user and group information * Synchronise Entra ID groups * Validate group memberships * Support automated entitlement workflows * Optionally retire devices from Microsoft Intune The integration authenticates using an Entra-registered application configured with **Application API Permissions**. ### Required API Permissions (Application)
PermissionType
GroupMember.Read.AllApplication
Group.Read.AllApplication
User.Read.AllApplication
Directory.Read.AllApplication
These permissions require: * Tenant-wide Admin Consent * Potential Security Team approval depending on enterprise governance processes ### Important Do not reuse the OIDC App Registration for Microsoft Graph synchronisation. The Graph integration uses: * OAuth2 Client Credentials Flow * Background service authentication * Server-to-server communication and therefore requires **Application permissions**, not Delegated permissions. ### Intune Integration If enabled, WSM can also integrate with Microsoft Intune to support device lifecycle operations such as: * Retire Device This requires: * Additional Microsoft Graph permissions * The relevant checkbox enabled within the WSM configuration ## Verifying Microsoft Graph Connectivity Administrators can validate Microsoft Graph connectivity and group visibility directly from the WSM server. This can be done by: 1. Opening an RDP session to the WSM server 2. Running the PowerShell validation script 3. Validating the returned group membership data WSM also provides an internal validation endpoint: ``` http://localhost/test/FetchAllEntraGroups ``` This endpoint can be used to validate: * Entra ID connectivity * OAuth token acquisition * Group enumeration * Microsoft Graph permissions
### Example Validation Script Copy this content, modify the "Variables" and save it as, per example, "**Get-GraphGroupMembers.ps1**". Run it from a PowerShell session directly on a WorkSpaces Manager appliance:
``` # Variables $TenantId = "" $ClientId = "" $ClientSecret = "" $GroupName = "" # Get OAuth token $Body = @{ client_id = $ClientId scope = "https://graph.microsoft.com/.default" client_secret = $ClientSecret grant_type = "client_credentials" } $TokenResponse = Invoke-RestMethod ` -Method Post ` -Uri "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token" ` -Body $Body ` -ContentType "application/x-www-form-urlencoded" $AccessToken = $TokenResponse.access_token $Headers = @{ Authorization = "Bearer $AccessToken" } # Search group $GroupSearchUri = "https://graph.microsoft.com/v1.0/groups?`$filter=displayName eq '$GroupName'" $GroupResponse = Invoke-RestMethod ` -Method Get ` -Uri $GroupSearchUri ` -Headers $Headers $GroupId = $GroupResponse.value[0].id Write-Host "Group ID: $GroupId" # Get group members $MembersUri = "https://graph.microsoft.com/v1.0/groups/$GroupId/transitiveMembers?`$select=displayName,userPrincipalName,mail" $MembersResponse = Invoke-RestMethod ` -Method Get ` -Uri $MembersUri ` -Headers $Headers $MembersResponse.value | Select-Object displayName,userPrincipalName,mail | Format-Table -AutoSize ``` # Self Service Settings The Self Service section provides configurable options that allow users to manage their own WorkSpaces without requiring administrator intervention.
Available self-service capabilities include: * Password changes * Account restores * Data migration * WorkSpace rebuild operations * User-driven lifecycle actions These capabilities help: * Reduce administrative overhead * Improve operational efficiency * Accelerate end-user support processes * Enhance user autonomy while maintaining governance controls # Active Directory (Single or Multiple Domains) Active Directory is a directory service that supports LDAP (Lightweight Directory Access Protocol), developed by Microsoft for Windows domain networks. {% hint style="info" %} You may need to contact the Active Directory Team or person in charge in order to obtain some of the details to configure this section. {% endhint %} In this section, we must configure the information about the Directory Service and the service account used to execute operations on it. The main part is set during the first setup, asking for the following information: * **Directory ID:** Automatically populated once created. * **NetBios Name:** A shortened version of the domain name, typically up to 15 characters. Example: **CLOUD**. * **Fully Qualified Domain Name (FQDN or DNS Name):** The complete domain name that includes both the hostname and the domain. Example: **NUVENS.CLOUD**. * **Default OU:** The default Organizational Unit (OU) for user accounts in Active Directory, provided in LDAP format using a distinguished name (DN) structure. Example: **DC=nuvens,DC=cloud** or **OU=Sales,DC=nuvens,DC=cloud**. * **Service Account:** A specialized account for running services, applications, or scheduled tasks in an Active Directory Windows environment. It should have the required permissions for WSM to interact with Active Directory and may need to follow corporate naming conventions. Example: **ad.service**. * **Service Password:** Critical for maintaining security, especially since service accounts typically have elevated permissions. * **Cost Optimizer Bucket:** The name of the S3 bucket where the Amazon Cost Optimizer for WorkSpaces management tool stores its data. * **Dry Run Mode:** A feature that simulates potential cost-saving actions without applying them. * **Active Directory Integrated:** Enhances network and management capabilities by leveraging the security and replication benefits of Active Directory integration.
{% hint style="success" %} Once saved, you can test the successful configuration of the directories with the [Resources/Directories](/admin/resources-section/directories) section {% endhint %} **Multi Domains (Active Directory)** On initial setup, and by default, you will be able to add only one domain. However, we can enable multiple domains by enabling the feature below in **Active Directory**. You can see additional guidance [here](/admin/appendices/adding-another-domain).
Once the **Multiple Domains** option for Active Directory has been enabled, additional configuration elements for the Forest can be defined, such as: * **Forest Service Account:** A service account used within the context of an Active Directory forest, which is the top-level structure for managing a group of domains that share a common schema, configuration, and trust relationships. * **Forest Service Password:** This password secures the Forest Service Account, which typically has elevated privileges across multiple domains. The security of this password is crucial due to the account's high-level access within the forest. * **Preferred Domain:** Refers to the primary or most authoritative domain in the forest, typically used for managing resources, services, and administrative tasks across the entire forest. * **Disable Delete Computer Object:** This feature prevents the deletion of computer objects in Active Directory when associated WorkSpaces are deleted, which could otherwise leave orphaned objects in the LDAP directory. * **Disable LDAPS:** This disables LDAP over SSL, preventing encrypted communication if LDAPS is not implemented or enabled in the target domain. When **"Multiple Domains"** is enabled, WorkSpaces Manager displays all available WorkSpaces directories, allowing each directory to be configured independently. This provides greater flexibility in environments where multiple domains, forests, or directory configurations are in use.
The following settings can be configured per directory:
1. **NetBIOS Name:** Specifies the short domain name (e.g., CORP) used by legacy authentication protocols and certain domain join operations. This must match the NetBIOS name configured in Active Directory. 2. **Fully Qualified Domain Name (FQDN):** Defines the domain that WorkSpaces will join (e.g., corp.company.local). This ensures WorkSpaces are associated with the correct Active Directory domain. 3. **Default Organizational Unit (OU):** Specifies the target OU where computer objects will be created, ensuring correct Group Policy application and organisational structure. This is pre populated by WSM and if it does not match the OU configured in AWS it will show up red
4. **Service Account Credentials (Username and Password):** Account used by WorkSpaces Manager to perform domain operations such as joining machines to the domain and deleting computer objects during termination or rebuild. This account must have appropriate delegated permissions in the configured OU. 5. **Cost Optimizer S3 Bucket:** Defines the S3 bucket used to store reports and data generated by the WorkSpaces Cost Optimizer integration. 6. **Cost Optimizer Dry Run Mode:** When enabled, Cost Optimizer evaluates recommended changes (e.g., switching between hourly and monthly billing) but does not apply them automatically. This is useful for validation before enabling automated cost adjustments. 7. **Active Directory Integrated:** Indicates whether the directory is integrated with on-premises or self-managed Active Directory. This setting affects how identity and computer lifecycle operations are handled. 8. **Custom KMS Key:** Specifies a customer-managed AWS KMS key for encrypting WorkSpaces volumes. This allows compliance with internal security or regulatory encryption requirements. See section [Amazon Web Services](/admin/configuration-section/settings/amazon-web-services) to enable the usage of Custom KMS Keys. # WorkSpaces (Personal) In this section, you can configure settings for **WorkSpaces (Personal)** in the WSM interface.
**General Settings** \ *settings that control update frequency and core enablement options.* * **WorkSpaces**: Enable/Disable AWS WorkSpaces. * **WorkSpace Update Frequency:** Automatically update the local database with up-to-date information at regular intervals. To avoid unnecessary API calls it is recommended to set frequency to 90 mins * **Auto Provision:** Enable [Auto-Provisioning](/admin/configuration-section/ap-profiles) of WorkSpaces via Active Directory groups. {% hint style="info" %} Removing a user from the AD group will not terminate the WorkSpace. This functionality can be obtained in conjunction with Auto-Delete {% endhint %} * **Auto Provision Frequency:** Define polling interval for auto-provisioning. This checks the AD groups in your AP profiles at specific time periods. {% hint style="info" %} If it finds a user in an AD group that does not have a WorkSpace, it auto-provisions one for them based on the Auto-Provisioning settings that you have specified. {% endhint %} **Lifecycle Management** \ *automate behavior based on activity, duration, and workspace state.* * **Use Global AutoStop Time:** Sets a global time for auto-stop all the WorkSpaces in this mode. * **AutoStop Timeout:** Set idle time (hours) before WorkSpaces are auto-stopped. * **AutoDelete:** Enable automatic deletion after a defined duration. {% hint style="danger" %} If you do not want the WorkSpace to be automatically deleted, ensure that the **"AutoDelete"** tag is **NOT** applied. {% endhint %} * **AutoDelete Exclude Not Connected:** When enabled WorkSpaces that have never been logged into will not be automatically deleted. * **AutoStop on AutoDelete:** Automatically convert an Always-on WorkSpace to Auto-stop. * **Simulate AutoDelete:** If enabled will simulate a deletion in the service logs. * **Terminate Never Connected Days:** Defines the number of days after which a WorkSpace that has never been connected to will be terminated (when **AutoDelete Excluded Not Connected** is disabled.) **Rebooting & Resiliance** \ *control system rebooting behavior and regional fault tolerance.* * **Auto Reboot:** Enables the Auto Reboot function. * **Unhealthy Reboot:** If enabled, the service checks every 10 minutes for WorkSpaces marked as Unhealthy. If still unhealthy upon recheck, they are rebooted or moved off the hypervisor. * **Auto Reboot Tag Name:** Specify a custom tag name to define the scheduled reboot time for WorkSpaces. For configuration steps, visit [Auto Reboot Setup](/admin/appendices/auto-reboot-setup). {% hint style="success" %} By default Auto Reboot will happen at 3am {% endhint %} * **Multi Region Resiliance:** Only enable this if you have configured Multi Region Resiliance, Associates secondary WorkSpace for primary. * **Remove Standby on Termination:** Determines if standby resources are automatically terminated with the primary WorkSpace. **Identity & Display** \ *customize how user identity is displayed on the WorkSpaces.* * **Display Real Name:** Show real name for user in System. * **Display Username:** Shows the username on WorkSpaces. **Storage & Security** \ *manage volume encryption and resource thresholds.* * **Disable Volume Encryption By Default:** To use non-encrypted volumes by default, enable the option to disable encryption. * **Volume Space Alert Threshold (%):** Alert if root/user volume usage is too high # WorkSpaces (EC2) The **WorkSpaces (EC2)** settings page allows administrators to enable and manage EC2 backed WorkSpaces.
To configure a **WorkSpaces EC2** instance, click on **Add Instance Definitions**. This takes you to the page where you can enter all the required details for your EC2 WorkSpace setup—including: * **Friendly Name** for easy reference * **AWS Instance Type** (e.g., `t3a.xlarge`) * **AWS Account ID** and **AWS Region** * **AMI ID**, **Subnet ID**, and **Security Group ID** * **Key Pair Name** for administrative access * **Volume Size (GB)** and **Encryption** settings * **Domain Join** configuration * **FQDN** and **Target OU** for domain joining (required when Domain Join is enabled) * **Safe Shutdown CPU %** Defines the maximum CPU utilisation allowed for a scheduled shutdown to proceed. If the instance is using more CPU than this value, the shutdown will be delayed by **30 minutes** and the user will receive an **email notification**. * **Shutdown Warning** period (**in minutes**) that users will be notified before a scheduled shutdown occurs. * **Simulate Shutdown** option for testing automated shutdown behaviour
{% hint style="warning" %} To manage an **EC2 Instance** as a WorkSpace, the following tag must be applied: * **Tag Name:** `WSM-Managed` * **Tag Value:** `true` If the tag is not present, the instance will not be discovered or managed by WorkSpaces Manager. {% endhint %} The **Add Schedule Definition** feature allows administrators to define automatic start and stop times for the EC2-based WorkSpaces, helping to optimize cost and resource usage. You can create custom schedules by setting stop and start times for weekdays, Saturday, and Sunday individually. For example, a schedule like "Mon–Fri Stop at 5pm" ensures that EC2 WorkSpaces are shut down at the end of the workday—reducing compute costs without requiring manual intervention.
--- [Next Page](/llms-full.txt/1)