Couple of interesting things happening

bob-

to verify what MCX settings have been applied to the workstation

dscl . -mcxread /Computers/localhost

Dan De Rusha

1 - Do you have any policies that may run anything that loop through /Users? How are you demoting/promoting accounts to begin with?

2 - If you are using MCX from Casper to manage this, enable it, delete MCX records and run sudo jamf manage on the client machine to get a fresh copy of the framework and see if that makes any differences.

I'm not sure what you mean by 'loop throguh /Users'

We've got a local administrator account on all the machines. Before Casper
that was built manually, so machines that were inventoried with the QuickAdd
package have 2 local administrator accounts, 1 visible and 1 hidden (the one
added by the Quickadd) We made sure to give them different short/long names
so there wouldn't be any arm-wrestling.

Any other promotions would be done by logging in through ARD, and checking
the 'Allow this user to administer this computer' box in System Preferences

Accounts

We are using MCX from Casper, and I've deleted all references to Bluetooth
we put in place and run sudo jamf manage on the machine, as well as
restarting it to no avail.

Interesting...it looks like the com.jamfsoftware.mcx isn't even touching the
iMac...but it's fully inventoried/managed and I can run policies on it all
day.

Immediately after running that command on both my machine locally and the
new iMac we just loaded:

10.5.8 MacBook Pro
App domain: com.apple.screensaver.ByHost
Key: askForPassword
State: always
Value: 1

App domain: com.apple.loginwindow
Key: LoginwindowText
State: always
Value: *Our login disclaimer

App domain: com.apple.loginwindow
Key: AdminMayDisableMCX
State: always
Value: 0

App domain: com.apple.loginwindow
Key: AdminHostInfo
State: always
Value: DSStatus

App domain: com.jamfsoftware.mcx
Key: version
State: always
Value: 7.1

App domain: com.apple.finder
Key: ProhibitGoToiDisk
State: always
Value: 1

App domain: com.apple.MCX
Key: DisableGuestAccount
State: always
Value: 1
------------------------------------
10.6.2 iMac
App domain: com.apple.screensaver.ByHost
Key: askForPassword
State: always
Value: 1

App domain: com.apple.MCXBluetooth
Key: DisableBluetooth
State: always
Value: 1

App domain: com.apple.MCX
Key: DisableGuestAccount
State: always
Value: 1

App domain: com.apple.loginwindow
Key: AdminHostInfo
State: always
Value: DSStatus

App domain: com.apple.loginwindow
Key: AdminMayDisableMCX
State: always
Value: 0

App domain: com.apple.loginwindow
Key: LoginwindowText
State: always
Value: *Our login disclaimer

App domain: com.apple.finder
Key: ProhibitGoToiDisk
State: always
Value: 1

What am I doing wrong? The two machines are in different MCX profiles in our
JSS, but the only difference should be a different internal SUS.

Bob-

I just took a mac pro out of the box from apple, went through the registration fun and opened terminal.
(I did nothing else but place an asset sticker on the box)

when I ran the mcx read, it came back with no return.....just gave me another prompt.

Something has to be placing those settings in there....

check /Library/Managed Preferences

Dan

Well we're bound to AD, so that could have something to do with it...but
whatever AD is enforcing should be universal, no?

I ran sudo dscl . -mcxdelete /Computers/localhost

Then ran a sudo jamf manage and rebooted the machine, only 3 of the MCX
settings came back. com.jamfsoftware.mcx still isn't there.

I also didn't get my com.apple.loginwindow settings to come back.

Well the only way you would get MCX records is if you bound the client
to an OD server or had the jamf binary installed which would pull MCX
records down from your framework settings in the JSS