I am trying to write a VBS script that install an USB/Ethernet adapter on Windows 7.
I've got a .INF file for this device.
I first tried:
Dim WshShell, res
Set WshShell = WScript.CreateObject("WScript.Shell")
res = WshShell.Run(WshShell.ExpandEnvironmentStrings( "%SystemRoot%" ) & "\System32\InfDefaultInstall.exe "" C:\Users\Me\Driver.inf """, 1, True)
res equaled 2.
Then I searched another way to do that and I found:
Dim WshShell, res
Set WshShell = WScript.CreateObject("WScript.Shell")
res = WshShell.Run(WshShell.ExpandEnvironmentStrings( "%SystemRoot%" ) & "\System32\rundll32.exe SETUPAPI.DLL,InstallHinfSection DefaultInstall 132 ""Driver.inf""", 1, True)
res equals 0 but I've got an error popup Installation failed.
What's wrong with my code? For the record, the script is launched with administration rights.
EDIT
I've tried to execute the first command directly in prompt and got: The inf file you selected does not support this method of installation..
Nothing happens with second command in prompt.
This is very weird because I can install the driver "manually" when I launch the device manager and select the inf file (with a warning: Windows can't verify the publisher of this driver software.):
Once the driver is installed, the class installer property shows NetCfgx.dll,NetClassInstaller. Could it be used?
I also tried with devcon with no success (program returns devcon.exe failed).
How about this way:
1)If you're using "Windows 7", why not take advantage of the driver pre-staging utility that is built right into the OS? W7 ships with a driver utility called "PNPUTIL". Issuing a command as such will add the drivers:
PNPUTIL -a "X:\Path to Driver File\Driver.inf"
This will process the INF and copy the CAT/SYS/INF (and any DLL, EXE, etc) into the "DriverStore" folder... which is the same place Windows stores all the in-built drivers ready for auto plug-and-play instalaltion.
2)If that's not an option for you, look for "DPInst.exe" (or "DPInst64.exe" for 64-bit systems). These are available as part of the Windows PDK (available free from Microsoft) and will process all INFs in the location you put the file and attempt to pre-stage them. This method tries to copy files to the "Drivers", "CatRoot", and "INF" locations which are not as reliable... and it can occassionally fail to copy required DLLs to "System32" folders etc... but 99% of the time (for simple drivers) it just works. I can arrange to send them to you if you can't find them.
Since I found the option (1) above, that has been my best friend. I use option 2 to isntall Canon USB printers and scanners on our base images, etc... so I know that works too.
I had same problem and solved it by explicitly using ASCII version of InstallHinfSection entry point:
res = WshShell.Run("%Comspec% /C %SystemRoot%\System32\rundll32.exe SETUPAPI.DLL,InstallHinfSectionA DefaultInstall 132 ""Driver.inf""", 1, True)
There is probably a better solution, though (like hinting at the script engine which unicode/ASCII flavor to use).
Also I'm using EN-US system so this workaround may fail on more exotic locales.
Try this:
res = WshShell.Run("%Comspec% /C %SystemRoot%\System32\rundll32.exe SETUPAPI.DLL,InstallHinfSection DefaultInstall 132 ""Driver.inf""", 1, True)
Related
I have made the following script in VBS but although it does work in windows xp & vista, I cant get it to work in win7 both 32 & 64 bit.
set myclip = createobject("clipbrd.clipboard")
bcode = myclip.gettext
if len(bcode) > 0 then
set wb = getobject("C:\DB.xlsx")
wb.sheets("1").range("a2").value = bcode
myclip.clear
myclip.settext wb.sheets("1").range("c2")
set wb = nothing
end if
set myclip = nothing
Through elevated cmd regsvr32 I get the
Regsvr32 DllRegisterServer in clipboard.dll succeded.
However when I try to run the vbs I get the following error:
Line: 1 Char: 1 ActiveX component can't create object 'clipbrd.clipboard' Code: 800A01AD S
Any ideas how to get passed it?
If it registered, but can't be instantiated there may be something it expects to be able to access during creation that it cannot access. There is a comment where you got this from:
"Note the constants i copied from msdn may not all be correct, or are outdated, see
http://msdn.microsoft.com/en-us/library/ebwdx8yh.aspx"
Based on that I suspect that one of the constant he copied from msdn is no longer available in Windows 7, or has changed, and that because of that it throws an error during creation.
Just a guess, but worth checking if you have VBS source.
In Windows RT on a Surface tablet, I'm running a VB script that fails on the first line which is:
Set WshShell = WScript.CreateObject("WScript.Shell")
The error message says:
Could not create object WScript.Shell with the error code: 80070005
This seems to be a generic error code having to do with access permissions. Any ideas?
I am running with admin privileges.
Windows RT (also known as Windows 8 RT, Windows 8.1 RT, and Surface RT) uses User Mode Code Integrity (UMCI) to restrict the software that is allowed to run.
In the case of VBScript, the Code Integrity component of UMCI only allows creation of "enlightened" COM objects.
"Which COM objects are enlightened?" you ask. Good question. Let's use PowerShell on our Windows RT device to help us find out.
$arrInstances = #(Get-WMIObject -ClassName 'Win32_COMSetting')
$arrCOMObjectProgIDs = #($arrInstances | Where-Object { $null -ne $_.ProgId } |
ForEach-Object { $_.ProgId })
$ErrorActionPreference = [System.Management.Automation.ActionPreference]::SilentlyContinue
$result = #($arrCOMObjectProgIDs | ForEach-Object { if (New-Object -ComObject $_) { $_ } })
$result
On my fully-patched Surface 2 device, as of today, 2021-Jan-17, the only enlightened COM objects with a ProgID (i.e., the only ones callable from VBScript on Windows RT) are:
Scripting.FileSystemObject
VBScript.RegExp
Scripting.Dictionary
It is not possible to create other VBScript objects (e.g., WScript.Shell, WScript.Network, WinNTSystemInfo, Wbemscripting.SWbemLocator, etc.) on Windows RT due to User Mode Code Integrity (UMCI).
For a more-robust version of the above code, check out my script "Get-COMObjectsProgIDsAllowedToLaunch.ps1" posted to my GitHub repo: https://github.com/franklesniak/PowerShell_Resources
I've seen in a few places people commenting that RT doesn't allow VBScript to run WScript.Shell, though I've not found any official documentation to that effect.
It may just be that the script needs to run with Admin privileges.
I need to identify the CD drive and eject the tray. This is executed while booted in WinPE, so the WMP eject function is not available. This script will be used on various computer models/configurations. I'm currently using this:
For Each d in CreateObject("Scripting.FileSystemObject").Drives
CreateObject("Shell.Application").Namespace(17).ParseName("D:\").InvokeVerb("Eject")
Next
It works, but sometimes it errors and requires user interaction before it ejects. I suspect that it's because of the hardcoded D:\ drive letter, but I could be completely wrong. I need this to work without 3rd party utilities.
Use the DriveType property of the Drive object:
For Each d in CreateObject("Scripting.FileSystemObject").Drives
WScript.sleep 60
If d.DriveType = 4 Then
CreateObject("Shell.Application").Namespace(17).ParseName(d.DriveLetter & ":\").InvokeVerb("Eject")
End If
Next
Here is code that uses Media Player to eject; I'm not sure how easy it would be to invoke from your WinPE environment:
' http://www.msfn.org/board/topic/45418-vbscript-for-openingclosing-cd/
' http://waxy.org/2003/03/open_cdrom_driv/
Set oWMP = CreateObject("WMPlayer.OCX.7" )
Set colCDROMs = oWMP.cdromCollection
For d = 0 to colCDROMs.Count - 1
colCDROMs.Item(d).Eject
Next 'null
Plan B would be to download a copy of "eject.exe", and include it on your WinPE media:
http://www.911cd.net/forums/index.php?showtopic=2931&hl=cd+eject
What I am trying to achieve I feel should be fairly simple yet it is driving me totally insane.
Background:
We run a system monitoring tools across our clients which has the ability to run .vbs scripts remotely. This works very well normally.
What I am trying to achieve currently is being able to read a line from the registry on both 32bit versions of windows and 64 bit versions.
The Client side.exe which monitors the machine runs as a 32bit process on BOTH platforms (This is the trick).
I want to read a key from HKEY_LOCAL_MACHINE\SOFTWARE\ for example. My script works perfectly fine on 32bit. example: objRegistry.RegRead("HKEY_LOCAL_MACHINE\Software\anything")
The problem I have is when I run this same line on a 64bit folder is is automatically looking in the wow64node folder. Example: objRegistry.RegRead("HKEY_LOCAL_MACHINE\Software\wow64node\").
I need to have it checking in EXACTLY the same place.
The key it is reading is part of a program that runs both 32bit and 64bit versions which is why it is not installed in the wow64node folder.
At this point I am unable to run the .VBS script as a 64bit process which would solve my problem entirely as it would then not look in the wow64node folder.
If anyone has any ideas at all please let me know.
I solved it using this piece of code.
Const HKEY_LOCAL_MACHINE = &H80000002
sPath = ReadRegStr (HKEY_LOCAL_MACHINE, "SOFTWARE\Microsoft\ASP.NET\2.0.50727.0", "Path", 64)
WScript.Echo sPath
' Reads a REG_SZ value from the local computer's registry using WMI.
' Parameters:
' RootKey - The registry hive (see http://msdn.microsoft.com/en-us/library/aa390788(VS.85).aspx for a list of possible values).
' Key - The key that contains the desired value.
' Value - The value that you want to get.
' RegType - The registry bitness: 32 or 64.
'
Function ReadRegStr (RootKey, Key, Value, RegType)
Dim oCtx, oLocator, oReg, oInParams, oOutParams
Set oCtx = CreateObject("WbemScripting.SWbemNamedValueSet")
oCtx.Add "__ProviderArchitecture", RegType
Set oLocator = CreateObject("Wbemscripting.SWbemLocator")
Set oReg = oLocator.ConnectServer("", "root\default", "", "", , , , oCtx).Get("StdRegProv")
Set oInParams = oReg.Methods_("GetStringValue").InParameters
oInParams.hDefKey = RootKey
oInParams.sSubKeyName = Key
oInParams.sValueName = Value
Set oOutParams = oReg.ExecMethod_("GetStringValue", oInParams, , oCtx)
ReadRegStr = oOutParams.sValue
End Function
Thank you Helen for your help!
Instead of WshShell.RegRead, use the WMI StdRegProv class — it allows you to specify whether you want to read from the 32-bit or 64-bit registry. Check out this MSDN article for more info and examples:
Requesting WMI Data on a 64-bit Platform
I found an idea for scripting the installation of IIS7 on Vista
I'm looking for a similar solution for IIS 5.1 on Windows XP. Any ideas?
Create your unattend text file. Check the following document on the Windows
Server CD for all relevant options:
support\tools\deploy.cab -- unattend.doc on W2K, or ref.chm for XP/W2K3
It looks something like this; here are some common ones you can pick from:
[Components]
iis_common = ON
iis_inetmgr = ON
iis_www = ON
iis_ftp = ON
iis_doc = ON
iis_htmla = ON
iis_pwmgr = ON
mts_core = ON
fp = OFF
fp_extensions = OFF
iis_smtp = OFF
iis_nntp = OFF
2.
Set Registry key at
HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\SourcePath = ""
i.e.
SourcePath="\server\share"
where \server\share\i386 contains Windows files.
3.
Run:
SYSOCMGR.EXE /i:sysoc.inf /r /n /u:
Make sure the identity which runs this command has access to \server\share
--