chapmani

A parallel thread is discussing removing the dependency of the "DHCP Client" service on the "NetBios over TCP/IP" non-Plug and Play device driver. With the addition of the suggested registry tweak, it seems you CAN disable "NetBios over TCP/IP" in nLite on the Tweaks | Services page -- at least for use in a home network. See the discussion in this thread: [bUG in 1.2.1] DHCP Client service depends on NetBT unneccesarily

Back in May, my installs started dyeing during the "copy files" stage - always on the same file. I tried the original Windows disk - it died. Tried a second original disk - still crapped out. Replaced the CD drive cable - still nada. Swapped out CD drives - still no joy. After hours of re-tries, and more time searching for answers than I'd care to admit, all I saw was the standard suggestions, bad burn, bad disk, bad drive, and bad cable. Finally in one dark corner of the web I saw the suggestion that it might be bad ram. It seemed unlikely - previous installs had worked, and it always seemed to crap out on the same file. I ran mtest86+ and low and behold - lots of errors. I did the old first on one stick of ram, than the other to find the bad one. I replaced it (it was still under warranty) and the problem was solved. Perhaps that might be your problem as well.

Each time you reformat the disk, an new Volume Serial Number is created. Do you restore the Volume Serial Number to the same one on the disk the WPA.DBL file came from? This is the most common trigger for WPA. I do my reformating outside of the install (with a BartPE disk) and use a batch file running SysInternals VolumeID available at: VolumeID Webpage

It took an amateur like me more than 15 cycles of: nLite -> Burn customised disk -> Install Windows -> Whine, moan and tear my hair out when there was no Internet connectivity - Reformat the partition -> Restore the Volume Serial Number (to prevent a Windows Product Activation crap out) -> Rinse and Repeat, to solve this. A little quick math on the install time, plus searching for solutions in the forums (as well as the rest of the net) adds up to a lot of wasted time. In my case several installs a day for more than a week. My doctor says the nervous tick will eventually go away! I'm about to try applying that registry change as part of my registry tweaks set in cmdlines.txt. I'll report back with the results. Since my local network uses NetBeui for machine to machine transfers, I'm probably a good test subject. (Configuration ala Steve Gibson's (grc.com) "Network Bondage" page -- IE Disable "NetBios over TCP/IP", Bind both "File and Printer Sharing" and "Client for Microsoft Networks" to the NetBEUI protocol, Unbind both from the TCP/IP protocol ) ---- Neui - I don't know if this dependency can/will be changed by nLite automatically in future version. But the current situation is dangerous enough, that it has probably caused a large number of network connectivity problems in nLite installs. Anyone who's read Steve Gibson's "Network Bondage" page immediately assumes "NetBios over TCP/IP" is something they don't need, and don't want, and therefore disables it. If the dependency can't be changed, might it be wise to remove "NetBios over TCPIP" from the Tweaks | Services page to eliminate that mistake? Alternatively somehow show a warning about the consequences of disabling it. --------- Edited To Add Promised Success/Failure Report In nLite on the Tweaks | Services page, I disabled the "NetBios over TCP/IP" service (actually a Non-Plug and Play driver). During the install I used Cmdlines.txt to install a very few registry tweaks. One of those included was the above recommended: ;Disable Dependency of "DHCP Client" service on "NetBios over TCPIP" service [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dhcp] "DependOnService"=hex(7):54,00,63,00,70,00,69,00,70,00,00,00,41,00,66,00,64,00,00,00,00,00 This removes the dependency of the "DHCP Client" service from requiring the "NetBios over TCPIP" non-Plug and Play driver be started first. (The original Hex value was longer, with the additional text "NetBT") As stated above, I use the NetBEUI protocol for wired local network transfers. I can confirm that these connections continued without a problem when using this registry change. I can also confirm that the machine now successfully obtains an IP address and communicates normally on the Internet. No errors appeared in the Event Log. There may be some other, not yet discovered, dependencies requiring the "NetBios over TCP/IP" driver, but so far things look good.

