Changing IP address in Windows7

[tedsmith]

In an old app running in XP I used the following vb6 module to change the IPaddress, subnet and gateway automatically when I started my app.
This was necessary in a particular fixed IP network application I did, the values being obtained from a different .ini file in each computer.
The properties had to be first set to Automatic.
The new values were global.

I find it now does not work at all in Windows 7
Any ideas would be appreciated?

'Courtesy of the fine people at Tek-Tips
'Used to Change IP addresses 

Private Declare Function OpenProcess Lib "kernel32" (ByVal dwDesiredAccess As Long, _
    ByVal bInheritHandle As Long, ByVal dwprocessID As Long) As Long
Private Declare Function GetExitCodeProcess Lib "kernel32" (ByVal hProcess As Long, _
    lbExitCode As Long) As Long
    
'Constants
Const PROCESS_QUERY_INFORMATION = &H400
Const STILL_ACTIVE = &H103

Sub ChangeAddresses(NewIPGateSub As String)
ReturnValue = ShellAndWait("cmd.exe /c IPCONFIG /release", vbHide) 'release old address
ReturnValue = ShellAndWait("cmd.exe /c NETSH INTERFACE IP SET ADDRESS " & _
    Chr(34) & "Local Area Connection" & Chr(34) & _
    " static " & NewIPGateSub & " none", vbHide)
End Sub

Function ShellAndWait(ByVal PathName As String, Optional WindowState) As Double
    Dim hProg As Long
    Dim hProcess As Long, ExitCode As Long
    
    If IsMissing(WindowState) Then WindowState = 1
    hProg = Shell(PathName, WindowState)
    'hProg is the process ID under Win32.  To get the process handle -
    hProcess = OpenProcess(PROCESS_QUERY_INFORMATION, False, hProg)
    Do
        'populate the ExitCode variable
        GetExitCodeProcess hProcess, ExitCode
        DoEvents
    Loop While ExitCode = STILL_ACTIVE
    ShellAndWait = 1
    
End Function

 

[Hypetia]

You are changing the IP address via cmd.exe. For this, you need to run, what in Windows 7, is called an "Elevated command prompt".

Try running your program with administrative privileges.

 

[dilettante]

Have you tried saying [tt]IPV4[/tt] instead of [tt]IP[/tt] yet?

It must also run elevated.

 

[HughLerwill]

Does the same stuff work if you type in the command manually from;
1. a standard w7 cmd prompt?
2. an elevated w7 cmd prompt?

 

[dilettante]

And yeah, there should be no need to fire up a whole command shell to run one process, much less fire up a second one just to run another. I won't even comment on the use of DoEvents() calls and their hazards, this should be well enough known to anyone by now.

GetExitCode() = STILL_ACTIVE is hazardously unreliable, use WaitForSingleObject() with the process handle instead. Who names a PID with a "handle" hungarian prefix? WindowStyle is an Enum (Long) not a Double. IsMissing() only works on a Variant... and the list goes on.

Where did you find this example of Bad Code™ anyway?

I checked, and it isn't close to April 1st yet.

 

[HughLerwill]

Re ShellAndWait in the OP

Looks like this example of ShellAndWait may have first appeared in tek-tips back in thread707-740084 jan 2004

It is still included in forum faq222-4910 mar 2004

We talked about use of it in thread222-1454008 feb 2008

 

[tedsmith]

Thanks for your very quick and vocal comments!

Even though it may be "bad code" it works 100% reliably if the values are in any way to the previous values when my app is started. If there is no change needed it skips past instantly.

I tried a number of different combinations but this was the only one that worked every time. I think it has something to do with time it takes to effect a change. Even when you manually change an IP, there is a considerable pause before it comes in to effect.

I have the Win7 computer set as one user as an admin with no password. I suspect priveledges is part of my Win7 problem.

I also notice I can't erase any unwanted folders in Program Files or add files to system32 (like you can with XP) as it says "contact your administrator" even though I AM an administrator!

How do you get to this "Elevated Command prompt" in code or do you really need to?

Unfortunately my 'vb6 working computer' is XP and I don't have easy access to one with Win7 yet.

 

[dilettante]

Well it looks like NETSH INT IP still works in Windows 6.x, so I'd bet the lack of elevation is the problem. You'd see this in the responses if you looked at them, the messages I get here are quite explicit.


You are not an administrator, just a member of the Administrators group and elevation-capable. I guess you haven't heard about split tokens yet. Hacking around in protected areas of the system isn't advisable. Surely you have an uninstall process as part of your installer? And if you are just trying to shoehorn stuff into those locations instead of using a proper installer it all probably ended up in virtualized per-user locations.


