Jump to content











Photo
* * * * * 1 votes

PE Network Configurator 2.30


  • Please log in to reply
21 replies to this topic

#1 TheTruth

TheTruth

    Newbie

  • Advanced user
  • 15 posts

Posted 11 March 2007 - 12:45 AM

Hello All,

Actually, this is my first post here, and I've decided to make this announcement on your boards for two reasons:
- I see brilliant work and ideas here,
- I promised Nuno Brito to participate some day. Happy? :P

Well, this is an updated version of PENetwork Configurator that should work under Windows PE 2.0.
Here is a non-published link to the binaries:
PENetCfg 2.30

Please refer to the enclosed "WinPE 2.0 Support.txt" file before going any further.

I hope guru scripts will come up with a quick script for this.

Acually, I'm short on time and haven't fully tested all features (espcially backwork compatibility with WinXP\2K3-based PE environments).
So please feed me back with your experience as I have to make this version publicly available ASAP.

Nuno Brito: Briliant work on WinBuilder. Keep it up!
NightMan: You're always pioneer. One of the first who made PE builder scripts (long ago :P). Glad you returned to the drawing board again and still PIONEER.

PS: I may not be as responsive as you may expect, but I need to have all issues related to PENetCfg here, so I can work on them in my free time.

Best regards,
Pierre Mounir (aka TheTruth)
http://www.geocities.com/pierremounir

#2 Brito

Brito

    Platinum Member

  • .script developer
  • 10616 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 11 March 2007 - 10:30 AM

Welcome to boot-land.net!

Really glad to see you back - thank you! :P

#3 bilou_gateux

bilou_gateux

    Frequent Member

  • Expert
  • 230 posts
  •  
    France

Posted 11 March 2007 - 01:15 PM

:P

It's really a good new to see you back.

Previous PE Network Configurator for WinPE / BartPe is still a most valuable tool. Hope the WinPE 2.0 compatible version (and backward compatible) will stays the same.

#4 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 11 March 2007 - 01:59 PM

Well, well, another nice guy from the good ol' times joining here. :P

Happy you are back!
:P

jaclaz

#5 martinr

martinr

    Frequent Member

  • Advanced user
  • 120 posts

Posted 11 March 2007 - 05:52 PM

I hope guru scripts will come up with a quick script for this.

I am not sure that I would qualify as one of those, but I have nonetheless prepared a script for Version 2.30.

I put it and the PENetCfg files (except PENetCfg.ini, which I left out) under Net. The script copies the files and makes the registry entries which The Truth said were required. I am not convinced that it works any better than what I had before, but at least it will provide a starting point for others to experiment.

Although I can access the Internet and map network drives using PENetCfg, I am still disappointed that I cannot see Network Neighborhood or its equivalent in A43 or Total Commander.

Attached Files



#6 thunn

thunn

    Silver Member

  • .script developer
  • 531 posts
  • Location:Brooklyn, New York
  • Interests:computers<br />mechanics<br />distortion<br /><br />
  •  
    United States

Posted 11 March 2007 - 06:31 PM

I made a script called minint network core that uses the network configurator v2.30. I haven't updated it for the new WB version because Holger's "PENetwork" solution has been working well. I really should though because it's better on resources and to be honest, my prefered prog. for this task, so, thanks for the reminder. And, a very special thank you to the Truth for his wonderful contribution that has helped so many of us.

#7 TheHive

TheHive

    Platinum Member

  • .script developer
  • 4199 posts

Posted 13 March 2007 - 04:38 PM

Welcome to the board " TheTruth ".

#8 TheTruth

TheTruth

    Newbie

  • Advanced user
  • 15 posts

Posted 13 March 2007 - 07:55 PM

@Nuno Brito
Special thanks man, highly appreciate the precious space you offered.

@bilou_gateux, jaclaz, TheHive,
Many thanks, highly appreciate welcoming me.

@martinr
Thanks for taking the time to come up with the script, I'll use it in my next VistaPE Build.

I am not convinced that it works any better than what I had before

Could you please elaborate?

@thunn
I've been away from the PE community for long, so I don't know much about the latest changes.
Actually, it's the first time I hear about Holger's PENetwork, I searched for it and had a look at it, nice work no doubt, but I didn't get the chance to test it. It's all a personal preference though.
Thanks for your nice words.

