Open and use a Web Part Maintenance Page

If you encounter problems with a Web Part or Web Part connection on your Web Part Page, you can use the Web Part Maintenance Page to help isolate and fix your problem. You must have the appropriate Web Part, Web Part Page, or Web Part zone permission to use the Web Part Maintenance Page.

Tip: If you are not sure which Web Part or Web Part connection is causing a problem on your Web Part Page, it is a good idea to work in a step-by-step fashion by closing one Web Part at a time and then browsing through the Web Part Page (click Go Back to My Web Part Page) to see if that fixes the problem. After you identify the problem Web Part, you can consider resetting or deleting it.

1. Open the document library that contains the Web Part Page.
2. Point to the name of the Web Part Page, click the arrow that appears, and then click Edit Properties.
3. Click Open Web Part Page in maintenance view to display the Web Part Maintenance Page.
4. Verify that you are in the view that you want, either a personal view or shared view. If you need to switch views, do one of the following:

• If you are in a personal view and you want to switch to a shared view, click Switch to shared view.
• If you are in a shared view and you want to switch to a personal view

5. Select one or more Web Parts, and then do one of the following:

• To move a Web Part to the Web Part Page gallery, click Close.
• To remove personal property values and revert to the shared property values of the Web Part, click Reset. You are prompted for confirmation before resetting a Web Part.
• To permanently delete a Web Part from the Web Part Page, click Delete. You are prompted for confirmation before deleting a Web Part.

It is possible to have permission to delete a Web Part in a shared view but not in a personal view.

6. When you finish, click Go Back to Web Part Page.

Tip: To access the Web Part Maintenance Page for a Web Part Page that is not stored in a document library, such as the site home page, append ?content=1 to the end of the URL for the page.

Note: You cannot use the Web Part Maintenance Page to close, reset, or delete a static Web Part (that is, a Web Part outside a Web Part zone). To maintain a static Web Part, you must use a Web design program that is compatible with Microsoft Windows SharePoint Services, such as Microsoft Office SharePoint Designer 2007.

How to change user accounts that run MOSS Services & App Pools

As part of implementing some improvements to a client's MOSS Enterprise site that I'd recently recommended they undertake, I had to change the accounts that were being used in their environments to ones that were independent from each environment. I've been caught too many times by a developer doing some development who manages to miss-key the AD User's password into a config file / registry key. The app being developed is then fired up and promptly locks the account out. At the same time, another unrelated system in another part of the building stops working. Why? Because the same AD Account was used in critical aspects of both systems.

Never Ever Use The Same Accounts to Run Your Development And Production Environments!!!

Anyway, they got me back to make this change because it can be tricky. Sure enough, it was. The biggest challenge when making wholesale changes to the service / app pool accounts is that if the farm account update fails to work properly, you then struggle to perform the rest of the changes because the security decryption keys MOSS uses to keep a track of passwords is corrupted. Oh man!
So I fired off the first change and waited... and waited... the WWW Publishing service failed to shut down properly, so after 20 minutes I figured I'd reboot the server and try it again (looking back, I may have saved some time by using pskill to terminate the process instead of rebooting, but it would have resulted in the same issue). Then in the event log, I started to see a proliferation of these error messages - "Error during encryption or decryption. System error code 997" and "An unhandled exception occurred in the user interface.Exception Information: Unable to connect to the remote server"
Once in this precarious position, Microsoft's recommended solution - for the closest example of something that comes close to the error message - is to rebuild the config database (http://support.microsoft.com/kb/927156) - but it's not much help onsite at a client's place... luckily there are some alternatives. Once the Farm account is half-changed, you cannot successfully change the rest of the accounts through the UI... but stsadm is the answer. Joel has the information on this page - http://blogs.msdn.com/joelo/archive/2006/08/22/712945.aspx
Just like using a sledgehammer to swat a fly, stsadm is not encumbered by a user interface or any of those nice-to-have things - it seems to be built around the premise "If it doesn't work, force it. If it breaks, it needed reinstalling anyway!" :)

So with stsadm, I went through the following steps:

First, to fix the central admin account's decryption key used to drive the app pools, complete the following on the server running the Admin site -
From the bin directory, run

Stsadm –o updatefarmcredentials –userlogin -password

You may need to then run iisreset /noforce.
You will have to remove the "Administration Application Pool Credential Deployment" job that gets created using the timer job definitions page (otherwise it will prevent you from progressing through the next steps).
Then to update the other moss site app pools -

Stsadm –o updateaccountpassword –userlogin -password

If you happen to use the same account to drive the admin site and the web site(s) (naughty) then you will need the noadmin switch eg

Stsadm –o updateaccountpassword –userlogin -password [-noadmin]

On each other server in the farm, you will need to perform the following steps -
As each server stores an encrypted version of the admin account password, you will also need to execute the following command for the account used to run the admin app pool -

stsadm –o updatefarmcredentials –userlogin -password -local

The Web site app pools for the non-admin sites should take care of themselves, but if not then just use the "UpdateAccountPassword" feature on the server to resolve the issue.

Then you will need to fix the SSP's...
From the server running the SSP you need to run the following command for each SSP that uses credentials to operate (like ECS and FS), except for the search services (they're next) -

stsadm -o editssp -title -ssplogin -ssppassword

You then run the following commands for the search services

stsadm -o osearch -farmserviceaccount -farmservicepassword
and...
stsadm -o spsearch -farmserviceaccount -farmservicepassword

You may now need to go into the search service section of the UI and change the indexing and crawling accounts if required.
Lastly, the SSO Service has to be changed using the Services Applet in the Administration Control section of the server it runs on.
At this point, an IISReset is probably a good idea (a reboot is an even better idea) - once this is done, attempt to access each affected area of the farm and verify that they are all now functioning correctly. If you still see some issues, use the relevant part of this guide to try and reset the credential information. Eventually (after 4 attempts) I moved past the first set of steps to change the Admin site app pool account - the rest was plain sailing from there.
Source: http://sharepointblog.spaces.live.com