How do I perform a snapshot w.o. executing a program. All I wanna do is add a file and reg entry (font).
I use Wise. Thanks
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
You don't have to actually execute a program to proceed to the after snapshot. Just make your changes, leave the path to exe blank, and when you're done hit next and it'll start the after snapshot. good luck, let us know how it works for you.
Answered 12/16/2008 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
Using SUC seems an incredibly long-winded way to add a file and some registry entries in WPS. Why not simply add the file in the 'Create new MSI' UI and then import the .REG?
Answered 12/17/2008 by: VBScab
Red Belt

Please log in to comment
0
ORIGINAL: VBScab

Using SUC seems an incredibly long-winded way to add a file and some registry entries in WPS. Why not simply add the file in the 'Create new MSI' UI and then import the .REG?


I didn't read the entire post...thinking/ guessing he probably doesn't know exactly what changes his configuration actions will make, e.g. launching the app instead of setup. I've used it in this way, as a kind of discovery tool.
If he's installing files and making reg entries directly, true, just add them in wise for windows intstaller, no need for snapshot.
Answered 12/17/2008 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
-1
You don't need to create a snapshot. Go to Windows Installer Editor - add the necessary files/registry changes and compile the package.
Answered 12/17/2008 by: InterneToughGuy
Senior Purple Belt

Please log in to comment
0
If you choose to, you may "snapshot" a notepad.exe or cmd.exe just to give you an entry point into snapshot tool, while making the changes you really intend to capture. Still a little convoluted, but who said packaging was easy $? [:D]
Answered 12/18/2008 by: revizor
Third Degree Blue Belt

Please log in to comment
0
Thanks for all the tips guys but what I am dealing with is the damn Fonts folder. When I do a copy it shows 0bytes on each font file that I pkg. My next question is how can I delete certain fonts ex. nam*.ttf and then call a VB script that re-registers new fonts? I have the script and I have the fonts I need. I need to do it in that order so I can run it as a GPO dist. Is it a module? Oh yeah, I wanna pkg this as an MSI.
Thx
Answered 12/18/2008 by: sam386
Senior Yellow Belt

Please log in to comment
0
I don't understand what's so hard here.

- Start a capture
- Remove whatever fonts you no longer need.
- Drop your new fonts into the fonts folder
- Restart your VM/VPC/VBox
- Finalise the capture

You *may* need to add detail to the RemoveRegistry table to ensure that registry entries relevant to the deleted font files are removed as well, as deleting the files (even using Control Panel) does NOT necessarily remove this data.
Answered 12/19/2008 by: VBScab
Red Belt

Please log in to comment
0
What I've seen is that TrueType (.ttf) fonts are really easy to handle throuth the File & Fonts table, however other types has been more problematic.
Answered 12/19/2008 by: AngelD
Red Belt

Please log in to comment
0
ok guys I think I have this in the bag. an msi that runs under the user shell. now my question is if I run it by calling the msi using a startup script GPO, is that the same as a user based assigned software deployment?
and if I do a startup script i dont want the install to continuously loop so will the below work via GPO?
Thank You

@echo off
IF EXIST "C:\FILENAME.TXT" THEN GOTO END ELSE GOTO INSTALL
:INSTALL
MSINAME.MSI /qn
OUTPUT > C:\FILENAME.TXT
:END
EXIT
Answered 12/23/2008 by: sam386
Senior Yellow Belt

Please log in to comment
-1
You seem determined to make this W A Y more complicated than it needs to be. Every part of your script's functionality (the 'MSINAME.MSY /qn' won't work, BTW) can be done in the MSI which you should then deploy as a machine-based package. A user-based package for fonts clearly makes no sense.
Answered 12/24/2008 by: VBScab
Red Belt

Please log in to comment
0
VBScab, I am just asking for suggestions not posting my final solution. If you have a better idea please post it. I HAVE tried using the msi as a machine based deployment but it DOES NOT work. The font's show as 0kb and DO NOT register.
Thanks
Answered 12/24/2008 by: sam386
Senior Yellow Belt

Please log in to comment
0
He did make a suggestion, use a machine based installation. If it doesn't work find out why, don't kludge it. read up on Windows Installer.

I hate to say this but your "solution" really makes no sense and will likely cause you more frustrations and problems.
Answered 12/24/2008 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
If you have a better idea please post it. Like I did in post #8? :)

Does the package work stand-alone, i.e. without GP's fog in the way?
Answered 12/27/2008 by: VBScab
Red Belt

Please log in to comment
0
Yes. We can use the MSI created using your recommendation in post 8 when we are logged on to the pc. What isn't working is attaching the msi as a computer or user assigned sw pkg via GPO. I should also add that I'm no pkg or GPO expert and don't mean to come across as an ass but there is NOTHING out there on this issue (deploy replacing fonts) with new versions. Like I said before i think it has to do with the Windows File Protection built into Windows. We can definately fix it using the MSI but it sure would be nice to deploy the solution. If someone can mock it up (replace a font) and get it to work I would love to know how you did it.
Answered 01/08/2009 by: sam386
Senior Yellow Belt

Please log in to comment
0
AAAAaaaaaaaaahhhhhhhhhhh....you're REPLACING fonts, not installing new ones! First, WFP doesn't apply to fonts, so forget that. I suspect the problem is how the Windows Installer engine handles files which don't contain binary version information. In summary, if a file in an MSI is older than (or the has the same date/time-stamp as) an existing file, it won't be installed. THIS is what I suspect is happening here.

- Clear out %SystemRoot%\TEMP
- Enable the MSI Logging policy on a target workstation (no need to reboot for this one)
- Run GPUPDATE on the w/s.
- In %SystemRoot%\TEMP there will be a selection of files names 'MSI[random alpha-numeric].LOG. Use the DOS FIND command to locate the one you're interested in. Easiest route is to use the ProductCode:
.....FIND /I /C [your MSI's product code] MSI*>LOG
- Open the log file and seek out the FileCopy entries. I suspect you'll see that the date/time-stamps mean that the existing files are left in place.
Answered 01/09/2009 by: VBScab
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity