MindManager per-user install, becomes MM 7 Lite when second user uninstalls
Clutching at straws here, as a post to MindJet's forum has drawn a complete blank (i.e. no responses...)
We have followed the instructions in MindJet's Deployment PDF to the letter. Here's our situation:
- We have a 5-user license
- We are installing per-user instead of per-machine. This is an absolute, non-negotiable client requirement. The client is unconcerned with multiple installs on machines (license permitting, obviously)
- We are applying a transform to the Admin MSI downloaded from the web site.
- First user logs in, MM installs and runs fine. License key is fine.
- Second user logs in, MM installs and runs fine (with one caveat - PDFWriter shortcut isn't created (log shows 'MSI (s) (3C:54) [12:38:14:786]: Skipping action: MMInstallPDFXchange_XP (condition is false)'). License key is fine. First user unaffected by any changes by second user.
- To test, second user is removed from AD group. MM uninstalls. We have marked the license Custom Actions as 'Leave installed on uninstall'. License registry key remains after uninstall.
- First user logs in. Start MM and WI repairs the install.
- When MM loads, it prompts for a license key (the license registry entry is still present!) and says it's a 21-day trial version.
- Help/About shows as 'MM 7 Lite' instead of 'MM Pro' but also shows the license key! The splash-screen, however, doesn't show the license key, which it did before the second user caused the uninstall.
- When attempting to enter the license key we have (which is pre-populated when the 'License...' button is clicked), MM says the key is for a different MM7 edition.
Can anyone advise either:
- what additional feature(s)/component(s) do I need to flag to be left installed on uninstall;
- what registry key/file is being read to determine that the license key isn't present/valid. If need be, I can build a Custom Action to recreate it in my transform. (ProcMon output too lengthy to be of any practical use, although I *am* revisiting it today);
- why MM thinks it's a different edition.
We have followed the instructions in MindJet's Deployment PDF to the letter. Here's our situation:
- We have a 5-user license
- We are installing per-user instead of per-machine. This is an absolute, non-negotiable client requirement. The client is unconcerned with multiple installs on machines (license permitting, obviously)
- We are applying a transform to the Admin MSI downloaded from the web site.
- First user logs in, MM installs and runs fine. License key is fine.
- Second user logs in, MM installs and runs fine (with one caveat - PDFWriter shortcut isn't created (log shows 'MSI (s) (3C:54) [12:38:14:786]: Skipping action: MMInstallPDFXchange_XP (condition is false)'). License key is fine. First user unaffected by any changes by second user.
- To test, second user is removed from AD group. MM uninstalls. We have marked the license Custom Actions as 'Leave installed on uninstall'. License registry key remains after uninstall.
- First user logs in. Start MM and WI repairs the install.
- When MM loads, it prompts for a license key (the license registry entry is still present!) and says it's a 21-day trial version.
- Help/About shows as 'MM 7 Lite' instead of 'MM Pro' but also shows the license key! The splash-screen, however, doesn't show the license key, which it did before the second user caused the uninstall.
- When attempting to enter the license key we have (which is pre-populated when the 'License...' button is clicked), MM says the key is for a different MM7 edition.
Can anyone advise either:
- what additional feature(s)/component(s) do I need to flag to be left installed on uninstall;
- what registry key/file is being read to determine that the license key isn't present/valid. If need be, I can build a Custom Action to recreate it in my transform. (ProcMon output too lengthy to be of any practical use, although I *am* revisiting it today);
- why MM thinks it's a different edition.
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
spartacus
17 years ago
Some things to check (if you haven't done so already) :
Firstly, eliminate your transform as a possible cause of the problem. If you install just the base MSI (with everything set at default) in per-user mode for the first user and then install the base MSI for the second user (also in per-user mode) do you then
(a) see the same issue with the PDFWrite shortcut missing ?
(b) see MM7 Lite in the Help .. About .. for the second user ?
It sounds to me like the main failing for the second user is the failure to create the shortcut for the second user. Could you not remove or alter the condition on the MMInstallPDFXchange_XP action so it is not skipped ?
However, to find out how the registration settings are laid down on the system, on a clean machine you could install the vendor's base MSI in `Lite` mode (don't supply a license key to start with) and then perform a snapshot before and after going through the process of entering the license key.
Once you have learned more from the above, you could then reintroduce the transform you created.
Hope this helps,
Regards,
Spartacus
Firstly, eliminate your transform as a possible cause of the problem. If you install just the base MSI (with everything set at default) in per-user mode for the first user and then install the base MSI for the second user (also in per-user mode) do you then
(a) see the same issue with the PDFWrite shortcut missing ?
(b) see MM7 Lite in the Help .. About .. for the second user ?
It sounds to me like the main failing for the second user is the failure to create the shortcut for the second user. Could you not remove or alter the condition on the MMInstallPDFXchange_XP action so it is not skipped ?
However, to find out how the registration settings are laid down on the system, on a clean machine you could install the vendor's base MSI in `Lite` mode (don't supply a license key to start with) and then perform a snapshot before and after going through the process of entering the license key.
Once you have learned more from the above, you could then reintroduce the transform you created.
Hope this helps,
Regards,
Spartacus
Posted by:
anonymous_9363
17 years ago
I have discovered this afternoon that the failure to create the s/c for the second user is because, in amongst the gazillion conditions for the CA which installs this sub-feature (almost ALL of the install is done by calls to DLL functions...thanks a BUNCH, Mindjet!) is one which checks for the existence of the feature's EXE. I removed that condition and now the s/c are installed OK. Like a good vendor, though, he hasn't seen fit to provide an uninstall CA for that sub-feature...
The *real* nasty is the license hoo-ha. I know where the license info lives in the registry and I have isolated it by the very process you suggest. I just monitored the first user start-up and it is IDENTICAL to the second user but STILL the second user switches to a Lite version. My suspicion now rests on one of the EXEs or DLLs being altered by a CA when the second user uninstalls or something like that.
Having said all that, the client is now impatient to get a distro so, given that a) there are only 5 licenses attached to the key we have and b) it is INCREDIBLY unlikely that 2 users will share the same machine and, if they did, one would uninstall that we took a decision to deploy in our current state. If the worst comes to the worst, we do the 'user log off, remove from group, log back in, add back to group, log off/on' dance. Not pretty but time's against us.
The *real* nasty is the license hoo-ha. I know where the license info lives in the registry and I have isolated it by the very process you suggest. I just monitored the first user start-up and it is IDENTICAL to the second user but STILL the second user switches to a Lite version. My suspicion now rests on one of the EXEs or DLLs being altered by a CA when the second user uninstalls or something like that.
Having said all that, the client is now impatient to get a distro so, given that a) there are only 5 licenses attached to the key we have and b) it is INCREDIBLY unlikely that 2 users will share the same machine and, if they did, one would uninstall that we took a decision to deploy in our current state. If the worst comes to the worst, we do the 'user log off, remove from group, log back in, add back to group, log off/on' dance. Not pretty but time's against us.
Posted by:
jmcfadyen
17 years ago
vbscab does your client actually know the difference between
PER USER deployment and
PER USER MSI's
you can still have roaming applications that are deployed PER MACHINE often these two terms are very misinterpreted.
I know there are clients who draw a hard line but often they dont even know what they are asking.
PER USER deployment and
PER USER MSI's
you can still have roaming applications that are deployed PER MACHINE often these two terms are very misinterpreted.
I know there are clients who draw a hard line but often they dont even know what they are asking.
Posted by:
anonymous_9363
17 years ago
ORIGINAL: jmcfadyenTrue, but with respect, it's irrelevant since in most cases the decision is effectively cast in stone. We could, of course, waste months in meetings advising the client of correct methodology but, in the meantime, the business units need their apps! God damn it, the real world *insists* on interrupting! :-) Plus, of course, we all *LOVE* meetings...
I know there are clients who draw a hard line but often they dont even know what they are asking.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.