Monitoring for a collected file

Hi there folks

I have a need to use SCORCH to perform some automation based upon a file.  Essentially this is what I wish to do

- Write a text file to a share on an SCCM client.  There will in fact be a number of SCCM clients

- The folder is monitored for file collection

- The file will be transferred to SCCM Site Server

- I want SCORCH to be able to look into SCCM for a number of known SCCM clients to identify that a new file has been collected, read the filename and then start processing the file.  Ideally I'd then like to have SCORCH delete that file.

It's that last stage which is causing me some concern as I cannot see how to programmatically get into File Collection and extract the text file.  Is there a script which we can access on this at all?

May 15th, 2013 12:09pm

Seems somehow complicated. What do you want to do exactly? I don't get it from your description. Who is writing what where and what should happen based upon what? :-)
Free Windows Admin Tool Kit Click here and download it now
May 15th, 2013 12:27pm

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

May 15th, 2013 1:18pm

Yes, I know this is an old post, but Im trying to clean them up. Did you solve this problem, if so what was the solution?

Free Windows Admin Tool Kit Click here and download it now
February 14th, 2015 1:08am

Since no one has answer this post, I recommend opening  a support case with Microsoft Customer Support Services (CSS) as they can work with you to solve this problem.

May 16th, 2015 2:35pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics