The Wait Operation Timed Out (Error Code 258)

Problem

A script deployed through Endpoint Central doesn't finish executing. There's no visible prompt or pop-up on the user's screen and nothing seems to be happening. After some time, the deployment fails anyway, with the error:

The wait operation timed out - Error Code: 258

Cause

By default, Endpoint Central allows a script 60 minutes to complete execution. When a script is run manually by a user, it works fine because there's no such time restriction and the user can respond to any prompt whenever they choose.

However, when the same script is deployed through Endpoint Central, it runs in a non-interactive context with this 60-minute limit. If the script contains any command that requires user interaction to proceed even if no visible UI actually appears on the endpoint it will silently wait for input that never comes, and time out once the 60 minutes are up.

How to avoid this

User interaction must be bypassed by handling it directly within the script itself, so the script can run unattended from start to finish.

The script should avoid operations such as the ones below. These are common examples, and other similar commands may also apply:

• Pause
• Message boxes
• Prompts expecting a Yes/No response
• Wait commands that depend on user input

PowerShell Scripts

To avoid user intervention in PowerShell, the script should be able to run autonomously without prompting for input.

Use Parameters Instead of Prompts

Parameters should be defined so required inputs are supplied at execution time rather than prompted for.

param(
    [string]$FilePath,
    [string]$Destination
)

# Use $FilePath and $Destination in your script

Provide Default Values

Default values should be set for parameters so the script can run with minimal or no user input.

param(
    [string]$FilePath = "C:\default\path.txt",
    [string]$Destination = "C:\default\destination"
)

# Use $FilePath and $Destination in your script

Avoid Read-Host

Read-Host prompts the user for input. It should be replaced with parameters or predefined values instead.

# Instead of this:
$username = Read-Host "Enter username"

# Use this:
param(
    [string]$Username
)

Use -Confirm:$false

For cmdlets that show confirmation prompts, -Confirm:$false should be added to bypass them.

Remove-Item -Path "C:\path\to\file.txt" -Confirm:$false

Handle Errors Gracefully

The script should handle errors on its own and not require user input to continue.

try {
    # Your code here
}
catch {
    Write-Error "An error occurred: $_"
    # Handle the error or exit
    exit 1
}

Suppress Output When Necessary

When running in the background or as a scheduled task, output should be redirected or suppressed instead of displayed.

Start-Process -FilePath "C:\path\to\program.exe" -NoNewWindow -RedirectStandardOutput "C:\path\to\output.log" -RedirectStandardError "C:\path\to\error.log"

Handle Wait / Sleep Operations Carefully

Wait operations that depend on user input should be avoided. Where a script needs to pause for a fixed duration, a time-based wait should be used instead of an interactive one.

Start-Sleep -Seconds 10

-Wait

Batch Scripts

In batch scripting, avoiding user intervention means automating tasks and suppressing prompts or inputs.

Suppress Confirmation Prompts

• The script should start with @echo off to prevent command echoing and keep output clean.
• The /Y switch should be used with copy and xcopy to overwrite files without prompting.

copy /Y source_file destination
xcopy /Y source_folder destination

The /Q switch should be used with del to suppress prompts when deleting files.

del /Q file_to_delete

Handle Inputs Without Prompting

Variables should be predefined instead of prompting the user:

set var=predefined_value

Or input can be redirected from a file to supply values automatically:

some_command < input_file.txt

Handle Errors Without User Interaction

exit /b should be used to exit a script or subroutine without requiring input, with error levels checked to handle failures automatically.

some_command || (echo An error occurred & exit /b 1)

Avoid pause

Pause commands should be removed. Pause waits for user input and should be avoided in scripts meant to run unattended.

Automate Any Required Inputs

If a command expects input, it can be simulated using echo and a pipe instead of waiting for the user to type it:

echo value | some_command

VBS Scripts

To avoid user intervention in VBScript, the following should be applied depending on what the script needs to do.

Suppress Prompts

If the script is running commands that produce prompts, these can usually be suppressed by modifying the command-line options or using silent flags. Many command-line utilities support a /quiet or /s switch to run without user interaction.

Handle Errors Silently

Errors should be handled without requiring user input:

On Error Resume Next
' Your code here
If Err.Number <> 0 Then
    ' Handle error or log it
    Err.Clear
End If

Automate Inputs

If a script requires inputs, they can be provided programmatically:

• Default values can be used, or necessary input values can be hard-coded directly in the script if possible.
• Command-line arguments can be used to pass values to the script:

' Example.vbs
If WScript.Arguments.Count > 0 Then
    Dim arg
    arg = WScript.Arguments(0)
    ' Use arg in your script
End If

Avoid Dialogs

The script should not trigger any dialogs or windows for example, MsgBox or any command that requires user input should be avoided.

Test and Validate

Before deploying through Endpoint Central, the script should be tested thoroughly in a non-production environment to confirm it runs to completion without any user intervention.