Important Notice: On February 29th, this community was put into read-only mode. All existing posts will remain but customers are unable to add new posts or comment on existing. Please feel to join our Community Discord for any questions and discussions.

Custom Timeout - Not timing out... has the behavior changed?

I have a small maintenance window and low bandwidth to remote locations, so when copying something huge like a Windows Feature Update, it's impossible to finish within the time window. 

So I made a package that runs a command line to XCOPY the files, and gave it a custom timeout of 5 hours.  In recent memory, it would churn for those 5 hours and fail.  "Exceeded timeout for completion."  The next night, it would pick up where it left off and fail again after 5 hours.  Eventually, 3-5 days later, all the files will have copied over.  Perfect.  That was in July '21.

But now with the same package, it blows past the timeout setting.  I discovered that when I came in one morning to many complaints from the remote sites about not being able to do business.  - (The package was still running 9 hours in and saturating their bandwidth.)

Did something change in a recent version?  The help file says, "This timeout applies only to the duration of a deployment to a target computer. The timeout does not include the initial process of copying installation files to the target."  Fair enough.  But I'm not using the embedded "File Copy" step.  I'm using a Command line step.  Does Deploy know that I'm copying something with that step, and hence aborting the timeout I have in place?

If so, is there any way around that?  This is the only means I have to get GB worth of files to my remote sites... chunks at a time over a number of days.

0

Comments

3 comments
Date Votes
  • I would consider setting up DFS and point your repository to a DFS location and have your jobs PULL from that location.  You can configure your DFS replication schedule to not use bandwidth during business hours.

    0
  • I recommend reaching out to support@pdq.com. Timeouts might just be broken in whatever version you're running.

    Also, I agree with looking into DFS. https://www.pdq.com/blog/distributed-file-system-in-windows/

    0
  • Thanks for the suggestions and reading material.  It's certainly something to look into.

    And just to follow up in case anyone else stumbles in here with a similar problem, support confirmed that this is a bug with v19.3.83.0.

    Multi-step packages might ignore the package timeout setting.  Single-step packages work as designed.

    0