Denney

Just as I thought, you NEED to have the following in the SVCPACK.INF file: [Version] MajorVersion=5 MinorVersion=1 BuildNumber=2600 [SetupData] CatalogSubDir="\I386\HOTFIXES" Seems unusual that Microsoft left those out of the SVCPACK.IN_ file placed on the CD to begin with...

@dukeleto: You MUST of had that "file not found" error on SP1 because the "CMDOW.EXE" file is NOT included with Windows.

Well, by just adding a "\" in from of I386 in my version didn't work. Must be version numbers that are required.

Where did you put the CMDOW.EXE file on the original CD? Putting it in the same place on the new CD should fix your problem.

Heh. Strange... My SVCPACK.INF is based on the version I expanded from the actual CD... Go figure... Microsoft left out some important bits...

Take a look here on how to make it fully unattended installation: http://www.msfn.org/board/index.php?showto...ndpost&p=151119

This setup used to work in SP1 but won't work now. Here are the related files: SVCPACK.INF: [Version] Signature="$Windows NT$" [SetupData] CatalogSubDir="I386\HOTFIXES" [ProductCatalogsToInstall] [SetupHotfixesToRun] DOTNETFW.EXEDOSNET.INF: [OptionalSrcDirs] HOTFIXES I created the DOTNETFW.EXE file using the method by GreenMachine here: http://greenmachine.msfnhosting.com/IEXPRESS/iexpress.htm For some reason, SVCPACK.INF doesn't get executed during setup. I have deleted the original SVCPACK.IN_ file in I386. Is anyone else having problems using SVCPACK.INF in Service Pack 2?

Use the ModifyPE program available at unattended.msfn.org. It will modify the PE (CRC) header of SFC_OS.DLL to allow setup to accept it.

@visaversa: I've done that but it doesn't set the keyboard layout properly (it also installs both Engligh (US) and whatever keyboard you want). Also, I have customized some of the regional settings.

@cxxxkies: It should say that the files have no digital signature and also that they were NOT able to replaced. If it says that, then your OK. Those errors are to be expected.

Here's how I do my setup: At setup (cmdlines), I create my user accounts, import my registry edits. At first boot (RunOnceEx), I install my applications and import my registry edits again. At second boot (RunOnceEx), I cleanup my installation and import my registry edits once more to make sure they get applied (some won't apply until second boot). This method works flawlessly for me. But it depends on your personal preference.

This is my "regional.inf" file, it removes the English(US) keyboard layout and adds the English(Australia) one: [Version] Signature = "$Windows NT$" [DefaultInstall] DelReg = Regional.DelReg AddReg = Regional.AddReg [Regional.DelReg] HKCU,"Keyboard Layout"; Removes all current keyboard layouts. [Regional.AddReg] ; Add Australian regional settings. HKCU,%INat%,iCountry,%REG_SZ%,"61" HKCU,%INat%,iCurrDigits,%REG_SZ%,"2" HKCU,%INat%,iCurrency,%REG_SZ%,"0" HKCU,%INat%,iDate,%REG_SZ%,"1" HKCU,%INat%,iDigits,%REG_SZ%,"2" HKCU,%INat%,iLZero,%REG_SZ%,"1" HKCU,%INat%,iMeasure,%REG_SZ%,"0" HKCU,%INat%,iNegCurr,%REG_SZ%,"1" HKCU,%INat%,iTime,%REG_SZ%,"0" HKCU,%INat%,iTLZero,%REG_SZ%,"0" HKCU,%INat%,Locale,%REG_SZ%,"00000C09" HKCU,%INat%,s1159,%REG_SZ%,"AM" HKCU,%INat%,s2359,%REG_SZ%,"PM" HKCU,%INat%,sCountry,%REG_SZ%,"Australia" HKCU,%INat%,sCurrency,%REG_SZ%,"$" HKCU,%INat%,sDate,%REG_SZ%,"." HKCU,%INat%,sDecimal,%REG_SZ%,"." HKCU,%INat%,sLanguage,%REG_SZ%,"ENA" HKCU,%INat%,sList,%REG_SZ%,"," HKCU,%INat%,sLongDate,%REG_SZ%,"dddd, d MMMM yyyy" HKCU,%INat%,sShortDate,%REG_SZ%,"dd.MM.yy" HKCU,%INat%,sThousand,%REG_SZ%,"," HKCU,%INat%,sTime,%REG_SZ%,":" HKCU,%INat%,sTimeFormat,%REG_SZ%,"h:mm:ss tt" HKCU,%INat%,iTimePrefix,%REG_SZ%,"0" HKCU,%INat%,sMonDecimalSep,%REG_SZ%,"." HKCU,%INat%,sMonThousandSep,%REG_SZ%,"," HKCU,%INat%,iNegNumber,%REG_SZ%,"1" HKCU,%INat%,sNativeDigits,%REG_SZ%,"0123456789" HKCU,%INat%,NumShape,%REG_SZ%,"1" HKCU,%INat%,iCalendarType,%REG_SZ%,"1" HKCU,%INat%,iFirstDayOfWeek,%REG_SZ%,"0" HKCU,%INat%,iFirstWeekOfYear,%REG_SZ%,"0" HKCU,%INat%,sGrouping,%REG_SZ%,"3;0" HKCU,%INat%,SMonGrouping,%REG_SZ%,"3;0" HKCU,%INat%,sPositiveSign,%REG_SZ%,"" HKCU,%INat%,sNegativeSign,%REG_SZ%,"-" HKCU,%INat%\Geo,Nation,%REG_SZ%,"12" ; Add Australian keyboard layout. HKCU,"Keyboard Layout\IMEtoggle\scancode" HKCU,"Keyboard Layout\Preload",1,%REG_SZ%,"00000c09" HKCU,"Keyboard Layout\Substitutes",00000C09,%REG_SZ%,"00000409" HKCU,"Keyboard Layout\Toggle",Hotkey,%REG_SZ%,"3" HKCU,"Keyboard Layout\Toggle","Language HotKey",%REG_SZ%,"3" HKCU,"Keyboard Layout\Toggle","Layout Hotkey",%REG_SZ%,"3" [Strings] INat = "Control Panel\International" REG_SZ = 0x00000000 REG_BINARY = 0x00000001 REG_SZ_NOCLOBBER = 0x00000002 REG_BINARY_NOCLOBBER = 0x00000003 REG_MULTI_SZ_APPEND = 0x0001000A REG_MULTI_SZ = 0x00010000 REG_DWORD = 0x00010001 REG_MULTI_SZ_NOCLOBBER = 0x00010002 REG_DWORD_NOCLOBBER = 0x00010003 REG_MULTI_SZ_DELVAL = 0x00010006 REG_ADDREG_APPEND = 0x00010008 REG_EXPAND_SZ = 0x00020000 REG_EXPAND_SZ_NOCLOBBER = 0x00020002 OFF = 0x00000000 ON = 0x00000001Export "HKCU\Control Panel\International" for regional settings and "HKCU\Keyboard Layout" for your keyboard layout.

