[THIN] Re: specialized streaming apps setup question
- From: "Rick Mack" <ulrich.mack@xxxxxxxxx>
- To: thin@xxxxxxxxxxxxx
- Date: Thu, 4 Oct 2007 11:15:50 +1000
Hi,
Managing reboots after an application install really isn't much of an issue.
You're faced with several possible scenarios.
The first is post reboot application DLL registration, etc which is almost
always by populating the
HKLM\Software\Microsoft\Windows\CurrentVersion\Runonce key.
If you get the runonce key values and manually execute the commands, you'll
be completing the installation procedure. So it doesn't really need a reboot
to complete things from an installtion recording viewpoint.
You can have a scenario where some in-use files are flagged to be replaced
post-reboot. These are listed under
HKLM\System\CurrentControlSet\Control\Session Manager\FileRenameOperations.
If the install is for an application, this will only arise for replacement
system DLLS under the system32 folder and can generally (famous last words)
be safely ignored.
If the application "insists" on a reboot at the end of the install process,
you cab overcome this by creating an admin user that has no reboot rights,
so when the install process tries to force a reboot, nothing happens. Take
care of the eunonce and file rename oprtayions and you have a complete
package/profile.
regards,
Rick
--
Ulrich Mack
www.commander.com
On 10/4/07, TSguy92 Lan <tsguy92@xxxxxxxxx> wrote:
>
> I've been struggling to get some of our more specialized application
> installs functioning under the streaming app profiler and after trying
> several tricks I'm close to giving up hope on streaming them :( so I figured
> I'd see if anyone else may have some insight.
>
> In particular the problems I'm having with the profiling of 2 of our apps
> are:
>
> - one of our vendor installs requires a reboot after which it registers a
> slew of Dll's.
> - the virtual reboot option is nice, but the dll registrations from
> the setup application after the virtual reboot fail.
> - I'd tried a variety of tricks I can think of to register the failed
> DLLS within the app profile, but all attempts to call out regsvr32 appear to
> be local machine call outs only, and don't work within the virtual app
> profile space.
> - other dos commands such as xcopy, and MD, from CMD scripts DO
> affect the virtual app profile space, and will dutifully adjust files and
> folders there, as opposed to the local profiler machine host.
> - If I make a directory on my machine used for profiling and put all
> the DLLS there, then regsvr32 works, but of course, it doesn't affect the
> app profile. :(
> - I'm currently recording all registry adjustments made by doing a
> Regsvr32 "dllname" on another system with regmon, but manually creating all
> of these adjustments to the app profile will be a major pain. If that's what
> it takes . .so be it . .but ugh...
>
> My other app issue with creating a profile is due to an app that requires
> a specialized COM component to be manually created and adjusted.
>
> - I've run into pretty much the same issues here as with the DLL
> registration process. Attempting to import an "exported" COM component from
> a correctly setup system won't import into the virtual app profile.
> - attempting to run the COM configuration app from within the app profile
> wizards only ever makes these COM adjustments to the local machine, not the
> app profile.
>
> So far I believe my options are down to either trying to recreate all
> registry and file system adjustments these apps may require by hand within
> the virtual app profile, or giving up the ghost all together on attempts to
> stream them. The sad part is that both of these tricky little app
> installs are required to be running within the same memory space as our Core
> production apps, which I can profile and stream with absolutely no issues.
>
> Thoughts / suggestions much appreciated
>
> TIA
>
> Lan
>
>
>
Other related posts: