kenlau

I just ran final RC9 with IE7 and KB947864. Both are slipstreamed correctly without any problems. MU does not report KB947864. As for LegitCheckControl, make sure you download the very latest. I have MU reporting that as well until I re-download the latest iteration of KB905474.

Everything work perfectly. The only odd thing was when WMP11 was run for the first time, it ask to validate Windows. Previous pre-SP3 WMP11 did not ask for validation. Now if TC can sort out the MCE mess, HFSlip would be perfect.

Thanks TC, I would have thought M$ will update Update Agent with SP3, but I guess not. M$ giveth, M$ taketh away. Anyway, I am retrying again, and will post if anything strange turn up.

Just completed my VMWare test installation of Windows SP3. I use RC7 to slipstream SP3, and then rest of the updates. Attached the log file. Just to report back, Windows install perfectly, and no high priority updates after running Microsoft Update. However, when initially running Microsoft Update, it requested to install the activeX components, and then restart the PC before I continue running MU. It looks like the MUAuth.cab did not take, either because the slipstreaming process failed or Microsoft has a new version. I am not sure which, but MU does appear on my start-up menu, so I suspect it is the later. The 2nd weird thing is that if I leave out KB905474 during slipstreaming, windows will download KB892130 and try to install it before allowing me to continue with MU. It keeps failing to install KB892130, which is why I go re-do HFSlip with KB905474, since I cannot find KB892130 for download. Finally, when I start WMP11, it will ask to run WGA as part of the first initialization. This did not happen on my previous pre-sp3 HFSlip slipstreams. None of the above are big problems, but I hope it helps in getting the next version of HFSlip ready. Thanks. HFSLIP.7z

Here goes nothing. Basically, when OEMScan runs, it will copy the matching oembios files to the system32 folder according to the matching slp in the bios. However, when this is done of XP x64, Windows quietly redirects the oembios files to x64-equivalent folder which is syswow64. When this happens, the pre-activation does not occur. The next alternative is for the oemscan.ini file to call a cmd file to copy the files again to the system32 folder, i.e., copy oembios.bin %systemroot\system32 /y Bugger it all, would you know it, Windows still redirects the files to the syswow64 folder. However, if you copy the files using Windows Explorer, it will work. So will copying the files from an user opened command windows, which was a red herring, as it lead me to believe it was an user permission problem. That was a wasted 2 days I am never going to get back. The neurons in my brain finally fired, and I remember AutoIT have a function that disable the redirection to the syswow64 folder. Below is the AutoIT script that is called from oemscan.ini. DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1) If FileExists ( @ScriptDir & "\oembios.bin" ) Then FileCopy ( @ScriptDir & "\oembios.bin" , @WindowsDir & "\system32\Oembios.bin" , 1 ) FileCopy ( @ScriptDir & "\oembios.dat" , @WindowsDir & "\system32\Oembios.dat" , 1 ) FileCopy ( @ScriptDir & "\oembios.sig" , @WindowsDir & "\system32\Oembios.sig" , 1 ) FileCopy ( @ScriptDir & "\oembios.bin" , @WindowsDir & "\system32\dllcache\Oembios.bin" , 1 ) FileCopy ( @ScriptDir & "\oembios.dat" , @WindowsDir & "\system32\dllcache\Oembios.dat" , 1 ) FileCopy ( @ScriptDir & "\oembios.sig" , @WindowsDir & "\system32\dllcache\Oembios.sig" , 1 ) FileCopy ( @ScriptDir & "\OEMINFO.INI" , @WindowsDir & "\system32\OEMINFO.INI" , 1 ) FileCopy ( @ScriptDir & "\OEMLOGO.BMP" , @WindowsDir & "\system32\OEMLOGO.BMP" , 1 ) FileDelete ( @WindowsDir & "\syswow64\oembios.bin" ) FileDelete ( @WindowsDir & "\syswow64\oembios.dat" ) FileDelete ( @WindowsDir & "\syswow64\oembios.sig" ) FileSetAttrib ( @WindowsDir & "\system32\Oembios.bin", "+S+R", 1) FileSetAttrib ( @WindowsDir & "\system32\Oembios.dat", "+S+R", 1) FileSetAttrib ( @WindowsDir & "\system32\Oembios.sig", "+S+R", 1) EndIf End of story. Now everything works.

