Jump to content

[SOLVED] Big trouble with nLited SP3 WinNT & WinNT32 installation


BikinDutchman

Recommended Posts

Here's a preset that doesn't work using winnt.exe with nLite v1.4.6.

Why is using winnt.exe so uncommon? It's quicker to install from a separate partition on an HDD than it is from a CD.

And with a CD, if you find that you left something out of your configuration/preset, you have to toss it and start over again. Just seems rather inefficient and wasteful.

Last_Session.ini

Edited by E-66
Link to comment
Share on other sites


You gotta understand two things:

- No one uses winnt.exe, it works fine on CD boot

- Tried one of your presets which was failing and it worked with 1.4.6 with the winnt32.

Anyway it is just a question of how much lines to remove from the wbemoc, they did something weird there, easy to break.

So post your presets that didn't work, just saying it does not help.

edit: tried it now again with just languages removed, meaning normal components are left, and there is no problem with winnt32 as stated in the changelog. If someones winnt32 fails and boot from the same ISO works then please post your preset.

Just integrating the SP3 on a original SP2 source through nLite makes the winnt32.exe install fail. Nothing removed, nothing tweaked, nothing else... just plain integration. This is on a Norwegian XP source. I haven't tried with an English source.

Integrating by using Microsofts methods will make the winnt32.exe install work, but once I use nLite to change ANYTHING after the integration, it fails again. Normal installation through CD works, but not winnt32.exe.

Link to comment
Share on other sites

Integrating by using Microsofts methods will make the winnt32.exe install work, but once I use nLite to change ANYTHING after the integration, it fails again. Normal installation through CD works, but not winnt32.exe.

I don't understand why nLite changes anything at all in the Windows source files when simply slipstreaming a service pack. Why can't it just run the Service Pack's /integrate switch? Does it need to make modifications to inf files or sif files at all? What is the purpose of this behavior?

Link to comment
Share on other sites

I don't understand why nLite changes anything at all in the Windows source files when simply slipstreaming a service pack. Why can't it just run the Service Pack's /integrate switch? Does it need to make modifications to inf files or sif files at all? What is the purpose of this behavior?

That is because some integrations go a lot deeper than just replacing a couple of files and setting. Example: IE7 integration.

Link to comment
Share on other sites

That is because some integrations go a lot deeper than just replacing a couple of files and setting. Example: IE7 integration.

Well, nLite still shouldn't touch anything unless I am, for example, integrating IE7. I still don't see a reason for it to touch anything if you are simply slipstreaming a service pack. If I was slipstreaming AND adding add-on packs and cutting out system services then I would understand why nLite would need to modify other Windows source files.

Link to comment
Share on other sites

Integrating by using Microsofts methods will make the winnt32.exe install work, but once I use nLite to change ANYTHING after the integration, it fails again. Normal installation through CD works, but not winnt32.exe.

I don't understand why nLite changes anything at all in the Windows source files when simply slipstreaming a service pack. Why can't it just run the Service Pack's /integrate switch? Does it need to make modifications to inf files or sif files at all? What is the purpose of this behavior?

It doesn't change anything when slipstreaming, if you find the contrary let me know.

Addons do change but nothing systematic, unless the addon does it by itself.

Link to comment
Share on other sites

It doesn't change anything when slipstreaming, if you find the contrary let me know.

Addons do change but nothing systematic, unless the addon does it by itself.

Well, as rogergh said, simply slipstreaming SP3 onto a Windows XP source with nLite causes the installation to fail when using winnt32.exe. This is not fixed with 1.4.6. I do find that nLite has modified the txtsetup.sif and wbemoc.inf files simply by doing a Service Pack slipstream and nothing else. After doing the slipstream the files show:

;  customized by nLite - www.nliteos.com

So there is some modification going on, thus this is why winnt32.exe installs are failing.

Link to comment
Share on other sites

So there is some modification going on, thus this is why winnt32.exe installs are failing.

For simple integrations these modifications of TXTSETUP.sif and WBEMOC.inf are just cosmetic. nLite removes comments and useless white space. (Always amazed how MS can deliver such crappy layouts).

Personally I prefer to slipstream SP3 first, before nLite. That gives me a constant start for new integrations.

On a different note: I read in the MS info that WinNT32 installations across a network slightly differ from installations partition to partion. That may give an additional source of confusion.

Link to comment
Share on other sites

It doesn't change anything when slipstreaming, if you find the contrary let me know.

Addons do change but nothing systematic, unless the addon does it by itself.

Well, as rogergh said, simply slipstreaming SP3 onto a Windows XP source with nLite causes the installation to fail when using winnt32.exe. This is not fixed with 1.4.6. I do find that nLite has modified the txtsetup.sif and wbemoc.inf files simply by doing a Service Pack slipstream and nothing else. After doing the slipstream the files show:

