我们为客户开发了一款在 Windows Server 2019 上运行的 SQL Server(2019) 备份软件。
该应用程序 (.net Windows Forms) 有一个界面，用于配置备份（例如选择备份日期、每天的备份时间等）和其他配置（数据到 SMTP 服务器、邮件分发列表等）。此外，客户端还包含恢复数据库的功能。备份通过计时器启动。
该应用程序运行良好，但必须 24/7/365 全天候运行。
问题描述：
该应用在客户服务器上运行，而客户不允许密码永不过期的帐户。
此外，服务器每两周至少自动重启一次。所以……我们必须至少每两周访问一次服务器并重新启动客户端，这可不太好。
因此，我们考虑将备份App“拆分”为两部分：
- Windows 客户端（已停用备份和电子邮件功能）
- Windows 服务（启动时读取配置文件、进行备份、发送电子邮件）
=> 目标：服务器重启后自动启动备份服务（无需手动启动）。
需求：
服务需要访问本地磁盘（读取 (.ini) 配置文件、存储备份）、SQL 服务器（安装在同一台服务器上）和 SMTP 服务器（位于另一台客户服务器上）才能发送电子邮件。
如上所述，目标是使用“系统帐户”没有密码（必须定期更改）。
我们是开发人员，不是系统工程师……因此“初始问题”是：
据我们所知，有系统帐户“本地系统”、“本地服务”和“网络服务”（可能还有更多...）。
问题：
上述帐户中的一个是否拥有所有需要的权限（或者是否有另一个）？
谢谢！
答案1
是的，您绝对需要将交互式“配置”和“服务”部分分开。服务部分需要一直运行，而配置部分则只在需要时运行。
如今，让应用程序在 Windows Server 的“控制台”上运行的想法充其量是麻烦的，而且随着 Windows 的每个版本的推出，难度都会越来越大。我制作了 20 年后仍在生产的 Windows 服务，我有点惊讶您在开发和测试期间没有遇到这个“挑战”。
但不管怎么说 ...
该应用程序在客户服务器上运行，客户不允许密码永不过期的帐户。
鉴于 Windows 支持许多密码永不过期的“系统”帐户，这对您的应用程序来说是一个奇怪的“要求”。
问题：这个“要求”实际上相关的?
要使用“配置”应用程序，您需要登录机器，因此您需要使用为此目的提供的任何凭据 - 那些交互式、用户特定的凭据应该定期到期。
“服务”部分应该只是运行和执行操作。
如果这些系统帐户的密码过期，Windows 生态系统将完全无法使用。
该服务需要访问本地磁盘（读取（.ini）配置文件，存储备份）...
是的，绝对如此。
任何“服务”帐户都应具有此级别的访问权限。
... 以及 SMTP 服务器... 以便能够发送电子邮件。
要访问“盒子外”的任何内容，需要网络感知帐户。
网络服务可能是您的最佳选择。
... 到 SQL 服务器 (安装在同一台服务器上）...
危险，威尔罗宾逊！
你真的是在说你的“备份”实用程序正在占用并储存SQL Server 备份同一台机器作为 SQL Server 实例本身？
这会破坏你的整个解决方案。
如果你丢失了运行 SQL Server 的计算机，那么你也会丢失备份您的数据库，并且由于仅有的备份存在的原因是为了保证无论发生什么情况你都可以恢复数据库什么如果出现严重、严重的错误，那么你的“备份解决方案”将完全被破坏。
你绝对地必须将备份从该服务器转移到另一台机器上，远离来自他们正在保护的数据库。