I use SVCPACK for .NET Framework + hotfixes. CMDLINES for user setup + regional settings + registry entries. RunOnceEx for applications + cleanup + registry entries. RunOnceEx on second boot for some annoying registry entries + final cleanup.

Hmm... an intriguing way to do things. This is almost like Gentoo's way of updating packages and installation.

Try setting your clock ahead 200 days and see. Personally, I would update to 2180 because it is final and is official supported. 2179 isn't supported. There was 2 or 3 major bugs that were fixed between 2179 and 2180.

One computer running SP2 build 2162 has the process at 220k but isn't using any CPU. Another computer running SP2 build 2180 has the process at 220k but isn't using any CPU anymore either. Was using about 20% CPU when printing via the network.

It must be known because on the original Windows XP CD, there is key that starts with "JJWKH". Edit: Didn't read gamehead's post first. Edit2: Seems to me just to be a simple stuff up. If I'm correct, and it is a retail key, doesn't it mean you'll have to activate it within 30 days? If so, then I don't think Microsoft have much to worry about.

What's more strange is that this product key works but the copyright information at the top of the file: (c) 1994 - 2001 Microsoft Corporation. All rights reserved. 2001? Has this file been updated since then?

I have that key also. I don't remember ever seeing it during the betas though.

@canucherfan: FYI, and to expand on prathapml's post, ModifyPE changes the CRC header on the TCPIP.SYS file and not the TCPIP.SY_ file. Any file that ends with .**_ is the compressed version, you need to expand it before you can modify the PE header (CRC).

@xb00t: You can use the one attached on the CD. No need to edit it. I only put the edits up so that people know what is edited in that file.

Ahwell, I'll just accept that it does something to my connection with Azureus... I may try and find out more later but it seems to fixed by setting it to unlimited. Setting it to 50 gave me another 5kbps overall but opening it up to unlimited and, on average, my download speeds are about 20kbps faster. Doesn't seem to affect many other programs though.

Thanks dirtyepic for the information but now I'm really confused. Ever since I joined the beta test of SP2, Azureus and eMule have decreased significantly in the speed at which they download and the number of connections that actually make. When I apply the registry tweak, nothing really changed, but once I started using this tcpip.sys file as well, speeds and connections have shot straight back up. Now, if, as you say, this connection limiting should have no effect, what else could be causing the low speed and number of connections? I'm not calling you a liar or anything, I'm just curious as to what else could have been causing the problem. The only 2 things I changed about my setup was that registry key and the tcpip.sys file. But the registry key alone doesn't make a difference. Weird...

Microsoft drivers are v61.78 (or something close to that). I think the problem was because nLite didn't remove the drivers properly.

To the people who want to unprotect certain folders, please use the forum search. Here the thread with that information: http://www.msfn.org/board/index.php?showtopic=21334 @netquik: The SFC_OS.DL_ file attached has been modified with modpe (correct header). It is ready to be put on the CD. The SFCSetting registry key is added by me so that you can disable WFP while Windows actually looks at SFCDisable (therefore tricking Windows into thinking it's enabled). In most cases, SFCDisable will turn out to be 0x0000000 while SFCSetting will be 0xffffff9d. That tricks Windows into thinking WFP is enabled but when it comes to removing protected files, it isn't.