Installation bug, Visual Studio Admin Tool install
Moderator: SourceGear
Installation bug, Visual Studio Admin Tool install
Looks like Visual Studio Admin Tool installation was written for Windows 9x, not for NT/2000/XP?
I logged in as a local administrator on the client machine, installed the 3.1.6 version of the Admin Tool, logged out, logged in as a regular user, and lo and behold, the Source Gear program group had no shortcut.
I logged back out, logged in as the same local administrator who did the installation, and found shortcuts on that administrator's private group.
I mumbled something not complimentary about the SourceGear Vault installation program, and copied the shortcuts to the existing SourceGear program group under All Users, where the installer should have put them for NT/2000/XP systems.
I logged out, logged back in as regular user, found the shortcuts, but the icons were missing, though, uh-oh, and tried them, and was not shocked to find they don't work.
So now I have to find and fix the permissions problem.
This is the kind of hand-fixing that having an installation program is supposed to avoid, I do believe.
I logged in as a local administrator on the client machine, installed the 3.1.6 version of the Admin Tool, logged out, logged in as a regular user, and lo and behold, the Source Gear program group had no shortcut.
I logged back out, logged in as the same local administrator who did the installation, and found shortcuts on that administrator's private group.
I mumbled something not complimentary about the SourceGear Vault installation program, and copied the shortcuts to the existing SourceGear program group under All Users, where the installer should have put them for NT/2000/XP systems.
I logged out, logged back in as regular user, found the shortcuts, but the icons were missing, though, uh-oh, and tried them, and was not shocked to find they don't work.
So now I have to find and fix the permissions problem.
This is the kind of hand-fixing that having an installation program is supposed to avoid, I do believe.
That would be an incorrect guess.
The concept was designed for an environment where the Administrators are security conscious and other people had access to the administrators' machine.
As I mentioned, I logged a feature request to allow the installer to use either the local account or All Users.
As a work-around, you'll need to make new shortcuts.
The concept was designed for an environment where the Administrators are security conscious and other people had access to the administrators' machine.
As I mentioned, I logged a feature request to allow the installer to use either the local account or All Users.
As a work-around, you'll need to make new shortcuts.
Jeff Clausius
SourceGear
SourceGear
I think I got confused partway through this process, and now there are multiple related threads here also confusing me.
I think part of my confusion was not understanding the security model.
I gather the person running the Vault Admin tool is supposed to run as a local windows administrator -- I hadn't understood that. I'm used to running as a so-called limited user, even when doing administration, except when specifically administering windows things on a local box.
Also, I got confused by the login dialog -- it looks the same as the vault client IDE dialog, except that apparently the profile buttons are all intentionally disabled. I assumed it was a bug that they were disabled.
I think it would have been less confusing if I didn't see the profile controls at all -- especially if they never work anyway, which I now understand is by design, for some security purpose -- I understand now, it is to prevent the user of the Vault tool from saving credentials.
(I may dislike that as a user who has too many credentials to memorize them all, but I can understand why some people would want that; I was just getting the two different interfaces -- Vault Admin and Vault client IDE -- confused, because they look almost the same in the login dialog.)
Or maybe if you really want to show the disabled profile controls, a tooltip of some kind to explain to the user when they try to click on the controls, that they are disabled for reason X (however you feel is best to explain it, I mean) -- just to help clarify that it is not a bug, and that the user isn't meant to figure out what to do in order to enable them.
I thought that either it was a bug, or that there was some configuration problem preventing them working -- both wrong guesses by me, so my experience suggests that a relatively ignorant user (such as myself, who did not read any installation manual) may guess incorrectly what they mean.
I think part of my confusion was not understanding the security model.
I gather the person running the Vault Admin tool is supposed to run as a local windows administrator -- I hadn't understood that. I'm used to running as a so-called limited user, even when doing administration, except when specifically administering windows things on a local box.
Also, I got confused by the login dialog -- it looks the same as the vault client IDE dialog, except that apparently the profile buttons are all intentionally disabled. I assumed it was a bug that they were disabled.
I think it would have been less confusing if I didn't see the profile controls at all -- especially if they never work anyway, which I now understand is by design, for some security purpose -- I understand now, it is to prevent the user of the Vault tool from saving credentials.
(I may dislike that as a user who has too many credentials to memorize them all, but I can understand why some people would want that; I was just getting the two different interfaces -- Vault Admin and Vault client IDE -- confused, because they look almost the same in the login dialog.)
Or maybe if you really want to show the disabled profile controls, a tooltip of some kind to explain to the user when they try to click on the controls, that they are disabled for reason X (however you feel is best to explain it, I mean) -- just to help clarify that it is not a bug, and that the user isn't meant to figure out what to do in order to enable them.
I thought that either it was a bug, or that there was some configuration problem preventing them working -- both wrong guesses by me, so my experience suggests that a relatively ignorant user (such as myself, who did not read any installation manual) may guess incorrectly what they mean.
No problem.Perry wrote:I think I got confused partway through this process, and now there are multiple related threads here also confusing me.
No. That is incorrect. I answered this in the other thread.Perry wrote:I think part of my confusion was not understanding the security model.
I gather the person running the Vault Admin tool is supposed to run as a local windows administrator
I can understand the confusion here. I'll create a feature request to differentiate Vault Admin Login vs. Vault GUI Login vs. Vault IDE Login.Perry wrote:Also, I got confused by the login dialog -- it looks the same as the vault client IDE dialog, except that apparently the profile buttons are all intentionally disabled. I assumed it was a bug that they were disabled.
I think it would have been less confusing if I didn't see the profile controls at all -- especially if they never work anyway, which I now understand is by design, for some security purpose -- I understand now, it is to prevent the user of the Vault tool from saving credentials.
Yes, that is why I mentioned adding yourself to the Vault Administrators group. This way you wouldn't need to remember a different password for the Admin account. Your normal Vault account would suffice. In addition, if you want to eliminate the number of passwords, I mentioned using AD authentication against the Vault server. In this setup, you would only need to use the Windows password to authenticate against Vault.Perry wrote:(I may dislike that as a user who has too many credentials to memorize them all, but I can understand why some people would want that
Noted. As I mentioned, I'll log a Request for Enhacement for this area.Perry wrote:I thought that either it was a bug, or that there was some configuration problem preventing them working -- both wrong guesses by me, so my experience suggests that a relatively ignorant user (such as myself, who did not read any installation manual) may guess incorrectly what they mean.
Jeff Clausius
SourceGear
SourceGear