@All

No one had the chance to test yet?!!!!!!!!!


Best regards,
Pierre Mounir (aka TheTruth)
http://www.geocities.com/pierremounir

#9 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 13 March 2007 - 08:05 PM

No one had the chance to test yet?!!!!!!!!!

Maybe I should test.
But currently I'm 100% satisfied with Holger's PENetwork. Therefore for me there has been no necessarity to try something else.

Peter

#10 martinr

martinr

    Frequent Member

  • Advanced user
  • 120 posts

Posted 14 March 2007 - 03:48 PM

@All
No one had the chance to test yet?!!!!!!!!!

Yes. I have been doing some quite extensive tests.

I have a basic Winpe 2.0 setup of my own design, which uses nu2menu as its base. I start the new version of PENetCfg from an autorun script which nu2menu calls using Erwin Veermans autorun.cmd. I use the parameter "/useprofile:penetcfg-dhcp.ini" which I borrowed from the BartPE plugin, and everything works fine. I am sure that the new version of your program does exactly what you wanted it to do.

My problems start when I use the program in VistaPE, and there is no obvious reason why this should be. There is a clue however in the fact that VistaPE takes so long to get started. Version 7 in its original form called wpeinit.exe before calling link.exe, which sets up the shortcuts. Nightman has since rewritten link.exe as vpeldr.exe, and has eliminated the separate call to wpeinit, but problems still remain in starting the network, which can subsequently be resolved by running PENetCfg.

My experiments show that it is the call to wpeinit which is the cause of the slow performance (although it works fine in the context of a basic WinPE 2.0 disk). Further experiment, using PENetCfg instead of wpeinit, saw PENetCfg hang. I was surprised to find that the failure was documented in a "wpeinit.log" in my PENetCfg folder. This lead me to the conclusion, which you will be able to confirm, that PENetCfg calls wpeinit as part of its internal programming. If this is so, it should not be necessary to run both programs separately.

My thinking at this present moment is that wpeinit (and therefore probably PENetCfg) run fine once the shell (cmd.exe, nu2menu and maybe PEShell) has been established and started, but perhaps not before. I have just discovered by looking at earlier versions of VistaPE that PEShell has autorun capabilities of its own, which used to be used to call wpeinit (see script 3-config.script in version 6). A possible solution may therefore be to run PENetCfg in this way. I have yet to try this out.

I hope some of this makes sense, and is not just a lot of rambling nonsense. The bottom line from my perspective is that PENetCfg Version 2.30 is fine. It just isn't working quite right in VistaPE, but then neither is wpeinit which does take some explaining.

#11 martinr

martinr

    Frequent Member

  • Advanced user
  • 120 posts

Posted 15 March 2007 - 02:41 PM

More experiments, and I now have some success to report, and also a little embarrassment (not for the first time!).

Continuing from my last post, to start PENetCfg using the autorun feature of PEShell, you need to add the following line to my penetcfg script, making the addition at the 8th line of the Process section, after the variables have been set up.
IniWriteTextLine,&#34;%TargetDir%\Windows\System32\PEShell.ini&#34;,&#34;AutoRun&#34;,&#34;1=%LinkDir%\penetcfg.exe /useprofile&#58;penetcfg-dhcp.ini&#34;
The autorun.cmd file in VestaPE\Build\system32 should look like this:
@echo off

title VistaPE Autorun...

echo Starting VistaPE Autorun, please wait...

echo.

%SystemRoot%\system32\link.exe
On running the new disk, I found that PENetCfg appeared to hang at the "Starting network support..." screen, but I was more patient than I had been previously, and discovered that after a wait of about 3 minutes the program continued to run to its conclusion.

I next tried an alternative method of starting the program using my penetcfg script in an unchanged form. The autorun.cmd file was changed to the following:
@echo off

title VistaPE Autorun...

echo Starting VistaPE Autorun, please wait...

echo.

%SystemRoot%\system32\link.exe

y&#58;\penetcfg\penetcfg.exe /useprofile&#58;penetcfg-dhcp.ini
This also ran properly, but with a similar time delay. I didn't like the fact that the console window stayed open while PENetCfg was running, so I really prefer the PEShell autorun approach.

