Jump to content

ponghy

Member
 View Profile  See their activity

  • Posts

    175

  • Joined

  • Last visited

  • Donations

    0.00 USD 

  • Country

    Spain

 Content Type 

Posts posted by ponghy

    Problem with driver directory (integration)

    in Unattended Windows 2000/XP/2003

    Posted

    First, thanks very much for your answer.

    However, I've read your thread, but I don't find the solution to my problem. My problem is I've the driver files in separate directories, not in I386 like you, and Setup don't find the driver files when needed (in text-setup mode). You said You have to change the source path in DOSNET.INF and TXTSETUP.SIF. And I asked you How?. I've tried several methods, including the [OptionalSrcDirs] section, but no go...

    Any clue?

    0

    Problem with driver directory (integration)

    in Unattended Windows 2000/XP/2003

    Posted · Edited by ponghy

    Hi:

    I don't know how to use a specific directory for my integrated drivers rather than the I386 standard from the installation source.

    I've integrated the vmscsi disk driver as a test by adding the following lines:

    Step 1: Editing DOSNET.INF

    [Files]
    d1,vmscsi.sys

    Step 2: Editing TXTSETUP.SIF

    [SourceDisksFiles]
    vmscsi.sys = 1,,,,,,3_,4,1

    [HardwareIdsDatabase]
    PCI\VEN_104B&DEV_1040 = "vmscsi"

    [SCSI.Load]
    vmscsi = vmscsi.sys, 4

    [SCSI]
    vmscsi = "VMware SCSI Controller"

    File drivers are directly copied into the I386 directory:

    vmscsi.sys

    vmscsi.inf

    vmscsi.cat

    Everything is fine, but if I want to change the source folder to an another one, i.e., I386\drivers\vmscsi, by editing DOSNET.INF:

    [Directories]
    d5 = \I386\drivers\vmscsi

    [Files]
    d5,vmscsi.sys

    Then Setup don't find the driver. Also, I tried to add all driver files to DOSNET.INF:

    [Directories]
    d5 = \I386\drivers\vmscsi

    [Files]
    d5,vmscsi.sys
    d5,vmscsi.inf
    d5,vmscsi.cat

    But NO go :( Is it possible to put the drivers in another subdirectory that is NOT \I386 (on the source CD)?? For example, on I386\drivers\vmscsi.

    Thanks :)

    PS: Note I'm NOT using the WINNT.SIF answer file, and I don't want to use it (I know this is possible with the OemPnpDriversPath directive, but I don't want an answer file in order to respect the original Setup behavior).

    0

    Help with my cleanup.cmd

    in Unattended Windows 2000/XP/2003

    Posted · Edited by ponghy

    Ok, you're right. I see the patch is for .NET Framework 2.0, the "infamous" KB928365, the hardest patch to integrate in the .NET 2.0 installation, believe me (see my last posts in the Silent .NET Maker of Tomcat76 if and you'll understand).

    Since .NET 2.0 installation is driven by Windows Installer, you could try Windows Installer directives passed as arguments (a.k.a "public properties").

    Try the following directive:

    REBOOT=S

    And this one:

    REBOOT=R (more agressive, suppress all kinds of reboots).

    0

    Create IE 7 and WMP11 installation packages with their patches

    in Unattended Windows 2000/XP/2003

    Posted · Edited by ponghy

    Hi :hello:

    I would like to create installation packages for the following Windows components:

    - Internet Explorer 7

    - Windows Media Player 11

    The problem is to add the necessary patches to both packages in order to keep up to date. That is, to slipstream the patches in the installation packages, not in the Windows installation source. When the user installs the package, this package must install the patches too. I know how to do this with a script (install every patch, one by one after installing the component), but my idea is to integrate the patches in the original installation packages.

    Is this possible?

    Thanks very much in advance.

    0

    Silent .NET Maker (latest update: 20080603)

    in Application Installs

    Posted · Edited by ponghy

    AgiHammerklau: I have SFC enabled, but this is not meant for .NET Framework 2. The repair process restores the original files of .NET 2 with or without SFC enabled. And this works in that way because the database contained in the CSetupMM subdirectory (the source cache feature) is the original database of .NET 2.0, not the patched one by KB928365. Setup extracts files from this MSI (database) file when repairing.

    Currently I'm working on modifying the PackageCode of the product stored on the Registry to match with the stored in the patched version of the MSI file. If both Package Codes don't match, a severe error will occur when uninstalling or repairing.

    0

    Silent .NET Maker (latest update: 20080603)

    in Application Installs

    Posted · Edited by ponghy

    I bump this topic because after several days of researching and tests I've figured out that repair ability for .NET 2.0 is not working well in your .NET Maker ONLY if you slipstream the KB928365 patch, and I think it's virtually impossible to workaround this in any way.

    Do the test yourself:

    Try to delete the following file:

    %WinDir%\Microsoft.NET\Framework\v2.0.50727\AppLaunch.exe . This file is marked with the following version string:

    2.0.50727.832

    Now, go to Control Panel > Add or Remove Programs and click the "Modify/Repair" button for the "Microsoft .NET 2.0 Framework" entry. The setup program appears. Select the "Repair" option and click Next. Repair process will take place. When repairing is complete, go to the previous directory:

    %WinDir%\Microsoft.NET\Framework\v2.0.50727\ , and show the properties for file AppLaunch.exe. You will see that the string version is the following:

    2.0.50727.42

    That is, the original version shipped with .NET Framework 2.0 (not the patched one included in KB928365). The repair process restores the original version of .NET Framework files, not the patched version (with KB928365 applied).

    The reason is simple: The hack you said me modifying the PackageCode value in the Registry is necessary in order to Setup can work with the original database of .NET Framework 2, since performing and administrative install of the product modifies the PackageCode in the administrative image. Due to this, Setup always use the original database to repair missing or damaged files.

    Now, I see why RyanVM removes the repair ability (source cache feature) of .NET Framework 2, not only for freeing space.

    I hope this post will be useful for you.

    Regards.

    0

    Embedding SATA Drivers into a customized xp install disc

    in Unattended Windows 2000/XP/2003

    Posted · Edited by ponghy

    @illegalbrain:

    Are you sure nLite does not create/modify the WINNT.SIF file on the I386 folder of the installation source in order to do that? I know the "classical method" is to modify the TXTSETUP.SIF file and may be DOSNET.INF file too, and then create/modify the WINNT.SIF file. The WINNT.SIF file must have the "OemPnpDriversPath" directive so that Windows loads the drivers at text mode setup.

    I need, for particular reasons (do an attended install), integrate some SATA drivers without creating the WINNT.SIF file. Is this possible?

    0

    How to integrate KB928365 into .NET 2.0

    in Unattended Windows 2000/XP/2003

    Posted · Edited by ponghy

    @Tomcat76:

    Again, thanks for your interest. As I said before, this issue is not easy to workaround, and I think has no solution...

    The method I said above it worked perfectly to integrate KB9172383 and KB922770, including the repair capability (believe me, and to achieve that it is necessary to perform steps 3 and 4 in that order). That is, initially I could install .NET 2.0 with the entire source cache feature, containing the updated netfx.msi on the CSetupMM subdirectory (the package took more space in the compressed form, about 40M, because it included the Netfx.msi file with 24M in size on the CSetupMM subdirectory). Therefore, uninstallation and repairing from Add or Remove Programs it worked seamlessly. Windows Update did not show the udpates after repairing, the process was consistent. But all these things don't work with KB928365....

    Finally, I suspect that KB928365 has something broken when doing and administrative install or when applying to an administrative image. Only Microsoft knows this.

    Check out the repair feature in your Silent .NET Maker, because you should remove it. If not, when an user clicks the "Modify and repair" button on ARP and then selects "Repair" from the install wizard, the program may crash if you have not updated the netfx.msi file on the CSetupMM subdirectory. If you don't include the CSetupMM subdirectory (I think you've choosen this way, as RyanVM did), make sure you substitute the default uninstaller (install.exe) with the MsiExec.exe command and the /X and [ProductCode] arguments, in an entry in the Registry table of the Netfx.msi file like this:

    [systemFolder]Msiexec.exe /X [ProductCode]

    This command removes .NET Framework 2.0 from the system. You must include the NoModify and NoRepair DWORD values in the Registry table (target key in the Windows Registry is HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[ProductName]) also, if not included yet. If you don't include these values, Windows will show in ARP the "Modify or Remove" button instead of "Remove" and if you pick support information, you will see the "Repair" button in the dialog too. Of course, this button will not work as expected.

    Hope this helps for your .NET maker.

    Regards.

    0
×
×
  • Create New...