This content has been marked as final. Show 4 replies
One temporary solution you can use while deciding however is to remove the bindings from the user key (Properties > Bindings > Remove the two that are there). This means when the connector next runs it wont pull those keys back to the original group.
We raised a call with McAfee support about this awhile back but the call got closed as I couldn't provide enough information (I was unable to provide a screenshot of a key being moved....). In the end we created what you suggested; a new group with a new connector but Im relatively sure that there is an easier way. Im also relatively sure that this problem only started happening recently as I dont recall having keys being moved like this at the beginning of this year. happy
I'm currently doing this with technician groups so that techs at each site are automatically placed into a group in MEE that can only manage their devices.
I setup each of the groups in the connector's "Search groups" list to find the users. Then under "Group mappings" I've mapped each of the gouips to a tech group in MEE based on the users' "memberof" attribute.
if you use the connector, you need to get the connector to do any moves in the EEM for you - otherwise the connector will keep putting users back where IT thinks they should be (as you found).
by clearing the bindings, you are disconnecting the user from their AD counterpart - that may be ok, but remember, if you disable/delete them in AD now, that won't affect their EEM counterpart.
Best to change the group mapping rules in your connector to move users into groups based on their AD profile, rather than trying to fudge things.
Group mappings definitely proved the best option for us based upon the 'Directory' attribute of the user AD profile.
It works a treat and means we only need to manage the one AD group, we've tidied user AD profiles where the department data was missing or incorrect and it all runs through the one connector too.
These changes also helped identify SafeBoot user accounts that were troublesome, i.e. passwords not updating the same as the users network password, and we also isolated these as being accounts that were created manually rather than automated through the connector.
The big issue we had as a result and something for other to be aware of, is despite creating our new user containers and adding these in as allowed to logon to our single group of laptops (thinking the changes would be seamless).... when user accounts were moved to their new container they were removed from the machine by the client and the machines kept locking up until we could force another sync to see the user account put back on.
Worst case scenario were users who rebooted and we had to give out our technical support user account details to get them back on (done remotely) and change this password at a later date. Maybe this was because the original single user group was also still granted access to the machines, it looked at this group and removed the account because it was not there, then next sync it saw the new group and re-added the account.