Now that I knew that PENetCfg was in fact working properly, I ran my Winpe nu2menu disk again and checked the timing. I found that the program moved on from the "Starting network support..." screen after a delay of only 15 seconds.

Armed with this information, I then asked myself the all important question - Why do two disks running the same operating system take widely different periods of time to run the same program? Then it hit me. My nu2menu disk was made in the usual WinPE 2.0 way, using imagex /mountrw and /unmount and putting all the system files into boot.wim, from where they eventually load into RAM. My VistaPE disk on the other hand had been made in the default way, without packing the image into boot.wim.

When I rebuilt my VistaPE disk with the Pack boot.wim checked in the 6 - Finalizing... script, I found that my wait time went down from 3 minutes to under 10 seconds. So there was the explanation. My nu2menu disk was running its system files from RAM, while VistaPE was running them from the CD. Although I knew of course that RAM is infinitely faster than CD, I hadn't expected that it would make much difference to a small program like wpeinit (23KB). I guess that the real reason is that it makes a lot of calls to DLLs, which are already in RAM in the one case, but have to be loaded and unloaded from CD to memory in the other.

Learning things like this the hard way means you never forget them, and I will always have that Pack boot.wim box checked in the future!

#12 martinr

martinr

    Frequent Member

  • Advanced user
  • 120 posts

Posted 21 March 2007 - 06:14 PM

Since my last post, NightMan has produced a later version of vpeldr.exe. It is available at http://www.boot-land...?...ost&p=11304

vpeldr is the replacement for the previous link.exe. The new version deals with the shortcuts better than ever, and it also runs wpeinit in the background, making internet and network available.

Since using the new version of vpeldr, I have however had a problem when running PENetCfg using AutoRun in PEShell (see my last post). Both programs run wpeinit and there appears to be a conflict. I have also had problems with Shutdown, when running both at startup.

So, I have deleted the IniWriteTextLine command which I had previously added to penetcfg.script (it is now back as it started). I am also running vpeldr instead of link.exe in autorun.cmd.

With this setup, I find that I can access the internet, ping other computers on my network, and access them using Remote Desktop. Wpeinit really sets it all up. The only time I use PENetCfg is when I want to map network drives, and then I run it separately from the Start Menu. Working this way, I don't have any problems with Shutdown, which also is a good thing.

#13 winpe64

winpe64
  • Members
  • 4 posts

Posted 19 April 2007 - 07:46 AM

Hello together,
very good work you've done with Network Configurator 2.30!!! Unfortunately our company starts to use 64-bit windows and therefore I'm going to use the 64 bit version of Windows PE. Everythings works fine except the Network configuration utility.

My questions is: is it planned to make a 64-bit version of the PE network configurator available?

Looking forward to your replay :thumbup:

#14 martinr

martinr

    Frequent Member

  • Advanced user
  • 120 posts

Posted 19 April 2007 - 04:30 PM

Everythings works fine except the Network configuration utility.

Did you manage to get PENetCfg to work OK in 32 bit WinPE before moving to 64 bit?

Something else to consider is that vpeldr runs wpeinit on startup. This should configure your network properly, without the use of PENetCfg. PENetCfg is of special help when it comes to mapping network drives. Does wpeinit used on its own get your network going? If it doesn't, it seems unlikely that PENetCfg would do any better.

My questions is: is it planned to make a 64-bit version of the PE network configurator available?

Only The Truth (Pierre Mounir) can answer this one. I have looked at his website, and also other forums where he has posted, and can find no reference to 64 bit. I suggest that you send him a PM on this one.

#15 winpe64

winpe64
  • Members
  • 4 posts

Posted 23 April 2007 - 08:56 AM

Thank you for the replay. Mainly I need to find a way how to prompt the user to input the IP-setting like subnet, gateway and so on. On WinPE 32-bit I'm using penetcfg for that (we do not have any DHCP available).

What is your suggestion to prompt the user for the IP-settings on WinPE 64-bit? I appreciate any help!

#16 martinr

martinr

    Frequent Member

  • Advanced user
  • 120 posts

Posted 23 April 2007 - 11:19 AM

Thank you for the replay. Mainly I need to find a way how to prompt the user to input the IP-setting like subnet, gateway and so on. On WinPE 32-bit I'm using penetcfg for that (we do not have any DHCP available).

