|
Is that a shaven or an unshaven..
I meant, what is the airspeed of an unshaven European beaver, versus an African unshaven beaver?
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Thats easy - European beavers are pink (close to red) and red always goes faster.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
[...]
Mycroft Holmes wrote: and red always goes faster.
The more blood is pumped through it..
So I shut up here. This no Soapbox 
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
That's the colour of rock-climbing helmet I asked for 
|
|
|
|
|
It was probably done by a modern beaver that wanted internet in his home.
Could happen over here (Netherlands) too as the beaver is returning after a period of absence.
|
|
|
|
|
Codewitch
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
<rant>
Why do vendors insist on launching elephanting web pages at the end of their supposedly enterprise-grade installers when you're installing them under the System account and you used the damn /quiet switch !?!?!?!?!?!?
THERE'S NOBODY LOGGED INTO THE ELEPHANTING MACHINE TO SEE THE ELEPHANTING WEB PAGE!
</rant>
<grumble>
Now I have to get out InstallShield and go hunting for a custom action and rip it out... elephanting vendors...
</grumble>
|
|
|
|
|
Dave Kreskowiak wrote: and you used the damn /quiet switch !?!?!?!?!?!?
THERE'S NOBODY LOGGED INTO THE ELEPHANTING MACHINE TO SEE THE ELEPHANTING WEB PAGE!
Because marketing demanded it.
It's not about being reasonable. If we were, marketing had no reason to exist.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
My favorite belongs to the hardware security key we use. Their installer can be run with a UI or "silently". Running it "silently" displays more windows (message boxes mostly) and requires more clicks than the full UI version.
Dumbasses.
Software Zen: delete this;
|
|
|
|
|
Yeah, I got another app that's "enterprise", from a major vendor that shall stay nameless. That thing assumes the users are admins on their own machines, like that's still a thing. When the install completes, it launches Word and a giant "readme.doc", and you can't turn it off! It's an .EXE installer so I can't modify it to remove that function! GRRRRRR!!
The vendors response? "Put in a feature request to remove it and maybe we'll get around to it."
Well, since this was supposed to go on some 3,000 machines, and I can't install it silently as System without it still launching Word, that's a large chunk of money this vendor is now missing out on while we go look for another product.
|
|
|
|
|
Have you considered getting it "repackage" professionally....?
Even if it is (on the surface) an exe it may still contain MSI's... these are (fairly) easily customized using Transforms... if you have to bite the bullet a complete repackaging (capture installation and repackage as an MSI) is an option but be sure that whoever does it is a "Professional" and consider possible updates in the future...
Who the f*** is General Failure, and why is he reading my harddisk?
|
|
|
|
|
More than anything else, I don't think that the customer should have to pay to fix broken software for the vendor.
Not that it doesn't happen all the time but I still, strangely, think the vendor is responsible for this sort of thing.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Oh, don't get me started on broken installers.
Keep in mind that vendor get paid to write software and they spend a ton of time doing that. Installers tend to be afterthoughts that they're not so hot at understanding. You'd be surprise at how many installers I come across that do really stupid things or are just broken and need to be fixed. Sure, they'll install/uninstall the software, but they also end up doing subtle crap that screw things up.
For example, I had a vendor include a custom action in their .MSI installer that indiscriminately killed off all of the WMI provider host processes during uninstall. Those would be the WmiPrvSe.exe processes you see at the bottom of Details in Task Manager. Well, doing that craps out all of WMI on the machine. SCCM (Microsoft's endpoint management and deployment suite) is heavily dependent on WMI. You can guess what chaos ensued when I uninstalled that piece of crap. If you we're running something that was dependent on WMI, you'd never know that happened. Restart the machine and all evidence of it happening is gone.
I cracked open the installer and found the offending (offsensive) custom action. Called the vendor. "Oh, really? It did that? Could you tell us where that is and what to do to fix it. The guy who builds our .MSI's doesn't work here any more..."  
I see sh*t like this once or twice a week.
|
|
|
|
|
Dave Kreskowiak wrote:
I see sh*t like this once or twice a week.
They shoot horses, don't they?
(make sure other's watch so they don't do the same and get the same "corrective therapy").
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I wish that was an effective deterrent. 
|
|
|
|
|
Deployment of *any* software is always last on the list of priorities (a bit like security  ) so basically a developer has to use (largely unknown) tools that present a next, next, next installation expecting to be a local admin.... don't talk about unattended... they just don't have the expertise...
Who the f*** is General Failure, and why is he reading my harddisk?
|
|
|
|
|
Unattended is THE main requirement in my house. I'm getting sick of vendors telling me to install it by hand for the users because they assume users can do it themselves when they can't, or won't (it's not in the contract,) or will never pick the correct options if any, even if there's just one! Grrrrr
"Oh yeah? You think I should go install by hand on thousands of machines, do ya?"
"oohhhhhhh  We'll get back to you."
|
|
|
|
|
I am the professional. You'd be surprised how hard it is to find a place that can actually repack.
There's no .MSI in the thing and I verified that with the vendor. It's straight up executable. That's also when they told to me to put in a feature request.
Setup captures are a last resort as we try to stay as close to the vendor installer as possible. The captures always pick up garbage, even on a machine stripped down to nothing specifically setup for the purpose. For an installation that runs for 45 minutes on a normal machine, that's a lot of time to pick up a lot of garbage to trim out of the install. Not to mention captures that include drivers are a royal pain in the ass to get perfect.
And then there's dealing with the bugs in the capture software.
|
|
|
|
|
Quote: For an installation that runs for 45 minutes on a normal machine, that's a lot of time to pick up a lot of garbage to trim out of the install.
That's why I said a "Professional".... if they are good that shouldn't be a problem...
Quote: Not to mention captures that include drivers are a royal pain in the ass to get perfect.
Drivers are easy... as long as they are signed
A good packager knows his tools (ergo and it's bugs... )....
Seriously, used to do this all the time in a previous life (10+ years ago)... some of the sh*t that was thrown at us....
Who the f*** is General Failure, and why is he reading my harddisk?
|
|
|
|
|
Phil.Benson wrote: if they are good that shouldn't be a problem...
It's tedious to do when you end up grabbing thousands of keys, and the tooling bugs you deal with won't show you all the keys it grabbed and/or it crashes when building the .MSI project because of certain registry value content, which can show up anywhere in those couple thousand keys. (Good Hunting!) You have to take those out, build the project, then go put them back in in the .MSI.
You were saying something about knowing the tools, and the bugs?
Phil.Benson wrote: Drivers are easy... as long as they are signed
Yeah, about that signing thing. Not everyone does it, especially said nameless vendor, even though MS pushes it and now tries to make it as mandatory as possible. I've run into more than one occasion where vendor signing certs are expired. Yada, yada, yada, ...
Those are fun phone calls when you tell them and they go scrambling to renew it, rebuild, and get you new source, 'cause, you know, deadlines.
|
|
|
|
|
Quote: It's tedious to do when you end up grabbing thousands of keys, and the tooling bugs you deal with won't show you all the keys it grabbed and/or it crashes when building the .MSI
A good packaging pro knows the limits of his tools ,Wise 8(unfortunately dead), AdminStudio, RayPack whatever... also solid exclusion lists and OS knowledge is a *must*...
Quote: Yeah, about that signing thing. Not everyone does it, especially said nameless vendor, even though MS pushes it and now tries to make it as mandatory as possible. I've run into more than one occasion where vendor signing certs are expired.
Internal Signing / Self Signing is the way to go....
Like I said, been there, done that, read the book, seen the film got the T-Shirt... luckily I left that all behind me... 
Who the f*** is General Failure, and why is he reading my harddisk?
|
|
|
|
|
Quote: A good packaging pro knows the limits of his tools ,Wise 8(unfortunately dead), AdminStudio, RayPack whatever... also solid exclusion lists and OS knowledge is a *must*...
WiseScript executables can hang on exit on Windows 10, anywhere from a couple minutes to over a week before I end up just killing the task. When they hang, it's always after the last line in the script, where the executable is doing cleanup and tearing itself down before the process is torn down. There is no fix, nor a workaround for it, other than rewriting in some other language/tool.
AdminStudio/InstallShield is currently the tool of choice, and the one with all the bugs Flexera doesn't seem to want to fix, but they'll add new "features", like a flat UI nobody likes. Yes, we've brought up the issues we keep running into with them, and, ... 4 full versions later we're still waiting for them to fix the problems we find, like crashing while building .MSI projects from a capture. We're sure it's with the data in registry values, but it is not limited to any one key.
Now, in a project with literally thousands of keys/values, are you going to sit there for a week, digging through every one of them, looking for exactly what's causing the crash? Nope. I don't have the time for that. That's Flexera's job. And yes, we've sent them a half dozen projects were the problem occurs. No word nor fix for it in years.
Now, how are you going to come up with an exclusion where the problem can occur in any key, but you also don't know exactly what content causes the crash? I have my suspicions, but there is no way to come up with an exclusion filter for them. Oh, and don't think that you can just exclude all of the registry from the build and add stuff back until the crash starts happening. It doesn't help. You can exclude the entire registry and it still crashes while "building" the registry of the .MSI project.
I running anywhere between 30 to 50 projects at any one time. I don't have the time to do Flexera's job for them, nor do I have the source code for the Repack tools, otherwise I'd fix it myself.
And, frankly, the whole "oh, you just have to know your tools and O/S" thing to work around every problem is insulting. There are some problems you just cannot work around.
Quote: Internal Signing / Self Signing is the way to go....
You're missing something there, but I'll leave it up to you to figure out what that is. After all, you should know your tools.
|
|
|
|
|
Quote: WiseScript executables can hang on exit on Windows 10
Wisescripts are never a good idea... I haven't come across many cases were it *had* to be used... if it gets that far a CustomAction (C/C++) would do the job, providing you handel rollbakc if in ExecuteDeferred.
Was never a fan of AdminStudio but didn't have that many problems even with complex captures...
Quote: And, frankly, the whole "oh, you just have to know your tools and O/S" thing to work around every problem is insulting. There are some problems you just cannot work around.
That was not to be insulting, but how many Packagers have you come across that had *no idea* what happens under the hood? (I used to do Wise/Altiris/AdminStudio Training and the standards ranged from "Can move a mouse without supervision" to real experts...)
I personally have gone as far as writing a filter drivr to get around access Problems, but that's a whole different level and a customer speocfic issue were Software and Hardware *had* to work together...
Still, at the end of the day as ever it's a case of Cost vs. Use...
Quote: You're missing something there, but I'll leave it up to you to figure out what that is. After all, you should know your tools.
No, not at all, your environment, your say of the matters. If you don't have a public cetificate for signing then it's your own fault if you don't have one for internal use in your domain... but I'll leave you to figure that one out.... (no insult intended). Back in the day there were *always* drivers that were not signed, have code-siging was a must before starting any packing projects...
Who the f*** is General Failure, and why is he reading my harddisk?
modified 3-May-21 11:39am.
|
|
|
|
|
Sorry. The driver for what gets me to the end of a project is mainly time constraints. If I to take a few days to figure out a problem and come up with a work around, that's too long in most cases. There's plenty of times where, due to outside project forces, I have just hours to get a project out the door. That doesn't leave much, if any, room for something to go wrong and get it working.
Phil.Benson wrote: but how many Packagers have you come across that had *no idea* what happens under the hood?
L-O-T-S of people call themselves "packagers" but really don't have a clue. I've been in interviews where "packagers" don't know what an .MSI really is! (Resumes are useless.) The challenge is finding people who have at least a minimum level of knowledge and are trainable to do the job, and do it to standards. Around here, that ain't easy to find.
Outside companies are no different. You can guess who they're hiring to put on a contract job. Also, companies that do packaging work usually don't do it to our standards. We constantly have to check their work and get things fixed, so are we really saving time by getting outsiders to handle some of the load? No, not really. We've been through half a dozen companies in the last decade. Doing it ourselves, we are always faster, more consistent and with a high quality of work.
Maybe our standards are too high, but when we deploy a piece of software to 16,000 machines, the standards better be high because we don't want to go fix all of those machines.
We don't get paid to repack so much as we get paid to protect the production environment, from vendors and from ourselves.
|
|
|
|
|
Do a search for the CEO of the company and let them know directly that they're loosing out on a large sale because of their installer and assumption that users are also local administrators. It should only take a few minutes to find the email address.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
