I did something very much like this at a past company. When I started it was a 3 person department to keep all the databases synched. It was down to me, and the parade of folks I was training to replace me, but who'd quit after 2 months.
Originally it was a pile of Access 2 VBA (before my time) that eventually evolved into hundreds of thousands of lines of Access 97 VBA (my time), and with the breaking changes that Access2k had (out with DAO and in with ADO, and about 90% of the code needed to be rewritten - where the fuck did CurrentDB go to?), I was racing to move it to a combination of VB, SQL Server and RAIC (Redundant Array of Inexpensive Computers = that warehouse of pentium 75/90s that hadn't been fully depreciated yet).
I set up a scheduler that basically ran through a table looking to see if it was time to run reports/processes. If so, in one of the columns, the name of the DCOM object was there as well as the last time it ran, what family of parameters it took, and current status. There was also a watchdog timer so that the scheduler could tell if something broke, and give the job to any other computer able to do it. All of the DCOM objects had identical calling parameters, although I suspect these days you'd just use reflection to determine what they were able to understand. A future enhancement was to page folks in operations to go over to the stack of steaming poo (RAIC) and reboot the borked box. Back then, Component Source shipped CDs which were easy for a heavy Access user to crack, and one of the toys on the CDs they'd send out like AOL floppies was a pager ocx for sending alphanumeric pages. Nowadays, most carriers have an email interface for pages, and crackberries take whole emails. I think this is where I mention walking to school 15 miles through the snow and it was uphill both ways, and we programmed in 1s and 0s and when we needed 0s, we carved them out of potatoes. ;)
Some of the jobs would take 10s to run on a 333mhz celery box, some would take 8-10 hours to run on a 1Ghz xeon (which was close to top of the line back in 99/00).
The processes for moving data around, let's call one "the jones report" and the other one "make the donuts." The scheduler would poll the score-board table every couple minutes to see if it was time to make the donuts (every afternoon at 5pm) or time to run the jones report (only on thursdays, except when it was the last week of the quarter, then every hour as folks were busy trying to close out their quarter's numbers).
Some of the processes were db to db moves, and some of the processes were manual ones involving importing data to/from floppies/cds, crunching it and moving it to other places. One of the more fun ones I came up with on my own took area code splits from nanpa and updated the list of approx 70k pharmacies and 600k prescribers in our databases.
About anyone could watch the scoreboard, and authorized folks could move things ahead. We don't need to make the donuts at 5pm today, we need to make them at 1pm.
>...have that service read a text file...
NT Services running as localsystem don't have access to remote drives. That's a gotcha that you can spend too much time debugging. In addition, they don't have access to the user's desktop except under special circumstances.
Email me if you want more details, ideas, or if this almost makes sense.