Scheduled Task loses access to remote share


I have a scheduled task and am seeing a behavior similar to the one described in the thread linked below.

The core idea behind the scheduled task is that a Windows 2012 R2 file server watches a directory accessible to end users, and if a new file/folder is placed in a certain directory then it launches a robocopy session to copy those files and folders to the hard drive of a machine console (the console is running a manufacturer provided version of Windows XP). The premise was to restrict access to older OS's from general user computers. The copied files are then used by the machine to make whatever parts are needed. The way the machine's console is setup I can't make any effective changes to the console itself.

My expectation is that the task monitor the directory and copy the files if the machine console is turned on. What is happening is the new files are detected (correctly) but the script reports that it is unable to access the machine console file share. At present this is the output from Get-ChildItem against the target path. I am able to ping the server.

System.Management.Automation.ItemNotFoundException: Cannot find path '\\\D$\NC_Released\' because it does not exist.   at System.Management.Automation.SessionStateInternal.GetChildItems(String path, Boolean recurse, CmdletProviderContext context)   at Microsoft.PowerShell.Commands.GetChildItemCommand.ProcessRecord()

If I login to the console of the 2012 file server and run the scheduled task again, new events are able to copy the files successfully.

Initially I just fired off a robocopy session when I detected a file event. With that I was logging some 1326 error messages in the robocopy output.

ERROR 1326 (0x0000052E) Getting File System Type of Destination \\\D$\NC_Released\ The user name or password is incorrect. 

Since adding the pre-checks, I'm avoiding the 1326 error messages, but it still does not maintain the ability to copy files. Now as part of my pre-check I first attempt to Test-Path the console share path, if that succeeds the robocopy session is launched. If it fails. I then use Test-Connection to ping the IP. If that fails, I assume the console is off. If it succeeds I attempt to Get-ChildItem of the console share path.

This is the full script for the Scheduled task, but I think the issue I'm looking for has to do with Windows and the scheduled task's ability to maintain its connection. It is worth noting that this script had performed well (even without the pre-checks) for quite a while. So I think some windows update may have played a role.

function Do-Something {
  param($message, $event)
  $(Get-Date -format "MM-dd-yyyy - HH:mm") + " " + $message + " Event Triggered" | Out-file G:\Apps\Logging\SyncLog\EventTriggers.log -append
  $PathSuccess = Test-Path($DestFolder)
  $ConsoleResponding = Test-connection $ServerIP -count 1 -quiet "   " + $event.SourceEventArgs.FullPath | out-file G:\Apps\Logging\SyncLog\EventTriggers.log -append
  if ($PathSuccess) {
    "   " + $($DestFolder) + " was accessible, begin Mirror" | out-file G:\Apps\Logging\SyncLog\EventTriggers.log -append
    robocopy $watchedFolder $DestFolder /s /e /MIR /log +:G:\Apps\Logging\SyncLog\SyncLog.txt /R:0
  elseif($ConsoleResponding) {
    "   " + $($ServerIP) + " ping state was: $($ConsoleResponding)" | out-file G:\Apps\Logging\SyncLog\EventTriggers.log - append# a little more debugging effort
    get-childitem $DestFolder -ErrorAction SilentlyContinue -ErrorVariable GCIResult "   " + $($DestFolder) + " GCI error was: $($GCIResult.exception)" | out-file G:\Apps\Logging\SyncLog\EventTriggers.log -append

  else {
    "   " + $($DestFolder) + " was inaccessible, not copying" | out-file G:\Apps\Logging\SyncLog\EventTriggers.log -append

$watchedFolder = "F:\Shop2\PARTS TO CUT\Mill\NC_Released"
$ServerIP = ""
$DestFolder = "\\\D$\NC_Released\"
$watcher = New - Object System.IO.FileSystemWatcher
$watcher.Path = $watchedFolder

Register-ObjectEvent -InputObject $watcher -EventName Created -SourceIdentifier File.Created -Action {
  Do-Something "Created"
Register-ObjectEvent -InputObject $watcher -EventName Deleted -SourceIdentifier File.Deleted -Action {
  Do-Something "Deleted"
Register-ObjectEvent -InputObject $watcher -EventName Changed -SourceIdentifier File.Changed -Action {
  Do-Something "Changed"
Register-ObjectEvent -InputObject $watcher -EventName Renamed -SourceIdentifier File.Renamed -Action {
  Do-Something "Renamed"

$encodedBlock = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($block))
# Destroy previous watcher
$PrvSession = Import-Csv \\apps\Logging\SyncLog\process.csv
if (Get-Process -id $($ {
  Stop-Process -Id $
  $(Get-Date -format "MM-dd-yyyy - HH:mm") + " Task Starting Stopped Previous ProcessID: $($" | Out-file G:\Apps\Logging\SyncLog\EventTriggers.log -append
} else {
  $(Get-Date -format "MM-dd-yyyy - HH:mm") + " Previous Watcher not found: $($" | Out-file G:\Apps\Logging\SyncLog\EventTriggers.log -append

##for running as Sched task
$Watcher = Start-Process PowerShell.exe -verb Runas -argumentlist '-WindowStyle Hidden', '-NoExit', '-EncodedCommand', $encodedBlock - PassThru
$(Get-Date -format "MM-dd-yyyy - HH:mm") + " Watcher Started ProcessID: $($" | Out-file G:\Apps\Logging\SyncLog\EventTriggers.log -append
## Export the process id for future monitoring
$watcher | Export-Csv \\apps\Logging\SyncLog\process.csv

Previous thread

asked on Stack Overflow Jan 13, 2021 by John Nickell

0 Answers

Nobody has answered this question yet.

User contributions licensed under CC BY-SA 3.0