Software Deployment

The only time I have ever had issues with shortcuts was when I wasn't using the 'actual' path to the executable. If I did that it always worked. I am suing Wininstall Packager Pro so not sure i can help with your issue. Good luck.

I would be testing the package outside of GPO's to see if the problem is with your deployment method OR the MSI itself. Having never used Wise I wouldnt be able to help with anything specific to that but from an IS point of view I would be re-creating the shortcut again if I had issues with it, re-importing the icon again and then retesting.

P

I would be testing the package outside of GPO's to see if the problem is with your deployment method OR the MSI itself. Thanks for responding but I did say "A stand-alone install using an admin-level account makes no difference to the outcome , however."

and

I would be re-creating the shortcut again if I had issues with it, re-importing the icon again and then retesting. "I am meticulous at cleaning out the relevant tables to ensure nothing's hanging around after these edits"

Which could of course be the problem, if you have deleted something you shouldnt ;)

Not saying you have but its worth looking at, going back to the original snapshot would be a good test, if the problem is there with that, before cleaning, then its a bug with Wise, at a guess.

P

PS. Oh, I did notice you had said you had installed it outside of GPO's but didnt have the time to edit the response :)
PSS. I know you said that you didnt have time to re-capture, but if you cant go back to the orignal pre-clean capture then I would re-cap it again, dont clean it, see if you get the problem on an uncleaned MSI.

I use WPS and have it set to always save back-ups so I have the original WSI and every increment between then and now so I can compare pre-clean and post-clean. Time-wise, it's obviously quicker to just use LNKs which is how we've gone with this baby.

If I get a nice short re-package which displays the same behaviour, I'll spend the time and re-capture it then compare the two.

Meanwhile, we still don't know why WPS creates these empty shortcuts in the first place - you'll recall that the whole "no icon displayed" scenario was kicked off because the advertised shortcuts were empty and gave an error "The parameter is invalid".

ORIGINAL: VBScab

Here's a corker for you all...

Our authoring tool is Wise Package Studio (WPS). We deploy our apps via Group Policy and, whenever possible, per-user. A stand-alone install using an admin-level account makes no difference to the outcome , however.

That outcome is that every now and again, an app will install fine (in terms of files copied, registr entries added, etc) but its advertised shortcuts will be completely empty: launching them results in the error "The parameter is incorrect". No amount of faffing about with the WSI or final MSI fixes this situation. Even hard-coding the target, as opposed to retaining WPS's SHORTCUTPATHx property lash-up, doesn't help. So, as like most of us I'm under time pressure to get apps out, I normally substitute with non-advertised shortcuts. These normally work well but again, *sometimes*, the icons don't appear properly, although they do launch the app OK. Further investigation shows that the .ICO hasn't been copied to %SystemRoot%\Installer\[ProductCode]. I am meticulous at cleaning out the relevant tables to ensure nothing's hanging around after these edits. Recapturing to build a completely new WSI/MSI is out of the question, time-wise. Logging the install (on by default on my test VMs) shows nothing out of the ordinary. The CreateShortcuts action returns 1 as expected.

The final work-around is to simply use .LNK files as part of the installation and this, of course, always works.

Can anyone shed any light on what's causing this?


ok, I'll bite: WHY did your organization decide to use per user installs? I've never actually heard of anybody doing this in a network/corporate environment. I am not even sure why you'd want a per user install AT ALL, as you can perfectly well set user prefs etc. with a machine install. I can see why theoretically you'd want to do it, if you had some super private app on a multi user machine. But again, never seen it in real life. Color me curious...

But on to the main issue, I usually follow this rule of thumb: if it's a repackage, and the original shortcuts were unadvertised, I just preserve those shortcuts as they were in the vendor install as closely as I can. Sometimes that means copying the actual .LNK files off for later reference, so I can always get the exact original path to the EXE, "start in" icon index etc. It also helps, if Wise loses the icon, to get the icon/EXE in the vendor installation.

I have seen some buggy behavior with Wise with shortcuts and setup capture. Usually that can be resolved by just deleting the bad ones using the above method and manually entering the path and "start in" (WkDir) in your shortcut entries in the Shortcut table. Another thing I've seen happen is, if the shortcut is a pointer to a file [#yourexe.exe] and you've deleted/re-added or moved the EXE or its component, its file index can be changed (it's now [#yourexe.exe998] and now the original shortcut is bad. )

One thing I would NEVER do is copy a hard coded lnk file. They are hell to maintain and troubleshoot. I inherited some of those from another packager, and cursed his name ( you seem like an OK guy though [;)] )

Unfortunately I don't know what do to about advertised shortcut problems. Usually, with these types of shortcuts I'm working with a vendor MSI and applying customizations and settings. Have you looked at msi.chm? I've never created an advertised shortcut from scratch, but there are a number of things to check:

Target
The shortcut target.
For an advertised shortcut, this column must be an external key into the first column of the Feature table. The installer evaluates the entry in the Target field as an Identifier and the entry must be a valid foreign key into the Feature Table. The file launched by the shortcut in this case is the key file of the component listed in the Component_ column. When the shortcut is activated, the installer verifies that all the components in the feature are installed before launching this file.
For a non-advertised shortcut, the installer evaluates this field as a Formatted string. The field should contains a property identifier enclosed by square brackets ([ ]), that is expanded into the file or a folder pointed to by the shortcut. For more information, see the CreateShortcuts action.

ok, I'll bite: WHY did your organization decide to use per user installs? I've never actually heard of anybody doing this in a network/corporate environment. I am not even sure why you'd want a per user install AT ALL, as you can perfectly well set user prefs etc. with a machine install. I can see why theoretically you'd want to do it, if you had some super private app on a multi user machine. But again, never seen it in real life. Color me curious...LOL...you think I didn't ask that question in the first week?!? :) It was a done deal when I was engaged. Almost 400 apps in to the desktop refresh project (the company was NT4 until late last year. And you don't want to know about desktop hardware...) , it's too late to go back, even if they wanted to.

As for advertised-vs-non-advertised s/c, for legacy installs, there's no such thing and WPS defaults to advertised and, generally, they just work. The file index "gotcha" is one I automatically look for, but the issue arises from the get-go, even before I've made any changes.

I think the long & short is that this is a WPS bug.

ORIGINAL: VBScab

LOL...you think I didn't ask that question in the first week?!? :) It was a done deal when I was engaged. Almost 400 apps in to the desktop refresh project (the company was NT4 until late last year. And you don't want to know about desktop hardware...) , it's too late to go back, even if they wanted to.

As for advertised-vs-non-advertised s/c, for legacy installs, there's no such thing and WPS defaults to advertised and, generally, they just work. The file index "gotcha" is one I automatically look for, but the issue arises from the get-go, even before I've made any changes.

I think the long & short is that this is a WPS bug.



I'm sure that it is a wise bug. I am not sure what advertising buys you, in a scenario where the original install's shortcuts are non-advertised, but Wise seems to want to do this. That's why I got into the habit of saving the original install's links off for later reference, so I could fix them.

Good luck!
OG

Hi

How to create Transforms usning WinInstall Pro. I tried as per the document but it is not creating and in the initials stage itself while giving the MSI file saying that this is not a valid MSI eventhough im giving the valid MSI file.

Thanks

Are the .ico files 16-bit icon files by any chance ?

Regards,

Spartacus

Ian - I've found shortcuts not installing as you describe (or with no icon being dispayed) when deployed over GP yet install fine when run from the command line or interactively. Recreating the GPO usually fixes without any changes to the MSI.

BTDT, JB. Jeremy and I recreated the GPO when we were faffing about with the app in question that we attracted comment from the MS chaps LOL. I'm glad it worked for you on this occasion, though.

Hi VBSCab. I know this is an old thread, but I just ran into this issue with a deployment. We pushed an app out to approximately 6200 machines over the weekend and have about 5% getting this "The parameter is incorrect" error when trying to launch the shortcut. A simple repair of the MSI fixes the issue. We're using WPS 7.3. Did you ever determine what the root cause of this issue was?

I'm afraid I never did. The client in question is now pushing apps via SCCM and as far as I'm aware, it hasn't occured with any such apps. Greg or Jon, if you're "watching", if you know different, do tell.