zorphnog

Well a simpler way to do what you want is this: getOSver()=="XP" && getSPver()<2 && getOSlang().substr(0,2)=="EN" More importantly, though, I believe you have discovered a bug. There is no getOSlang() function. Therefore no matter what you try, the condition is never going to work if getOSlang is in the equation. @Kel I searched through all the scripts and unless I am just blind I never saw the function. After adding the following code, the conditional statement worked flawlessly: function getOSlang() { position="core.js"; whatfunc="getOSlang()"; return oslang; }

I'm a little confused. You want to deploy this 2003 build to only new servers or do you want to be able to recover corrupt servers as well? Is your dilemma determining whether a logical drive is actually a SAN or is it whether a drive should be recovered period?

The desc field for your CDRWin entry needs to be on one line. Some how yours is on two.

Post your conifg.js file.

Try launching the hta using mshta.exe. mshta.exe %CDROM%\WPI\WPI.hta

By the way, the reason you can boot from network is because when you boot from the network you use a universal driver. All PXE-enabled NICs can use the universal driver, but once the PE environment loads you need the NIC specific driver.

It doesn't matter what its called as long as its not named boot.wim and in the sources directory. As far as your image not working. Are you mounting it or applying and then capturing it? If you're mounting winpe.wim its not going to boot because the original wim was not captured as bootable. Apply the winpe image, make your changes and capture the image using the /boot parameter. Alternatively, you can just mount the boot.wim image and make changes because it is already bootable.

I'm not sure why the WAIK gives you both .wim's because they're basically the same except for the fact that boot.wim is bootable. I usually just delete winpe.wim and edit boot.wim. I'm not sure where you are getting the capture and apply differences for them. The wim's have nothing to do with capturing and applying images, only imagex.exe is involved in that.

If you install them manually to your PE image you must place the driver inf in the \Windows\inf folder, and the source files in the \Windows\System32\drivers folder. Since it is a network driver, be sure to rename the .inf file by prefixing it with "net" i.e. e1000.inf becomes nete1000.inf.

Thats too vague of a description to go by. We need the specific errors that you are receiving and your configuration files at least. I would guess its something in your configuration. Post the error messages and your config.js.

You could be missing the network drivers for whatever machine you are trying to boot it on. Use devcon.exe to check the status of the NIC. Try something like: devcon status pci*

What kind of CD were you using that ignored it after the first boot? Was it PE or something else? I would start with it and try to reverse engineer it.

Well I'm not sure that it would necessarily be a BIOS manipulation, simply bc there are so many different bios's that it would seem impractical to implement it that way. I would think more along the line of the cd boot loader checking for some type of setting change that would prevent it from loading the cd. Personally, I remove the "Press any key to load from cd..." and just eject the cd tray before I exit PE to ensure that it will not boot from cd again. Granted, all my hardware platforms are laptops so I don't have to worry about the tray closing.

So what kind of errors are you running into? I understand what you are trying to do, but I'm not sure exactly what problem you are having. Does it just not load? Do you receive an error message? Does it not logon? Does WPI freeze? Just to make sure I understand you correctly, you're logging in as a user originally, run you're autologon utility, reboot, auto logon as admin, install PCAnywhere, delete registry entries, reboot, and try to log back into the user account and run final.bat?

Most likely a driver issue. What NIC are you using?

Ok, I ran a test script with the calls you are using and received a "User has cancelled operation" error. However, when I modified the run command it worked flawlessly. Try using shell.run("cscript i:\script.vbs") or shell.run("wscript i:\script.vbs").

Need a little more info. How are you trying to call the script? Are you mounting the share?

How are you trying to open the .hta file? You should be using: mshta "X:\Program Files\My HTA\myhtafile.hta" Or wherever your .hta is located, just make sure that you use the full path to the .hta file or nothing will happen.

You have two configuration entries named the same thing? Did you create your config file manually? Try using the configuration editor within WPI. You should never have two entries with the same unique ID, nor should they have spaces in the IDs.

What you need to do is a mix between a dependency and a gcond. The gcond of AppA should be a check for a file or or registry entry that is specific to .NET Framework 1.1. The dependency of AppA should be the unique ID of your .NET Framework configuration entry.

Well you could still solve this with one script. Try something like: Run(@ScriptDir & "\exe\AdbeRdr80_en_US.exe") That should give you the relative path that you need.

Ok, this is what I think is happening. WPI runs from the WPI folder and since the call to your AutoIt script is made from WPI the base directory is WPI. Basically, WPI runs your AutoIt script from a command prompt where the root is your WPI path. So when your AutoIt script tries to access exe its really trying the path: WPI\exe\AdbeRdr80_en_US.exe instead of WPI\Install\exe\AdbeRdr80_en_US.exe. I'm not completely sure that is what is happening, but you can easily verify by changing the Run command of your AutoIt script to ("Install\exe\AdbeRdr80_en_US.exe").

Definitely sounds like and error in your autoIt script. You will definitely need to re-compile it. I would suggest using relative paths instead of absolute paths, then you won't have to re-compile again in the future. edit: After thinking about it more, I'm not sure that this will solve your problem. I have an idea that it may be something else, but I need you to post your folder structure and the part of your autoIt script you are using to call the install file to be sure.

Yep. The Windows 2003 RIS drivers worked! I was looking and the only difference in the hwid is that mine was REV_12 instead of REV_11 which for some reason shows up as just "Ethernet Controller" as the descriptor. Thanks for the help.

Nope. The cards show up as HP NC373i which are supposed to be covered in the beta drivers on that ftp site. I'll look into the NetExtreme II drivers though, who knows...