What is your suggestion to prompt the user for the IP-settings on WinPE 64-bit? I appreciate any help!

As you have found, running PENetCfg in WinPE 32-bit without using a profile does give you the opportunity of inputting the data you want. If it won't work in 64-bit, I can only suggest you contact the author - Pierre Mounir.

I was going to suggest that you tried PE Network Manager, which also allows you to input static IP info, but I see that you have recently posted to Holger's site. So, I presume that you have already tried his program and that it too only works in 32-bit.

The one program that certainly does work in 64-bit is wpeinit.exe, which is run from startnet.cmd in a basic WinPE setup. It sets up the network resources among other things. No doubt you have tried this, and maybe it only works fully when DHCP is available. The program can of course be run from any script, and according to the WAIK the only option which it takes is -unattend which points to a custom answer file. The WAIK also comes with an Unattended Windows Setup Reference guide, which gives information about answer files and has network components in it. My thinking is that it may be possible to write a proforma answer file, maybe using Windows System Image Manager and the Unattended Reference guide, and then write a script to prompt the user for the IP data you need. The script would need to go on and write or edit an answer file with the required data and then call wpeinit -unattend to run the answer file.

If I am honest, I am well out of my depth with much of this last suggestion, but it may be worth some research, if you can't find another way.

Continuing my wade through unknown waters, I think that there may be an easier way using netsh. After running wpeinit to set up your network adapter and start the network services, you would type netsh at the command prompt, which changes the command prompt like diskpart does. Then you need a series of commands like:
interface ip
set address name="Local Area Connection" source=static addr=192.168.1.50 mask=255.255.255.0 gateway=192.168.1.1 gwmetric=1
quit (or exit)

You can check the address by typing netsh interface ip show address or just show address if you haven't left netsh.

Clearly to use this method, you would need a script to capture your data into variables and then run your netsh command, which in a batch file could be written in a single line as:
netsh interface ip set address name="Local Area Connection" source=static addr=192.168.1.50 mask=255.255.255.0 gateway=192.168.1.1 gwmetric=1
substituting your variables for the data.

I am not an expert in this field, but hopefully this will give you some ideas to work on. A good reference book which covers the netsh commands is Microsoft Windows Command-Line by William R Stanek from Microsoft Press.

I have not given any thought about how this could be incorporated into VistaPE, but rest assured it will be possible. First get it all working in basic WinPE setup.

#17 martinr

martinr

    Frequent Member

  • Advanced user
  • 120 posts

Posted 25 April 2007 - 06:21 PM

We seem to have lost winpe64 since my last post.

For the benefit of anyone else who may have the same problem of how to set up static IP addresses in WinPE, and to test my own theories, I wrote the following script.

StaticIP.cmd
@echo off

setlocal

echo Please enter all Static IP data in the format&#58; x.x.x.x

echo.

&#58;DATA1

set ERROR=

set /P ADDRESS=&#34;Enter IP Address&#58; &#34;

if &#34;%ADDRESS%&#34; == &#34;&#34; goto DATA1

for /f &#34;tokens=1-4 delims=.&#34; %%i in &#40;&#34;%ADDRESS%&#34;&#41; do call &#58;CHECKIP %%i %%j %%k %%l

if &#34;%ERROR%&#34; == &#34;1&#34; &#40;

	echo Invalid data. Please re-enter.

	pause

	goto DATA1

&#41;

&#58;DATA2

set ERROR=

set /P MASK=&#34;Enter IP Mask&#58; &#34;

if &#34;%MASK%&#34; == &#34;&#34; goto DATA2

for /f &#34;tokens=1-4 delims=.&#34; %%i in &#40;&#34;%MASK%&#34;&#41; do call &#58;CHECKIP %%i %%j %%k %%l

if &#34;%ERROR%&#34; == &#34;1&#34; &#40;

	echo Invalid data. Please re-enter.

	pause

	goto DATA2

&#41;

&#58;DATA3

set ERROR=

set /P GATEWAY=&#34;Enter IP Gateway&#58; &#34;

if &#34;%GATEWAY%&#34; == &#34;&#34; goto DATA3

