OD dropping members from Computer groups

[warrens]

Hello,

We have a 10.6.3 OD master that has been dropping computers from computer groups. Over the past few weeks we’ve had a script that compares the GroupMembers, GroupMembership, Member, apple-group-memberuid and memberUid fields and alerts of any discrepancies between them. This week as we’ve been rolling out new computers we are seeing the problem happen. What I’m seeing:

GroupMembers and apple-group-memberuid have been showing the drops, the other fields remain constant, the members tab of workgroup manager shows a “full” list. If I try to rebuild the membership list by deleting all the computers from the members tab and re-add them I do not get all 4 of those fields populated and need to resort to deleting and rebuilding the whole group entry from scratch.

This week we’ve seen this happen several times it generally has affected machines that have been renamed by going into the computer record and manually changing the long and short name of the computer.

Has anyone seen these symptoms or anything like it? Experience any specific problems when renaming computers in OD? Is there a best practice computer re-naming technique that’s being missed?

Thanks,

Warren

[tlarkin]

[QUOTE][u]Quote by: macshome[/u][p]To change the name of a computer I wouldn’t just do it in WGM. I would unbind and then rebind it with the new name…[/p][/QUOTE]

I agree, I would unbind and then rebind and use the [i]-force[/i] switch in the command to bind to force a new entry. Then it should update the record in WGM. I have a certain number of machines in my deployment that I want to disallow any network accounts to log in and only use local accounts. To do so I bind the computer (via authenticated bind script) to OD and when I do so, it updates the computer records in WGM.

example:
[code]
#!/bin/bash

# set this script to bind sumner iMac desktops

# set the FQDN of server for client to bind

server=”FQDN.myserver.com”

# start script

/bin/echo “Starting script..”

# bind to ODR Sumner

/usr/sbin/dsconfigldap -f -v -e -a $server -u diradmin -p mypassword -c `/usr/sbin/networksetup -getcomputername` -l localadmin_acct -q localadmin_passwd

/bin/sleep 40 #give it time to authenticated bind before proceeding

/usr/bin/dscl localhost -create /Search SearchPolicy dsAttrTypeStandard:CSPSearchPath

/usr/bin/dscl localhost -merge /Search CSPSearchPath /LDAPv3/$server

/usr/bin/dscl localhost -create /Contact SearchPolicy dsAttrTypeStandard:CSPSearchPath

/usr/bin/dscl localhost -merge /Contact CSPSearchPath /LDAPv3/$server

/bin/echo “completed process of autehnticated bind..”

/bin/echo “now purging all logs to clean up what we just did…”

/bin/rm -rf /var/logs/*

/bin/echo “logs purged now exiting…”

exit 0[/code]

I have this run via Casper policy or post image, or have one of my fellow techs run it manually say off a thumb drive if need be. It does contain passwords so I remove all the log files after it runs. The -f switch should force the computer to add to OD even if the record exists, which should over write the existing record. So, unbind your client, rename it, then run the script and it should update the records in OD.

[Author]

Posts