将 SQL Server Express 与您的业务应用程序一起部署时，应使用什么用户来使用 SQL Server 代理服务？
我们正在使用 .NET 应用程序部署 SQL Server Express，即我们自己的 SQL Server Express 实例会在应用程序的设置过程中自动安装。
在无人值守安装过程中，可以指定用于 SQL Server 代理的用户帐户（通过命令行参数 /AGTSVCACCOUNT，该参数是非可选的）。但是，似乎所有选项要么 (a) 不可行，要么 (b) Microsoft 不推荐：
NT AUTHORITY\NetworkService和NT AUTHORITY\LocalService：这些选项域控制器不支持。 （在终端服务器环境中，我们的业务应用程序有时安装在域控制器上。我知道这不是最佳实践，但这正是我们的客户有时所做的。）NT AUTHORITY\System：微软表示：“提供本地系统帐户选项只是为了向后兼容。本地系统帐户具有 SQL Server 代理不需要的权限，请避免将 SQL Server 代理作为本地系统帐户运行。"自动创建新的本地 Windows 或域用户：我认为这不是一个可行的选择。作为用户，如果我在计算机上安装的简单业务应用程序自动创建一个新的用户帐户，我会认为这是相当具有侵入性的。无论如何，应该使用哪个密码？一些预定义的、硬编码的值（=安全噩梦）？一些新的随机密码（= 管理噩梦）？
要求用户提供或创建帐户：在许多情况下，在家庭计算机上安装软件的“简单用户”既不知道也不关心它是什么“用户帐户”，因此这也不是一个选项。不管怎样，用户为什么要为他正在安装的业务应用程序的一些内部实现细节（SQL Server 代理服务）而烦恼？
我错过了什么明显的事情吗？是否有一些关于如何解决此问题的成熟最佳实践？
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\NetworkServiceandNT AUTHORITY\LocalService: These options are not supported on domain controllers. (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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为什么您认为 SQL Server 代理帐户是静默 SQL Server Express 安装的非可选参数？我已经多次以静默方式安装 SQL Server Express，而从未指定
/AGTSVCACCOUNT选项。此外，SQL Server Express甚至不支持SQL Server Agent，即使仍然安装了SQL Server Agent服务，它也会被安装程序禁用。
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
/AGTSVCACCOUNToption.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.
为了合理选择服务应使用哪个帐户，必须能够确定服务的需求，即服务成功运行所需的 Windows 权限。了解这一点后，您就可以确定哪些服务帐户具有满足这些要求的权限集。
我不会为您提供笼统的答案，而是为您提供一些可能有助于您做出决定的信息
角色和权限
与每个帐户关联
上述内容均未涉及如何最好地处理域控制器上 SQL Server 的安装。不幸的是，这不是我很了解的领域，所以我不会冒着传播错误信息的风险试图解决这个问题。
顺便说一句，SQL Server 代理服务的目的是代表 SQL Server 运行计划作业。如果您的应用程序没有使用 SQL Server 代理支持的任何功能，您可能会考虑禁用该服务以减少 SQL Server 的表面积
我意识到这不是对所提出问题的完整答案，但我希望它有所帮助
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
of the role and permissions
associated with each account
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