I had this exact same problem below and copied the post to here for further reference. Click here for the origianl post:
http://www.whitworth.org/Blog/PermaLink,guid,f0c3c8b0-bfb8-4796-b130-dcc7175ce2e4.aspxI was recently installing WSS 3.0 on a SQL Reporting Services server to prepare it for Sharepoint Integrated Mode and got an error similar to the following at the end of the Sharepoint Technologies Configuration Wizard:
Error during encryption or decryption. System error code 997
After reading the article included below, I realized our problem was that we changed the sharepoint service account password nearly a month ago. Everything still appeared to be working fine, but when I went to join a new server to the farm it was still trying to receive the incorrect credentials that were cached. In a nutshell, you have to run stsadm -o updatefarmcredentials on the central admin server (with the correct parameters below) and then also update the credentials on the server that failed to join, then go back and do one more update on the central admin server. I also disconnected it from the farm and reconnected it after the failure.
I found the following
article on the Centricity Web Site. My apologies for the direct copy, but this was useful info I did not want to lose.
I was adding a secondary web front-end to their already existing Production MOSS 2007 Farm for one of my clients. The MOSS 2007 RTM software was installed using the "Complete" option ("Web Front-end" only option was tried as well with the same results) on a newly created server.
Each time I attempted to run the "SharePoint Products & Technology Configuration (SPTC)", I received the an error stating to the server could not be added and that I should review the PSC_Diagnostics.log file. The actual error is shown below.
Most Common Advice is not always the "Best Advice"
The error code (997), as well as a number of SharePoint professionals, pointed me to a Knowledge Base Article (
http://support.microsoft.com/kb/927156)
This article simply says to recreate you configuration database, using the following command line.
psconfig -cmd configdb -create -server ServerName -database ConfigDBName -user Domain\User -password Password
Expected Outcome
By doing this, expect to loose time and everything but content. You will have to do the following to properly recover:
Recreate each web application and reattach the existing content database.
Recreate the Shared Services Provider web application and reattach that database.
Re-add each web front-end and application server to the farm.
Research Found
Jukka Paajanen [MSFT] on EggheadCafe associates the error code (997) with a few other issues and provides the problem. He says the issues are:
the error number is 997
have standalone install (or have configured your farm with account that has no password or the account password changed)
one of the SharePoint services used an account that has password (web app, services)
are reinstalling,
The Problem, he states is "the existing configdb has old references to passwords that it cannot decrypt."
His Solution was to do the same as above.
Better Solution
Well, my problem is fixed and I did not recreate my configdb. It is much simpler. At the time this article was written no one other than Jukka had made the association between changing passwords and the error code (997). This lead me to look into resetting farm credentials, which led me this article by Joel Oleson
Joel Oleson outlines the process in detail:
----------------------------
If you know the password before the password change, you can do the following to your machine with WSS on it:
Ensure the WSS Administration and WSS Timer services are running on all machines.
On machine with central admin (WFE1)
stsadm -o updatefarmcredentials -userlogin "domain user" -password "newPassword"
iisreset /noforce (optional)
On any machine after this completes (wait for the "Administration Application Pool Credential Deployment" job definition to go away on the Timer Job Definitions central admin page)
stsadm -o updateaccountpassword -userlogin "domain user" -password "newpassword" -noadmin
Otherwise, after a password change:
Go to the server central admin box:
run the command stsadm –o updatefarmcredentials –userlogin
-password
User must run IISReset /noforce to complete the action.
Delete the updatefarmcredentials timer job on central admin page->operations->job definitions page
Go to each other server in the farm, and run the command:
stsadm –o updatefarmcredentials –userlogin -password -local.
If –local isn’t supplied, it will fail because step (4) created a timer job that locks creating OTHER timer jobs.
On any machine after this completes (wait for the "Administration Application Pool Credential Deployment" job definition to go away on the Timer Job Definitions central admin page)
stsadm -o updateaccountpassword -userlogin "domain user" -password "newpassword" -noadmin
More verbose Instructions from MSIT. Note these are not really polished, but a have some integrated tips that should be of value.
Password Changes
WSS WFEs
Central Admin AppPool (First)
Stsadm –o updatefarmcredentials –userlogin -password
Other AppPools
Stsadm –o updateaccountpassword –userlogin -password [-noadmin]
Use –noadmin if the Central Admin AppPool is the same account as other Web AppPools
Posts