Hi ZaForD, In my opinion, x64 offers much better speed and stability than x86, plus the simple fact that I plan to skip Vista entirely. I just cannot see myself using Vista. As far as OS for new machines are concerned, XP x64 is one of the better kept secrets. I already looked through Signet Software, Basically I scoured both MSFN and Signet for clues to why my oemscan do not work. I know someone in Signet reported that they got x64 to activate, but leave no details on how it was done. In any case, I got it working by calling an AutoIt exe file from oemscan.ini that copy the proper oembios files across, bypassing the x64 redirection. It is just an extra step, and not a big deal really. If the author is going to come up with a new revision, I just hope he keep in mind this bug. Thanks

I don't know if this thread is still active. Anyway, I been trying to use oemscan on Windows XP x64. Oemscan runs, detect the right set of oembios files to copy but fail to copy. I use the cmd line to invoke a cmd file called oemcopy.cmd that basically re-try to copy the oembios files to the system32 directory, but that also fails. I did manage to copy the oembios files to both syswow64 and dllcache directories, but that does not activate windows. Oemscan however, have no problems importing the oembios.cat file. If I copy the oembios files manually using windows explorer to the system32 folder, windows will activate. I am already logged on as administrator, and tried to run oemscan as a detachedprogram and from runonceex. It runs and imports the.cat file everytime but not the others. I even removed the oembios files (sig, dat and bin) from the installation Cd and removed all mentions from the txtsetup.sif and dosnet.inf files. Am I missing something obvious here? Any help will be much appreciated. UPDATE I think I found the reason why oemscan is not copying the files to system32 folder. Basically, the x64 windows is redirecting all files to the system32 folder to the syswow64 -x64 equivalent folder instead. That will not activate windows. Strangely enough, all attempts to copy to the %systemroot%/system32 using cmd will also end up in the syswow64 folder. I think I solve the problem by adding an AutoIT executable that will run from the cmd line in the oemscan.ini file to copy the files to the right folder instead. I think there should be a version 1.4.2 to solve this error for us hapless x64 users, me in particular.

Sorry but I have no idea that this thread was still active, which is why I did not check it for quite some time. DryKillLogic, Strictly speaking, there is no way you can activate it silently, but you could try activating it first, then exporting the license somewhere, and then reusing the license when you install silently. I have not try this myself. wirawan1988, I think you are confusing the serial number and activation. The serial number only allow you to install, and you still need to activate it once installation is completed. shauntr, I cannot help with this as it looks like the serial number is invalid for some reason. You could check with Adobe on this issue. contdeforum, 512MB RAM is a minimum requirement for Adobe Photoshop. I have no idea how to circumvent this requirement. Given the low price of RAM, I suggest a RAM upgrade.

Looks like I am not the only one with this problem. I have a Dell M1210 XPS notebook using Sigmatel. The drivers are integrated and the sound works. I also have another desktop PC with Realtek HD audio, again the drivers are integrated with nLite and there is audio. In both cases, I am left with a yellow exclamation mark in my Sound devices. Upon closer examination, in both cases it seems to be Microsoft Kernel Echo Acoustic Canceller. If I reinstall the driver, it will find the driver for Microsoft Kernel Echo Acoustic Canceller but then the install will failed with the remark 'The device is invalid" or something to that effect. I search high and low and tried different Microsoft patches but none work. I did not suspect that it is nLite. If Nuhi can fix this, it will be great. This symptom seems to be appear in the last few versions of nLite. I am now using 1.3.5.

mty, I see you are using deployment.xml file for your silent install. Is this the one that come with the CD, or one that you created yourself using "setup.exe --record=1"? Basically, I think your are using the wrong deployment file, as your installation actually proceeded without any errors, since you have exit code=0. To be frank, I am not too sure what is the your error since you do not mention it specifically. Is it ..r"estarted cyclically and infinitively without intervention"? ------------------------------------------------------------ jander44, You can use variables. For example, I use AutoIt script "RunWait ( @ScriptDir & "\setup.exe --mode=silent --deploymentFile=" & @ScriptDir & "\install.xml" )" where @Scriptdir is the variable that translate to "D:\Software\Photoshop\". What you cannot do is use relative path. For example, "setup.exe --mode=silent --deploymentFile=\XML\install.xml" where XML is a subdirectory from where the setup.exe is located. The same apply even if your install.xml is located in the same directory as your setup.exe file, i.e., "setup.exe --mode=silent --deploymentFile=install.xml" will NOT WORK. I am installing from DVD, and using AutoIT. I did try using WIHU but getting the script right was difficult since the %SRCDRIVE% variable have to be inserted, i.e., setup.exe --mode=silent --deploymentFile=%SRCDRIVE%\Photoshop\install.xml. This obviously DID NOT work. I have a feeling running runonceex will have the same problem, as I can never figure out where all the quotes go to make it run properly so I simple resorted to AutoIT. ------------------------------------------------------------ iceangel89, install.xml is CREATED when you run setup.exe using the followinng parameter, "setup.exe --record=1" without the quotes. This will not actually install anything on your hard disk, but create a record of intended installation in C:\Program Files\Common Files\Adobe\Installations folder. Copy the two xml file located in C:\Program Files\Common Files\Adobe\Installations to the same directory as your setup.exe and rename one install.xml and the second one uninstall.xml. You should not amend either setup.xml or deployment.xml. As long as your code can translate into absolute paths, you should be able to install silently, even if your drive letter changes. See my example above using AutoIT script.

