Ive looked at two knowledgebase articles about this, neither solution helped ( and Ive searched the forum ).
I installed the server a couple of weeks ago, and was able to operate it as admin and the one free user. At the time I tried importing my existing sourcesafe repository. That made a bit of a mess, so I obliterated it all, deciding to just start from scratch.
Today my license arrived, and I installed it.
Now I can log in as admin from the client, but not as any other user ( some were created by the sourcesafe import ). When I try to login I get the "Encryption Failed" error.
In addition, if I try to edit a user with the admin tool, I get an "Access Denied" error. The changes take ( except for group membership ) however.
Im running on Windows Sever 2003, with Sharepoint ( Ive already worked through the install issues with sharepoint ).
Client say "Encryption Failed"
Moderator: SourceGear
Is it safe to assume, you have installed the Vault 2.0.6 server? There were some configuration problems with early versions of Vault and IIS servers running in IIS 5.0 isolation mode.
There have been reported issues on Windows 2003 servers when the Application Pool's identity (assuming no identity impersonation is used) does not have access to the "%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys" directory, or the machine keys for the file starting with "edb3f753ca89beb7d17f32a80a447d75_" were created with incorrect NTFS security permissions.
First, I would recommend checking the NTFS permissions of "%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys". Make sure the Application Pool has full access to this directory.
Second, I would delete all files starting with "edb3f753ca89beb7d17f32a80a447d75"
After this, try to log in. Does it fail? Also, can you check the server's log file ( default location - %windir%\temp\sgvault ). Are there any error messages recorded there as well?
There have been reported issues on Windows 2003 servers when the Application Pool's identity (assuming no identity impersonation is used) does not have access to the "%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys" directory, or the machine keys for the file starting with "edb3f753ca89beb7d17f32a80a447d75_" were created with incorrect NTFS security permissions.
First, I would recommend checking the NTFS permissions of "%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys". Make sure the Application Pool has full access to this directory.
Second, I would delete all files starting with "edb3f753ca89beb7d17f32a80a447d75"
After this, try to log in. Does it fail? Also, can you check the server's log file ( default location - %windir%\temp\sgvault ). Are there any error messages recorded there as well?
Jeff Clausius
SourceGear
SourceGear
Tried Both
Those are the two KB articles that Ive followed.
The server is not running in isolation mode.
Ive granted full access to everyone to the mentioned directory and deleted the file.
The server is
Version 2.0.6.2219 Installed 04 November 2004
After the initial install I was able to log in as the one user I had created. So it did work.
I can still log into the client as admin - seems to me that this doesn point to any of the crypto service errors that others have reported. No errors are being generated in the log file - but every time I reset IIS a startup message is logged.
Iam the admin of the machine - nothing has changed about it since I did the install, except for getting the license today.
The server is not running in isolation mode.
Ive granted full access to everyone to the mentioned directory and deleted the file.
The server is
Version 2.0.6.2219 Installed 04 November 2004
After the initial install I was able to log in as the one user I had created. So it did work.
I can still log into the client as admin - seems to me that this doesn point to any of the crypto service errors that others have reported. No errors are being generated in the log file - but every time I reset IIS a startup message is logged.
Iam the admin of the machine - nothing has changed about it since I did the install, except for getting the license today.
Fixed It
As I was typing in my last reply I thought that I should test to see if the client worked without the server license being activated.
I deactivated and deleted my license ( nice that it is so easy ).
Then I discovered that you can only have one active user in the admin, so I deactivated all but one user ( + admin ).
At this point I was able to log in with the client, as both admin and myself.
I put my license back in, and reactivated it.
Then I reactivated all the users.
This time I did not get an error editing them ( as I had before ).
I am also able to log in as any user.
Aside from the creating myself ( and a user I added today testing the admin "Access Denied" error ) about ten users were created while importing the previous sourcesafe repository. It seems to me that the error is cropping up in there somewhere ( existing active users previous to a license being activated ).
I deactivated and deleted my license ( nice that it is so easy ).
Then I discovered that you can only have one active user in the admin, so I deactivated all but one user ( + admin ).
At this point I was able to log in with the client, as both admin and myself.
I put my license back in, and reactivated it.
Then I reactivated all the users.
This time I did not get an error editing them ( as I had before ).
I am also able to log in as any user.
Aside from the creating myself ( and a user I added today testing the admin "Access Denied" error ) about ten users were created while importing the previous sourcesafe repository. It seems to me that the error is cropping up in there somewhere ( existing active users previous to a license being activated ).
Server Logs
I did check the logs, no errors were being reported. Normal status messages were, so the log is working.
I dont believe this was a systematic failure ( eg: failure to aquire the crypto subsystem ). I think it is a bug in the user handling code, and represents some sort of interaction problem between the sourcesafe import and the license activation.
I dont believe this was a systematic failure ( eg: failure to aquire the crypto subsystem ). I think it is a bug in the user handling code, and represents some sort of interaction problem between the sourcesafe import and the license activation.