Changing SQL and Agent Service account?

Are there any best practices recommending changing the SQL Server/Agent
domain service account password? I assume you do not want to leave these
the same forever after install, and I have a service pwd change utility
without restarting SQL server, but not seeing a lot of talk about changing
these account(s). Should they not change just like any other priveledged
user?"Brian" <bpollard@.idahodba.org> wrote in message
news:OCqXZ8KdEHA.3016@.tk2msftngp13.phx.gbl...
> Are there any best practices recommending changing the SQL Server/Agent
> domain service account password? I assume you do not want to leave these
> the same forever after install, and I have a service pwd change utility
> without restarting SQL server, but not seeing a lot of talk about changing
> these account(s). Should they not change just like any other priveledged
> user?
>
If you change these accounts it is probably easiest to do so through
Enterprise Manager. If you have not read the following paper, I recommend
it:
http://www.microsoft.com/technet/pr...n/sp3sec02.mspx
while it does not make any firm recommendation on account/password changes,
this really should default (IMO) to whatever policy is in place in the
domain. More importantly, follow the recommendation of using a "service"
account that is not local system and is not an administrator on the server.
Steve|||I guess this all depends upon your Security Policy that you have in place.
The service accounts should be running under a low privilege domain acount
and should be changed
based upon the password expiration you've set for other domain accounts.
So, yes I believe they should be changed.
Typically, you modify the account within SEM, but here's an article on how
to do it outside of SEM.
283811 How to change the SQL Server or SQL Server Agent Service account
without
http://support.microsoft.com/?id=283811
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.

Changing Default SQL ports on SQL 2000 Server

Hi Group,
As part of best practices we would like to change the default port number
that SQL Server 2000 listens on.
Once this has been done, can the application client dynamically determine
the new port number using the SQL Server Reporting Service listening on udp
1434?
Please note that Named Pipes are being used to establish the connections and
that there is a firewall between the SQL Server and the
applications clients.
Regards
CMHi,
Just change the port via the SQL Server Network Utility. On the client
open the Client Network Utility and create a TCP/IP based alias that
dynamically determines the port. The client will then use port 1434 to
determine which port it needs to use. Make sure that your firewall has
both port 1434 and the port the SQL Server instance is listening on open.
Jonathan
CP wrote:
> Hi Group,
> As part of best practices we would like to change the default port number
> that SQL Server 2000 listens on.
> Once this has been done, can the application client dynamically determine
> the new port number using the SQL Server Reporting Service listening on ud
p
> 1434?
> Please note that Named Pipes are being used to establish the connections a
nd
> that there is a firewall between the SQL Server and the
> applications clients.
> Regards
> CM
>|||Hi Jonathan,
Thank you for your response. Can I still do this (creating the TCP/IP based)
if I am using Named Pipes as my connector on the client?
I have read a post somewhere that Named Pipes cannot dynamically determine
destination SQL port numbers in SQL Server 2000.
Regards
CM
"JPD" wrote:

> Hi,
> Just change the port via the SQL Server Network Utility. On the client
> open the Client Network Utility and create a TCP/IP based alias that
> dynamically determines the port. The client will then use port 1434 to
> determine which port it needs to use. Make sure that your firewall has
> both port 1434 and the port the SQL Server instance is listening on open.
> Jonathan
>
> CP wrote:
>|||Hi,
In your case you need to do nothing on the clients. Named Pipes on the
client will be able to negotiate a connection with the server.
Jonathan
CP wrote:[vbcol=seagreen]
> Hi Jonathan,
> Thank you for your response. Can I still do this (creating the TCP/IP base
d)
> if I am using Named Pipes as my connector on the client?
> I have read a post somewhere that Named Pipes cannot dynamically determine
> destination SQL port numbers in SQL Server 2000.
> Regards
> CM
> "JPD" wrote:
>|||Hi Jonathan,
Thank you again for your reply.
I am a bit confused here, as I had the understanding that Named Pipes and
TCP/IP were two different connectivity mechanisms and that if Named Pipes ar
e
used in SQL 2000, the connections will fail if the default port is changed a
s
Named Pipes in SQL 2000 cannot dynamically determine destination port number
s.
Regards
CM
"JPD" wrote:

> Hi,
> In your case you need to do nothing on the clients. Named Pipes on the
> client will be able to negotiate a connection with the server.
> Jonathan
>
>
> CP wrote:
>