I’ve installed VP UML and Eclipse plug-ins, and added the corresponding keys. Any user who has admin privaleges on the machines is able to run VP UML without any problems; however, users without admin access are not able to run VP UML because the license manager is unable to recognize that the licenses are there.
It seems that the problem is that some portion of the program is does not have the right level of access to allow non-admins to run it. A list of registry entries and program directories and the access they require so that non-admins can run the program would be greatly appreciated.
May I know where did you install VP Suite to? Besides, did you install with the account that have the admin privileges? Finally, could you show me a screenshot of your license key manager? Thanks a lot.
May I know where did you install VP Suite to? Besides, did you install with the account that have the admin privileges? Finally, could you show me a screenshot of your license key manager? Thanks a lot.
Best regards,
Jick[/quote]
It was installed to its default install location (C:\Program Files\VP Suite 3.0), it was installed with an account that has admin privileges (and other accounts with admin privileges have no problems running the program).
As an added note, when I installed VP Suite I was also installing the SDE for Eclipse and it changed the permissions of some files/folders in Program Files\Eclipse with the same result that eclipse was no longer able to read the configuration files correctly.
Some additional information, our system is setup so that each time a user logs in a profile is created for them and when they log off the profiles are blown away. Now usually if we have settings/keys/etc as an admin user and copy them to the default profile then whenever these profiles are created for a user logging in all the settings are preserved for them. The problem here seems to lie in the fact that after copy the profile of a user with admin access to the default profile when a non-admin user logs in and has a profile generated, it isn’t recognizing the keys that have been added. There is no problem with the identification if another user with admin access has a profile created.
Solution: The actual problem lies in how Visual Paradigm stores the location of the keys. Visual Paradigm stores the location of the keys in the C:\Documents and Settings\ username .vpumlprops.vp.ls, the problem lies in the contents of this file which has hardcoded the location of the keys. So when copying the default profile, this results in all users looking at the location where the user with admin access has the keys, which a non-admin wouldn’t have access to. The fix to this was the change the location in .vp.ls file to somewhere that everyone has access to, and then move the keys to that location.
