Anyone have experience deploying inSync with local accounts/Enterprise Connect?
We are currently trying the IMD command with success but uploading the CSV for device mappings is a lot less automated then we are used to, and i see a lot of room for human error.
Your DRUVA Consultant should point you to
The CSV is one part and thenthere is the JAMF policy that will deploy and install the inSync Druva client. There is an activation code that is mention that you Consultant will give you to place into that code to activate.
Make sure to use the PPPC Utility to open up the following
- Address Book
- All Files
- Media Library
Druva provided me with a script that had options to query Jamf, EC, or a local file to populate the email address. Testing so far using the Jamf approach has been successful - overall very straightforward execution, and a well-crafted and documented script. This method is going to require that device assignments have to be kept up to date.
It's also giving me some nifty ideas on scripting a sanity check to compare JSS assignment versus most recent EC user versus most recent local login..
@petecurtner@todosw Ahh this might explain something with our rollout of NoMAD. We have had Druva InSync for a while using automatic activations but perhaps the demobilizing part of the change over is preventing this.
I've reached out to Druva Support however they say they are not aware of the script, that it may of been made by a tech for a customer but not shared further with the Support team.
Even if you can give an overview of what the script is doing that would be helpful. I'm guessing it either somehow builds up the .csv file for importing into Device mappings or perhaps calls an API for adding to Device mappings ?
I've looked at moving to Jamf Connect / Druva activations via AzureAD however unfortunately our students are not in the same AzureAD tenant as our staff yet so wee are in a hold on that until they are combined.
It does look possible to now do IMD (integrated mass deploy aka automatic activation) without device mappings for non AD accounts however there a couple of security notes which I don't think would work for us:
I'm guessing I'm going to need to look at something which builds up the .csv file for importing into the console as device mappings.
Which part would you like more info on @todosw ?
IMD for non-AD accounts without device mappings ? https://docs.druva.com/Endpoints/030_Set_up_inSync_for_Endpoints/040_inSync_Client_mass_deployment/0...
IMD for non-AD accounts using device mappings https://docs.druva.com/Endpoints/030_Set_up_inSync_for_Endpoints/040_inSync_Client_mass_deployment/0...
I'm still hopeful @petecurtner might be able to explain the script mentioned more. I've not yet figured out exactly how I might be able to automate the building of the .csv for IMDv3 yet. Creating the .csv for a few machines isn't hard, it is just yet another manual task though which I'd like to avoid if possible.
Our Mac users have manually activated InSync for years without any troubles. They *want* to be backed up, but it would be nice to have automatic activation's to match how it works for our staff using Windows.
I have tried this method: IMD for non-AD accounts without device mappings: https://docs.druva.com/Endpoints/030_Set_up_inSync_for_Endpoints/040_inSync_Client_mass_deployment/0...
But getting this error during activation:
IMDv4 - User Name : akamenev The return code, stdout, stderr for command: 0, MM-MAC-10022 IMD Details: email:None, massDeploy_ver: 4, objectSID_found: False Trying to connect to cloud.druva.com:443 Connection successful with cloud.druva.com:443 Error while IMDv4. Check server logs for more information.
Hmm, I'm not sure on that error. Sometimes check server logs means you might find details in your console, or it might mean Druva Support can check their side of things too. Whilst they have no visibility or access to your tenant, they can see things such as an attempt to register with an email address which is already used in another tenant.