I've noticed this behaviour with VSE 8.5i, and 8.7i and curious about the behaviour. It doesn't sound right - but seems to either be "by design" or a bug that has lasted a very long time. Not really sure if it's an CMA issue or a VSE issue - I'm assuming the latter.
On an EPO Managed desktop, with VSE 8.7i/8.5i installed (and various CMA agents), I have a policy through EPO (User Interface Properties) to enforce "Tools/User Interface Options/Password Options/Password protection for conformance to Common Criteria" and a password set. This locks the VSE client and stops end users mucking around with settings.
If I unlock a console on a desktop using the password, then I can modify settings etc. At CMA policy enforcement time, the settings that I have modified are returned to their default settings - but the console is still unlocked.
If however, while the console is unlocked, I modify the "Password Options" to "no password", then when policy enforcement occurs, the console is locked again and the setting reverted to "Password protection for conformance to Common Criteria". If I change that setting to "Password protection for all items listed" or "Password protection for all selected items" and then force a policy enforcement, the console remains unlocked.
I would assume that the expected behaviour during policy enforcement would be to lock the Console again.
Do others replicate this too? Known issue? By Design? Bug?
Solved! Go to Solution.
The KB article says "The console should be locked after a policy enforcement." but on my machines the console remains unlocked (like in KB58116), i always need to lock the console via user interface.
The article says it should be locked because that is what it should do by design. McAfee are investigating why this does not happen and hope to provide a fix for this as soon as possible. In the mean while, please use the workaround. The article will be updated as soon as a fix becomes available.