http://www.whitworth.org/Blog/PermaLink,guid,f0c3c8b0-bfb8-4796-b130-dcc7175ce2e4.aspx

I 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 DomainUser -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:

1. Recreate each web application and reattach the existing content database.
2. Recreate the Shared Services Provider web application and reattach that database.
3. 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:

1. Ensure the WSS Administration and WSS Timer services are running on all machines.
2. On machine with central admin (WFE1)
   1. stsadm -o updatefarmcredentials -userlogin "domain user" -password "newPassword"
   2. iisreset /noforce (optional)
3. 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)
   1. stsadm -o updateaccountpassword -userlogin "domain user" -password "newpassword" -noadmin

Otherwise, after a password change:

1. Go to the server central admin box:
   1. run the command stsadm -o updatefarmcredentials -userlogin <domain
      ame> -password <newpassword>
2. User must run IISReset /noforce to complete the action.
3. Delete the updatefarmcredentials timer job on central admin page->operations->job definitions page
   1. Go to each other server in the farm, and run the command:
      1. stsadm -o updatefarmcredentials -userlogin <domain
         ame> -password <newpassword> -local. 

      2. If -local isn't supplied, it will fail because step (4) created a timer job that locks creating OTHER timer jobs.
4. 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)
   1. 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 <domain
ame> -password <password>

     Other AppPools

Stsadm -o updateaccountpassword -userlogin <domain
ame> -password <password> [-noadmin]

Use -noadmin if the Central Admin AppPool is the same account as other Web AppPools

We have a SharePoint farm consisting of 3 Front-ends, 1 Index server, and Cluster SQL 2005.  The 3 Front-ends are using Microsoft NLB  (WHICH IS EVIL BY THE WAY)!  Anytime we got high usage on the front-ends we were slammed with "Server is not Operational" in the Application event log.  Since the SharePoint site is using Forms Authentication we originally thought it was a problem with the LDAP provider.  But couldn't make the case for that.  After extensive searching my colleague found an older article about TCP wait time.  Here is the link to that article.

http://www.port80software.com/200ok/archive/2004/12/07/205.aspx

It appears what was happening is that with all the flooding that happens with MS NLB it was causing issues with the connection the AD during heavy use periods.  My colleague made this change on each front-end:

You must add the Tcp TimedWaitDelay REG_DWORD value to the HKEY_LOCAL_MACHINE
SYSTEMCurrentControlSetServices TcpipParameters
registry subkey. Then, you set the delay to the number of seconds (in decimal
form):

Value Type: REG_DWORD--  Time in secondsValid Range: 30-300 (decimal)Default: 0xF0 (120 decimal)

http://windowsitpro.com/article/articleid/23276/the-time_wait-states-effect-on-iis-performance.html

This decreased the wait time reset value from 4 minutes to 2 minutes.   

 After monitoring the system for a couple of days, Whala!  No more errors.

I sure hope this helps someone else out there! 

We are having some very strange permissions problems with one of our customers.  First off all of the document libraries, and
lists in the entire Site Collection and sub sites do not show the Settings
Button menu.  You can still get to the
settings through all Site Settings, Site Administrations and then Customize the
the Content. 

As well when going to a doc lib or list the "Edit
Page" under site actions are missing.

I have also tried to just check out any of the pages in
the Master Page Gallery and receive and "ACCESS DENIED" page. 

We have tried several different users all having Site
Admin, Designers, Full Control permissions. 
I have even checked to ensure that there are no unique permission set on
these lists or doc libs. 

I also created a new sub site with Unique permissions and
still have the same issues.  Appears to
be something with Web Application but I can't find what the problem is.

************************  UPDATE  ************************************

Oh what an idiot I am.  Never occurred to me to look in the most obvious place.  

Check what you currently have as
the' User Permissions for the Web Application' by going to Central
Administration -> Application Management (for the pertinent Web Application)
-> User Permissions for Web Application (Under Application Security
Category) and see if all permissions here are checked. If not, they will not
filter down to any of the Site Collection permissions.

Problem:=========After Installing few Windows server 2003 updates, SharePoint Portal administration service was not starting on all Sharepoint servers. Environment:===========

Sharepoint Portal server 2007

Medium server farm  Root Cause (if known):==================NA Resolution:=========We changed following registry settings on the Sharepoint servers:  Added:HKLMSYSTEMCurrentControlSetControl change DWORD value ServicesPipeTimeout and assign 60000 (i.e. 60 thousand which means 60 seconds) Modified:Increse value of in HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl string value WaitToKillServiceTimeout to 120000 (120 thousand which means 120 seconds) We rebooted the server.We found that Sharepoint portal Administration service is running fine on the server.

We did the same changes/additions on other two Sharepoint servers as well and the service started running o them as well a