Signoff after disconnect for special Active Directory Group 2days - normal User 2 hours - same Pool - How?

[Michael Modro]

Hi,
at one of my customers, I have the problem that a selected group of users have to run large amounts of data or long import batch jobs on their virtual desktop (dynamic instant clones), so the sign-off has to take place 2 days after the disconnect. 
A separate pool for these users is not conceivable as the resources are fully utilized.
I have set the Log Off After Disconnect for the pool to 2880 minutes.
How can I ensure that I log out all other users who are not in the group in question after 2 hours instead of 2 days?

What I have already tried:

RDP GPOs are only taken into account for terminal servers and not for desktops.

The registry key 
SOFTWARE\Policies\VMware, Inc.\VMware VDM\Agent\Configuration\VDIDisconnectTimeout
which is set with Item-level targeting: Security Group in the user context works, but only after the first login, as the key is only set by policy then.
If I load it into the computer context when starting the desktop, it applies to every user, which should only be replaced for a specific group.

The idea of doing it with a Powershell script from the outside doesn't work either,
because I don't get the user information with the Powershell function Get-HVMachineSummary (from VMware.HV.Helper .psm1) (actually this is intended).

Who has an idea how to solve this?

Best regards

Michael Modro

[Joe Graziano]

Just confirming I understand this. The group of users login to an IC VDI and kick off an Import task that takes 2 days and disconnect from the session.

Then you want that session to be logged off when the import task is complete?

Are you using DEM in your Horizon environment? I wonder if you could setup a powershell script to monitor or keep-alive the session while the import task is running and then stop the keep alive when it's complete and the logoff would be able to complete.

In DEM you can create condition sets for actions like this and assign it to the AD group these users are a part of so that it won't impact the other groups of users.

 

[Sean Massey-1]

So a couple of questions here to understand the use case and ask.

First - how is the pool configured?  Does it have an automatic Log-Off After Disconnect policy configured in the pool settings? 

Second - Why isn't a new pool an option if they're already using the same Instant Clone desktop image for both normal and these long-running sessions?  A new pool using the same image wouldn't create any additional resource utilization if you shrink the regular pool by the number of desktops needed for long running jobs.

[Michael Modro]

On 9/10/2024 at 4:56 PM, Joe Graziano said:

Just confirming I understand this. The group of users login to an IC VDI and kick off an Import task that takes 2 days and disconnect from the session.

 

 

On 9/10/2024 at 5:39 PM, Sean Massey-1 said:

So a couple of questions here to understand the use case and ask.

First - how is the pool configured?  Does it have an automatic Log-Off After Disconnect policy configured in the pool settings? 

Second - Why isn't a new pool an option if they're already using the same Instant Clone desktop image for both normal and these long-running sessions?  A new pool using the same image wouldn't create any additional resource utilization if you shrink the regular pool by the number of desktops needed for long running jobs.

Thanks for your feedbacks. 

Joe, yes, that's right. But we don't know (and don't want it to know) what the customer do in his session. 
The Users in the AD Group need to get the rights for a late signoff after 2 days.
The other default users should be signed off after 2 hours. 
Customer whish.

Now the pool has the Log-Off After Disconnect policy for 2880 Minutes for all.
And this is a problem because of running out of free sessions.
The customer works in shift.

Our pools are defined by performance clases.
The users with the late signoff needs to use VDs in different performance classes so that we would need to split all pools in late and early sign off. This is a overhead for only a couple of users.

Yes, we use DEM in our Environment. But if I change the default  Log-Off After Disconnect policy back to 120 Minutes, how can the DEM give the special AD-Group longer time?

I thougt there must be another way. That the reason for my topic.

 

[Sean Massey-1]

10 hours ago, Michael Modro said:

But we don't know (and don't want it to know) what the customer do in his session. 

So...this is a problem.  As a consultant supporting this environment, you need to understand the use cases and usage patterns.  The details are very important, especially when the use case or usage pattern raises an architectural issue like you're experiencing.  It is hard to provide recommendations or a solution if you don't know why some users need a session that runs for 2 days to complete a process or the impact that is has on operating the environment.

You have to go back to your customer to gather these details.

10 hours ago, Michael Modro said:

The Users in the AD Group need to get the rights for a late signoff after 2 days.
The other default users should be signed off after 2 hours. 
Customer whish.

Now the pool has the Log-Off After Disconnect policy for 2880 Minutes for all.
And this is a problem because of running out of free sessions.
The customer works in shift.

This is going to be hard to do within one pool. But I will provide some options below.

10 hours ago, Michael Modro said:

Our pools are defined by performance clases.
The users with the late signoff needs to use VDs in different performance classes so that we would need to split all pools in late and early sign off. This is a overhead for only a couple of users.

So this is where understanding the customer's use case and the task are really important.  Perhaps this specific task or process could me moved to an RDSH server, automated in some way so it doesn't rely on the desktop, or if none of that is possible, moved into a desktop pool dedicated to this task (ie - users would only log into that desktop to run this specific workflow...or these users would be moved into a pool with different settings so they can run this task without issue).  But without details, you can't provide alternatives.

10 hours ago, Michael Modro said:

Yes, we use DEM in our Environment. But if I change the default  Log-Off After Disconnect policy back to 120 Minutes, how can the DEM give the special AD-Group longer time?

I thougt there must be another way. That the reason for my topic.

You can't extend a session unless the user signs in or remains active.  Once they disconnect, the timer starts, and the only way to stop it is to reconnect.

You might be able to end a disconnected session early using DEM.  I have not tested this, so it's only a concept.  You would need to test this in your lab before presenting it to your customer.  But the idea would be as follows:

1. Set the pool log off after disconnect timer to 2880 minutes (which you've already done)

2. Set up a policy in DEM to run a Task on Disconnect for users who are not in the group of AD Users who the longer sessions.  This task would enable a scheduled task to log out the user after 2 hours from when the task runs.  This would have to be done with a PowerShell script that would modify and enable a scheduled task.

3. Set up a policy in DEM to run a Task on Reconnect for users who are in the AD user group to disable the scheduled task if they reconnect to their session.  This would prevent the scheduled task from running and logging them out if they rejoin their session.

Another option would be to use the Horizon REST API to get all the disconnected sessions that are over 2 hours old, check each session's users against the group of users who need longer sessions, and log out those that do not. This is probably the option I would recommend because it doesn't rely on multiple steps inside of a desktop, but it would require you or the customer to write the tool to do this.  I'm not aware of any application or tool that does this today.

Edited Thursday at 04:22 PM by Sean Massey-1