However, it does not pull any down by itself until we enroll it. If we manually bind a machine, we can also enroll it manually.
#Pro tools for mac yosemite how to#
I wasn't sure if I'd need to write something to unbind the machine first since some of these machines will be reimages, and then what logic to use to tell the script how to recognize when a machine was new, etc. I thought about writing a script but I don't know enough about scripting in this environment to be sure I won't kill something important. And when we manually bind in 10.10.3, it works fine. We have zero connectivity to our network pre-binding. We looked at the derflounder site but it did not apply in this situation. That was the first thing I read about and checked off the list of possibilities. in which case please ignore me and cary on. Or maybe I've just diverted the conversation. But I thought maybe this odd behavior might be part of what you are experiencing so maybe it might help one of the genii out there solve your issue. I have not yet tested whether I get similar behavior from Deploy Studio since my predecessor had us working from a monolithic image - Disk Utility Restore process (and I'm only just now getting modular imaging setup here), and as we don't have Casper yet I obviously can't test that.
It also binds just fine if the script is run locally or from the GUI bind process. everything binds normally like the package (or remote script from ARD) did.
I have also found the exact same effect if I try and run my bind script via ARD.
I have to FSCK it just to get it to boot normally afterwards. but on 10.10.3 machine it not only fully locks up the machine, but totally corrupts the hard drive. pkg binds the machines just fine (via script). pkg that configures all of our settings post imaging to make things easier for our techs. My new environment does not have Casper yet (luckily we are in the process of purchasing it now). So I have had some interesting problems with binding and 10.10.3 myself.
0 kommentar(er)
