Automatically Scripting Windows Startup Scripts and Shutdown Scripts using the Command Line

System Requirements:

  • Windows 2000, XP Professional, Vista Business, 7 Professional, 7 Enterprise, 8 Professional, 8 Enterprise, 8.1 Professional, 8.1 Enterprise, 10 Professional, 10 Enterprise
  • Windows Server 2000, 2003, 2008, 2008 R2, 2012, 2012 R2, 2016
  • Windows Scripting Host 5.8 or higher

The Problem:

It’s been a problem since 1999. You want to install a Startup or Shutdown Script on a local Windows machine without having to go through GPEdit.msc to manually populate the user interface necessary to install the script processing hook.

Well, now you can do it automatically!

More Info

So here is a VBScript api file which does the work for you to install either a Startup or Shutdown script from the command line. This installs the script as part of the Local Windows Group Policy processor, which on Domain Joined systems will be executed before Domain Logon Scripts.

  • No warranty is offered or implied. Use this script at your own risk
  • Please do not redistribute this script, please link to this page [Perma-link: http://www.c-amie.co.uk/qlink/?id=142]
  • You may not sell or profit from the use of this script
  • You may not bundle this script as part of an application deliverable or payload
If you found this useful, please consider making a donation or using the Amazon Affiliates Link to help support this site!

Download: AddLocalGpStartupScript.zip [4KB]

Usage

You can call the script from the Command Line or a bat (batch) file using the following syntax

cscript.exe AddLocalGpStartupScript.vbs <startup|shutdown> <path> <arguments>

You can view the help screen and examples at any time by calling

cscript.exe AddLocalGpStartupScript.vbs /?

Examples

Writes http://www.c-amie.co.uk/ to the file C:\LogFile.log during startup

cscript.exe AddLocalGpStartupScript.vbs startup "cmd.exe" "/c echo http://www.c-amie.co.uk>>C:\LogFile.log"

Opens C:\LogFile.log in Notepad during shutdown

cscript.exe AddLocalGpStartupScript.vbs shutdown "notepad.exe" "C:\LogFile.log"

Calls D:\Scripts\MyScript.cmd with no arguments during shutdown

cscript.exe AddLocalGpStartupScript.vbs shutdown "D:\Scripts\MyScript.cmd"

Executes the PowerShell Script C:\MyPsScript.ps1, ignoring the System Execution Policy during startup

cscript.exe AddLocalGpStartupScript.vbs startup "powershell.exe" "-ExecutionPolicy bypass -windowstyle hidden -file C:\MyPsScript.ps1"

Performing a Test

If you want a simple test to find out if it works, try the following which writes a log trace to two text files on the root of C Drive:

cscript.exe //NoLogo AddLocalGpStartupScript.vbs startup cmd.exe "/c echo %date% %time% startup>> c:\startup.log"

cscript.exe //NoLogo AddLocalGpStartupScript.vbs shutdown cmd.exe "/c echo %date% %time% shutdown>> c:\shutdown.log"

Why isn’t there a Logon and Logoff Script Version?

There is actually one and it doesn’t work. The process of installing the Logon Script isn’t quite a simple as the process for a Startup Script because it has to be written into the registry on each user account. Consequently, until such a time that I have the will to automate this part, while it performs the installation legally, it doesn’t execute unless you go in and press the apply button on the Logon Script UI.

PEAR for PHP Error “No releases available for package “xxx” install failed” after running ‘pear install xxx’ on Windows Server 2008

System Requirements:

  • Windows Vista
  • Windows 7
  • Windows Server 2008, 2008 R2

The Problem:

You know that something a bit odd is going on when one of a batch of servers starts throwing errors that the others sailed past. In this case trying to configure PEAR for a new PHP install with Mail, Mail_Mime and Net_SMTP (pear.php.net/mail, pear.php.net/mail_mime and pear.php.net/net_smtp) should be fairly standard. The other servers took the install and even this server too Mail and Mail_Mime but would not accept Net_SMTP returning:

C:\Program Files (x86)\PHP>pear install net_smtp
No releases available for package “pear.php.net/net_smtp”
install failed

Leaving it overnight before rolling up my sleeves (in case it was just downtime at the package repository) the fix was fairly simple.

The Fix

If you are experiencing the same problem this server was having, running the following

pear remote-list

Will result in

SECURITY ERROR: Will not write to C:\Users\<user[8.3]>\AppData\Local\Temp\pear\cache\e9b88593398eb79a9aa91024351d646arest.cacheid as it is symlinked to C:\Users\<user>\AppData\Local\Temp\pear\cache\e9b88593398eb79a9aa91024351d646arest.cacheid – Possible symlink attack

If you get something akin to the above simply browse to:

C:\Users\<user>\AppData\Local\Temp\

and delete the pear folder

Windows Vista & Windows 7 Implicit Answer File Search Order (Unattend.xml) Clarifying “Setup!UnattendFile”

System Requirements:

  • Windows Vista, SP1, SP2
  • Windows 7, SP1

The Problem:

A slight matter of a documentation error on TechNet that has existed for a very long time and is causing a lot of confusion.

More Info

TechNet states that the first and preferred search location for an Unattend.xml file is the registry location:

HKLM\System\Setup!UnattendFile

This is vague and confusing and is in fact probably typo that has been left for a long time. This could mean a value called Setup!UnattendFile under HKLM\System or a number of other things.

You can see the TechNet link below.

View: Manual Installation of Windows 7: Overview

The Fix

I can confirm from first hand experience with Vista, 7 and 7 SP1 that this should be:

Key: HKEY_LOCAL_MACHINE\System\Setup
Value Name [REG_SZ (String)]: UnattendFile
Value Data [e.g.]: C:\Windows\Setup\Scripts\MyUnattendFile.xml

Unattend.xml files found through this registry key do not have to be named Unattend.xml, you can call them whatever you like.

Error 0x80070005 when using SWbemLocator.ConnectServer to initiate a WMI session despite using the correct username and password

System Requirements:

  • WMI 1.5 or higher
  • Windows 95, 98, 98SE, Millennium
  • Windows NT 4.0, 2000, XP, 2003, Vista, 2008, 7

The Problem:

When using WMI’s SWbemLocator.ConnectServer class to log onto a remote system, you receive an 0x80070005 access denied error (Decimal -2147024891).

This error occurs even though the username and password are correct and the account credentials are synchronised properly between the local and remote machine – either by domain or manually in a workgroup.

More Info

The classfull connection line for using SWbemLocator is:

Set objWMIService = objSWbemLocator.ConnectServer(<computerName>, <wmiDefaultClassPath>, <username>, <password>)

for example:

Set objWMIService = objSWbemLocator.ConnectServer("192.168.0.100", "root\cimv2", "Administrator", "12345abcde")

The Fix

There is a very good chance that the problem you are having is to do with the username you are entering. You need to ensure that you are prefixing the username with the logon domain.

For example if your domain is camie.local your username should be camie\Administrator

Set objWMIService = objSWbemLocator.ConnectServer("192.168.0.100", "root\cimv2", "camie\Administrator", "12345abcde")

But I’m using a workgroup!

Don’t worry, you can do one of three things.

  1. Prefix the remote machine name (the local logon domain)
  2. Prefix the workgroup
  3. Send a null logon domain
Set objWMIService = objSWbemLocator.ConnectServer("192.168.0.100", "root\cimv2", "myHostName\Administrator", "12345abcde")

Set objWMIService = objSWbemLocator.ConnectServer("192.168.0.100", "root\cimv2", "workgroup\Administrator", "12345abcde")

Set objWMIService = objSWbemLocator.ConnectServer("192.168.0.100", "root\cimv2", "\Administrator", "12345abcde")

Using one of the above, you should be able to connect to the remote workstation. If you are dealing with a mix of workgroups or cannot know the hostname in advance I suggest using \<username> with I have tested to work on Windows 95 right through to Windows 7.