ceztko

Confirmed! It works. I had to add the "usbser.sys" driver. Summarizing, 2 files are needed: mdmcpq.inf (put it in \windows\inf) and usbser.sys (put it in \windows\system32\drivers). I think nlite function to leave files on the resulting media should work. Thanks Slurpymeister.

The easy way? Download an original windows xp pro image from p2p. If you fear of legal implications, consider that you are already elegible of owning an un-customized copy. Nlite can't support any existent broken xp build.

I can agree but... These are, frankly, exaggerations. The max that can happen with your job is you loose your job (*). The max that can happen to nuhi is nothing: "NO WARRANTY" on the license is more than enough for him. The max that can happen with MS is you loose the warranty. Loosing warranty is all another issue: if you have licenses for 1000 pc, and you sign a proper support contract with MS (such as Premium Support), you can probably afford using MS supported tools, such as the cited OPK. If you own, let's say, 30 standard WXP licenses for your job, without any further support contract, from a sysadmin prospective (your grandmother probably doesn't use nlite on his home pc anyway ) loosing warranty on the OS, and with software in general, can't be considered an issue: if you find a bug on a nlited windows that is reproducible on a standard windows buid, and report it to MS, you basically have the same opportunities it will be fixed promptly. And if you need tech help (always from a sysadmin/power user perspective), I don't think it's available without signing proper support contracts. Another situation: one want to use nlited windows for embedded purpouse. This is stupid: 1) WXP (or W2K) itself isn't suitable for embedded applications; 2) You don't have any kind of Tech Help Support from MS. EDIT: (*) Here I am assuming no sysadmin would be so stupid to use nlite in mission critical applicances, e.g. medical, air-traffic controlo appliances... while I don't see any problem in using nlite on universities computer networks (that may be very big).

