Hello!

After I integrated all Updates, integrated WMP11 and IE7 (at T-13) I get a IE6 icon on the desktop that reproduces itself when clicked but does not start the IE.
When I open the startmenu I can find the correct IE7 icon that starts the IE7 without problems. Even additional registry tweaks (Phishing filter, etc) work pretty good with the 1.5.0R3 release.
I also tried to remove the desktop icon and reenabled it but then the same IE6-style icon apears and it does not start IE7. If you doubleclick it a new icon is created on the desktop "copy of Internetexplorer" (translated from German) - just as if you insert an already existing file.

I tested with v1.4.4 v1.4.5 and the 1.5.0R3. The first two cause the phishing-tweaks to fail, the last just has this strange desktop-IE7-icon problem.


Any ideas how to solve it? Has anyone seen this before?

It is not acceptable to just delete the icon from the desktop. I need a proper solution - it's not for my home-use...

where's you HFSLIP.LOG?
anyways, please check your HFs and make sure you didn't include HFs for IE6. I made the mistake of not deleting those IE6 HFs that where in HF folder when IE7 slipstreaming was first introduced to HFSLIP...

As glentium noted, can you post your HFSLIP.LOG file?

I didn't notice any (unknown) problems slipstreaming IE7 into a German XPSP2 source. The IE7 icons in Quick Launch and on the Desktop work as intended. I'll try the SVCPACK method now...

Well... It's all working here with an SVCPACK install (using IE7SVCPACK=1 in HFANSWER.INI).

Screenshot

Attachment: HFSLIP.LOG (not the actual run but one of the non-functional ones).

I removed KB928090 that has been replaced by KB931768 but it makes no difference.


I also tried to integrate the IE7 ONLY (just with the IE7-named files in the HF folder an no other patches) but the effect stays the same.
-----------

Edit: I have that line in the ini (IE7SVCPACK=1 in HFANSWER.INI)...

IE7 works but the desktop-Icon is IE6-style and does not work. The Quick-Start Icon is IE7-Style and works. :-/

HFSLIP.LOG seems fine for the most part. You should also remove WindowsXP-KB896344-v2-x86-ENU.exe (for English and Japanese versions only) and WindowsMedia9-KB917734-x86-DEU.exe (for WMP9, not 11) but that shouldn't have anything to do with your problem.

Can you ZIP HFANSWER.INI and attach it to your next post?

Attached HFANSWER.INI as ZIP.

I'll try to find the German version of KB896344-v2.
----------
EDIT: The German Microsoft website links to the same patch that is only available as englisch or japanese version. It does not seem to be critical but I am not sure if I can drop it. Our WSUS may automatically detect that this patch is missing...
----------

For testing purposes I created two different compilations: WinXP-SP2 without anything added. So I just run HFSLIP to see what will happen with the desktop IE-icon: It works, IE6 of course.
Then I tried to implement everything except IE7 (WMP11 and all patches): It works fine but of course without IE7.

May it be a problem with the german IE7 installation or am I doing anything wrong?


Except this little issue I like your tool very much. It seems to be much better than alternatives (don't want to start a flamewar) because it does not limit the functionality of Windows.

---------------------
EDIT2:
I attached the LOG of the latest run with RC8 (File: HFSLIP_RC8-IE7_WMP11.zip). The Computer is installing right now and I'll report back if it worked. The Changelog for RC8 mentiones something about localized versions and desktop icons...

>> Our WSUS may automatically detect that this patch is missing...

KB896344 is only available for English and Japanese versions of Windows XP. It doesn't apply to other versions.


>> May it be a problem with the german IE7 installation or am I doing anything wrong?

Well... You've seen my screenshot of WinXP SP2 German with IE7 integrated (SVCPACK method). The IE7 desktop icon works and I even removed it and placed it back. So right now I doubt it's a general problem with German versions of XP.


>> The Changelog for RC8 mentiones something about localized versions and desktop icons...

It mentions the "Show Desktop" icon ("Desktop anzeigen" in German), which is something different than the IE7 icon.

I just started having this problem with the U.S. English XP SP2 slipstreamed, and IE7 (at T-13). I have not found the fix for it yet, but I have found that running the IE7 install again afterwords does fix the IE problem. I was not having this problem before I changed 2 things though:

1)Started using an unattended install through microsoft's setupmgr.exe.
2)Started installing the .NET framework 1.1, 2.0, and J# through 0_dotNET11SP120-VJ1120.exe at T-13

