# 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**

![The wait operation timed out - Error Code: 258](https://cdn.manageengine.com/sites/meweb/images/desktop-central/help/configurations/custom_script.png)

## 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

**For Example**

If a script includes a pause command, it will only continue once the user manually presses "Enter." Since there is no one to do this when the script runs through Endpoint Central, this type of interaction is not supported.

**Note**

The sections below list common commands and strategies to correct in a script. The script should be reviewed and corrected so it runs fully unattended, with manual verification that everything works as expected before deployment.

## 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.

```powershell
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.

```powershell
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.

```powershell
# 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.

```powershell
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.

```powershell
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.

```powershell
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.

```powershell
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.

```batch
copy /Y source_file destination
xcopy /Y source_folder destination
```

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

```batch
del /Q file_to_delete
```

### Handle Inputs Without Prompting

Variables should be predefined instead of prompting the user:

```batch
set var=predefined_value
```

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

```batch
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.

```batch
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:

```batch
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:

```vbscript
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:

```vbscript
' 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.

**Note**

An attempt will be made to modify the script to eliminate user interaction, though this may take time depending on its complexity. If the script is very complex, it is recommended that it be modified directly to remove any user interaction.