Login script that checks current IP address to a load certain script

I just thought the other day about how we have been using something very handy at work for quite some time now that I have never thought to post. We use a class C network, and each branch/location, as well as each floor of our corporate center, are on different subnets for the third octet of the IP address (EG: 123.123.XXX.xxx). This is a Windows domain, with XP pro loaded on the client stations.

Each branch has their own files as well as a core piece of software that loads off of network drives that are stored of that location’s local server. We use .BAT login scripts for each location that map the proper drives and whatever else is needed for that location. This was working fine, until we ran into the issue of users wandering to locations different than their home branch. They would sign in as themselves, which -never mind roaming profile issues-, would cause them to load the login script for their home location which would not be of much help at their present local.

My boss and I did a little research; and poached, and customized, some handy code of the interwebz that would allow us to give users a generic .VBS script in active directory that would check what network they were in and then call the appropriate batch file that would map their drives. The .VBS script is saved in the same replicated folder on the domain controllers as the rest of .BAT script files are.

Here’s the code, including the original author’s (of part of this script anyway) comments:

‘Go and get the IP address of the current machine
Set objWMIService = GetObject(“winmgmts:\\” & strcomputer & “\root\CIMV2”)
Set IPItems = objWMIService.ExecQuery (“Select IPAddress from Win32_NetworkAdapterConfiguration where IPEnabled=TRUE”)
For Each IPConfig In IPItems
If Not IsNull(IPConfig.IPAddress) Then
For i=LBound(IPConfig.IPAddress) to UBound(IPConfig.IPAddress)
If varIP=”” Then
End If
End If

‘Split the IP address up into 4 separate parts and put it into an array

‘Create a variable containing the 3rd octet of the IP address

‘Check value of varThirdOctet and run appropriate code
Select Case True
Case varThirdOctet=”100″
Set WshShell = WScript.CreateObject(“WScript.Shell”)
WshShell.Run “SCRIPTA.BAT”

Case varThirdOctet=”2″
Set WshShell = WScript.CreateObject(“WScript.Shell”)
WshShell.Run “SCRIPTB.BAT”

End Select

The initial portion of the code basically looks at the network adapter and reads it’s current assigned IP address. It then splits the four octets into an array that we can load into variables. It then checks this variable against the list of possible matches in the select case segment and calls the batch file associated with that network when it finds a match. You can put more than just two choices in the select case, obviously, but I used two for this example. Remember that when working with an array, the it starts with 0 and not 1, so the third octet of our IP address is in “part 2” of the array.

You may have noticed in the code above that I also added a variable for the second octet. This year I have been working (almost done actually) on changing our networks to conform to best practice. Our first two octets were not proper numbers for an LAN IP address, and many of our locations had incorrect and/or completely illogical numbers for the third octet as well. We are now using the actual branch number as the third octet for all of our branch numbers.

In working on this project, I ran into the issue that when changing certain branches over to the new network the third octet would be the same as another location still on the old network. This would pretty much break the script’s concept, as it would simply load the first case in line that had the matching number. I got around this problem by simply adding a check for the second octet (which was also changed when I flipped a branch over) that would differentiate between the two networks in the case of a duplicate third octet. In the example below, we look at both the second and third octets to match a certain value to load the proper script:

Case varThirdOctet=”11″ And varSecondOctet=”1″
Set WshShell = WScript.CreateObject(“WScript.Shell”)
WshShell.Run “SCRIPTC.bat”

Case varThirdOctet=”11″ And varSecondOctet=”2″
Set WshShell = WScript.CreateObject(“WScript.Shell”)
WshShell.Run “SCRIPTD.bat”

Note that the third octet we’re looking at for both these example locations are the same but the second octet is different, so we use the “and” modifier to ensure that the right script is loaded for the right network. There is no reason why you cannot take this a step further and look at more of the octets by adding another variable and extending the cases, as the whole IP address is already loaded into the array “ArrayIP”.

Disclaimers: I have rather limited knowledge of VBscript (and programing in general) and mostly muddle my way through this stuff, so I am no expert, and you should not look at this script as though it were written by one. This is used in a Windows domain environment with a Windows 2003 or 2008 domain controller at each location with the client PCs that are loading the script being Windows XP SP2 or SP3. I have not yet tested this script with Windows 7, or any other operating systems other than the ones listed above. I did not write the above code completely myself, rather I retrieved most of it off of the internet and modified it with my limited understanding of VBscript to suit our needs. I do not know the names of any of the original authors.