Are you doing either of these or anything similiar Charley? I will experiment with this a bit and let you know if changing the way either of these are done fixes it for me.

Hello...

I have removed two patches from the HF folder that had the ending -ENU. All others are for the german version of XP.
The RC8 build failed as well: The IE7 icon is still an IE6 icon that does not work. :-(



OK, but where is the difference? Why is it failing when I do it? I have to get it working as it is on the screenshot that you posted.

Let's try to find the difference...
I use a legal Volume License Key version (aka Corporate Edition). We have a select contract with MS... The folder "source" contains everything from an original WinXP SP2 (German) CD.
Operating system on the PC to run HFSLIP: Windows XP SP2, all patches installed.
HFSLIP was started as local administrator.

Can you please try to integrate IE7 and the IE7 rollup-package only - no other patches?
But, well... all other integrations (WMP11, patches) work. So I doubt that this is the problem. :-/



Should I try one of the other integrations of IE7?
I am afraid of the missing .png transparancy and users who will complain about it...


-------------

@the Brain:
I tried to integrate .NET 2.0 but it does not change anything.
I will not test to install IE7 after integrating it. I have to get it installed without user interaction. Only the T-13 or the direct integration are possible options right now. We have to enroll Windows to ~250 Computers and it is not acceptable to install IE7 by hand at each PC.


Does someone know where the desktop IE icon is handled in the registry? A Registry-Tweak would be an acceptable option...

I just took a closer look at your log file. I don't know if that's the source of the problem, but if you want to slipstream WMP11 you need to include WindowsXP-KB898543-v3-x86-ENU.exe. Not slipstreaming this MSOOBE hotfix will cause MSOOBE to fail to run (and possibly other things) when slipstreaming WMP11. This is explained on the Important things to know page but I forgot to add it to my hotfix list when incorporating WMP11 into it yesterday.

If the source OS is not English, HFSLIP will only slipstream msobmain.dll from it; that's enough to fix the MSOOBE issues.

On a side note... You should remove WindowsXP-KB923689-x86-DEU.exe, and you probably want to have WindowsXP-KB927891-v3-x86-DEU.exe in.

*lol*

After you mentioned the one "English / Japanese only" patch I found the other one and removed it as well. I'll add it again...
I tried so many combinations already that I don't wonder that KB927891 is missing...

Important: I also tried to integrate IE7 only. So just the IE7 installer and the patches that are named IE7*.exe. No WMP11 and no other patches. The result was as bad as usual. I doubt that it has anything to do with WMP11 or any other patch.


Just to be sure that it is no typo: Could you please send me your hfanswer.ini and a list (dir /b HF\*.*) of all patches that you include to get the fully functional slipstreamed version?
Do you use special versions of the programs in the HFTOOLS? Maybe I have one file with an odd version inside :-/

If your source came with SP2 you may want to make sure you remove everything from the SVCPACK folder. Some newer SP2 sources install a non-public IE6 patch.

My source was originally "Gold", manually updated to SP2.

Thanks Tomcat.

On Tuesday I'll retry do it with the new final 1.5.0 and your hfanswer.ini There are some differences.

I will keep you up to date. Thanks so far.

I was not using the MSOOBE patch, because I didn't want OOB to run, but I put the patch in there now. Also, I did find the IE patch in my source's svcpack folder, and removed it (cleared out the whole folder). The source I was using was the latest XP downloadable image from MS Volume Licensing. I'm slipstreaming a new image now, and will try installing on MS Virtual PC once it's done, and let you know if that did the trick.

Unfortunately, even after adding the MSOOBE patch and getting rid of the stuff in the svcpack folder of the source, I'm still having the problem. Attached is my hfslip.log if you can find anything in it that could be causing the problem.Click to view attachment

Was there no problem with the desktop icon after using version 1.4.5?

If so, try this:

1) Run HFSLIP 1.4.5
2) Copy IE7_INST.EXE from SOURCESS\I386\SVCPACK some place else
3) Run HFSLIP 1.5.0
4) Replace IE7_INST.EXE from SOURCESS\I386\SVCPACK with the one you backed up before
5) Install

