AD Bind best practice

we put a jamf flushPolicyHistory
in our firstboot scripts so that reimaged machines get to run policies again...

A few things you can do.

1- Include the bind policy as part of your imaging process. These will get done on first run so the Mac will reboot after imaging and then bind. This is typically how most environments do it.

2- If you'd rather keep the bind settings out of your imaging for some reason, you can flush all policy history as part of your imaging process in your first run script (jamf flushPolicyHistory)

3- Use a Smart Group to determine which Macs are not already bound to your AD domain and scope that group to the policy and set it to Ongoing.

The 'flushPolicyHistory' will ensure any previously run policies will re-run after a Mac gets re-imaged, including your AD bind policy, which you may or may not want depending on how you've got things set up.

Using the 3rd method, some Macs may get the binding config that you don't want included, unless its a policy that all Macs must get bound to AD. You can always make adjustments to your Smart Groups though.
So pick whichever works best for you.

And I'm sure there are additional solutions beyond these..

Or do all three :D

I have a bind in my image along with a policy flush and a Smart group which checks for unbound machines and rebinds them if possible.

Good point! :) No reason not to have all 3 in place to cover your bases and ensure any Macs that need to be bound, get bound.

I'm a smart group junkie. Nearly everything I do is with smart groups, and I often create a ton of extension attribute scripts just so I can create custom smart groups.

I have noticed issues when using this method when machines are already bound to the AD. For example, if existingMac is bound to the AD, I re-image it with this process, and a rebind attempt occurs, it fails because the machine is already there. Fi, however, have existingMac unbound first, then re-image and re-bind, it will work. Any suggestions or opinions on this?

[environment: 10.8.2 with a 2008R2-AD]

Two quick comments.

1. I'm pretty sure a JAMF employee told me that the 'flushpolicyhistory' is now something that is automatically done so you no longer need to stick a script in your configuration to do that.

2. I'm re-imaging test machines that are bound to the domain and I don't have any problems that require me to first Unbind them. I would take a look at the account you are using to do the binding and make sure it has the necessary permissions in the applicable OUs. (Create/Delete Computer objects etc...)

Thanks arse, The account used is able to create/delete computer objects in the container as, logged into this account, I am manually able to do this in the AD MMC-plugin. I will look to use perhaps another account or double-check further to see what is going on that prevents me but allows you guys.

I am having the same problem, I was told that there is a problem with the latest version of Caspers AD Plugin, the only way I found to get this to work was using this script to unbind the machine then binding it again to AD.

----------------------------------------------------------------------------------------
#!/bin/sh

echo "Unbinding the computer from Active Directory..."
/usr/sbin/dsconfigad -r -u "username" -p "password"

echo "Restarting Directory Services..."
/usr/bin/killall DirectoryService

----------------------------------------------------------------------------------------

I used a startup trigger to do this and also the following smart group: Active Directory Status is "Domain Name" So I knew that It had run correctly.

Hope this helps you out.

Paul.

Thank you, Paul. After quite a bit of testing this weekend, I believe I am more aligned with your experience than the rest. I will give your idea a go next.

Tim

When I said it was working for us I probably should have mentioned that our clients are all Lion and our JSS is still at 8.52.

We do ongoing with custom trigger. Then have a script run at reboot in the imaging process which calls jamf policy and the custom trigger. Then you can have a smart group which checks for unbound systems and again use the script which calls jamf policy on the custom trigger.