Two business units use separate workspaces. You published a RemoteApp application group (AppGroupA) from a pooled host pool and registered it to Workspace1. You must make the same published applications appear in Workspace2 without adding more session hosts and with minimal administrative overhead. What should you do?

Creating a second RemoteApp application group in the same host pool with the same published applications and registering it to Workspace2 is the correct solution. Application groups are workspace-specific. To publish the same applications to a different workspace, you need a separate application group for that workspace. This method reuses the existing session hosts, avoiding additional infrastructure costs, and minimizes administrative overhead as you're simply creating another application group linked to the same resources. Registering AppGroupA to both Workspace1 and Workspace2 is incorrect because an application group can only be registered to a single workspace at a time. Moving AppGroupA back and forth on a schedule is impractical and would cause service disruption. Creating a second host pool is unnecessary as the existing session hosts can serve both workspaces, and it would incur additional costs and management overhead.