You are not logged in.

Announcement

[2016.09.20] DeployStudio build v1.7.5 (checksum, release note).
[2016.08.26] DeployStudio build v1.6.19 (release note).
[2013.02.23] DeployStudio last universal build v1.5.17 (release note).

#1 2015-01-23 09:30:48

nathanzamprogno
Member
Registered: 2015-01-21

Cloned workstations all report same serial# to Profile Manager

I have used DeployStudio to clone an idealised lab Mac to a number of others in a school lab.

Workstations (Mac Minis running 10.10.1) all have unique computer names as defined in the sharing panel and are bound to AD and an OD Server.

The OD Server (also Yosemite 10.10.1) also runs Profile Manager.

When I attempt to enrol any Mac to Profile Manager via http://<servername>/mydevices, then suddenly ALL the macs in the lab report that they are enrolled for management and present the SAME SERIAL NUMBER in the web interface, which is the serial number of the Mini from which the image was made.

Meanwhile, in the Profile Manager management interface, only one device shows up as under management. Only the first device ends up being managed, and the others cannot be enrolled because they are sure that they are already.

Obviously, something nasty in my image is tangling something up. In the deployment workflow, all the necessary boxes have been ticked to remove network configurations and machine-dependent caches, and rename ByHost prefs, so why can't these workstations present themselves cleanly and discreetly to Profile Manager? How can I clear out the settings?

Offline

#2 2015-01-23 18:36:39

Nathan Fisher
Member
Registered: 2014-08-13

Re: Cloned workstations all report same serial# to Profile Manager

ssh bumps against ssh_host_dsa_key for unique verification.  I don't know if that's what's being used here or if there's something else.  go into /etc and remove all six ssh_host_ files and reboot, it should reroll those keys.  see if that changes anything?

Offline

#3 2015-01-25 07:37:18

nathanzamprogno
Member
Registered: 2015-01-21

Re: Cloned workstations all report same serial# to Profile Manager

There are no files named ssh_host* in my /etc folder.
There are four files that do not look computer-generated: ssh_config, ssh_config~orig, sshd_config, and sshd_config~previous. These files don't look like the kind of thing that would auto-generate, and their date-stamps mark them as fundamental to Yosemite.

What else should I check? Something that isn't getting cleared out and is confusing Profile Manager as to the identity of the Macs attempting to enrol.

Last edited by nathanzamprogno (2015-01-25 07:38:10)

Offline

#4 2015-01-25 09:36:55

nathanzamprogno
Member
Registered: 2015-01-21

Re: Cloned workstations all report same serial# to Profile Manager

Looks like I am not the only person to have this problem:

https://discussions.apple.com/thread/4787560

However, the solution proffered makes no sense. The offered solution on the Apple forum suggests:

|   It seems the enrollment profile that the device gets from My Devices is somehow different than
|   the enrollment profile you can download from Profile Manager.
|   If I download the Trust and Enollment profiles from Profile Manager and run from each Mac they work great.

I can see where I download the Trust thingy in PM (just go to your logged in name in the top right and download it from there).
But how do I download the Enrolment profile? The only place I can seem to do so is in My Devices, which is purportedly what is causing the problem.

Offline

#5 2015-01-25 16:13:44

nathanzamprogno
Member
Registered: 2015-01-21

Re: Cloned workstations all report same serial# to Profile Manager

I have fixed the problem, although at high cost.

1. Reimaged all lab macs without any directory binding (OD or AD).
2. Manually bind each workstation by hand.
3. Completely rebuild server (simply resetting the Profile Manager portion didn't do the trick).
4. Enrol each lab mac from the <server>/mydevices url.

I suspect it was step three that made the most difference.

I might add an additional twist was that we use an authenticating proxy and took a while to realise that configuration changes are passed to clients via Apple's push service, which requires an active Internet connection. Enrolment could not complete without each client "logging on" to the internet (we have the kind of firewall that throws up an interstitial URL when the user first asks for a website).
I will be exploring a solution whereby the entire block of Apple IPs (17.0.0.0/8) is exempt from authentication from our firewall.

Offline

Board footer

Powered by FluxBB