OT: Just read the EULA. IANAL, but I'm pretty sure some clauses can't be enforced: This kind of clauses have never been proved as valid in trials. As long I think M$ can't sue me for what I'm producing (and where I'm using it) with Word, Excel or Access, I assume I can't be sued if am using a nlited build in my job. The customized windows build, in fact, is just the product of nlite, not nlite itself. Even nlite custom script that may be present in the build probably can't pose a restriction on the use of a nlited windows build, for the same reason MS can't limit the usage of my OpenXML files just because MS products wrote the XML skeleton of them. They may still be subjected to copyright, so yes...I may not be allowed to copy those script, but this is not a problem. Probably there are even better examples. It's a long standing myth that's so easy to put a clause of this kind on your License Agreement to give you easy win on trials in case of so called "reverse engineering". If I want, I'm perfectly allowed to study just the build of Windows (without reading any nlite custom script) to learn what nlite is doing to it and reimplement the same behaviour in similar program, a "clone" of nlite. This reverse engineering technique is called clean room design, ofen used by companies that want to create compatible products and it's perfectly legal (for example, Intel reverse engineered x86-64 set of istructions to produce their 64 bit compatible cpus).

Too complicated and out of the purpouse of nlite. Read this WONDERFUL guide about RunOnceEx. There's even an explanation on how to use it during T-12 minute stage of Windows XP Setup. WARNING: if you don't use nlite to customize your build, .net 3 won't installable during Setup. This is caused by some registry keys that are not fully setted up on that stage: nlite processing fix this.

One point is using nlite as part of the product you make and sell. Another is using nlite to create customized windows builds for your daily work. I believe the first is prohibited. About the second one, I think it could not even be enforceable, if present in the EULA...

Yes, it's XPLite. If you see the site linked in my first post P.S., it's described how to patch sfc-os.dll to make WFP switchable like xp-lite does. It's this patched version I'm using now. janedoe's patch does work, but it does disable WFP definitively without registry modifications, like nlite does. The registry modify in this post does work with stopping useless pop-ups . Again: at least with my sfc-os.dll, dunno with an unpatched one. The only problem I have with it is that I can't have it available at the first boot, as winlogon.exe is resetting it to 0. Only once: if I set it after first boot, it remains on the next ones.

To quote myself, it seems that setting this key during the install doesn't surive the first boot Something is setting it again to dword:00000000 just before the installer reboot the system. This is not so good as the setting requires a reboot to apply. If someone knows how to make it surviving the first boot, it would help much. EDIT: "Almost" confirmed. Citing this site, speaking about SFCDisable=dword:ffffff9d value in W2K: Well, seems that M$ added another "feature" and now 4 is another value resetted to 0 after the first boot. If someone knows how to circunvent this, but I have some suspects it is hardcoded...

I used to use RW discs, but it was tedious to clean them before burning them

I don't think WFP applies to driver signing policy (and viceversa). A driver simply shouldn't touch system files, that are in a diferent set, so the user is always allowed to load unsigned drivers, unless the policy is set to block. This is true even in a unpatched system. You are right, but the problem is that the WFP pop-ups windows arising in a nlited system: - are absolutely non-informative: if you are able to consult windows logs (I am not and I don't care; I take a look only at my /var/log/messages ), they can probably help you more; - they aren't really informing you that someone is trying to ovewrite a files in the system and what files. They are just reminders that you have patched/modified files on your system (and after nlite processing they can be IE7, WMP11 files or sfc-os.dll, uxtheme.dll, etc...). They appears only once on a running system and they come back again the next time you reboot. The reason why they are appearing in particular moment? Because you are overwriting (or some other tools for you) a WFP protected file, yes... but if the file overwritten is correctly present in the dllcache, it will be anyway replaced after you answer yes/no to the pop-ups. The next time you'll overwrite any other WFP protect file in the current session, you won't get any other reminder, and the file will be silently replaced. Try yourself.

Taking a look at the news archive page, I saw that many complained in the past about Windows File Protection Pop-ups after nlite processing. It was recently my case, using the just released nlite 1.4.7: I integrated ie7, wmp11, a patched sfc-os.dll and now every time some stupid installer touch system files I got 3-4 WFP pop-ups... But it's just because I know of stupid installers that I want to keep WFP enabled, as most people should do. Understanting that they are just warnings, not errors, I remembered of this little tweak: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] "SFCDisable"=dword:00000004 Where SFCDisable=4 is "enabled, with popups disabled". It works perfectly (seems that even M$ devs like their systems tweaked, after all ): WFP works and no stupid pop-ups that you, nuhi, can't fix for every possibile situation (or at least we can't ask you to do so...). Why don't you integrate this tweak in nlite? P.S.: A small clarification: I am using this patched sfc-os.dll that fully respects values of SFCDisable. Not sure if the original sfc-os.dll respects SFCDisable=4.

No, thanks. It worked perfectly.

Hi! I'm trying to replace sfc-os.dll on a windows xp sp3 media build with a patched one that permit switching of the windows file protection (so is not exactly the wfp disable patch that is already on nlite). I tryed 2 methods: - I tryed to put the file on the $OEM$/$$/system32 and $OEM$/$$/system32/dllcache dirs. If this method has ever worked, well... now it stopped. The wfp is active when copying $OEM$ dirs, so the file is getting replaced by the orginal compressed sfc-os.dl_ version; - I tyred to compress my edited sfc-os.dll with makecab and putting it in the i386 dir. This is described as a working method in many sites. Well, for me it hasn't worked: while trying to copy the files from cd to hd (the first phase after partitioning; sorry don't know the correct phase name), it stopped exactly at that file. Can't say if the installer wasn't able to expand it or it detected it was edited so refused it. Can you tell me a working method to replace WFP protected files on i386 dir in recent windows versions? Could putting the un-compressed file on the i386 dir (even after nlite processing) works? Sorry, but I don't want to waste other dvds (I'm not using a vm...), and can't find up-to date infos googling around. Thanks, Francesco

Confirmed, I was overwriting the modified sysoc.inf with my own. If I can give an advice, when WMP11 slipstreamer finish its job, in the pop-up window the user could be warned on modifying files such as wbemoc.inf, svcpack.inf and sysoc.inf. In my case, I hadn't any clue WMP11 slipstreamer was modyfing sysoc.inf. Thanks for the prompt help (and you and Boooggy for the great app)!!! Francesco

I AM breaking my own SYSOC.INF . I have a modified, already processed by nlite, sysoc.inf in my $OEM$/$$/Inf directory. This is because I am adding the W2K IIS to the WXP HOME build. If you are telling me that wmp slipstreamer needs some modifications to sysoc.inf, good: I just know what to do! Thanks for the moment, I'll keep you informed.

To help debugging, here is my wbemoc.inf after WMP11 slipstreamer processing (wbemoc-wmp11-slip.inf), after nlite processing (WBEMOC-nlite.INF), svcpack after WMP11 slipstreamer processing (SVCPACK_wmp11_slip.inf), svcpack after nlite processing (SVCPACK.INF). Consider I first run WMP11 slipstreamer alone, and after I run nlite on the processed source. wbemoc_wmp11_slip.inf WBEMOC_nlite.INF SVCPACK.INF SVCPACK_wmp11_slip.inf

The problem described here and confirmed here is still present in the last version of WMP11 slipstreamer, the 1.3.1.0. As anonim1979 seemed to have offered a workaround, that seems to be merged in 1.2.3.0, why the problem is still here? EDIT: solved, i was overwriting the modified sysoc.inf

I already know how to workaround this issue. The problem is: "Keep files" section in nlite doesn't work for files in driver.cab, as it should. This seems to me a bug: how can i report the bug to the author so i'm sure he's aware of the problem?

I changed the title of the topic: it seemed everybody thought "problem solved". (see previous post)

It didn't work! Have this in my conf: ... [KeepFiles] msconfig.exe agp440.sys ... agp440.sys is still missing from driver.cab and i386 dir. Is "Keep Files" broken for drivers' files??? Thanks, ceztko

Well, i supposed there were needed other files, like *.inf or *.cat. The truth is that if you simply copy this file in system32, you fix a "broken" system, but i don't know if this is a clean method or only a workaround. Anyway, i didn't know that section Assuming it does work with files in driver.cab, should be fine for me. Thank you!

Hi! This is not obviously a nlite bug, but a stupid policy in intel chipset drivers releases: file agp440.sys, presumably responsabile for agp440 service driver, is missing in a windows xp customized build made with "Agp Filters" checked in nlite and a replacement can't be found in official intel chipset drivers integrated into the build. I don't know how much work will be necessary, but would be possibile to trucate the selection of drivers in "Agp filters" and permit another specific check for "Intel Agp filters", considering this very special case of drivers available only in the original distribution? Unfortunately, simply unchecking "Agp filters" is not an option for me, because i need it for other computers that needs this to install older version of Via chipset drivers. Thanks a lot for the attention and for this wonderful tool! Francesco, "ceztko" UPDATE: Title changed, see below.