Yes the user is called fsiadmin but it's the same with all users.
I've run the log when running the connection manager on the 2008 DC in 2003 mode. I've done an edit find on that account and pasted the log stuff related to it.
28/03/2013 15:10:57 Checking if dn 'CN=FSI Admin,OU=FSI,OU=Staff Users,DC=a4egroup,DC=co,DC=uk' is a group
28/03/2013 15:10:57 ldap reports = 0 (Success)
28/03/2013 15:11:00 Checking if dn 'CN=FSI Admin,OU=FSI,OU=Staff Users,DC=a4egroup,DC=co,DC=uk' is a user
28/03/2013 15:11:00 ldap reports = 0 (Success)
28/03/2013 15:11:04 Checking Endpoint Encryption User FSIAdmin
28/03/2013 15:11:04 ...change attribute older than current users: Ignoring other changes
28/03/2013 15:11:04 ...No changes needed.
That's what I needed, the change attribute issue means that the entry for the user in eem has a change number larger than the one in your domain (it's not synced between servers - it's a local domain server counter). Thus it won't sync changes until the value in the ad exceeds the one in eem.
To solve, you need to zero out the change values in eem for each user (in their bindings). You can do this with a script if you have a lot of users.
Ideally this would be a /= comparison rather than a<comparison, but it's not. The number in the ad has to exceed the number in eem for changes to be reflected.
Manually change it for that user and run the job again to prove this - I'm pretty sure it will work fine.
I've repeated the process of removing the security group, syncing, then adding back to the security group on Server 2003 DC's. This is the logs related to the account.
28/03/2013 15:19:33 Checking if dn 'CN=FSI Admin,OU=FSI,OU=Staff Users,DC=a4egroup,DC=co,DC=uk' is a group
28/03/2013 15:19:33 ldap reports = 0 (Success)
28/03/2013 15:19:42 Checking if dn 'CN=FSI Admin,OU=FSI,OU=Staff Users,DC=a4egroup,DC=co,DC=uk' is a user
28/03/2013 15:19:42 ldap reports = 0 (Success)
28/03/2013 15:19:57 Checking Endpoint Encryption User FSIAdmin
28/03/2013 15:19:57 ...updating user state.
I've done a quick search and have found this:
Thanks i've reset the state change on that user and it's working now on the 2008 server.
- If you don't mind i've just got a few questions regarding this issue. Really appreciate your help, you've been great as usual!
- Do you know why it would only be affecting our 2008 server DC's? I've tried running the test on a number of 2008 server DC's and it fails on them all unless i 0 the change state. In addition im unsure why it's only the addition to the security group that it doesn't recognise, and yet it happily disables and generates new users?
- Can you see any side affects of running a script to change all the change states of 2000+ users. I'm just a little apprehensive and i don't want to break anything.
- We will be moving to native 2008 in the future, is 5.2.11 (moving shortly to 5.2.12) connection fully compatible?
1. It's nothing to do with the server version - it's simply because the change value for the user differs between servers, and in this case the server you moved to has lower change values than the server you moved from.
2. Whether it affects any particular user also depends on their respective change values - it depends on how many changes have been made to the user.
3. Resetting it for everyone will cause a one time glut in traffic as the connector resyncs them all - it would be better if you just mine the log for users with this error message and reset them only.
4. The connector talks to AD - it's not version specific so yes, everything is supported.