Hey @Nic -

I created a worklet with the instructions called out near the bottom of this documentation to bulk move devices between Orgs.

The steps I’m using go set new key, set new group, deregister, and then restart the client:


& "C:\Program Files (x86)\Automox\amagent.exe" --setkey 'newOrgKey'


& "C:\Program Files (x86)\Automox\amagent.exe" --setgrp 'newGroupName'


& "C:\Program Files (x86)\Automox\amagent.exe" --deregister


Restart-Service amagent

I’m finding this to be very unreliable… sometimes it will move most of the devices in a group, sometimes it won’t move any of the devices. I’m not seeing anything being posted to the Activity Log in either of the involved orgs either, making it difficult to know why it may be failing or even validating that it attempted to run.

Any ideas on what I may be doing wrong/why I’m seeing inconsistencies?

I’m wondering if the commands aren’t completing before the next one tries to run. That might interrupt one of the commands that’s still running when the next one executes. Could you try putting some delays in between the commands and see if that does anything?

I tried adding in a 10 second pause and am still not seeing changes in the target device group or anything appearing in the logs…

& “C:\Program Files (x86)\Automox\amagent.exe” --setkey ‘newOrgKey’


Start-Sleep -Second 10


& “C:\Program Files (x86)\Automox\amagent.exe” --setgrp ‘Default Group/newGroupName’


Start-Sleep -Second 10


& “C:\Program Files (x86)\Automox\amagent.exe” --deregister


Start-Sleep -Second 10


Restart-Service amagent

You might need to put the setgrp command after the restart of the service. Let me check with our support folks to see if we’re missing anything else.

If I refresh the console repeatedly after executing the worklet, it looks like the systems drop out temporarily and then come back in within the same Org/Device group(don’t know if that helps).

Ok so it looks like the problem might be losing contact with the agent while the worklet is running, due to the commands issued, which would abort the script. Support suggested running the script as a background process to ensure that the script doesn’t get interrupted:

I’ve been playing with this, still to no avail…

Here is where I’m at:

Start-Job -ScriptBlock {


# set key to new Org key


& “C:\Program Files (x86)\Automox\amagent.exe” --setkey ‘newOrgKey’


Start-Sleep -Second 10


# deregister client from old Org


& “C:\Program Files (x86)\Automox\amagent.exe” --deregister


Start-Sleep -Second 10


# restart agent


Restart-Service amagent


Start-Sleep -Second 10


# set Device group to new Device group


& “C:\Program Files (x86)\Automox\amagent.exe” --setgrp ‘Default Group/newDeviceGroup’


}

Nothing seems to happen when executing it from the GUI. When I execute it on the local machine using PowerShell ISE, somehow the the entire agent/service is getting uninstalled and removed from the system.

That’s strange that it’s completely removing the agent. Have you talked with support yet about this one?

We have the same issue as well.

Yeah, I’ve had an ongoing discussion with support for a bit over a month trying to flush out the inconsistencies I’ve been seeing.

Hopefully they’ll be able to shed some light on it. Also I’ll let our product team know that this is something that we might want to consider for an actual feature in the product rather than something we pull together in a worklet.

Ok this issue looks like it’s a bug on our end. I’m watching the bug ticket so I can let you guys know when it gets fixed.

This bug has been fixed, with the deregister command, so you can resume automating moving devices from one org to another.