We are deploying SQL Server Express with our .NET application, i.e., our own SQL Server Express instance is automatically installed during the setup process of our application.
During unattended installation, one can specify the user account that should be used for the SQL Server Agent (via the command-line parameter /AGTSVCACCOUNT
, which is non-optional). However, it seems that all options are either (a) unfeasible or (b) not recommended by Microsoft:
NT AUTHORITY\NetworkService
andNT AUTHORITY\LocalService
: These options are not supported on domain controllers. (开发者_C百科In terminal server environments, our bussiness application is sometimes installed on domain controllers. I know it's not best practice, but that's just what our customers do sometimes.)NT AUTHORITY\System
: Microsoft says: "The Local System account option is provided for backward compatibility only. The Local System account has permissions that SQL Server Agent does not require. Avoid running SQL Server Agent as the Local System account."Automatically creating a new local Windows or domain user: I don't think this is a feasible option. As a user, I would consider it quite intrusive, if a simple business application I install on my machine automatically creates a new user account. Anyway, which password should be used? Some predefined, hard-coded value (= security nightmare)? Some new random password (= administration nightmare)?
Ask the user to provide or create an account: In many cases, the "simple user" installing the software on his home computer neither know nor cares what a "user account" it, so this is not an option either. Anyway, why should the user be bothered with some internal implementation detail (the SQL Server Agent service) of the business application he is installing?
Did I miss anything obvious? Are there some well-established best practices on how to solve this issue?
Why do you think SQL Server Agent account is a non-optional parameter for silent SQL Server Express installation? I have installed SQL Server Express silently many times without ever specifying /AGTSVCACCOUNT
option.
Moreover, SQL Server Express doesn't even support SQL Server Agent, and even though SQL Server Agent service is still installed, it is disabled by the installer.
In order to make a reasonable choice about which account a service should use one must be able to determine the needs of the service with respect to what Windows permissions are required for the service to operate successfully. Once you know this, you can then determine which of the service accounts has a permission set that meets these requirements.
Rather than provide you with a broad blanket answer, I will provide you with some information that may be helpful in making your decision
- This page contains a description of the role and permissions associated with each account
- This page describes the SQL Server Agent Service and the Windows permissions it requires
None of the above deals with how best to handle the installation of SQL Server on domain controllers. Unfortunately that's not an area I know a lot about so I'll not attempt to address it at the risk of spreading misinformation.
As an aside, the purpose of the SQL Server Agent service is to run scheduled jobs on behalf of SQL Server. If your application isn't using any of the features supported by SQL Server Agent you might consider disabling the service to reduce the surface area of SQL Server
I realize this is not a complete answer to the question posed but I hope it is somewhat helpful
精彩评论