Does this program need to be run by non-admins? If not, at best they'll face an elevation prompt every run so you may as well just elevate your whole program each run.

If you try to elevate your "shell and wait" operations... you have two, so they'll face two prompts. You can't use Shell() for this, you'd need to move to one of the forms of ShellExecute that accepts the [tt]runas[/tt] verb.

And if a non-admin must run the program, either way they'll need an admin account's credentials to do over-the-shoulder elevation - every run.


Windows 95 is long gone, and the appcompat shims that let you play fast and loose breaking the rules in XP as if you were on Win9x no longer apply. It is a pain laying out cash when it seems pointless, but keeping up is part of the game in software development. I just bite the bullet and call it compeititve advantage along with other things like the mystery known as reg-free COM.

One stopgap measure, if XP isn't too creaky to run a recent Virtual PC and you have 2GB or so of RAM there...

If you do a search on "IE TEST VHD" you can find downloadable VHDs that are good for about 3 months. Just get a Vista VHD, it will be smaller than Win7 and almost all of your Win7 issues are really Vista issues, Win7 being a thin facelift in many regards. Using Vista saves download time and disk space, and contrary to a lot of FUD (even from Microsoft) generally boots a bit faster.

Then the only problem you'll face are 64-bit Windows issues, but that's another whole series of topics.

 

[tedsmith]

Thanks for your advice, that is what I suspected.
I purchased an i7 with 64bit windows and find all my apps run on it without any problem (except this one).

My problem is that I am now 76 and therefore I have to carefully balance what valuable TIME I have left to live with how much time I want to spend to update my programming skills.
If I can zero in on the answer I need I will do so unashamedly at the expense of horrifying some of the purists that visit this forum.
As you will find time is the most precious commodity as you get to the end of your life. I need another 75 years to do all the things I want to do in my life!
I imagine I am just a quick minded as a 30 year old but statistics would say I am not!

Unfortunately one of my old client (in our State Government no less) keep calling me back to do things for them because they are still struggling with an old technology system that all their recent employees cant understand or don't have enough imagination to come up with a suitable solution.

Look at it another way, I never asked Microsoft top change it, it fact it is a nightmare trying to turn off all the warnings and security stuff in Windows7 when you don't want it!

I would be grateful if you could point me in the right direction to simply solve this problem without me having a stroke!

 

[HughLerwill]

Does the same stuff work if you type in the two 'DOS' commands manually from;
1. a standard w7 cmd prompt?
or if that fails
2. an elevated w7 cmd prompt?

 

[strongm]

>even though I AM an administrator

No, you are not. Not on Windows 7 (nor would you be on Vista). The real admin account is disabled by default. The admin user you think you are is just a slightly privileged user account.

This is to stop a trojan or virus form hijacking your privileges to wreak havoc on your system, and also to stop people who don't quite understand how Windows works from making changes to the system that they really shouldn't be making

>I tried a number of different combinations

Did you try the WMI solution that I suggested in the third link provided by HughLerwill (to one of your own previous questions on this). You can in principle include the relevant impersonation in the WMI code to avoid the UAC, but that normally involves hardcoding an admin password which isn't a good idea), but you'd only get one prompt

 

[dilettante]

Based on the WMI example (probably a good place to use WMI though normally I avoid it in applications) it sounds like doing a release on the initial DHCP address isn't needed.


Using WMI would also require elevation, so unless this application is going to be running with full admin rights you might as well start an external process anyway.

Is this a separate setup/config application that gets run once (or once in a great while)? Then maybe elevation of the app is fine, and WMI would do the trick nicely. But somehow I'm getting a weird feeling you have the machine set up to autologon, then autorun this application, and it then sets the IP configuration each time a boot & logon has been done (or the app gets re-run some other way later).

I can't see your network security police being too happy about a kiosk running with admin rights all day long. And after booting somebody would have to be there to approve the elevation request unless you ran with the built-in admin account (which is normally disabled for good reasons). Turning off UAC means you could use a regular admin account, but that still sounds unacceptable from a security standpoint.


All of this seems very odd though.

Even if fixed IP addresses need to be assigned to individual machines it seems very weird that they would need to be reset very often. When they did need to be changed this should be a fairly simple admin task entirely separate from the application. Why would you have these machines set up to boot with DCHP settings anyway?


If this must be done, there is a normal way to do it in the post-XP world:

You put your admin operation into a small program or script, that could even look in some data file for the IP address to assign. Then you set up a scheduled task to run the thing as some admin user "with highest privileges" at system startup. No elevation prompts will be seen when it runs. The new Task Scheduler has lots of new features like this.

