No Resource for Personal Session Desktops feature of Server 2016

[JimPriestley]

There is no resource for enabling the new Personal Session Desktops feature of Server 2016.

http://social.technet.microsoft.com/wiki/contents/articles/31780.windows-server-2016-remote-desktop-services-introducing-personal-session-desktops.aspx

I plan to begin work on creating this resource within the xRemoteDesktopSessionHost module.

I plan to implement all the features in the above documentation link.

[JimPriestley]

Because the Remote Desktop Personal Session feature is an extension of New-RDSessionCollection, but has a requirement for OS version >= 10, I plan to implement it as a new resource, rather than as additional properties on the existing xRemoteDesktopSessionCollection resource, so that I do not break backwards compatibility in that resource. I feel this will be a cleaner implementation, than testing the parameters in the Set-Target function, and throwing an exception there.

I am open to feedback on this though. @TravisEz13, looks like you contributed the original, what do you think?

[TravisEz13]

@JimPriestley Could you include your proposed schema?

[JimPriestley]

@TravisEz13 Here is the proposed schema for MSFT_xRDPersonalSessionDesktop

[key, Description("Specifies a name for the session collection. ")] string CollectionName;
[key, Description("Specifies an RD Session Host server to include in the session collection. ")] string SessionHost;
[write, Description("Specifies a description for the collection.")] string CollectionDescription;
[write, Description("Specifies the Remote Desktop Connection Broker (RD Connection Broker) server for a Remote Desktop deployment.")] string ConnectionBroker;
[write, Description("Specifies whether to grant local administrative privledge")] bool GrantAdministrativePrivilege;
[write, Description("Specifies whether to auto assign user to an available session host")] bool AutoAssignUser;

[TravisEz13]

Is there really a need to configure remote hosts (ie SessionHost)? With this property, you could have multiple LCMs trying to configure the same host.

[JimPriestley]

Good point, we could restrict it to use the local host by default, implying that this would need to be applied exclusively on the session host machines. In that case, I believe the connection broker parameter would become mandatory, as it would be required in any deployment of more than one server.

I'm envisioning a scenario where a farm of hosts is deployed in Azure through an automation process, that assigns it as personal session host, and optionally assigns a user.

I was conflicted on this, as the next resource I intended to implement would be user/host assignment, to the sessionhosts.

In the feature documentation, they run this command on the connection broker, assigning users to the session hosts.

In practice, do you think it would be better to spread the user host assignment out on to each session host as part of it's individual config, or pass it in as a hash table only on the connection broker?

I was leaning towards the connection broker, as then it would only be one hash table in the config source. My thought is an admin could release a change to the config hashtable, and then only the connection broker's dsc has to refresh to update the assignment list.

In a full automation scenario, this enables me to delete the session host with out having to wait for it to update it's config, to unassign the user.

Of course the automation process could just execute the un-assignment against the connection broker, while deleting the VM, but I was looking to keep all of the configuration and assignment in DSC, and only do the infrastructure management directly from an automation script.

[TravisEz13]

I lean to the per host assignment. The hashtable should the configuration data passed into the configuration, then have a configuration for each host. Most, but not all, resource that I see that allow configuring remote hosts don't have a good reason to allow it.

We need to keep in mind that DSC at the core is supposed to declare the state. When you start declaring the state of something remote, there is no real assurance that it is in that state. If the remote resource has LCM, it is better to create a resource, then declare that you are dependant on the remote resource instance in your local configuration.

I've seen cases where this isn't possible with resources for services that lack a master node (or conceptually equivalent.) I'm not seeing that here (but I'm relying on your explanation.)

[JimPriestley]

Makes sense. The ConnectionBroker is the master node in this scenario, and I will rework it so that this resource is to be applied locally on the session host LCM it is applied to, exclusively.

[johlju]

@JimPriestley this issues is labeled as in progress. I relabel this as help wanted. If you still work on this, then let me know and I relabel it again. Thanks!