The credentials entered are stored per user profile - so if your consultant logs in as User A and sets credentials within Manage > Credentials, then you log in as User B you will not have access to those credentials.
The shared credentials is meant for sharing the credentials with the Protect console service and other sections of the application - not for sharing the credentials with other users on the Protect console system.
I hope that helps clear it up.
OK, I have come to the realization that the creds he setup, I cannot use. I must setup my own. Such is life.
However, when I try to use the machine groups that he created, then I must apply my own creds but, and I really mean BUT, my creds applied on my profile appear to wipe out the cred that he applied on his profile!
So, can machine groups be shared across different admin accounts? If so, how are the creds supposed to be setup so they don't clobber each other?
It should not be forcing the other user's credentials to be removed. I would suggest opening a support case to work through this issue.
Contact info for support: http://www.shavlik.com/support/contact/
Case 00675255 raised.
Brandon says he was able to help you get this resolved. Is everything working ok for you now?
It's a long story... The departed consultant was having issues with the console crashing so he took it upon himself to delete his local profile on the server whilst logged in. This of course just borked his profile since it was in use at the time. After that, he would get a TEMP profile each time he logged in.
We had to clean up his profile and delete his shared creds which also removed all the creds from all his machine groups, so that set me way back, as I have to test every machine now and apply the proper creds. What I don't understand is why he would not have grouped the machines with like creds or at least put comments on them. He just chunked them into groups of 64 machines, citing that number as the max a group should hold.
I have a spinoff question...
Now that I need to assign and test the creds on every machine, I find that the Test credentials only works for physical machines, not for VMs. Why is that?
The test creds is so much faster than performing a scan to verify the creds. Tell me what is the fastest way to work around this:
I was told to use "Custom Action Patch Scan" as my default and set it to "Scan selected" "Shavlik"
Is everything working ok for you now?
Working with another level 1 tech, we wiped out all the creds from the db and created new ones. This caused some accounts to start working as expected and others not to.
I asked for this to go to level 2 but they want me to create a new db and repro the issue. I am not interested in creating a new db and just want the existing db to be fixed.
New case #00676005.
It sounds like they just want to see if you have the same issue when testing with a new database to confirm it is actually a problem with the database or not. As long as you name the test databse differently than your existing database, it won't overwrite the old one. Then you can use the database setup tool to go back to your existing database.
I also find the "SharedCredentials" logic flawed, there's never just one admin managing a set of server, it's always a group doing 2000 other things at the same time. So, if I Share a cred, I expect other users to be able to use it.
In our case, we're a couple of admins managing the same set of servers, it makes absolutly no sense for everyone to start from scratch when managing the patches. So as a simple workaround, we all use the same creds to RDP to the Shavlik Console Server and voilà, workaround...
Thanks for your input. We too are considering using a single "shared" AD account to RDP to the server but that limits concurrency so only one admin at a time can be logged in. At this stage, we will be two, a consultant and me. A former consultant entered everything as himself and now much of that is lost.
Since then, I have been putting in as much as I can logged in as the generic "shared" user, hoping and praying that the system doesn't mess up. I already had it mess up to where this "shared" user lost all the VM browse creds and I had to delete all the creds from the db along with all the machine groups that relied on those creds. Granted, the groups were not what we wanted to go forward with so, in this case the pain was contained, but I would hate to see this happen once we put the permanent groups in.
Next week I start working with a new consultant so he will use the generic "shared" account while I use my own AD creds. If this messes up, it will cost us dearly, both in consulting expense and in terms of delivering the project on time.
Just to close the loop on this, case #00676005 is resolved. Had to do with mixed (UPPER/lower) case.