The case of Persistent, SessionHost assignment remains even if the user is unassigned from AppGroup.

[kyohei_]

Is this in the specifications?

Here is what I tried:

1). Created HostPool as a personal type (persitent is true). 

2). After signing in as a user, that user was assigned to the session host. 

3). Unassigned the user from AppGroup.

4). Failed to connect as another user.

5). Checked the session host properties, the previous user was still assigned.

[#2 · Accepted solution]

@kyohei_ : Yes, this behavior is by design, in two ways:

1. The removal of the user from the app group does not remove the session host assignment.

2. Through the cmdlets, you can't simply re-assign a session host to a different user. We view this as tight security, since a user likely had local data on the VM (as opposed to the pooled scenario where that user's profile was on a user profile share).

To re-assign that session host, you need to completely remove it from the environment, then re-register the host.

[#3]

@Christian_Montoya 

Hi Christian, with regards to the statement below, could you give more information on the correct steps to complete this for this for a direct assignment on a 'personal session host'.

"To re-assign that session host, you need to completely remove it from the environment, then re-register the host."

[#4]

@HandA : Sure. So essentially, you would need to remove the session host and then get new registration info for the host pool so you can re-add it.

Remove-RdsSessionHost -TenantName <tenantName> -HostPoolName <hostPoolName> -Name <fullSessionHostComputerName>

$token = New-RdsRegistrationInfo -TenantName <tenantName> -HostPoolName <hostPoolName>

$token.Token

 Then, go to the VM and uninstall all of the agents in the installed programs. Likely, you'll want to re-start the computer. Then, follow the steps here to re-install the agents with that Registration Token, using the steps here: https://docs.microsoft.com/azure/virtual-desktop/create-host-pools-powershell#register-the-virtual-m... .

[#5]

@Christian_MontoyaOnce again, thanks Christian. A great help!