/build/static/layout/Breadcrumb_cap_w.png

Mac Imaging - Rename Computer waits for first logon

I'm pushing an El Capitan image to Macs, and have a script to rename the computer post-install and to bind it to the domain post-install.

After the image deploys, and the Mac reboots, it sits at the login prompt, as expected, but the Progress/Manual Deployments/Details window shows the Rename script to be in progress. If I log into the Mac as the lone local user, the rename process continues, succeeding, but the following bind to domain script then fails. If I then mount the //k2000/peinst samba share and manually find/run the "Bind to Domain" script, it works.

So I'm unsure if I have one problem leading to the second, or if I have two problems. Here's my scripts:

Mac - Rename Computer:
#!/bin/bash
SOURCE="/Volumes/Macintosh HD/ComputerName.txt"    # Placed here in an earlier script
COMPNAME=$(<"${SOURCE}")
/usr/sbin/scutil --set ComputerName "${COMPNAME}"
/usr/sbin/scutil --set LocalHostName "${COMPNAME}"
rm "${SOURCE}"
exit 0



Mac - Bind to Domain:
#!/bin/bash
USER=[my user for binding to domain]
USER_PW=[the domain-binder's password]

# Add it to the domain
dsconfigad -add  acu.local -computer "`hostname -s`" -username $USER -password $USER_PW -ou "CN=Computers,DC=acu,DC=local" -localhome enable -useuncpath enable -alldomains enable

Any ideas?

Thanks!


0 Comments   [ + ] Show comments

Answers (1)

Posted by: taylor-madeak 8 years ago
Yellow Belt
0
I get around this by configuring OS X for auto-login during sysprep.  All PO tasks that need to run in OS X (and not in KBE) will be launched after that login.   A final script disables the auto-login feature.

Details:

Computer name assignment happens as a mid-install task in the OS X KBE, using this script:

MAC=`/usr/sbin/networksetup -getmacaddress Ethernet 2> /dev/null | awk ' { print $3; }' | sed -e s/://g `

TEMP_PATH="/opt/kace/petemp/${MAC}"

if [ -f "${TEMP_PATH}" ]
then
    COMPNAME=`cat ${TEMP_PATH}`
    echo "Computer name is going to be ${COMPNAME}"
    /usr/libexec/PlistBuddy -c "Set :System:Network:HostNames:LocalHostName ${COMPNAME}" "${KACE_SYSTEM_DRIVE_PATH}/Library/Preferences/SystemConfiguration/preferences.plist"
    /usr/libexec/PlistBuddy -c "Set :System:System:ComputerName ${COMPNAME}" "${KACE_SYSTEM_DRIVE_PATH}/Library/Preferences/SystemConfiguration/preferences.plist"
   /bin/rm "${TEMP_PATH}"
fi

exit 0

This script excerpt disables the auto-logon:

sudo defaults delete /Library/Preferences/com.apple.loginwindow autoLoginUser
srm /etc/kcpassword

After the computer name is assigned, this script binds the system to the domain in the appropriate OU (we separate desktops from laptops).  Please be advised that this script has been sanitized for public viewing and must be configured for your environment:

#!/bin/bash
touch /var/log/join_domain.log
exec 1>/var/log/join_domain.log 2>&1

### You must edit these for your specific environment

# 1) fully qualified DNS name of Active Directory Domain controller.
domain=mydomain.com

# 2) username of a privileged network user.
udn=privileged_user

# 3) password of a privileged network user.
password=********

# 4) Distinguished name of container for the computer
laptopOU="ou=Laptops,ou=Computers,DC=mydomain,DC=com"
workstationOU="ou=Workstations,ou=Computers,DC=mydomain,DC=com"

# 5) 'enable' or 'disable' automatic multi-domain authentication
alldomains="disable"

### End of configuration

# Get the local computer's name.
computerid=$(/usr/sbin/scutil --get LocalHostName)

# Bind to ntp server, sync time, set timezone
systemsetup -settimezone America/NewYork -setusingnetworktime on -setnetworktimeserver time.apple.com

# Add additional NTP servers
echo -e "0.us.pool.ntp.org\n" \
"1.us.pool.ntp.org\n" \
"2.us.pool.ntp.org\n" \
"3.us.pool.ntp.org" >> /private/etc/ntp.conf

# Activate the AD plugin, just to be sure
defaults write /Library/Preferences/DirectoryService/DirectoryService "Active Directory" "Active"
plutil -convert xml1 /Library/Preferences/DirectoryService/DirectoryService.plist

sleep 20

# Bind to AD
IS_LAPTOP=$(/usr/sbin/system_profiler SPHardwareDataType | grep "Model Identifier" | grep "Book")

if [ "$IS_LAPTOP" != "" ]; then
ou=$laptopOU
else
ou=$workstationOU
fi

sudo dsconfigad -force -add $domain -computer "$computerid" -username "$udn" -password "$password" -ou "$ou"
sleep 30
dsconfigad -mobile enable -mobileconfirm disable -localhome enable -useuncpath enable -groups "Domain Admins, Enterprise Admins, Workstation Admins" -alldomains $alldomains

# Add the AD node to the search path
csp="/Active Directory/MyDomain"

dscl /Search -append / CSPSearchPath "$csp"
dscl /Search -create / SearchPolicy dsAttrTypeStandard:CSPSearchPath
dscl /Search/Contacts -append / CSPSearchPath "$csp"
dscl /Search/Contacts -create / SearchPolicy dsAttrTypeStandard:CSPSearchPath

# Restart Directory Service
killall DirectoryService
sleep 2

exit 0

Comments:
  • This is good information; thanks!

    But it doesn't answer my fundamental question: Why is the renaming not taking place until a console login occurs?

    Getting back to your answer: You're using PBuddyList to edit .plist files, whereas I'm using the supposedly Apple-canonical method of scutil to rename the computer.

    What are the pros and cons with the two methods? Thanks! - kentwest 8 years ago
    • The scutil utility interacts with the OS X dynamic store, and does not provide any way to specify an offline volume to find that store on. This is why renaming with scutil can't take place until a console login occurs.

      PlistBuddy doesn't have that limitation, as it is a tool to modify any plist file that you point it at. OS X then sources the information from the plist file to build the dynamic store and apply settings to the OS. - taylor-madeak 8 years ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