;  customized by nLite - www.nliteos.com

So there is some modification going on, thus this is why winnt32.exe installs are failing.

That is simply not true.

nLite DOES NOT MODIFY on Slipstream.

You must have integrated something or did Unattended or Tweaks...

And the modification it then does on wbemoc is needed to make manual install work. Yes 1.4.6 fails for winnt.exe, works on my winnt32.exe tests. Next one will be even more compatible.

Link to comment
Share on other sites

That is simply not true.

nLite DOES NOT MODIFY on Slipstream.

I take that back. I did some further tests and winnt32.exe installs do work for me after using nLite to slipstream. There are no modifications done to the Windows source. You are correct. I apologize for making incorrect accusations.

What I had done was integrate one driver after slipstreaming. I integrated the Intel Matrix Storage Manger driver so that I could install on a Dell Optiplex 755 system that was configured in a RAID 0. So, when you integrate one driver nLite makes the modifications to the wbemoc.in_ and txtsetup.sif files, etc. This is the point when the install becomes broken.

Nuhi, nLite is an awesome product. I appreciate the efforts that you have made and I know that you have had countless late nights and have put in so much hard work which mostly goes unnoticed. Thank you for your efforts!

Link to comment
Share on other sites

Tigrao, good. No harm done, I just had to make it clear.

Btw what you said about the driver integration...it shouldn't be necessary to "fix" the inf in that case, gonna check and do it only on addons and removals.

Thanks for the feedback.

Link to comment
Share on other sites

nuhi,

maybe off-topic, or cpmpletely unrelated, but could any of the problems with WINNT.EXE (or WINNT32.EXE) installs be related to this thing reported by BinkinDutchman? :unsure::

--Delete i386\USETUP.exe; copy i386\System32\SMSS.exe one level up, and rename it to USETUP.exe (to have an up to date GUI steup for all types of install: CD, WinNT, WinNT32).
-Delete i386\USETUP.exe: this version is not updated, causes problems with WinNT and WinNT32 installs

http://www.msfn.org/board/Windows-XP-SP3-s...up-t118781.html

jaclaz

Link to comment
Share on other sites

maybe off-topic, or completely unrelated, but could any of the problems with WINNT.EXE (or WINNT32.EXE) installs be related to this thing reported by BinkinDutchman? :unsure::

I believe not. The USETUP versions do not differ much, see earlier posts in this topic by aittersu.

I am paying so much attention to making my WinXP_SP3 source up-to-date and always the same, to help figuring out what the problem is.

I have still the same problems with nLite 1.4.6, WinNT32 and can fix it by editing TXTSETUP.sif. I still need to do a comparison with a CD install and after that report back.

I am now getting also concerned about possible differences between (partition to partition) and (network to partition) installs.

Link to comment
Share on other sites

Thanks to many suggestions, I think that the winnt32.exe install is fixed (not sure about winnt.exe yet). At least for me anyway.

I had the same problems and I tried the $oem$\$1\$$rename.txt under the I386 folder. This seemed to help some. Then I remembered I had not tried the suggestion made by litvinoven from this thread This Thread Post #14

In the wbemoc.inf I only needed to comment out

[WBEM.CopyMOFs]

rsop.mfl

rsop.mof

and added

[WBEM.SYSTEMMOFS]

cmdEvTgProv.mof ;nLite add: ,evtgprov.mof

napclientprov.mof ;nLite add: ,napprov.mof

napclientschema.mof ;nLite add: ,napschem.mof

using nlite 1.4.6.

I'm not sure yet which or if both the $$rename.txt and litvinoven methods fixed my problem.

I've attached my wbemoc.inf, the preset, and the $$rename.txt.

Also there are no errors in the setuperr.log

So far the only thing I see is the following. I only shows up twice and I'm pretty sure is during the setup.

Event Type: Error

Event Source: PSched

Event Category: None

Event ID: 14000

Description:

QoS: The Packet Scheduler failed to register with the Generic Packet Classifier (msgpc.sys)

Let me know if you may need anymore info.

Update

Upon further testing i did not need the $$rename.txt or the lines under the [WBEM.SYSTEMMOFS]. Commenting the lines out of the [WBEM.CopyMOFs] section fixed (so far) my problem. One more thing this seems to break the winnt.exe install. The install ignores parts or most of the unattended winnt.sif file.

I forgot to mention I install over the network. BartPE and winnt32 work for now.

Update

The winnt.exe install ignores the following

OemSkipEula

ProductKey

TimeZone

workgroup\domain

OEMSkipWelcome (mini setup)

There may be a couple more.

The setup does complete without errors.

wbemoc.inf

XPSP3.ini

__rename.txt

Edited by mdemel
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...