That is only one user log info. What about other users. Do you see many "...updating user state." or similar?
Normally you should get "...No changes needed." after each static user.
1676 of the entries look like this:
01/22/2010 02:06:07 PM Checking Endpoint Encryption User CLingus
01/22/2010 02:06:07 PM ...updating user information fields
We sync only two user info fields: Display Name, which changes very rarely, and Employee ID number, which never chnages
Then that might be it. I suspect, if you have non-blank entries in "User mapping" tab, you might be always getting that message (and counted towards updated).
Regardless if it was recently changed or not. Did you find information on 3 other accounts that do not update user information fields?
You nailed it. Without any mod to conn settings, the three accounts that didn't change were all non-AD accounts: admin and two $autoboot$ accounts. I whacked all the settings in User Mappings tab and then when sync runs I get :
01/23/2010 09:34:16 AM checked 1680 users (0 updated)
The advantage to removing them is that the connector sync runs ~60% faster. The downside is pretty obvious--the AD user info isn't synched if it's updated or a new account is added. Guess I don't understand why the connector would still need to update all those fields if the uSNChanged value hasn't incremented.
I discovered that removing all the entries in the connector User Mapping doesn't remove any existing values in users that had already had the info synched into the matching EE user account. To get the best of both worlds I created two identical connectors: one without the user data mappings set that runs frequently so new EE accounts are added soon after addition to AD and one with the user data mappings set that runs twice a day to update those values in the accounts. I suppose I could script something to mod the appropriate lines in CmSettings.xml periodically so that only one connector would be needed. I won't though for fear it's "unsupported".
Yet more admin effort required to work around app limitations, and more moving parts which could fail. Sort of what I've come to expect unfortunately. Arrgghhh!! As always, thanks Peter.
1 of 1 people found this helpful
I would NOT create two separete connectors for the same users. Reason is: bindings. Bindings are critical to be pinned to only one connector name. Otherwise you can get odd results when managing those users. Why do you need User Mapping info anyways? We considered any additional info obtainable from pre-boot as insecure, therefore we do not put anything there.
Good point. I'll try my XML mod idea using a separate connector on a separate set of non-production users and see how it works out.
All info fields are set to "Hidden". It's there for the convenience of admins, and when helpdesk recoveries are performed it's used to do light identity verification without having to lookup the info elsewhere. In this context it enhances security. If the info is inconvenient to get to helpdesk staff will more often than not simply skip the verification. They're under the gun to resolve issues and close tickets. Anything that slows them down, even if it's only 20 seconds, falls by the wayside.
Unfortunately, we have to sync with AD frequently. We have 40,000 employees across 6 time zones running 24/7 operations. We don't have a lot of laptops but when one is allocated our desktop team needs all of 30 minutes to have it ready to ship. They already complain about once hourly syncs. They want to know the new user's EE account is synched to the machine DB before it leaves the shop. As a security guy I do too: laptops have disappeared in transit and most have some end-user data preloaded for convenience--we need it encrypted with pre-boot auth active before handing to the carrier. We want the new user's account on the machine so they can boot it and start the OS as soon as they receive it.
Update: my XML file mod idea does the trick. I wrote a script that flips the UserMap elements back and forth as needed, plus a bunch of safety checks, and it works like a champ.
Any idea if SbAdmCl can clear existing User Attribute Values? (The same as clicking the Clear button in the EEM interface.) I can use UpdateUserCfg to set existing values, but what about clearing them? If not any ideas for doing this?
If you have:
Then running UpdateUserCfg again with:
clears not only content but also labels.
Oh man, you rock! Thanks. I was about to force carpal tunnel on an intern.