Jump to content

Ogopogo

Member
  • Posts

    6
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United States

About Ogopogo

Ogopogo's Achievements

0

Reputation

  1. the following are optional: rundll32.exe nview.dll nViewCmd pon rundll32.exe nview.dll nViewCmd loadprofile dualview all since they only turn on the nView Desktop Manager and load the profile specified (dualview in this case). nwiz.exe /installquiet Is probably required. It normally runs in GUI mode after reboot unless you remove the HKLM\software\microsoft\windows\currentversion\runonce key for it. The /installquiet just makes it silent.
  2. Note: Per nVidia Customer Care, enterprise support is required to obtain deployment information. I managed to figure this out on my own, thus I have not signed their Mutual Non Disclosure Agreement. Should MSFN feel that this should not be posted, then remove it. If not, then heres some information for anyone who wants to find it. Needed before beginning: Unzip app that will extract compressed EXEs (7-Zip for example) Custom nView profile (Created using nView Properties, saved in c:\windows\nview\[profilename].tvp or c:\documents and settings\all users\application data\nView_Profiles\[profilename].tvp) The Forceware drivers are a typical InstallShield setup. Download the Forceware driver and Extract it (personally, I use 7-Zip). Run the following to record the answer file (located in c:\windows\setup.iss) setup.exe -r Replace the setup.iss included with the extracted driver installer with the one you just recorded. The drivers can now be installed (on other systems, since you just got done installing them on the current one) by running the following setup.exe -s -f1 setup.iss After running the install, the nView source files are extracted to C:\Windows\NV########.TMP\. The numbers are random each time. After rebooting, the temp directory will be deleted and the files will be located wherever necessary. This is when I copy my dualview.tvp to c:\windows\nview. Also, you can delete the following registry key: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce, value: nwiz; since we are trying to avoid GUI stuff here... Reboot the system at this time. You can proceed with the next steps without doing so, but in HKCR the items for the nView stuff will point to the temp directory rather than the permanent directory, and nwiz.exe/nview.dll will not be in %PATH%. After logging back in, from command line, execute the following: nwiz.exe /installquiet rundll32.exe nview.dll nViewCmd pon rundll32.exe nview.dll nViewCmd loadprofile dualview all nwiz.exe /installquiet configures some of the nView stuff, /installquiet suppresses all GUI prompts. rundll32.exe nview.dll nViewCmd pon enables the nView Desktop Manager persistently. rundll32.exe nview.dll nViewCmd loadprofile dualview all loads the dualview.tvp from c:\windows\nview, the all switch ensures that the full configuration is loaded. For other calls to the nview.dll, try opening it with Dependency Walker. Some of calls will give you the options if you pass help to it (eg: runndll32.exe nview.dll nViewCmd help) To address the rebooting issue, I created a batch script to run the commands above. I call it using CPAU, to ensure it runs with admin rights. I call the CPAU job using the RunOnce key (HKLM\Software\Microsoft\Windows\CurrentVersion\Runonce). Also, for bundling all of this together, I use NSIS. I have noticed on my test system that I am unable to find/access the nView properties window after following this method. I am not sure what is really causing it, but at this point I'm happy just having a deployable solution. - Ogo
  3. Ryan, Thanks again. I think for now I am just going to run the hotfix exes from the svcpack.inf without doing the /integrate. Loose a little protection that way, but at least it will save me some space on the media for drivers. Maybe one day I will go back and see about extracting the QFE versions of the hotfixes, recompress them, extract the .cat files, and compile all the registry changes into a single .reg file which could be imported during the cmdlines.txt portion. But that would certinatly be for a different day. Speaking of which, what's the difference between the QFE and GDR versions of the hotfix files? The more I look into this stuff, the better and better nLite with Ryan's pack seems to be. Unfortantly, I really want to be able to know exactly how everything is put together and to maintain it on my own. Would be a real problem to rely on Ryan's pack then a week later he gets hit by a bus or something. - Ogo
  4. Alright... I thought I had it handled here, but on one last stumbling block. I am attempting to use the /integrate switch on all Type 1 hotfixes to provide instant protection. However, I noticed that the whole KB#.exe's are still copied to i386\svcpack as well as the KB#.cat file. I am failing to understand why the EXEs are still required after integration. I tried removing all the KB#.exe's from i386\svcpack and removed the necessary entries from svcpack.inf. It worked for the most part, but there are still 4-5 hotfixes which it did not work for. Is there some way to get the hotfixes to integrate cleaner? If I have to still have the execuables in there, then where I would I append the Type2 hotfixes and other apps (eg: WMP11)? Also, for some reason, the /integrate puts all the entries in svcpack.inf in reverse order. Is that correct, or do I have to switch all of them around? I /integrated them in the correct KB#.exe order. Thanks for any help, - Ogo
  5. Doh! Goes to show my noobness... lol! Thanks a lot Ryan
  6. Forgive me if this is discussed elsewhere. I was unable to find anything via search. This is my first time working towards an automated install disc. Unfortantly, I have to use a complete microsoft solution (No nlite, RyanVM, etc). I am having a hard time deciding how to handle hotfixes. I have downloaded all of them off the sticky hotfix post. Installing them via the svcpack.inf file does not work as well as I would like. The drawbacks that I see are extra time, extra file size, and the fact that the system is brought up on the network before the hotfixes are installed. The pros are that all hotfixes are installed at the same time, and qchain can be used to ensure that the proper file versions are retained. I would like to use the /integrate method since it will take less time, will not require the KB.exes to be extracted, and will provide protection to the system during the install process. However, there is always the problem of Type 2 hotfixes which do not support the /integrate switch. Also, by doing so, I cannot rely on qchain. A third possibility is to take the time to extract all the hotfixes and cross reference the Type 1s to the Type 2s to ensure that the proper order is taken. If any Type 1 hotfixes replace files of an earlier Type 2 hotfix, then I would have to add the Type 1 to the svcpack.inf rather than using /integrate on it. I suppose the biggest question is, is it possible that a Type 1 hotfix would replace files that might be altered previously (KB# previously) by a Type 2 hotfix? Also, would any application installs possibly be covered under a Type 1 hotfix? Application examples would be WMP9/10/11, DirectX, IE6, etc. Like I said before, I am having a really hard time deciding how to handle hotfixes in the best possible manner. Any advice would be apprecaited. Thanks, - Ogo
×
×
  • Create New...