Service Account Password Change

My boss told me to change the password on our server account.

I go through our documented password change procedure, which almost
immediately fails because it's incorrect. (i.e. change password at any
desktop workstation, go to http://sharepoint/).

I call the guy that changed the password last time, and he walks me
through a hardcopy procedure that he has -- which is totally different.
(change identity on app pool, change logon account for SP related
services) Everything seemed to come up, except when I search, I get an
error: "Your search encountered an error. If the problem persists,
contact the portal site administrator."

If I go into site settings, and pick "Configure Search and Indexing", I
get the error: "The gatherer index was not initialized. The content
index must be remounted. If the index is still not initialized, remove
it."

When I use Sharepoint Central Administration to try and change any
setting, I get this error: "Error accessing database. Verify that the
database server name and the instance name (if present) are correct.
Also, ensure the configuration database administration account has
sufficient permissions on the server or instance and the service
corresponding to your SQL Server instance is running."

If I go through event logs, I can see username/password errors: "The
gatherer object cannot be initialized. Context: http://oxynet.oxy.com/
Application, ProfileImport Catalog Details:
Logon failure: unknown user name or bad password. (0x8007052e) For more
information visit
http://www.microsoft.com/servers/redirect/contentredirect2.asp For more
information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp."

If I look at logs (Sharepoint Central Administration > Sharepoint
Portal Server > Configure Diagnostic Settings > xxxxx_SPSADMIN.LOG) I
see this line, repeatedly: "04/07/05 18:14:13:578 UNK 00000000 00000C9C
Exception in GetBlobFromCurrentState: System.InvalidOperationException:
Cannot get virtual server configuration at
Microsoft.SharePoint.Portal.Topology.PortalSite.a(a A_0)" although I
don't believe that it's related.

This was working fine before I changed the password. I screwed up our
SharePoint Portal server farm, and I haven't been able to find any
useful messages on how to fix it, although I think I've seen a couple
people who had a similar problem and ended up reinstalling.
Reinstalling will get me yelled at.

I've been wanting to "Configure the server farm account settings", but
this generates the above-mentioned "Error Accessing Database" message.

I used STSADM to change the content database, username, and password
but it didn't accomplish anything. (those settings were blank, so I
don't think STSADM uses the "real" settings for that).

If anybody knows something, I'd sure appreciate the help. I'm lost.
I've gone through the SharepointPSAdmin.chm.

ParagSinkar
Thu Apr 07 19:17:02 CDT 2005

did u check SQL Server Account Password?

Thanks

"joshua_jacobsen@oxy.com" wrote:

> My boss told me to change the password on our server account.
>
> I go through our documented password change procedure, which almost
> immediately fails because it's incorrect. (i.e. change password at any
> desktop workstation, go to http://sharepoint/).
>
> I call the guy that changed the password last time, and he walks me
> through a hardcopy procedure that he has -- which is totally different.
> (change identity on app pool, change logon account for SP related
> services) Everything seemed to come up, except when I search, I get an
> error: "Your search encountered an error. If the problem persists,
> contact the portal site administrator."
>
> If I go into site settings, and pick "Configure Search and Indexing", I
> get the error: "The gatherer index was not initialized. The content
> index must be remounted. If the index is still not initialized, remove
> it."
>
> When I use Sharepoint Central Administration to try and change any
> setting, I get this error: "Error accessing database. Verify that the
> database server name and the instance name (if present) are correct.
> Also, ensure the configuration database administration account has
> sufficient permissions on the server or instance and the service
> corresponding to your SQL Server instance is running."
>
> If I go through event logs, I can see username/password errors: "The
> gatherer object cannot be initialized. Context: http://oxynet.oxy.com/
> Application, ProfileImport Catalog Details:
> Logon failure: unknown user name or bad password. (0x8007052e) For more
> information visit
> http://www.microsoft.com/servers/redirect/contentredirect2.asp For more
> information, see Help and Support Center at
> http://go.microsoft.com/fwlink/events.asp."
>
> If I look at logs (Sharepoint Central Administration > Sharepoint
> Portal Server > Configure Diagnostic Settings > xxxxx_SPSADMIN.LOG) I
> see this line, repeatedly: "04/07/05 18:14:13:578 UNK 00000000 00000C9C
> Exception in GetBlobFromCurrentState: System.InvalidOperationException:
> Cannot get virtual server configuration at
> Microsoft.SharePoint.Portal.Topology.PortalSite.a(a A_0)" although I
> don't believe that it's related.
>
> This was working fine before I changed the password. I screwed up our
> SharePoint Portal server farm, and I haven't been able to find any
> useful messages on how to fix it, although I think I've seen a couple
> people who had a similar problem and ended up reinstalling.
> Reinstalling will get me yelled at.
>
> I've been wanting to "Configure the server farm account settings", but
> this generates the above-mentioned "Error Accessing Database" message.
>
> I used STSADM to change the content database, username, and password
> but it didn't accomplish anything. (those settings were blank, so I
> don't think STSADM uses the "real" settings for that).
>
> If anybody knows something, I'd sure appreciate the help. I'm lost.
> I've gone through the SharepointPSAdmin.chm.
>
>

joshua_jacobsen
Thu Apr 07 19:31:09 CDT 2005

It's the same service account that I'm using for everything else. I
don't know how to set that, without going through the SPS Central
Admin. If you know a way for me to reset that, I'd appreciate it!
Thanks for the reply.

joshua_jacobsen
Wed Apr 13 16:36:08 CDT 2005