On the "Tweaks" page of nLite, in the Services tab, indeed a "NetBios over TCPIP" service is listed. *** DON'T TOUCH IT *** The "DHCP Client" service requires the "NetBios over TCPIP" service. If you disable the "NetBios over TCPIP" service, the "DHCP Client" service can't start, and your machine will never recognize that it has been assigned an IP address. Nuhi - this is dangerous enough, that it has probably caused a large number of network connectivity problems in nLite installs. Anyone who's read Steve Gibson's "Network Bondage" page immediately assumes this is something they don't need, and don't want, and therefore disables it. Might it be wise to remove it from the Tweaks | Services page to eliminate that mistake? Alternatively somehow show a warning about the consequences of disabling it. It took an amateur like me more than 15 cycles of: nLite -> Burn customised disk -> Install Windows -> Whine, moan and tear my hair out when there was no Internet connectivity - Reformat the partition -> Restore the Volume Serial Number (to prevent a Windows Product Activation crap out) -> Rinse and Repeat, to solve this A little quick math on the install time, plus searching for solutions in the forums as well as the rest of the net adds up to a lot of wasted time. In my case several installs a day for more than a week. My doctor says the nervous tick will eventually go away! ----- (From a message posted elsewhere) In an over zealous use of nLite* I disabled the "NetBios over TCPIP" service. I guess Steve Gibson's (grc.com) "Network Bondage" page made me too sensitive to that phrase. While the network card works for the NetBeui protocol across my local network (not over TCP/IP), and my router assigns an IP address (that implies that one was requested), the computer never recognizes that it has an IP address. Therefore there is no internet access. Simple - turn the service back on, right? Nope. The "NetBios over TCPIP" service does not show up in the Services management console. To turn it back on, go to the "Device Manager" (shortcut [Windows Key]+[R] devmgmt.msc[Enter]). On the "View" menu, pick "Show Hidden Devices". Expand the "Non-Plug and Play Drivers" section. Double Click on "NetBios over TCPIP" and pick it's "Driver" tab. In the "Startup Type" section pick "System" from the drop down box. The easiest bet is to reboot, and all will be well. I you want to take the hard way, click the "Current Status" "Start" button on that tab. Then go to the "Services" management console (shortcut [Windows Key]+[R] services.msc[Enter]). Double click on "DHCP Client", and then click on it's "Service Status" "Start" button.

In an over zealous use of nLite* I disabled the "NetBios over TCPIP" service. I guess Steve Gibson's (grc.com) "Network Bondage" page made me too sensitive to that phrase. While the network card works for the NetBeui protocol across my local network(not over TCP/IP), and my router assigns an IP address, the computer never recognizes that it has an IP address. Therefore there is no internet access. Simple - turn the service back on, right? Nope. The "NetBios over TCPIP" service does not show up in the Services management console. To turn it back on, go to the "Device Manager" (shortcut [Windows Key]+[R] devmgmt.msc[Enter]). On the "View" menu, pick "Show Hidden Devices". Expand the "Non-Plug and Play Drivers" section. Double Click on "NetBios over TCPIP" and pick it's "Driver" tab. In the "Startup Type" section pick "System" from the drop down box. The easiest bet is to reboot, and all will be well. I you want to take the hard way, click the "Current Status" "Start" button on that tab. Then go to the "Services" management console (shortcut [Windows Key]+[R] services.msc[Enter]). Double click on "DHCP Client", and then click on it's "Service Status" "Start" button.

In the MSFN | Unattended Windows | Download section There's a "Video Resolution Changer". I've taken to using it on systems where resolution I set in nLite doesn't stick. http://unattended.msfn.org/files/global/1365Vidchng.zip

The answer is fairly simple, and obvious. Take the stuff you put in the RunOnceGUI section of nLite out. Add them back in to your RunOnceEx. Conflict eliminated.

Since nLite now includes a page on which to integrate drivers, I stopped using the OemPnPDriversPath option in the WinNT.sif file. It seems to have had a side benefit of reducing the number of type-o's I make in those long path statements tool!