Excel 2003 hanging on network files and automated removal of Office updates

We had an issue at work that just popped up this week. While trying to open an Excel (.xls) document over the network (a file stored on a network share), and while using Office Excel 2003 (2000 and 2007 versions had no problems), the file would hang. Smaller Excel files would take quite a bit longer to load, while a larger one (~4mb) would just hang the program. The same files would open just fine if you first copied them to the local disk.

This happened abruptly at the end of last week. There were no new Windows or any other updates/changes that corresponded to the timing of the issue. After some googling, I found many others that had the issue, as well as a few different solutions.

The solution that worked for us was to close out all Office programs and IE and uninstall these two Office Updates: KB2541025 and KB2509503, in that order. We then set the two updates to declined on our WSUS server, so they would not get pushed out again.

It is strange that these two updates would suddenly break Excel, considering they were installed months ago, but I’m not one to argue with results. This was an easy fix, but as more people report the problem, going to each station and manually uninstalling these is going to be a pain, especially if the user is offsite and you have to remote in.

So I looked up a method to automate the process. I found these two links from Microsoft themselves to be surprising helpful. http://support.microsoft.com/kb/903771 and http://support.microsoft.com/kb/832672

In reading those pages I learned the fairly simple commands to create a batch file that would uninstall the two updates automatically without requiring much user (or administrator) action.

Here’s the batch file, you’ll still want to close out of all Office products and IE before running it:

msiexec /package {90110409-6000-11D3-8CFE-0150048383C9} /uninstall {D1CCA188-7FE2-49A0-8FE5-B5A34054F9ED} /passive
msiexec /package {90110409-6000-11D3-8CFE-0150048383C9} /uninstall {BCBA2E91-F93F-4501-9FBA-5AD21606920A} /passive

The first string of hex on each command is the product code GUID, in this case for Office 2003 Professional Edition. I found this by searching the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall section of the registry for “Office”, and found my product. In this case, the ID is the same for both commands.

The second strings represent the updates themselves. Using this method, you don’t need to worry about a file path, Windows will know what update that is, and if it is installed it will remove it. If not, it will do nothing. I found those two hex strings by going to add/remove programs and with “show updates” checked, drilling down to the offending updates, then I highlighted them and clicked on the “click here for support information” link. The value for “Update ID” will be your string.

I tossed a /passive on the commands so that they will run silently. All the user should see is the command box running the commands. So this can be added to a login script, or you can simply have the user launch the batch file off of a network share. This was tested/designed with Windows XP SP3 and Office 2003 Professional. I don’t see why a similar technique couldn’t be used for other products and updates, but I cannot promise it will work the same.

Windows XP reboots when a USB device is connected

I’ll keep this one short, because it’s really a lazy band-aid sorta fix more than anything, but I’ve been meaning to post it. We had some newly imaged HP 6000 pro towers here at work that would constantly reboot when any USB device was connected to the PC. I forget what the BSoD message was when we turned off the reboot on error.

Anyway, I learned that it was probably related to a SP3 driver and it was suggested that you replace the file: C:\WINDOWS\system32\drivers\usbport.sys with a copy of the same file off of a XP machine with SP2 installed.

As I said, this is more of a half-ass fix. I ended up creating a new image from scratch for the rest of the PCs of this model and they no longer require this hack. But if you have a trouble PC or more you need to get up with a USB device, try this out. So far I haven’t seen any side effects with the 12 stations we used this little trick on. Not sure exactly what causes it to begin with though though. Probably a botched Windows update, but I had never seen this happen before.

-Dave out

Script to Check Adobe Version and update if needed

Here you are Mike, I’ve played with a few scripts and had great results… but this one has to be my crowning achievement at this point.

Some background info first: We needed most of our PCs to have Adobe Reader version 8.1.4 installed. We have automatic updates for adobe blocked on the firewall, and we also couldn’t install 9.0 because it would not be supported by another piece of software. Some of the PCs still had adobe reader 7.0, most had 8.0 or 8.1. I wanted a script that got called in a login script and checked what version they had and ran a silent install of adobe 8.1.4 if needed.

