One of the things that I like to do in my AppSense configurations is use an "Enabler" node at the top of each trigger. For instance, in the Logon trigger, the very first node queries an Active Directory group to see if the user is a member. If they are not a member, then processing is stopped. This is a very efficient way of ensuring that AppSense processing only occurs on the users that you want it to.
However, I also wanted to do the same thing in the Startup trigger, to ensure that only the correct devices process the AppSense configurations. Whilst this may seem a little pointless - after all, devices will only process the configuration if the agents are installed on the endpoint - what I was after was an easy way to "turn off" AppSense execution on the endpoint for troubleshooting purposes, without having to change Deployment Groups and/or remove or reinstall configurations. The best way I figured was to check for Computer Group membership at the start of the Startup trigger, and only process the configuration if the device was not in the "exemption" Active Directory Computer Group.
Unfortunately, I was a bit confused to find that the Computer Group Condition I set up simply didn't seem to work at all.
After a bit of thought an idea occurred to me as to why, perhaps, it wasn't working. When you set up a User Group Condition, you get the "LSA Supported" suffix on the Condition as shown below. This indicates that the security group membership has been "cached" locally, if you like, and there isn't a need for EM to query Active Directory to verify it. I guess it's kind of like using the user's security token - and it naturally saves valuable time.
Now, what I did notice, is that for the Computer Group Condition, there is no "LSA Supported" suffix.
Does this indicate that for a Computer Group query, EM has to contact Active Directory? If that's true, then it would tell us why the query isn't working...because in the Startup trigger, there's a good chance that the network hasn't initialized yet and the AD lookup can't be completed.
One quick call to AppSense support later, and confirmation is provided - a Computer Group Condition has to contact AD to complete successfully. Incidentally, the Site Membership and Computer OU Conditions suffer from exactly the same issue. This is a bit annoying - especially seeing as at every reboot, like a user, the computer will actually pick up and maintain a local security token that contains the details of the AD groups that the machine account is a member of. Apparently in future the functionality to query the computer security token (or similar) will be added to allow Computer Group Conditions to process without contacting a domain controller - but at the moment, we're looking for a workaround.
What utilities are there available that can tell us what groups a computer account is a member of without requiring network connectivity? Offhand, the one that sprung immediately to mind was gpresult. Can we call gpresult from within Environment Manager - preferably from PowerShell - and output the target group?
I must again make apologies for the rudimentary nature of my PowerShell skills - any suggestions for cleanup or optimization are gratefully accepted. But anyway...this is the PowerShell I came up with. Don't forget we are trying to check whether the machine is not a member of the specified Computer Group, so that's why the return code is 1 if the check for the group name succeeds.
# Query computer security token for specific group membership
$result = (GPRESULT /R /SCOPE COMPUTER | Select-String -pattern "App AppSense Device Exemption Group" -list).line
$result1 = $result -replace " ",""
if($result1 -eq "App AppSense Device Exemption Group")
{
exit 1
}
else
else
{
exit 0
}
We have saved this as a Reusable Condition, so we can call it whenever we want. It appears to need to run as System to work correctly.
Now, there is a small problem with this. Users update their security tokens at logon time when they are authenticated by a DC. Machines update them at boot time, when they establish a connection to the domain controller. But we already know that the Startup trigger is processed before AD connectivity is available. If I was to add a machine to the exemption group in AD, and then restart it, the security token would still be showing the old group memberships. I would have to restart the system twice - once to pick up the new security token, and the second time to actually process it in the Startup trigger. This isn't very workable, so is there any way around this problem?
Well, there is an executable called klist.exe that is available on 2008 R2 and Windows 7 (and up, hopefully) that can actually refresh a system's tokens without rebooting. If you're intending to use earlier Windows server or client versions with this trick, you might need to pay attention to this article - http://sdmsoftware.com/general-stuff/picking-up-computer-group-membership-changes-without-a-reboot/. As we are working on a XenApp 6/Windows 7 platform, we can use this without any jiggery-pokery being required.
The key is to specify the logon ID so that the tokens for the System account are refreshed. We are going to call this as an Execute Action from the Shutdown trigger - so if a computer is added to a new AD Computer Group, when it begins to restart, it will refresh the tokens so that it is already updated by the time the Startup trigger is executed, and there will be no need to have AD connectivity.
The -li 0x3e7 switch specifies the System account. However, I'm wondering if the Run As tab in the Execute Action is set to System, whether this switch may be unnecessary and purge may be the only parameter that is required?
Anyway, once we've added this to the Shutdown trigger - hey presto! I added the computer account to the "exemption" group in AD, rebooted it once - and the AppSense configuration was not processed at all. Success!
There is one caveat to this, though - this isn't going to work on PVS systems. The computer security token will always be identical to the one present when the image was sealed - therefore with PVS (or similar) systems, there won't be any way to update it without contacting Active Directory. Even multiple restarts won't cut it, because it will reset to the master image at each reboot. I suppose you could try and redirect the security token onto a persistent drive - but I'm not going down that route, the possibilities for totally trashing the operating system seem way too likely!
But if you simply need to be able to query Computer Groups in the Startup trigger in a conventional environment (or maybe just on your physical endpoints, rather than SBC or VDI which may be using PVS images), this little trick should certainly allow you to do it.
Update #1 - thinking about it, you probably could do this on a PVS system, but it's an almighty fudge. You would have to set a User | Logon Action to query the Computer Group (using the native Condition, not the PowerShell we used here), and if successful, write some sort of flag file to the persistent disk. But obviously the problem is that if the membership was changed you would have to restart the system and then also get a user to log in, before the change was reflected in your flag file. This is probably hopelessly inefficient for the purpose I had here.
Update #2 - as pointed out by fellow ACA Aaron Parker, this highlights the fact that Environment Manager is, in current guise, primarily a USER environment management tool rather than device management. I totally agree - and whilst I would love to see EM positioned a bit better as a device management tool, because the Conditions give it so much power - right at this moment, there are better ways you can achieve management of your device environment. Hopefully it may change in the future!
Update #1 - thinking about it, you probably could do this on a PVS system, but it's an almighty fudge. You would have to set a User | Logon Action to query the Computer Group (using the native Condition, not the PowerShell we used here), and if successful, write some sort of flag file to the persistent disk. But obviously the problem is that if the membership was changed you would have to restart the system and then also get a user to log in, before the change was reflected in your flag file. This is probably hopelessly inefficient for the purpose I had here.
Update #2 - as pointed out by fellow ACA Aaron Parker, this highlights the fact that Environment Manager is, in current guise, primarily a USER environment management tool rather than device management. I totally agree - and whilst I would love to see EM positioned a bit better as a device management tool, because the Conditions give it so much power - right at this moment, there are better ways you can achieve management of your device environment. Hopefully it may change in the future!