Hi Torsten
OK, it's a bit complicated but I have a branch office like scenario but each is an untrusted forest. I have a server down on the branch which is an MP, SUP, DP and SCCM client and it manages a bunch of SCCM clients down in the branch. This server
also functions as a SCOM gateway for managing the infrastructure boxes.
Down in the branches however I have a bunch of boxes which cannot have an SCCM client installed on them (even with the new clients) which from a central location need to have jobs run on them.
At head office I have a package for each Branch and I write a job file for a system in the form SYSID-TicketID.JOB where SYSID is the name of the system and ticket ID is what Remedy built. The .JOB file goes into the package and the package content
is refreshed. The .JOB file finds it way down through SCCM and eventually arrives at the branch and is copied to the share. At the branch, systems will look in the share and see that there is .JOB file for them. They will do something at
this stage.
When the system is performing its stuff it will write to a share on the SCCM client called BACKCHANNEL a file called SYSID-TicketID.LOG. Through file collection SCCM delivers this file back to the SCCM server.
Now, we need SCORCH to be able to look into SCCM for any collected files and then extract them, adding the .LOG file to the ticket in Remedy. When this is done we want SCORCH to be able to remove the .LOG file from SCCM and then to remove the .JOB
file from the package source. The next time a new .JOB file is created there and the content refreshed the old .JOB will be removed from the DP and the new .JOB sent down.
Yes, it is complicated in a way