A user reports that a VBScript logon script that maps network drives stopped working after a Windows update. The script uses the MapNetworkDrive method. Other scripts on the same computer work fine. What is the most likely cause?
Trap 1: The script file was deleted by Windows Defender.
While Windows Defender is designed to protect against malicious software, it typically does not silently delete legitimate logon scripts without specific user interaction or a definitive malware detection. If a script were deemed suspicious, Defender would more likely quarantine it, notify the user, or block its execution rather than outright deleting a file that is part of a standard logon process within an enterprise environment. Such an action would usually generate an alert in the Windows Security log or Defender's history.
Trap 2: The update changed the default script host to PowerShell.
Windows maintains specific file associations for different script types, and VBScript files (.vbs) are inherently associated with either `wscript.exe` (for GUI interaction) or `cscript.exe` (for command-line execution). A standard Windows update does not fundamentally alter these core system associations by reassigning the default script host for VBScript to PowerShell. PowerShell uses its own execution engine (`powershell.exe`) for .ps1 scripts, and these distinct script environments are not interchangeable by default through system updates.
Trap 3: The network share requires SMB 2.0, which is no longer supported.
SMB 2.0 is a robust and widely supported network file sharing protocol that has been a standard in Windows environments for many years, succeeding the deprecated SMB 1.0. Therefore, the assertion that SMB 2.0 is no longer supported is incorrect; it remains fully functional and commonly used. Furthermore, if there were an issue with SMB connectivity, it would manifest as a general inability to access network shares and resources, affecting all network-dependent operations, not just the execution of a VBScript logon script specifically.
- A
The script file was deleted by Windows Defender.
Why wrong: While Windows Defender is designed to protect against malicious software, it typically does not silently delete legitimate logon scripts without specific user interaction or a definitive malware detection. If a script were deemed suspicious, Defender would more likely quarantine it, notify the user, or block its execution rather than outright deleting a file that is part of a standard logon process within an enterprise environment. Such an action would usually generate an alert in the Windows Security log or Defender's history.
- B
The update changed the default script host to PowerShell.
Why wrong: Windows maintains specific file associations for different script types, and VBScript files (.vbs) are inherently associated with either `wscript.exe` (for GUI interaction) or `cscript.exe` (for command-line execution). A standard Windows update does not fundamentally alter these core system associations by reassigning the default script host for VBScript to PowerShell. PowerShell uses its own execution engine (`powershell.exe`) for .ps1 scripts, and these distinct script environments are not interchangeable by default through system updates.
- C
The update disabled VBScript execution for security reasons.
Microsoft has progressively implemented stricter security measures, which include restricting or disabling VBScript execution in various contexts due to its historical use as an attack vector. Recent Windows updates can introduce or enforce Group Policy settings or registry changes that specifically disable VBScript execution, particularly for scripts originating from less trusted zones or those not explicitly signed. This security hardening aims to reduce the attack surface, preventing older, less secure scripting technologies from being exploited.
- D
The network share requires SMB 2.0, which is no longer supported.
Why wrong: SMB 2.0 is a robust and widely supported network file sharing protocol that has been a standard in Windows environments for many years, succeeding the deprecated SMB 1.0. Therefore, the assertion that SMB 2.0 is no longer supported is incorrect; it remains fully functional and commonly used. Furthermore, if there were an issue with SMB connectivity, it would manifest as a general inability to access network shares and resources, affecting all network-dependent operations, not just the execution of a VBScript logon script specifically.