Instructions here http://www.msfn.org/board/index.php?showtopic=101954

I found countless useful tips here on how to silently install my apps, so I thought I finally give something in return. This is based on Adobe instructions which are do not actually work, and information gleaned from other forums. Here is how to silently install Adobe CS3 Applications, i.e., Photoshop, Illustrator, InDesign, Flash and Dreamwever. It is tested on these apps, but should work for all CS3 apps since they all follow the same method of installation. 1. The directory structure and name of the original CD or DVD is important. If you copy the installation files into a different folder name, then you MUST amend the setup.xml file that reside in the payloads folder. Open setup.xml using notepad, and inside between <Payloads> and </Payload> limiters, you find entries like <Payload folder="AdobeALMAnchorServiceAll">Adobe CS3</Payload> Here, Adobe CS3 is the folder name where setup.exe resides. Change Adobe CS3 to whatever is your current folder name. Not doing this will give you error code 4, since setup will not be able to find the installation files. 2. Next, in the payloads folders, select the main application folder. If it is Photoshop, it should be AdobePhotoshop10en_US_volume. If it is Dreamweaver, it will be AdobeDreamweaver9en_US. Inside, select file that end with ....proxy.xml. If is is Photoshop, it should be AdobePhotoshop10en_US_volume.proxy.xml. Edit this file with notepad. Use the find function to find <Requires> entry in the xml file, and delete all the entries between <Requires> and </Requires>, including <Requires> and </Requires> limiters. Doing this will show the options to allow you to select which components you want to install. 3. Now, from the setup root folder where setup.exe resides, from command prompt type: setup.exe --record=1 4. This will perform a record of the installation without actually installing the apps. From here, you can also select which of the options you want installed. Some options are critical, so if the apps do not run after installation, you have to come back to this step and re-enable the option. 5. After the recording of the installation is completed, go to the Program Files/Common Files/Adobe/Installations folder. Inside will reside 2 xml files, one for installation and another for removal. Rename them install.xml and uninstall.xml respectively. Copy them to your setup folder. 6. Now, create application.xml.override file inside the application payload folder. The entry should be <?xml version="1.0" encoding="utf-8"?> <Configuration> <Payload> <Data key="Serial" protected="0">1XXXXXXXXXXXXXXXXXXXXXX</Data> <Data key="Registration">Suppress</Data> <Data key="EULA">Suppress</Data> <Data key="Updates">Suppress</Data> </Payload> </Configuration> 7. Finally, you can now silently install the apps with the command setup.exe --mode=silent --deploymentFile=D:\Photoshop\install.xml. 8. Note that you must have the absolute directory path for the install.xml. It will give error code 4 or 5 is you do not. 9. If you still encounter errors, you should first have a look at the installation log that resides in Program Files/Common Files/Adobe/Installations folder. Search for "ERROR" and it will usually give an indication of the error that has occurred.

Yeap.. The problem is running HFSlip on x64 system, and not due to corrupted hotfixes. Note in my original posting, I re-download all hotfixes and extract them just to be sure that they are not corrupted. I just use HFSlip again on a x32 system, and it all goes OK. Funny thing is that previously, I used x64 before and it always work without any problems. I think it is only when HFSlip tries to repack IE7 that is utilizes some system file which created this error. Another clue is that I can actually view and install the created IE7_Inst. exe file on my x64 system, but not on my x32. All the clues was staring at me in the face, but it really took me a while to see the logic. I hope this help anybody that come across the same problem.

The SOURCESS folder is the one that contains the slipstreamed Windows. However, it will seems to me that your slipstreaming process is incomplete or have some errors, since HFSlip usually cleaned up after it processes all the hotfixes and you should not see s Work folder after slipstreaming completes.

