You actually have feature parity (or the ability to add that parity) between Windows and OS X agents on this matter - but as you stated it is not well documented.
The OS X agent acts slightly different from the Windows agent during installation. The Windows agent installs and does not attempt to broker immediately unless you edit the installer and add a broker -r command to it. The OS X agent however already has the broker -r command added in. This means that if the OS X agent is in-band (can reach core and CSA) during installation it will (mixed results here) automatically broker.
Activation via policy:
In the case that this fails you may also create a sh script to execute the following command via policy on any device that is not brokered, but is in-band.
Activation while out-of-band:
The Windows agent supports using a .lng file for out-of-band brokering: Unattended configuration of client for the Cloud Services Appliance
*Note: I have not released a new version of the ldgatewayassistant yet to support the new miniscan technology - so it may not function correctly with 9.6.1 Windows agents. The service will likely crash. The OS X version should still work though.
Hopefully this helps,
hi peter, i talked to support and they said that it's even more simple than that. for 9.6, sp1, the only thing that you have to do is attach the csa to the core server first and THEN create the mac agent. the command to run brokerconfig is built into the agent creator. so basically, if the core server has a csa associated with it, that csa name and external ip will be built into the agent so that when the agent is out of band and switches to the mac version of gateway mode, it will look for the csa and present the csa certificate to start communication. i have tested this out and it has worked. the core server has seen the test mac change ip addresses from internal to external and i was able to remote to it both ways. thanks for your help on this!
That is the same as what I had listed for immediate activation:
The OS X agent acts slightly different from the Windows agent during installation. The Windows agent installs and does not attempt to broker immediately unless you edit the installer and add a broker -r command to it. The OS X agent however already has the broker -r command added in. This means that if the OS X agent is in-band (can reach core and CSA) during installation it will (mixed results here) automatically broker."
That method will work - I was just providing all three cases to trigger the activation for a more complete and detailed answer.
With the way that you currently have it setup; if you install the agent while it is off the network and not on vpn - it will not automatically connect to the CSA and broker. You will still need to use the methods I listed above. The reason for this is that the agent does not have embedded credentials to initiate the broker'ing process. However if you can get all of your devices to broker during their initial setup then you should not have to worry about out-of-band activation.
I am curious about this. I have SP2 with 2 gateways. When the mac agent is installed to a device that is not directly connected to the network it won't retrieve a cert to be able to upload an inventory to the core server. But if I do a cert retrieve, then it will work. Is this how it is supposed to work or perhaps is something in the configuration perhaps not correct?
Doing a brokerconfig -r while not able to directly connect to the core will not work. As a work around if you do it via the GUI brokerconfig.exe and put in credentials then it will work. It uses the credentials to connect via the gateway to get a certificate.
So you are correct, that is how it is supposed to work.
Hope this helps,
Thanks Peter. As I mentioned in my previous reply, we can do a manual retrieve but I wasn't sure about the -r and working while not connected to the core through either a VPN or direct connection. But your reply answers that.