VBS Script Syntax Check

[CommodoreS]

I have found a very simple VBS script to register a DLL file that has become unregistered:

 

Set oShell = CreateObject("Wscript.Shell")
oShell.Run "RegSvr32 /s " & chr(34) & "%ProgramFiles%\Internet Explorer\ieproxy.dll" & chr(34)

 

If I want to register more than one DLL file in the same VB Script do I need to repeat both lines, or just the second one?

 

E.g. Will this work:

 

Set oShell = CreateObject("Wscript.Shell")
oShell.Run "RegSvr32 /s " & chr(34) & "%ProgramFiles%\Internet Explorer\ieproxy.dll" & chr(34) 
oShell.Run "RegSvr32 /s " & chr(34) & "%ProgramFiles(x86)%\Internet Explorer\ieproxy.dll" & chr(34)

 

Or does it need to look like this?

 

Set oShell = CreateObject("Wscript.Shell")
oShell.Run "RegSvr32 /s " & chr(34) & "%ProgramFiles%\Internet Explorer\ieproxy.dll" & chr(34)
Set oShell = CreateObject("Wscript.Shell")
oShell.Run "RegSvr32 /s " & chr(34) & "%ProgramFiles(x86)%\Internet Explorer\ieproxy.dll" & chr(34)

[Steve21]

First one. It's just basically setting a variable, should only need to change if if the object changes.

 

Steve

[ChrisH]

The first one is fine you can reuse the oShell object.

[mac_shinobi]

@Steve21

 

How does that vbs work with the environment variable. Ive always had to use the expand environment variable command to make it return the correct info for the path etc

[ChrisH]

@Steve21

 

How does that vbs work with the environment variable. Ive always had to use the expand environment variable command to make it return the correct info for the path etc

 

This is correct I missed that too ! It will need expanding first.

[mac_shinobi]

This is correct I missed that too ! It will need expanding first.

 

Prolly easier to make a bat file to register or un-register each / all of the relevant dll / ocx file types as you don't need to use the expandenviromentvariable command. If you wanted a vbscript to do it ( if you can post back with a list of dll file names and there full path(s)

 

I can post back with a script to do that unless @Steve21 or @ChrisH beat me to it

[Arthur]

Would this work?

 

On Error Resume Next

Dim strPFx86,strPFx64

Set oShell = Wscript.CreateObject("Wscript.Shell")
strPFx64 = oShell.ExpandEnvironmentStrings("%ProgramFiles%")
strPFx86 = oShell.ExpandEnvironmentStrings("%ProgramFiles(x86)%")

oShell.Run "RegSvr32 /s " & chr(34) & strPFx64 & "\Internet Explorer\ieproxy.dll" & chr(34) 
oShell.Run "RegSvr32 /s " & chr(34) & strPFx86 & "\Internet Explorer\ieproxy.dll" & chr(34)

[mac_shinobi]

Would this work?

 

On Error Resume Next

Dim strPFx86,strPFx64

Set oShell = Wscript.CreateObject("Wscript.Shell")
strPFx64 = oShell.ExpandEnvironmentStrings("%ProgramFiles%")
strPFx86 = oShell.ExpandEnvironmentStrings("%ProgramFiles(x86)%")

oShell.Run "RegSvr32 /s " & chr(34) & strPFx64 & "\Internet Explorer\ieproxy.dll" & chr(34) 
oShell.Run "RegSvr32 /s " & chr(34) & strPFx86 & "\Internet Explorer\ieproxy.dll" & chr(34)

 

Do you even have to ask, 99.9% of the stuff you post or suggest works lol

[CommodoreS]

The other two I need to register are:

 

oShell.Run "RegSvr32 /s " & chr(34) & "%SystemRoot%\System32\actxprxy.dll" & chr(34)
oShell.Run "RegSvr32 /s " & chr(34) & "%WinDir%\SysWOW64\actxprxy.dll" & chr(34) 

 

Re-registering these two (four - as two are for 32 bit and two are for 64 Bit) solves an issue where double clicking on a Windows Explorer folder will cause it to open in a new window - even if the explorer settings are set to tell it not do so.

 

Although I also have a 2Simple OCX/DLL problem elsewhere and think I can work out from this how to adapt the VBS script to fix the issue there.

 

I probably could use a Batch file - but guessing the VBS file will do the same thing - as long as I place it in a Computer Configuration startup script in the AD.

Edited June 12, 2013 by CommodoreS

[mac_shinobi]

Something like this :

 

On Error Resume Next

Dim strPFx86,strPFx64, winx86, winx64

Set oShell = Wscript.CreateObject("Wscript.Shell")
strPFx64 = oShell.ExpandEnvironmentStrings("%ProgramFiles%")
strPFx86 = oShell.ExpandEnvironmentStrings("%ProgramFiles(x86)%")
winx86 = oShell.ExpandEnvironmentStrings("%SystemRoot%")
winx64 = oShell.ExpandEnvironmentStrings("%WinDir%")