To change the static IP when required just update the statup program or script, or the data file if that's where the value will "live." Then reboot.


This should not really even be your concern, since it is an administrative function. But I know how useless box jockeys are.

 

[tedsmith]

Thanks
It may look strange but problem with this particular installation is that the computers are not 'computers' in the normal sense.
I will try to explain-
They don't have a keyboard, mouse or normal monitor connected to them.
They are a secure information display three to six monitors saying different things. Existing units don't have any outside control of any kind and are controlled and updated by TCPIP from a central control room miles away via fiber optic cable.

New ones are being added and all now use Windows7
There could be 100 of these devices on the same network.
All units have a fixed IP, Sub & gateway.

The reason for this IP changing routine I am asking about in this thread is to ensure that when a computer is replaced for maintenance purposes in the field, or a new one is installed it automatically is set to the correct fixed IP.

As it has no keyboard, all the installing electrician has to do is to have the location number (1 to 100) preset in an INI file before it leaves the workshop and this routine guarantees it will be on the correct IP.

It is run every time the computer restarts as it has no effect if the up is already correct. It has worked perfectly up to now.

I know this all sound foreign to a 'normal' computer person but all 'computers' don't have to be used the same way or follow the same rules created for a different usage (even though Microsoft keep trying to make us do so).

 

[strongm]

>all the installing electrician has to do is to have the location number (1 to 100) preset in an INI file

Um ... surely if someone can set the INI file with a location code they could, instead, set the IP4 info ...

 

[tedsmith]

One would think so but I am dealing with a State Government department!
They are not all as bright as you!(In fact none of them are and wouldn't know what an IP address was)

Staff change at the drop of a hat and when two computers end up with the same IP all hell breaks loose.

Entering three sets of up to 12 digit numbers via the control panel is extremely more difficult than 1 number that can easily be copied on site from a memory stick automatically without a keyboard!

You gotta make it easy for people!

 

[dilettante]

It sounds as if you are just copying a file with the IP address then.

So why not use an elevated scheduled-for-startup task that reads this file and does the IP configuration? Could be a WSH script, or even a small Form-less VB6 program.

Update the IP data file, then reboot. Every boot this would happen again.

When this startup task is set up in Scheduler you assign it the user to run under and that it should run with highest privileges. Yes, I realize I am repeating myself.

 

[tedsmith]

Sorry but I really want to make it all happen in my app every time it is started.
Consider the situation when a computer fails after I die and my client has to install the app on a new computer.
He wont know enough to muck about with scripts or set up the scheduler reliably.
All I want him to do is run the app and it will be all automatic.

I would be grateful if someone could indicate what code do I include to get Windows 7 to respond and how do I get around this "elevated" thing you are all talking about?

This procedure has worked perfectly for some years under XP

 

[HughLerwill]

Does the same stuff work if you type in the two 'DOS' commands manually from;
1. a standard w7 cmd prompt?
or if that fails
2. an elevated w7 cmd prompt?

 

[dilettante]

The reason it "worked for years under XP" was in part due to the many appcompat shims that tried to make XP look like Win95 to applications written poorly that still had to run.

But even in this case the program never should have worked under XP. I have to assume you were having it run in a session left loogged on as an admin user. That was always a strict "no no."


Because people insisted on doing that yet turned around and pissed and moaned that "Windows is insecure" Microsoft did something about it. Now logging on with an admin user does not give processes that you start admin rights by default. Instead admin rights must be requested (manually or via a manifest or through legacy installer detection), and then they must be interactively approved. By a person. Sitting right there at the screen, mouse, and keyboard. Through a secure desktop, not the default one so nothing like a SendKeys hack can touch it.

Game over.

Nothing new here, Microsoft began telling us about the change back in 2006.


Seriously, if this is a mystery you should not even be programming on Windows anymore. I say that speaking as a bit of an old fart myself. I understand your pain, but I just suck it up myself and move on. I simply look at it as competitive advantage now. ;-)

 

[tedsmith]

Thanks.
1. Standard prompt does not work. How does one get to an "elevated prompt?"

2. Of course I set all the XP computers as an admin user with no usernames or passwords because as I said I purposely DON'T want any security so I can do what I want to do with it!

I understand it must be hard for some people (including Microsoft) to understand that there are still some people that want to run computers as a device NOT connected to the internet or humans in any way. How could anyone possibly survive without their hourly dose of Facebook, Twitter and porn?

One thing I wonder about is I notice I cant copy any files or delete any files in Win7 System32 even though I am logged on "as an Administrator" however the very old Package & Deployment wizard happily installs files in System32. How does it achieve this as it was developed before this elevate privileges stuff ?