No, I still had the problem with HFSLIP 1.4.5. The only time I didn't was when I wasn't doing an unattended install. Let me try running it without the unattended install and see what happens, although I'm not too sure what unattended would do differently.

Getting rid of the unattended setup fixed it, so it's something with how windows handles the unattended installation, or something with the options in the winnt.sif file. I did have it in the winnt.sif file to set an IE search path and some preset favorites. I'm going to get rid of those and see if it will run unattended.

People have reported problems with unattended + IE7 before. I don't really know how an unattended install works "on the inside" so right now I doubt I can come up with a workaround.

When the IE7 installer (even the original) is installed at T-13, ActiveSetup bits are forcefully removed from the registry so IE6-related post-installs aren't executed. An unattended install may handle things slightly differently and Microsoft haven't yet taken that into account.

You can actually test if the modifications made to the IE7 installer by HFSLIP are the evil doers by excluding the IE7 hotfixes (and BRANDING.CAB if you're using that). In this scenario, HFSLIP won't touch the original executable; it will just be renamed.


Edit...

Exclude these:
WindowsMedia10-KB917734-x86-ENU.exe (for WMP10; may conflict with WMP11)
WindowsMedia-KB891122-x86-ENU.exe (for WMP9/10; harmless, but a waste of time to have HFSLIP handle it)

Hi!

In my case it's an unattended setup as well... So this may be the cause for the problem.

Would it be helpful if I attach the winnt.sif (without the windows key of course)?

After removing all internet Explorer related stuff from the winnt.sif, the setup completed successfully with the correct IE7 icon, and the icon functions correctly.

I removed:


Although I'm guessing I don't really need to remove the favorites because those are just files. It may even be just one of the other 3 things, but they're not that important to me, so I'm not going to worry about researching those on my own. I will probably retry the favorites again though.

That's an interesting find. It may be that the branding has changed in IE7.

Suggestion: use IEAK7 to create BRANDING.CAB with those custom settings of yours, copy it in the HFCABS folder and let HFSLIP handle it from there.

@CharlyBrown

Are you also using "BrandIEUsingUnattended"?

Hi!

Yes. We set Favorites, Help_Page, Home_Page and some quick links.


I'll try to remove the IE realted stuff as theBrain did.
Is there a good link how to get the same settings using a branding.cab? I never tried that before...

In principle, you don't need IEAK7 for this. You can create your own install.ins file and cab it into BRANDING.CAB.

Expand INSTALL.IN_ from SOURCE\I386 and open in Notepad. This is only to see how it's done. Don't use it as a base.

Expand the main IE7 installation package and open install.ins in Notepad. Make your changes in there, based on how it's done in the one from SOURCE\I386. It's pretty much the same as what you do in WINNT.SIF. Compress your customized install.ins into BRANDING.CAB and place it in HFCABS.

One problem solved - next already waiting...

dotnet2.exe (ryan)... copied it to the HFSVCPACK directory but the setup shows an error message that it can't find the dotnet2.exe file. I checked it: it's present in the sourcess\I386\svcpack folder and of course in the i386\svcpack folder in the installation source.

@ CharlyBrown ... why not use this instead: Silent .NET Maker (latest update: 20070201), Create silent switchless .NET installers for Win2K/XP/2K3 x86?

Are you presented a dialog where you can provide the location of dotnet2.exe? If so, what happens when you point it to I386\SVCPACK on the CD?

If this is a network install, that's probably the source of the problem. In that case, please give me a copy of HFSLIP.CMD in SOURCESS\I386\SVCPACK.

If I remember right it was just a line in the dos-box that said that the dotnet2.exe could not be found. No dialog to enter the path.

Yes, it is a network installation. I tested my HFSLIP-ISO with a CD based install and dotnet installed without problems. Nevertheless it would be better if dotnet would be as functional as the rest during a network install.

Attached file: HFSLIP.cmd (not zipped) (working, without dotnet2)

EDIT:
Attached file: HFSLIP.zip (zipped HFSLIP.CMD) (non-working with dotnet2) BTW: The roots-section does not find the required files as well... but that is less important.

It isn't just dotnet2.exe or the roots update that fails with a network install, but anything in HFSLIP.CMD that refers to files in the Windows source. The path to the I386 folder is determined (among other things) by checking for a drive letter from C to Z, which won't do the trick for a network install.

Executables used to install fine in the past because they were installed from SVCPACK.INF. But this was changed because people wanted the ability to install .NET before any MSI files that require .NET. MSI files must be installed from a batch file so the only (easy) way to accomplish this was to install the executables from the batch file as well.


Replace HFSLIP.CMD in SOURCESS\I386\SVCPACK with the one that's in the attached ZIP file. Then start the network install.

This HFSLIP.CMD file doesn't hide. It gives some output while the path to the I386 folder is determined in the old way, and, if necessary, in a new way. Please let me know what you see.

The plan was to get this done for 1.5.0 but you're the first "network installer" to give me an HFSLIP.CMD file to work on.

Output:


No additional error messages.



Now you have someone that does it.
It's already running pretty good compared to other slipstreaming projects. Great job! I also build a slipstreamed Windows for my home use.

----------------------

EDIT:

As expected by the errormessage from above: Dotnet2 is not installed.
The IE7 customization has failed. The startpage is still the msn site.

That was to be expected. The batch I gave you quits if the HFSLIP variable couldn't be defined.

This is a bummer. I read on a page on the MS server that the PUSHD command was supposed to temporarily map a network folder to a drive letter. Apparantly not (or I don't get it).



EDIT--
Super Magician has something. I'll give an updated batch below.

Have you tried using SUBST? Also, in order to have PUSHD temporarily map a network directory to a drive letter, you need to enable command extensions, which you didn't do.

I can't believe this... I had it in my test file...

Thanks


@CharlyBrown: try the attached file. It will pause to display whether the variable could be defined or not, but will continue after that even if the variable couldn't be defined.

You should have just asked me for one . I remember giving you guys a lot of grief way back when (years is it now?) with network installs (still have yet to do a CD based install using HFSLIP) but since CD based support only, I worked around my issues by setting "Multiboot cd path" to "source\" and having I386 and other directories copied local before running XP setup (in my "unattended install" installation script):

then my hslip.cmd starts off like:
It does add time to the install process making the local copy, but it works GREAT. Local I386 in case it's ever needed, no need to search for a CD.

Also note, I boot the targeted workstation from a boot CD into a winpe environment (instead of DOS based network install[MUCH better]) where I select what type of machine (manufacturer) I'm building, input of computer name, laptop/desktop and Domain machine will be a member of. Click on OK and there goes unattened install of XP/Tablet PC/Win2k3.....

Thanks... I'll try it tomorrow.


Little bit off topic: Right now my system @home is making some trouble. During the install (HFSLIP from a CD) it has some problems with "ASMS". If I can't find the reason for this strange error message (didn't write it down... sorry) I'll open a new thread for it.
-------------------------------------------

Edit3: *grumble²* ... The IE-Problem IS solved... Forget my first two edits...

-------------------------------------------

Edit 4:
That's the message.
BTW: There is no subst in the CMD.

OK, but did either .NET 2.0 *or* the roots update install?

Is it needed? The PUSHD command is supposed to assign a drive letter to a network share; I'm then using DIR /B to determine the path and store it in the %HFSLIP% variable. I wish I could test this better myself but I haven't been able to find out yet how I can browse the network through a command prompt like with My Network Places.

Hmmmm... Sorry but I did not check if the roots or .net installed. *doh*

You can show mapped drives with "net use". I know that it's not very nice but once I handled such output by writing it into a .txt-file and then filtering it with "sed".

OK. Please stop testing for now. I rewrote all sections that handle HFSLIP.CMD and SVCPACK.INF, and am now testing if everything still works as intended on a regular CD-based install. I'll post a new test release later.

For network-based installs...
* silent executables will work for sure
* msi files, the roots update, AutoIT scripts, reg files and inf files is still a question mark (that's for you to tell me )
* installation of Recovery Console won't work

Alright. The new test release is in the wild. Please try it and let me know how it goes...

No error messages but dotnet2 is not integrated.

The file dotnet2.exe is located in: HFSLIP\HFSVCPACK.
Is this still correct or should it be placed in HFSLIP\HF?


Less important: The branding.cab does not work. It seems to be ignored.
EDIT: The branding.cab inside the IE7 installer seems to be damaged! I tried to extract it with 7zip but got an error message. The Branding.cab that I added into the HFCABS folder is OK. Can you check that?
EDIT2: The file is just empty. That's why I get an error message when I select "extract files".

It is not in SOURCESS\I386\SVCPACK?

HFSLIP doesn't copy BRANDING.CAB but its content. If it's not too big, can you attach it here?

It does not seem to copy any content OR it fails.


Attached branding.cab. That's the one that has failed every time.

Today I created a new one that I don't have right now and that I did not test yet. The new one is on the test-system in our company and it is a little bit different. I tried to keep it simple.
IEAK creates a setup.exe to force the branding on an already existing installation. I tried it on a test system and it worked pretty good that way.
----------------

dotnet2.exe: I'll tell someone to check it or we would have to wait until Friday..

You are talking about the "IE7 installer" so I guess you didn't slipstream it this time. INSTALL.INS from BRANDING.CAB should be inside IE7_INST.EXE in that case. Can you verify that it is?

BTW... Was this file created with IEAK7? I'm having a hard time believing that because of this:



dotnet2.exe
If placed in HFSVCPACK, it should've been copied into SOURCESS\I386\SVCPACK just like before. The only difference is that the current test release initiates the install from SVCPACK.INF (just like in the old days) instead of from HFSLIP.CMD.

You know... I'm beginning to think that there are files that fail to copy on your computer. The first ASMS.CAB file you gave demonstrates a problem that's really puzzling me. But I can only say that for sure once you follow up on my last post in the other thread.

I always try to integrate it at T-13 because of the png-issue.


YES, it is! I was wondering about this version number as well because I expected to find something like 7.*


I just received the mail: dotnet2.exe is present in the right folder.


Chkdsk /r is running.

Please don't mix things up! THIS thread is about the problems that I am facing in our company. It is independend from the other thread that is about the problems that I have at home. Nevertheless I doubt that my harddrive at home is defective. It is working pretty good without any issues until today. It's a 10k SCSI harddrive.

You do realize that HFSLIP is for PERSONAL use. Do you plan on giving your paycheck to the developers for doing your work?

I made an offer to get a chance for at least a one-time-payment but Tomcat76 refused it.

Our company can not make any "donations". We would need some kind of service quote for "adjustments for enterprise use". If it would be accepted it might be payed. I can't guarantee it.

BTW: During the last weeks I am doing lots of testing for your project. As Tomcat said you don't have anyone else who tried to install from a network source.

Double-Posting, but worth it:

Our network share has a hyphen in its name that cannot be removed. It's caused by the software to install systems with PXE over the network...

Might this be the Problem?