First, I got myself a full exe of Adobe 8.1.3 (for some annoying reason you can only patch to 8.1.4 from 8.1.3, and there is no full install of 8.1.4). I used resources that adobe themselves provide to make a custom msi package and also set it to include the separate 8.1.4 patch. This all gets dumped into a directory on a network share that all users have access to.

I then added this line to the users login scripts (batch files) to call the script:

cscript “\\LocalServer\share\folder\adberdr81Silent\setup files\adobe814.vbs” /quiet /passive

This calls the script silently and does not ask the user if they want to run or whatever other BS safety messages Windows XP vomits at you normally when you run a file off the network.

Now the VBscript (script in blue, my comments for this post in normal):

Dim FilePath
Dim fso
Dim version
Dim WshShell

Set objFSO = CreateObject(“Scripting.FileSystemObject”)

If objFSO.FileExists(“c:\program files\adobe\reader 8.0\reader\acrord32.exe”) Then
Set objNet = WScript.CreateObject(“WScript.Network”)
strCaption = “Adobe Reader”
Set objWMI = GetObject(“winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2”)
For Each objSoftware in objWMI.ExecQuery(“SELECT * FROM Win32_Product Where Caption Like ‘%” & strCaption & “%'”)
version = objSoftware.Version

^ This says look to see if the folder for adobe 8.0 exists on the local C:, and if it does, it searches the registry for what exact version it is and stores it in the “version” variable. If the folder for 8.0 does not exist, the script can assume that either 7.0 is installed, or no version of adobe is installed and will run the setup in the “else” option below:


set objWshShell= CreateObject(“Wscript.Shell”)
set objEnviroment = objWshShell.Environment(“PROCESS”)
objEnviroment (“SEE_MASK_NOZONECHECKS”) = 1

^ This changes the registry so that it will disable those annoying open file warnings during the script

Set WshShell = WScript.CreateObject(“WScript.Shell”)
WScript.Echo WshShell.CurrentDirectory
WshShell.CurrentDirectory = “Y:\folder\adberdr81Silent\Setup Files”

^ This changes the running directory (I had trouble with some stations thinking I was trying to run setup.exe out of the windows directory, this fixed that) Y: is mapped to the “share” on the local server.

Set WshShell = WScript.CreateObject(“WScript.Shell”)
WshShell.Run “setup.exe”

set objWshShell= CreateObject(“Wscript.Shell”)
set objEnviroment = objWshShell.Environment(“PROCESS”)
objEnviroment (“SEE_MASK_NOZONECHECKS”) = 0


^ This calls the setup.exe located in that folder and the custom adobe msi I made to install completely silently (among other custom settings) takes it from here. Then the script undoes the change I made to disable the open file warnings and exits the script. Adobe 8.1.4 is now installed.

End If

If version = “8.1.4” Then


^ Here we have the other option, the script finds the adobe 8.0 directory and is now going to check that version variable. For my purposes, checking if the version is 8.1.4 (highest version of reader 8 ) is what I needed. If that version is already installed the script quits and does nothing further.


set objWshShell= CreateObject(“Wscript.Shell”)
set objEnviroment = objWshShell.Environment(“PROCESS”)
objEnviroment (“SEE_MASK_NOZONECHECKS”) = 1

Set WshShell = WScript.CreateObject(“WScript.Shell”)
WScript.Echo WshShell.CurrentDirectory
WshShell.CurrentDirectory = “Y:\folder\adberdr81Silent\Setup Files”

Set WshShell = WScript.CreateObject(“WScript.Shell”)
WshShell.Run “setup.exe”

set objWshShell= CreateObject(“Wscript.Shell”)
set objEnviroment = objWshShell.Environment(“PROCESS”)
objEnviroment (“SEE_MASK_NOZONECHECKS”) = 0


end if

^ Otherwise, if Adobe reader 8 is found, but does not equal version 8.1.4, then the script updates it to the version required by running the silent setup. From that point the setup.exe is smart enough to just install the patch(es) needed. Adobe made these easy to customize.

So there you have it. This script was added to the login process and if the PC didn’t already have Adobe Reader 8.1.4, it would install it. Otherwise it would not do anything. Either way the end user had no idea it was happening. I’m sure this script is sloppy, but it did exactly what I needed it to do – and saved Celeste and I a shitload of tedious work – , so I was pleased.

-Dave out

Retrieving serial numbers remotely over the network

Lets say the CIO of you company says he’d like to have all the neglected inventory spread sheets updated by the end of the month. You look at the portion of the workstation spreadsheet you’re responsible for and find that your lazy ass has not updated it in quite some time. It sucks to have to go to every computer one by one and read the little sticker with the serial number, so lets do it remotely!

Step one, the VBS script:

I found this on the internet a while ago, don’t remember the source and am too lazy to look. But lets just say I take no credit for writing this. Anyway, create a .vbs file and paste this into it:

ComputerName = InputBox(“Enter the name of the computer you wish to query”)

winmgmt1 = “winmgmts:{impersonationLevel=impersonate}!//”& ComputerName &””

‘WScript.Echo winmgmt1

Set SNSet = GetObject( winmgmt1 ).InstancesOf (“Win32_BIOS”)

for each SN in SNSet MsgBox “The serial number for the specified computer is: ” & SN.SerialNumber Next

This simple little script will prompt you for a computer name or IP that is on your domain and when you enter that it will return the serial number of the PC. You didn’t even have to leave your desk. You can also leave the input field blank to get the serial of the PC you are currently running the script on.

If we are talking about PCs with no Windows firewall enabled, you needn’t worry about step 2. Otherwise, read on.

Step two, the only problem:

The only issue I quickly found was that the Windows Firewall on the remote PC (the one you’re trying to get the serial number from) will block the WMI request. You can, of course, disable the firewall on all your client PCs… but that is not the greatest option.

I discovered, thanks to this site, that all you need to do is allow Remote Admin WMI requests through the windows firewall. I’m sure this can be done via a GPO, but lets say for the sake of argument that you aren’t that comfortable with group policy, and/or your boss wants to be the only one to setup new GPOs and can’t be bothered with this.

Well, there is a simple command line that will change this setting for you:

netsh firewall set service RemoteAdmin enable

Add this to your users (.bat file) login script, or to any batch file and it will open up the Windows firewall to allow the script shown above access to get the S/N. If you want to remove this for whatever reason once you have all the info you need the same command, but replacing enable with disable will return it to default.


I’ve only used this for Windows 2000, XP, and 2003. So I can’t confirm or deny that it will work for other versions of Windows. As a .VBS script, I would also imagine that other OS’s than windows will not support this. Also, one last thing, it seem that PC you are querying from and the remote client need to be members of the same domain for this to work. Oh, and the remote PC needs to be turned on. Duh.


With all these things in mind, I found this script to be immensely helpful. In my job, I have PCs that are at other locations, some of which are a good drive away. Since I was too lazy to keep my inventory up to date in the first place, this helped my out to easily get the S/N’s I was missing remotely without the end users even noticing I did anything. I accomplished this all from the comfort of my own desk.

I hope this is helpful to you as well.

-Dave out

Remove infected locked files and more

I am fighting with a friend from work’s personal computer and have removed many virus/malware/etc off of it so far. Something is still a little fucked with it, but I made some good progress. I’ve learned of a few handy little freeware programs in the process and I thought I’d share.

First off is Advanced Process Manipulation, a lightweight program that acts as a more advanced version of task manager. You can see all the running processes and also what DLLs they are using (and therefore protecting). You can end the whole process or just unload certain DLLs on each process. Pretty handy for finding what files a process is tying up.

Next we have the Locked Files Wizard, which is another small program that is incredibly handy. It allows you to pick protected Windows files and rename, delete, move, and replace them. The only really handy (and best way not to fuck up your copy of windows) use for this is to replace corrupt/infected system files with a copy of good files off another computer. I thought she had some infected system files, namely comctl32.dll, so I replaced the file with this program.

I discovered a couple free anti virus programs that made AVG look like crap (admittedly not difficult). Avira seems to have positive reviews, so I tried that out and it was not bad. ClamWin Portable was also quite handy. It can be installed and updated to a single folder and is easily copied to a flash drive and can be ran from there on another computer. Of course, Spybot is always a great help too.

There is a nice little guide here that gives methods for removing protected files, and links to many more utilities like above. So, if what I’ve listed above doesn’t work for you check it out.

If you have any more suggestions for nice freeware utilities/software, or helpful suggestions for when “just rebuild it” isn’t the best option, feel free to comment and add your thoughts.

-Dave out