The Classic "home user has to have RAID because it's cool." RAID is cool - until something goes wrong. As you've discovered, when things go "splat", none of your normal "fix it" tools work. IMHO, for the average home user RAID is a big mistake. Just marketing hyperbole. I'm currently bashing my head against computer with a single drive, single partition RAID setup - IE a totally useless one. It's problem - massive viruses and no backups. Perhaps try a BartPE disk, loading your RAID drivers from floppy at the "Press F6" prompt. That will let you get access to your "must save" data, and move it off to another, standard drive.

In know you're talking about Server 2003 - so I'm not sure my comments apply, but . . . NetBEUI as a transport protocol on a wired, local network, works very well -- faster than TCP/IP because of less overhead. If configured correctly is extremely safe because it is non-routable. While Steve Gibson's "Network Bondage" page has never been updated to show the configurations for XP - it does a good job explaining the concept. http://www.grc.com/su-bondage.htm The secrets are: 1. Install the NetBEUI protocol (From the XP CD copy \VALUEADD\MSFT\NET\NETBEUI\NBF.SYS to the Windows\System32\Drivers directory | From the XP CD copy \VALUEADD\MSFT\NET\NETBEUI\NETBF.INF to the Windows\Inf directory | Local Area Connection Properties | Install | Protocol | NetBEUI Protocol) [i do these steps by placing the two files in the $OEM$\$$\System32\Drivers and $OEM$\$$\Inf directories on the install disk and adding "MS_NetBEUI=params.MS_NetBEUI" to the [NetProtocols] section of the WINNT.SIF file] 2. Disable "NetBios over TCP/IP" (In XP that's Local Area Connection Properties | Internet Protocol (TCP/IP) | Properties | Advanced | WINS | Disable NetBIOS over TCP/IP) [i'd bet that this can be done in WINNT.SIF too, if I knew what I was doing] 3. Ensure that both Client for Microsoft Networks and File and Printer Sharing are bound to the NetBEUI protocol and NOT to TCP/IP (in XP Network Connections | Advanced Menu | Advanced Settings | Bindings for Local Area Connection [or whatever you called it] | Uncheck "File and Printer Sharing for Microsoft Networks / Internet Protocol TCP/IP" and Uncheck "Client for Microsoft Networks / Internet Protocol TCP/IP) [Anybody got a hint on how to do this automatically?]

If you look at the Documents and Setting tree, you will see that there is a branch called "Administrator" and "Administrator.INFECTED". Your $OEM$ copied files are in the "Adminstrator" branc. It seems that when the install sees the account already exists (IE from its creation in the $OEM$\$Docs) it creates a new one by suffixing the computer name on the end. This is probably an attempt to keep files and setting from being overwritten by a new install.

You can gain some performance by turning off unneeded services. (Search the web for the Black Viper tweaks - he seems to be offline, but his tweaks live on.) Of course you can do this to any install (via Services.msc), but nLite will let you pre-configure your system that way from the get-go.

Others have suggested that the CD may be corrupted. I've had issues when the Nlite customised CD didn't work well when burnt at the writer's top speed. I've slowed it down a notch or two and that cured the problem. Personally I always let Nlite make the ISO, but burn the disk in my regular CD software to give me that control. A good check might be to run the install from the original Microflacid disk and see if that works. (Yea - I know there goes another hour or so down the drain.) There are other possible problems too. For example at one point my installs started dyeing during the "copy files" stage - always on the same file. I tried the original disk - it died. Tried a second original disk - still crapped out. Replaced the CD drive cable - still nada. Swapped out CD drives - still no joy. After hours of re-tries, and more time searching for answers than I'd care to admit, all I saw was the standard suggestions, bad burn, bad disk, bad drive, and bad cable. Finally in one dark corner of the web I saw the suggestion that it might be bad ram. It seemed unlikely - previous installs had worked, and it always seemed to crap out on the same file. I ran mtest86+ and low and behold - lots of errors. I did the old first on one stick of ram, than the other to find the bad one. I replaced it (it was still under warranty) and the problem was solved. Perhaps that might be your problem as well. Mtest86+ is more current than the older mtest86 version. Download pre-compiled CD ISO's, Floppy Disk, or USB Memory key versions at: http://www.memtest.org/#downiso