This Article was prepared on the 19th August 2019.
This article attempts to expand upon the OS level tweaks that are required in order to fulfill all the requirements set out by AWS in the article below:
The AWS article is quite clear on what is required on the AWS side, but it may not be clear what’s required on the Windows 10 image side. Hopefully this will help you quickly get your Windows 10 image ready to upload to AWS.
The Supported Editions – Important
Before you begin, ensure that you understand that at the time of writing (19th August 2019), the most recent Windows 10 release is NOT SUPPORTED – Whilst I am told it will “work”, you will not be able gain official support if you do encounter any problems. Stick with the supported builds.
As stated by the article, the VM must run one of the following Windows versions:
Windows 10 Version 1607 (Anniversary Update)
Windows 10 Version 1703 (Creators Update)
Windows 10 Version 1709 (Fall Creators Update)
Windows 10 Version 1803 (April 2018 Update)
Windows 10 Version 1809 (October 2018 Update)
Graphics and GraphicsPro Workplace bundles currently do not support Windows 10 Version 1809 (October 2018 Update) with BYOL.
The Requirements – The checker
To help ensure the build is ready, a checker is available from here:
NOTE: If you have concerns clicking on a random link, this link is provided via the previous linked document over at AWS. It is left here as a convenience. This link was current as at 19/08/2019.
The following “tests” need to pass inorder for a build to function correctly as a workspace image:
|OS is 64 Bit||Windows 10 is 64 bit|
|AutoLogon is disabled||Disabled by Default|
|Automount is enabled||Enabled by default|
|Antivirus is not installed||Windows Defender doesn’t affect this test|
|System is not Azure domain joined||Do not join an image to a domain|
|DHCP is enabled on network interface||DHCP is enabled on most VM platforms|
|Windows Update is disabled||To satisfy this requirement, do not set this via registry, simply disable the Windows Update service AND set the “Windows Modules Installer” service to manual. The checker will automatically fix this if required.|
|System is not AD domain joined||Do not join an image to a domain|
|Attached C: disk is smaller than 80 GB||Potentially to do with MaxUploadParts = 10000 ?|
|Windows Firewall is disabled||The checker will automatically fix this if required.|
|More than 10GB of free space on C: drive|
|MBR Partitioned volumes||Cannot use GPT volumes (which means only Generation 1 Hyper-V builds can be used)|
|Image is not in-place upgraded||An image should be from a fresh install|
|Only local disks are attached||Remove all removable drives including floppies|
|Single bootable partition|
|Supported Windows Operating system||See the list of supported editions|
|PCoIP Agent is not installed|
|No pending system reboot|
|PowerShell version installed is 4.0 or higher||All editions of Windows 10 should have at least Powershell 5.0 or higher|
|RealTimeISUniversal registry key is enabled||Registry setting under HKLM\System\CurrentControlSet\Control\TimeZoneInformation The checker will automatically fix this if required.|
|Rearm count is 0||Do not use a trial edition of Windows that has been reset.|
|VMWare Tools not installed||Remove the VMWare Tools if the image is built under VMWare|
|WorkSpaces_BYOL account is enabled||Advised to create the first local account on the image as this account|
|WorkSpaces_BYOL account exists||Advised to create the first local account on the image as this account|
You must make sure you meet the requirements outlined in the article; this includes:
- Your Microsoft licensing agreement allows Windows to be run in a virtual hosted environment.
- You will use a minimum of 200 Amazon WorkSpaces. This is a requirement for running your Amazon WorkSpaces on dedicated hardware. Running your Amazon WorkSpaces on dedicated hardware is necessary to comply with Microsoft licensing requirements.
- If you plan to use GPU-enabled (Graphics and Graphics Pro) bundles, verify that you will run a minimum of 4 AlwaysOn or 20 AutoStop GPU-enabled WorkSpaces in a Region per month on dedicated hardware.
- The Windows operating system image must be activated against your key management servers.
- Activate the licence of image with your local KMS servers. This may require manually setting the DNS suffix of the image to your relevant DNS suffix in order to reach relevant KMS services.
The Build – General Guidelines
With regards to the image, the following recommendations have been made:
- Keep customizations to a minimum
- Do not join an image to a Windows Domain
- It is recommended that a local user be created with the name of “Workspaces_BYOL” with Local Admin rights.This password may be needed in future.
- Upon completion of build, all removable drives must be removed – this includes floppy disk drives.
- Whilst building the image, leave the network interface disconnected to avoid triggering Windows updates.
- If using Hyper-V do not build using Generation 2 as all volumes must be MBR partitioned.
- Do not Sysprep this image natively – run the checker and allow press the “sysprep” button only when the build passes all checks.
With regards to the image, the following regular build items will generate a warning condition when running the checker tool that the tool can correct if required:
- The Windows Firewall must be disabled prior to uploading the image to AWS
- Windows Updates must be disabled
- RealTimeIsUniversal registry key needs to be enabled
The Windows Firewall – post build
It is reasonable to expect that in most organisations, GPOs have normally been instantiated in order to restrict connectivity in and out of workstations via the Windows Firewall.
For a full list of ports required for Workspaces take a look at this article:
Once the image has been uploaded and is ready for build, each Workspace will feature a regular production network interface along with a management interface. In order to ensure a stable workspace build, ensure that the following ports are enabled inbound on the management interface port:
- Inbound TCP on port 4172. This is used for establishment of the streaming connection.
- Inbound UDP on port 4172. This is used for streaming user input.
- Inbound TCP on port 8200. This is used for management and configuration of the WorkSpace.
NOTE: If there are plans to utilse the web client TCP port 4489 will also need to be enabled.
In most organisations, the inbound ports are restricted and typically outbound is unrestricted. However; in organisations that have blocked outbound, the following ports will need to be opened outbound:
- Outbound UDP on ports 50002 and 55002. This is used for PCoIP streaming. If your firewall uses stateful filtering, the ephemeral ports 50002 and 55002 are automatically opened to allow return communication. If your firewall uses stateless filtering, you need to open ephemeral ports 49152 – 65535 to allow return communication.
- Outbound TCP on port 80 to IP address 169.254.169.254 for access to the EC2 metadata service. Any HTTP proxy assigned to your WorkSpaces must also exclude 169.254.169.254.
- Outbound TCP on port 1688 to IP addresses 169.254.169.250 and 169.254.169.251 to allow access to Microsoft KMS for Windows and Office activation.
Note: If the Web Client is being used, 8443, 9997 TCP and 3478, 4172 UDP need to be open outbound.
The Logon Banner Message
Many organisations implement a LegalNoticeCaption and LegalNoticeText via GPO fairly high up in their OU structure. Once these are defined, it can be quite awkward to “disable” them. There is a requirement to not show this for AWS workspaces builds. The good news is that simply defining those policy elements blank (with no value) is sufficient to meet the requirements here.