I am using HFSlip 1.4.2 and being trying unsuccessfully to integrate IE 7 for the past couple of weeks. It is a strange problem. I ran HFSlip successfully, with no errors. When I use the ISO to install Windows XP, IE 7 is not installed. Browsing to the Svcpack folder, I can find the IE7_Inst.exe file, but the file has no icon. Running the file give me an error message "This is not a valid win32 application." Originally, I thought maybe my hotfixes was corrupted, so I re-download all the hotfixes again. Still no go. Then I use a new copy of Windows XP. That did not work either. Then I get use another copy of Windows XP, OEM for my Acer notebook. When that also did not work, then plainly I exhausted all alternatives. Bear in mind it all used to work but all the sudden, it does not. Attached is my hfslip.log file. Sure appreciate any help I can get on this one. ------------------------------------------------------- I tried using RyanVM update pack and integrator to create a copy of slipstreamed Windows. Then I put the IE7_Inst.exe created by HFSlip into the svcpack directory and what do you know, I still get the same error! I think I finally figure out what went wrong. I think HFSlip must be taking something from the running OS when creating IE7_Inst.exe, and since I am running HFSlip from Windows XP x64, the resultant IE7_Inst.exe will not run on a Win 32 system. Let me check if my theory is correct. HFSLIP.txt

I went back to using nLite 1.3 RC2 which always work well for me, and what do you know, the problem went away. In anycase, RC2 will integrate WMP 11 (not slipstream) but the final release depends on Booogy's slipstreamer which, the last time I check, does not work on x64 anyway. Therefore, you have to manually integrate WMP11 in the svcpack folder instead. So it looks x64 users are better off using RC2 than the final release.

Nope. The latest IE7 give axactly the same thing. I went to MS site and download the version that was stated in previous post, nlite that and install the OS. Exactly the same thing. Anyone else have other ideas?

First, I did a clean nLite, with just slipstreaming SP2 and drivers. No options or tweaks whatsoever, and this problem still occur, so it does look like a nLite bug. Ikky, Now, let me see if I can this straight. If I slipstream SP2 and the latest IE7 release 14th March with nLite, this problem will go away? I will try it and report back.

I figure out how nLite integrate WMP11 from the svcpack.inf, so I just replicate that after nLiting Windows XP x64. Just guess I have to wait for Booogy to update his slipstreamer.

I seem to have the same problem. Whether I am in nLite or another program, say VMWare Workstation, when I select the "browse" button, the explorer interface window does not appear. I can still type in the drive and folder, and it will work, but the convenience of the explorer window disappeared. This bug seems to be a recent thing, since I notice it with the latest nLite 1.3.0.4 but not on nLite 1.3 RC2. Moreover, it seems isolated only to Windows XP x64 systems only. I also slipstreamed SP2 so I am not too sure if SP2 has anything to do with this issue, or it is due to nLite. Can anybody else replicate this bug?

Add me to the list of those who wants to slipstream to Windows x64. Thanks.

I being using nLite RC2 to integrate WMP 11 into my Windows XP x64 edition. The official release however utilize WMP11 Slipstreamer from Boooggy to slipstream WMP11 which limits only to x32 Windows. This basically is a step backward for x64 users since we can no longer utilize nLite to integrate WMP 11. The leave me the option to use the offcial release to update my installation, the use RC2 to integrate WMP 11. I am not even sure that will work yet, but I will try it tomorrow morning. Can we request in the next release of nLite to choose either to use the original RC2 WMP 11 integration for those of us that uses x64, and WMP11 Slipstreamer for those using x32 Windows? It is not a perfect solution but at least it does not leave us x64 users out in the cold.

I guess 70203b os not 100% ready yet, because the download link is not working. I got hfslip-70202b to work now.. , although I install with the network disable.

Tomcat - Check and double-check. I do have iexpress.exe in my system32 directory. Has anybody successfully ran the test release to install IE7?

I did not specify the i386 folder in HFSlip because I run winnt32.exe /noreboot and then edit the txtsetup.sif file to point that to the i386 folder. To cut a long story short, I first run Hfslip, then Bashrat's drivers, and the create the multiboot dvd as per MSFN's guide. So far, it work beautifully, and usually Hfslip work without any problems. As a matter of fact, 1.2.2 work using this method without any problems whatsoever, but not the latest test releases. I ran the exact same hotfixes, updates and cab files in 1.2.2 and the test releases. I notice another odd thing. I place UPHClean-Setup.msi in the HF directory as per your guide, but once I ran Hfslip, I notice that it move this file to HFSVCPACK_SW directory. I always edit txtsetup.sif so it will point to the i386 directory. I just notice that I need to edit the hfslip.cmd file in the svcpack directory as well. I will do that and retest, but the odd thing is that I did not do that for 1.2.2 and the installation still went smoothly.