Well, as an update... We managed to get our portal semi-working again,
by going to the active directory administrators and getting my service
account password changed back to the previous password. I then
reversed all of the password-change procedure. This, of course,
doesn't address the fact that our password change procedure sucks and
will kill us, and that we'll have a portal outtage every time our SOX
requirements kick in.

joshua_jacobsen
Wed Apr 20 14:42:06 CDT 2005

We ended up rebuilding the server. Our Microsoft reps never got back
to us. Our consultant really tried to get us working again, but
couldn't. We went to tape backups, which didn't resolve the problem
(?!). Our best (admittedly weak) theory at this point is that a GPO
caused a problem, and SharePoint corrupted itself trying to deal with
it. Or cosmic rays. Or aliens.

joshua_jacobsen
Tue May 10 13:52:34 CDT 2005

For anybody with similar problems, we encountered the problem again,
and Microsoft Technical Support worked us through it. I guess we got
better guys this time around. It isn't an easy fix, however, and I
think it's a bit risky. I'll summarize it, but I'm a bit lazy, and
hope that anyone who needs this info will have enough administrative
experience to follow me. You can email me, if I'm not being explicit
enough.

First, clean up your passwords.

On each server in your farm, go into IIS Administration, and check the
properties of all your SharePoint-related app pools. On the identity
tab, re-enter your current password and apply. Recycle all of your app
pools to make sure everything is using the good credentials. Open the
Services MMC, and look for the four SharePoint services. These are
"Microsoft SharePointPS Search", "SharePoint Portal Administration",
"SharePoint Portal Alert", and "SharePoint Timer Services". Open the
properties for each one of these. Under the "Log On" tab, set the
password to your current password. On the "General" tab, stop and
restart the service.

Tedius, eh?

Next, tear apart your SharePoint Topology and scrap the Config
Database.

Go into sharepoint central administration, under the SharePoint Portal
Server section, and manage the topology. Select "Change Components"
and removed every server from every role, and set the Job Server to
none.

Next, delete the portals (but do not delete the content databases, when
given the choice).

Detach from the config database in SharePoint Central Administration
and deleted the config database on the SQL Server.

Sweet. Now rebuild it.

SharePoint will force you to recreate the config database. You should
be able to use the same name, if you like. Next, recreate the portal
sites, attaching to the still-existing content databases. Last, go
into the topology and select the original roles for each server.

That's it... resolved the database error for us.

"Error accessing database. Ve rify that the database server name and
the instance name (if present) are correct. Also, ensure the
configuration database administration account has sufficient
permissions on the server or instance and the service corresponding to
your SQL Server instance is running."

PlugnPlay
Thu May 12 10:41:52 CDT 2005

Just had to do this today as well, after multiple password lockouts. I
went through the services and changed the password, went through the
app pools and changed the passwords, when I got to the sharepoint admin
site, i experienced the same problems as you. I found that in sql
enterprise, the sharepoint domain account didnt have the database admin
role - I ticked the box, rebooted the server twice and hey presto, no
more lockouts. I could then go into the sharepoint admin site and
change the passwords as needed. everything now seems to be working
okay, its a dev environment anyway, so ho hum
Our dev environment is a domain member server running sharepoint portal
server 2003 and sql 2000 on the same box

hope this helps someone

cheers

matt


joshua_jacobsen@oxy.com wrote:
> For anybody with similar problems, we encountered the problem again,
> and Microsoft Technical Support worked us through it. I guess we got
> better guys this time around. It isn't an easy fix, however, and I
> think it's a bit risky. I'll summarize it, but I'm a bit lazy, and
> hope that anyone who needs this info will have enough administrative
> experience to follow me. You can email me, if I'm not being explicit
> enough.
>
> First, clean up your passwords.
>
> On each server in your farm, go into IIS Administration, and check
the
> properties of all your SharePoint-related app pools. On the identity
> tab, re-enter your current password and apply. Recycle all of your
app
> pools to make sure everything is using the good credentials. Open
the
> Services MMC, and look for the four SharePoint services. These are
> "Microsoft SharePointPS Search", "SharePoint Portal Administration",
> "SharePoint Portal Alert", and "SharePoint Timer Services". Open the
> properties for each one of these. Under the "Log On" tab, set the
> password to your current password. On the "General" tab, stop and
> restart the service.
>
> Tedius, eh?
>
> Next, tear apart your SharePoint Topology and scrap the Config
> Database.
>
> Go into sharepoint central administration, under the SharePoint
Portal
> Server section, and manage the topology. Select "Change Components"
> and removed every server from every role, and set the Job Server to
> none.
>
> Next, delete the portals (but do not delete the content databases,
when
> given the choice).
>
> Detach from the config database in SharePoint Central Administration
> and deleted the config database on the SQL Server.
>
> Sweet. Now rebuild it.
>
> SharePoint will force you to recreate the config database. You
should
> be able to use the same name, if you like. Next, recreate the portal
> sites, attaching to the still-existing content databases. Last, go
> into the topology and select the original roles for each server.
>
> That's it... resolved the database error for us.
>
> "Error accessing database. Ve rify that the database server name and
> the instance name (if present) are correct. Also, ensure the
> configuration database administration account has sufficient
> permissions on the server or instance and the service corresponding
to
> your SQL Server instance is running."

joshua_jacobsen
Thu May 12 15:56:30 CDT 2005

Wow, that sounds a lot easier than my fix. Kudos! Unfortunately, in
my environment, I can't have Database Admin access for my service
accounts. The DBA's are unhappy with the Security Administrator,
Process Administrator, and Database Creator roles that I'm already
using.