oShell.Run "RegSvr32 /s " & chr(34) & strPFx64 & "\Internet Explorer\ieproxy.dll" & chr(34) 
oShell.Run "RegSvr32 /s " & chr(34) & strPFx86 & "\Internet Explorer\ieproxy.dll" & chr(34)
oShell.Run "RegSvr32 /s " & chr(34) & winx86 & "\System32\actxprxy.dll" & chr(34)
oShell.Run "RegSvr32 /s " & chr(34) & winx64 & "\SysWOW64\actxprxy.dll" & chr(34)

 

Might want to test this on one client by running the script manually on the client first to make sure it does work correctly without errors, possibly comment out the on error resume next line though

[mac_shinobi]

Not related to the script but just a quick question to @Arthur

 

Would it make any difference between this :

 

 

Set oShell = Wscript.CreateObject("Wscript.Shell")

 

OR This

 

Set oShell = CreateObject("Wscript.Shell")

[CommodoreS]

Something like this :

 

On Error Resume Next

Dim strPFx86,strPFx64, winx86, winx64

Set oShell = Wscript.CreateObject("Wscript.Shell")
strPFx64 = oShell.ExpandEnvironmentStrings("%ProgramFiles%")
strPFx86 = oShell.ExpandEnvironmentStrings("%ProgramFiles(x86)%")
winx86 = oShell.ExpandEnvironmentStrings("%SystemRoot%")
winx64 = oShell.ExpandEnvironmentStrings("%WinDir%")

oShell.Run "RegSvr32 /s " & chr(34) & strPFx64 & "\Internet Explorer\ieproxy.dll" & chr(34) 
oShell.Run "RegSvr32 /s " & chr(34) & strPFx86 & "\Internet Explorer\ieproxy.dll" & chr(34)
oShell.Run "RegSvr32 /s " & chr(34) & winx86 & "\System32\actxprxy.dll" & chr(34)
oShell.Run "RegSvr32 /s " & chr(34) & winx64 & "\SysWOW64\actxprxy.dll" & chr(34)

 

Might want to test this on one client by running the script manually on the client first to make sure it does work correctly without errors, possibly comment out the on error resume next line though

 

I think strPFx64 andstrPFx86 are pointing to the wrong directories - should not matter for this, but may do if others modify this to register other files. ProgramFiles(x86) is normally seen on x64 systems and ProgramFiles on x86 systems.

 

Also not had a chance to test this yet (need to find another system which has this problem, as it now seems a bit random) - but also not sure if the spaces between the DIM variables will make any difference.

[mac_shinobi]

1. You will need to adjust the variables / paths so they point to the correct paths for the relevant files ( where ever the files are actually located ) that you are trying to register / un-register etc. So that way each path is the full path to where the file(s) in question are.

 

2. No the spaces are just ignored, so if you want you could delete the spaces between the variables, as long as there is a comma between each of the variable names ie

 

var1,var2 versus var1 , var2

[Arthur]

I think strPFx64 and strPFx86 are pointing to the wrong directories

They're not (if you are using a 64-bit OS).

 

strPFx64 = %ProgramFiles% because that's where 64-bit programs get installed.

strPFx86 = %ProgramFiles(x86)% because that's where 32-bit programs get installed.

 

Obviously, the "Program Files (x86)" folder and variable only exists on 64-bit windows OSs, so you could perform an additional check before trying to register the DLL file. You could also rename strPFx64 to strPF.

 

not sure if the spaces between the DIM variables will make any difference.

@mac_shinobi is right. It doesn't make any difference.

Edited June 13, 2013 by Arthur

[CommodoreS]

They're not (if you are using a 64-bit OS).

 

strPFx64 = %ProgramFiles% because that's where 64-bit programs get installed.

strPFx86 = %ProgramFiles(x86)% because that's where 32-bit programs get installed.

 

Obviously, the "Program Files (x86)" folder and variable only exists on 64-bit windows OSs, so you could perform an additional check before trying to register the DLL file. You could also rename strPFx64 to strPF.

 

Sorry I meant on 32 bit OSs which the OSs still are (I guess this can be looked at in two ways and I have looked at it the other way) - I want to add the 64 bit stuff for futureproofing though. I will just leave it as is

[mac_shinobi]

Sorry I meant on 32 bit OSs which the OSs still are (I guess this can be looked at in two ways and I have looked at it the other way) - I want to add the 64 bit stuff for futureproofing though. I will just leave it as is

 

Not sure how reliable vbs is with regards to checking if the OS is 32 bit or 64 bit, however could possibly include that to check if the OS is 64 or 32 bit and then you would be able to use the relevant directories from there with regards to a 64 bit program files vs 32 bit program files etc or any other directories that have there own path for 32 or 64 bit OSes ?