Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


xpman

Member
  • Content Count

    53
  • Donations

    $0.00 
  • Joined

  • Last visited

Everything posted by xpman

  1. Yes I am sure. The RunOnceEx entries are created from cmdlines.txt. And as I found out, everything works perfectly after all. I merely wanted to point out a (womewhat strange) additional feature in connection with RunOnceEx. Actually, you can regard this behavior as completely separate from the unattended installation process. The latter only automatizes the creation of the registry entries. The behavior I described has only to do with the RunOnceEx service. Why are you asking?
  2. I was just about to post the following when I realized my mistake. I had used HKCU instead of HKLM (although I am sure I specifically double checked this). EDIT: I forgot to change the topic to something like 'HowTo execute RunOnceEx in HKCU', but I only see how to edit the content of my posting. I still decided to post this, because I find it very interesting to know, that the DLL function, when being called manually, also executes a RunOnceEx within HKCU. So for people wanting to use the visual apperance of the RunOnceEx installation window and at the same time customize it for a specific user, this might be of interest. After all, RunOnce doesn't create any window, but it could be used to trigger the execution of a HKCU RunOnceEx. If you do not consider this helpful/interesting or it is well known and I just didn't find it, please delete the thread.
  3. 1. Except for at least one of the entries in winnt.sif showing effect, I know of no way to determine whether it is actually used. If, like in this case, it seems that none of the settings has any affect, I'd suggest putting winnt.sif on a floppy disk, which seems to override any winnt.sif on the CD. That also saves you the trouble of having to burn your CD over and over again just to incorporate some changes in one text file. On the CD, the correct location depends on your booting method. For "regular" CDs, it goes into the I386 folder, for multi-boot CDs it must be located within the directory containing the extracted boot floppy disks. 2.) I have my winnt.sif set up to let me select the partition and the file system, but maybe the following information helps: The following switch prevents windows from deleting all partitions on the first hard disk and creaing one big NTFS partition. So it's a good idea to add it to winnt.sif in any case: [unattended] Repartition="no" The only real problem could be that for the automatic partition selection to work, the partition must be both large enough for windows and may not contain a previous version of windows. So if you are repeatedly testing on a system without manuall formatting the first partition on the hard disk, this may be the reason why it fails. I also don't know whether the content of the $OEM$ folder is added to the size of windows by setup, but if it is, the partition can become too small very quickly. In any case, OemSkipEula should always work. The fact that it doesn't strongly indivates that winnt.sif is really not used during setup and the floppy disk method is a good place to start - and, as said above, save CD burning time.
×
×
  • Create New...