Is that OK to leave a small endless loop script running on server?

Solution 1:

As a general alternative to this: put your script in Task Scheduler and trigger it every minute, two minutes, whatever. This is more reliable, as your process with survive reboots or script errors. Using Scheduled Tasks not only allows your process to survive reboots, as mentioned already, but can also make your task deployable to a large number of servers via Group Policy Preferences. Your current solution is an enemy to both scalability and reliability.

As for the actual script you're talking about - it seems like you're re-inventing a Frankenstein's Monster of DFS-R and/or Robocopy.


DFS-R is a scalable, mature file replication tool that is built into Windows Server. You should see if you can use it for this situation. Microsoft has put way more engineering brain-power into DFS-R than you could ever put into a script that does the same thing.

Also, even if you can't use DFS-R for some reason, robocopy has a /mir switch, which will mirror directories. If you really can't use DFS-R for some reason, at least use something like this in a script.

Solution 2:

You should be commended for asking about your approach. Its easy to run with the first idea you have, but better to validate with with others.

Several issues with your approach:

  • It has to be restarted manually everytime the server restarts
  • It requires you to stay logged onto the console with credentials that have access to source & destination
  • There are already tools that do this (DFS, scheduled tasks, etc.)

(Some of these issues can be addressed as you've mentioned with the service.) That said, only you can assess the validity of any particular solution to the problem you face. At least now you have options.


Solution 3:

There are surely better ways to do that than running endless loop. Endless loops are pain, and causes frustration at all levels to everyone. Please don't do that.


Solution 4:

I'm curious why you are asking. Several people have offered alternative solutions and the response seems to be that you were ordered to do it this way. Are you looking for alternatives or are you looking for ammunition to go back to your manager and protest doing it this way?

The reasons for not doing it this way have been enumerated in other answers:

  • it is prone to failure in that it won't survive a failure, or a system restart, or any kind of processing error.

  • it requires effort on your part (as opposed to a vendor's) to maintain

  • there are security risks to this method

  • it is relatively inefficient

As far as alternatives go, I too had a bad experience with DFS and used DoubleTake Replication with great results. However a subsequent release of DFS resolved my issues with DFS and now we use that for DR replication across a WAN.