for /f &#34;tokens=1-4 delims=.&#34; %%i in &#40;&#34;%GATEWAY%&#34;&#41; do call &#58;CHECKIP %%i %%j %%k %%l

if &#34;%ERROR%&#34; == &#34;1&#34; &#40;

	echo Invalid data. Please re-enter.

	pause

	goto DATA3

&#41;



netsh interface ip set address name=&#34;Local Area Connection&#34; source=static addr=%ADDRESS% mask=%MASK% gateway=%GATEWAY% gwmetric=1



&#58;&#58; Uncomment next two lines to check the address

&#58;&#58; netsh interface ip show address

&#58;&#58; pause

endlocal

goto &#58;EOF



&#58;CHECKIP

if %1 LSS 0 set ERROR=1

if %1 GTR 255 set ERROR=1

if %2 LSS 0 set ERROR=1

if %2 GTR 255 set ERROR=1

if %3 LSS 0 set ERROR=1

if %3 GTR 255 set ERROR=1

if %4 LSS 0 set ERROR=1

if %4 GTR 255 set ERROR=1

goto &#58;EOF
Using the WAIK, I made myself a basic WinPE 64 disk, and so I was able to run the script in both 32 and 64 bit. It seems to do the job, although I am sure that the script and the error-checking could both be improved.

Looking back on this topic, I notice that winpe64 said that everything worked in 64 bit except the network configuration utility, which wasn't 64 bit anyway. I wonder if he was using VistaPE. I doubt it, and it set me thinking whether we could ever do a 64 bit version of VistaPE. The basic stuff is all available in the WAIK and in the 64 bit version of Vista, but the real problems seem to be that the shells are all in 32 bit and so are most of the programs we would wish to run.

#18 teardrop

teardrop
  • Members
  • 2 posts
  •  
    China

Posted 13 May 2007 - 05:53 AM

thanks!

#19 winpe64

winpe64
  • Members
  • 4 posts

Posted 15 May 2007 - 07:51 AM

We seem to have lost winpe64 since my last post.

For the benefit of anyone else who may have the same problem of how to set up static IP addresses in WinPE, and to test my own theories, I wrote the following script.

[...]


Thank you very much. It seems to work very good. And you're right: the main problem with 64-bit PE is that all the GUIs are in 32-bit and won't work under 64-bit.

#20 Maniaxx

Maniaxx

    Newbie

  • Members
  • 11 posts
  • Location:Ruhrpott
  •  
    Germany

Posted 11 August 2007 - 07:00 PM

Its not possible to connect to a 'guest access enabled' Vista host via SMB (aka anonymous access). You must define a username and password instead that is present on the host.

Vista has a new SMB version (most linux distros had similar problems with it) so it may be related to this. I don't know...

#21 someoneingbg

someoneingbg
  • Members
  • 1 posts
  •  
    Sweden

Posted 17 August 2007 - 12:05 PM

I am not sure that I would qualify as one of those, but I have nonetheless prepared a script for Version 2.30.

I put it and the PENetCfg files (except PENetCfg.ini, which I left out) under Net. The script copies the files and makes the registry entries which The Truth said were required. I am not convinced that it works any better than what I had before, but at least it will provide a starting point for others to experiment.

Although I can access the Internet and map network drives using PENetCfg, I am still disappointed that I cannot see Network Neighborhood or its equivalent in A43 or Total Commander.


Hello
Sorry, but i'm not following you in this. Where should the files be placed and how should the file you made be named`?

Best regards

#22 martinr

martinr

    Frequent Member

  • Advanced user
  • 120 posts

Posted 21 August 2007 - 09:11 AM

Hello
Sorry, but i'm not following you in this. Where should the files be placed and how should the file you made be named`?

If you are using my original script from 11 Mar, the script should be named penetcfg.script and should be placed in the ...\Projects\VistaPE\Net folder. The program files should go into ...\Projects\VistaPE\Net\PENetCfg.

Since I wrote the original script, NightMan made some small modifications to it. He included the program files in the script in encoded form. His revised script is available for download through the Download Center in WinBuilder. You will find it in the VistaPE Main Site\VistaPE\Net section.

Either script should work satisfactorily, but the new one is perhaps easier to use for the first time, as you don't need to put the program files in yourself; the script does it for you.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users