BiggAndyy

C:\IPCONFIG

WHOA!!!!!!!

That’s a LOT of devices… not just the 5 or 6 usually listed… I had HUNDREDS.  What’s going on?  I don’t want them there, even if they are important!

Turns out they aren’t really that important, especially if you are one of the millions of users still using IPv4 (xxx.xxx.xxx.xxx) IP address configuration.  Windows 7 ships with both IPv4 and IPv6 already enabled.  All those tunneling adapters are translators from IPv6 to IPv4.  But since we aren’t using IPv6, let’s get rid of them.  They slow down the machine when there are hundreds, and if you want any USEFUL information from IPCONFIG the getting rid of is easy.

First, uncheck the IPv6 option in your Adapter Settings dialog box and click OK.

If it were THAT easy this post would not be necessary.  It isn’t that easy.  When you retype IPCONFIG at a CMD window the tunnel adapters are still listed.  Don’t bother disabling and re-enabling the network cards or starting and stopping the wireless service or even rebooting.  They won’t work.

Second, you probably (99% sure) will need a program from MS called DEVCON.EXE.  This is the key to the rest of the process.  If you are running Windows 7 64 bit (and many of us are) you can get it at this >>link<<.

Put the program somewhere you can access it easily from a CMD window (such as %HOMEPATH%).
Open a CMD window to that directory and type this:

DEVCON REMOVE *6TO4MP

After you hit ENTER, depending on how many of those things have built up over the months, it can take a minute or two.  Eventually the program will give you the all clear and when you type IPCONFIG again, *POOF* they are all gone.

So, no more swirling down the digital doo-doo drain!  You’ve just fixed it on your own.  Good luck.

Windows 7 (and Vista and even Xbox) will encounter this error, and there are numerous fixes in the cloud to remedy this problem.  I’ll quickly list my attempts failures, and then describe what I did that finally did succeed.

I tried editing the Firewall to allow all the Microsoft sites access.  No help.

Updating the Network Card device driver.  Nothing.

Reinstalling several .dll files mentioned at some sites.  Did not work.

Edited the registry to change the MTU (maximum transmission unit).  Zilch.

Swearing loudly.  I felt better but the machine ignored me.  Zip.

Re-performed all those things logged in as the local administrator.  Up until now I did it as the local user and just upped the privileges when asked by 7.  Lots of time but no effect.

Finally I started to think outside the box/cubicle.  I remembered one of the .dll files was java-something-something.dll.  I began to wonder… did this machine have updated Java?  No, it did not.

I updated Java (to 6r30) over the web, rebooted, and heeeeeeey!!!!  That worked!

Once again, the simplest solution was the correct one, and once again, it was one of the Big 3 Things (Windows Updates, Java, and Antivirus).  So, long story short, if the propeller heads start directing you to edit this registry entry and modify that policy object STOP.  Try the simple things first!  It will only take a small amount of time and many times WILL solve the problem.

Sounds easy, find a file on your hard drive to be used in your BATCH script.  Usually you don’t need to.  Microsoft keeps fairly well the directory structure from one version to the next.  Usually.  What about files like PRNPORT.VBS and all those files in printer administration?

In Windows XP they can be buried down 4 levels, but maybe only two.  In VIST/7 maybe just 2, and in other versions if you have to deal with them, who knows if they are even there.  Let’s face it, not every IT enabled business has up to date standards, machines, and uniform OS’s throughout.

Sometimes you have to write an awful lot of code to do a simple thing, like when a network printer changes it’s IP address, the printers are not on a print server, and all the mappings on the local machines are pointing to the IP address.  Simple thing to write a script to change the IP address.

Not so much.  Remember, I don’t have access to the AD tree, even though I am an administrator.  Since I am considered an outside “contractor” by the powers that be (even though I am paid from the same pool as the general IT staff), I have much less access.  So let’s try some guerrilla administration and solve this problem, writing a script that doesn’t care where PRNPORT.VBS lives, it will find it and use it.

Here is the code I cobbled together and I think it warrants passing along:

@echo off
@CLS
::
:: Initializing variables used
::
SETLOCAL ENABLEDELAYEDEXPANSION
SETLOCAL ENABLEEXTENSIONS
SET curdr=
SET myvar=
SET targetfile=
SET diritup=
::
:: Ask for file to find.
::
SET /P targetfile=”File to look for: ”
::
:: Initialize the target file,
:: the @ is important to keep the display uncluttered
::
@SET diritup=”dir /s /B %targetfile% 2>NUL”
::
:: Find the target file
:: It can take a while on a hard drive with a lot
:: of data.  If you have a way to search faster
:: let me know.
ECHO Finding %targetfile% (This may take a few moments)…
ECHO Note this will return only the LAST file found if there
ECHO are multiple copies of the file.
set curdr=%cd%
cd\
for /f “tokens=*” %%a in (
‘%diritup%’
) do (
set myvar=%%a
)
cd\
cd %curdr%
IF “%MyVar%”==”" GOTO :FILENOTFOUND
ECHO.
ECHO Found the file found at
ECHO %myvar%
ECHO.
ENDLOCAL
Exit /b 0
:FILENOTFOUND
ECHO File Not Here.
ENDLOCAL
Exit /b 0

Wow.  That’s a lot of typing to just do this: CSCRIPT PRNPORT.VBS -T -R %OLDPORT% -H %NEWIP%

Yeah, that’s what happens when you can’t depend on where PRNPORT.VBS lives.  The script does a couple of things, first it remembers where you started the script, goes to the root of the drive, executes a DIR /B to return the file with it’s path (IMPORTANT) and finally switches back to the original directory to do whatever you want the rest of the code to do.

One trick built in, if there are multiple copies (say you type *.JPG) for the search term (this is a generic portion of the script I wrote), the only file displayed will be the last one found.  To see all of the files insert ECHO %%a in the FOR loop just after SET MYVAR=%%a

You are asking, is this really necessary?  Yeah, in order to pass a directory result to a variable WITHOUT using a temporary file, this is one way.  You could also pipe a FINDSTR on the DIR command but I have found a FOR loop to be a bit faster and a smaller hit on the performance of the machine.

Copy it and give it a try.