We would need a lot more information to propose a solution that would be likely to satisfy the customer's needs completely.  What exactly do you mean by "programmatic"?  Where would the "program" be running? If "programmatic" means on the device, then as Larry pointed out, the device would have to have a way of knowing what Site it was at.  We have done that in a variety of ways before, but each case needs to be considetred to see what might work.  Once the Site to which a device "belongs" has been determined, it can be assigned to that Site in one of two ways.  First, if there are no Production Site Settings being inherited by devices from the Site, then simply changing the Registry so the SiteID reported to MSP is different will cause MSP to treat the device as being at that Site.  Second, if there ARE Production Site Settings being inherited by devices from the Site, then the device should be directed to pull the Production Site Bundle for that Site, which will apply the Production Site Settings for the Site AND set the SiteID to that Site so MSP will treat the device as being at that Site. If "programmatic" means somewhere else, such as on the Server, then there are few options, since MSP does not expose any "automation" APIs.  MSP allows querying of information via APIs or DB but not driving behavior of MSP.  What I would normally do is set Device Attribute values, via the Tag Function, or importing a CSV file.  Then use those Device Attributes to drive Policies that will push the Production Site Bundle for a desired Site to a particular device.  When that device installs the Production Site Bundle for a Site, it will get the Settings for that Site and then report to MSP that it is at that Site, resulting in MSP treating the device as being at that Site.

First of all it needs to be a solution that is 100% automatic with no human interaction... and the question is generic for all kind of MSP implementation if the siteID is stored on the device or not. Well the idea if a device needs to go to service due to hardware failure or back to a service depot for other reasons (device may still be checking into a relay server) in that case the user will go to a external web site. This website is a remote server on the internet that let user to create a service request (RMA) for instance. After the service request MSP server should be updated itself.   Ideally would be a API for updating MSP information from external source but as it doesn't exists... So would it be possible to create a "Job" and "regDoc" xml files and drop them into a FTP relay server from a third party application to update MSP properly? The Job xml file would tell the device to update it's siteID (this is for redudancy purpose if the device still checks in and to avoid overwrite siteID on server side)  and the regDoc for updating MSP database with the devices new siteID in case the device is broken and/not capable doing it for itself. Is the above theory doable? Our partner has a solution already for doing it on SOTI.

I would need a LOT more information about exactly what you are trying to do in order to propose a possible solution or state that such a solution is not practical.  If what you are looking for is a complete RMA process, that is something we plan to implement down the road and is unlikely something you can practically build yourself except in very simple cases. What I can say is that any attempt to "spoof" jobs or documents to or from MSP or a device from some external application is likely to mess things up and would NOT be recommended or supported.  MSP and the MSP agent make a lot of specific assumptions about how the files they exchange are handled and we cannot support anything that interjects itself into that process and might not follow the rules or coordinate its activity with them.

Hi Kjell, there are mulitple ways to change a device from one site to another in MSP, and the appropriate one in a particular case depends on how site was assigned in the first place.

If siteID was assigned ONLY at the MSP server (so that devices do not know their siteID and therefore do not report their current siteID value to MSP as an attibute) then site can be changed by manually editing the siteID value or by importing a spreadsheet to set (new) siteID values for a group of devices. If siteID was not assigned at the MSP server, but was instead installed on each device, so that each device reports its siteID attribute to the MSP server, then changing the value in the MSP server database won't work - that value would just be overwritten by the next incoming reported value from the device. So in this case a method must be found of changing the siteID attribute value that is store in the managed device, so that the new value will be reported from the device to MSP. The best method for doing this will depend on how siteID was assigned in the first place, and on whether there is any attribute of the device that will allow you to determine the siteID. Can you tell us more about the way siteID was assigned in the first place?

I solved this for a customer once.  They had seperate warehouses on seprate IP subnets so we created a rule that sent siteID setting to devices based on Default Gateway being repoted via GetAdapters. When the device reported a change in DGW MSP queued up a job for that device and changed the siteID attribute. This customer had one central relay server so it was pretty simple.