The ITea Guy's questions

环境：Server 2019 域控制器。

我有一个简单的脚本，可以梳理我的 AD 用户并禁用过去 35 天内未登录的任何人（组织策略）。看起来像这样：

Get-ADUser -Filter * -Properties Name,Lastlogontimestamp,PasswordNeverExpires | Where-Object {([datetime]::FromFileTime($_.lastlogontimestamp) -le (Get-Date).adddays(-35)) -and ($_.passwordNeverExpires -ne "true") } | Disable-ADAccount

如果我手动运行它，它会起作用 - 遍历整个过程，找到 35 天以上未使用过的人并将其关闭。

我最初尝试使用 Task Scheduler 直接调用此脚本，但它不起作用 - 任务将永远“运行”但脚本永远不会执行，因为我知道尚未使用的用户帐户（这是一个得到在手动运行中标记并且我重新启用以测试预定版本）不会重新禁用。

我尝试修改脚本以关闭执行策略（然后在最后重新打开），但这也无济于事。

我确实找到了对我有一点帮助的指南： https ://community.spiceworks.com/how_to/17736-run-powershell-scripts-from-task-scheduler

我没有调用脚本，而是调用 powershell，然后将 Set-ExecutionPolicy Bypass 和脚本的位置（现在位于 C:\ 上）传递给它。这是一个轻微的改进，因为虽然脚本仍然没有实际运行（晴雨表帐户没有再次禁用），但任务最终停止并声称它成功运行（0x1 代码）。

凭据对于它运行的域管理员帐户是正确的，并且它被设置为以最高权限运行（无论我是否登录，尽管我在测试这个的整个过程中都登录了）。

我不知所措——每个单独的元素似乎实际上都在“工作”——脚本完全起作用，调度程序执行并“完成”——但组合产品却没有。

我哪里错了？我在使用批处理文件时没有遇到过类似的问题，所以我怀疑在使用 PowerShell 执行此操作时我忽略了另一个因素。

一段时间以来，我们的漏洞扫描器一直在我们的一台服务器和一个管理工作站上检测到过时的 .NET 组件；这与我们最近在其上部署的一些软件有关。但是，我解决此问题的任何尝试都没有解决此问题，包括据称导致解决方案的发现本身的链接。

发现声称：

    Path              : C:\Program Files\dotnet\shared\Microsoft.NETCore.App\3.1.22\
      Installed version : 3.1.22
      Fixed version     : 3.1.30

显然，这甚至比我们的安装日期晚了好几个月，这很令人烦恼。给出的解决方案的链接是这样的：

https://dotnet.microsoft.com/en-us/download/dotnet/3.1

我上次尝试修复时，版本 3.1.29 仍然是最新的，并且明显的补丁都不起作用。即使尝试在该页面上安装每个 x64 版本，我也无济于事（事实上，其中一个 x64 安装程序实际上在 x86 文件路径中引入了一个漏洞）。我已经在我们的 WSUS 中推送了一个与此相关的 KB - KB5019349 - 但即使这样也只是卡在“错误 0x80244019”中。

我怀疑这个更新比我理解的要多。我到底应该如何更新这个文件，我从哪里获得真正的更新，以及它应该如何部署？

在 Windows Server 2019 上使用 MS SQL Server 2019，我正在尝试做一些非常简单的事情：运行 SQL Server 安装中心实用程序中的“已安装的 SQL Server 功能发现报告”工具。

但是，即使我在管理员组中并且无论我是否以管理员身份运行安装中心，都会弹出：

TITLE: SQL Server 安装失败。

SQL Server 安装程序遇到以下错误：

访问被拒绝。

如需帮助，请单击：https ://go.microsoft.com/fwlink?LinkID=20476&ProdName=Microsoft%20SQL%20Server&EvtSrc=setup.rll&EvtID=50000&EvtType=0xC5001868%25400xDC80C325

纽扣：

好的

日志中似乎没有任何内容表明权限失败，不幸的是，该 URL 似乎导致了 Surface 平板电脑的推销。谷歌搜索事件 ID 导致我发现我应该卸载的东西： https ://docs.microsoft.com/en-us/sql/relational-databases/errors-events/sql-server-native-client-error-mssqlserver- 50000?view=sql-server-ver15

这太过分了。

SQL 本身运行良好；除了机器上的管理员之外，我还需要其他一些权限来运行这个工具吗？

我遇到的问题是，如果我将两个可写域控制器之一脱机，似乎没有人会像他们应该的那样“故障转移”使用另一个域控制器 - 我们在网络中运行的应用程序使用 AD 进行身份验证只是不断询问用户名和密码，而从未真正对您进行身份验证，并且依赖于另一个网段上的只读 DC 的外部用户也无法对我们的远程访问网站进行身份验证。

我的域中目前有三个域控制器：DC1、DC2 和 RO1。DC1 和 RO1 是 Server 2019，DC2 是 Server 2012R2。两个可写 DC 都是集成了 AD 的 DNS 服务器，它们的网络适配器配置为相互指向。

DC1 和 DC2 位于同一子网上。RO1 是位于不同网段的只读控制器，以支持由我上方的组织（管理我连接到的通用网络）管理的远程访问解决方案。

过去，如果我让一个或其他本地 DC 脱机，本地用户将故障转移到实际仍在运行的任何一个（如预期的那样），远程用户也会如此，因为 RODC 会获取活动的 DC 进行身份验证。

当前的 DC1 是一个相对较新的添加，取代了一个称为 DC 的。DC1 上线并与 DC 和 DC2 一起加入，一切似乎都很好。我将 DC 拥有的所有 FSMO 角色转移到其替代品 DC1 - netdom 查询 fsmo 显示所有角色都在新的 DC1 上。我们将 DC 降级并使其下线以使其退役，因为它是一台 Server 2012 机器，我们正在从这些机器迁移。清理了一些错误的 DNS 记录，这些记录声称旧的 DC 仍然存在，但除此之外，一切都照常进行。虽然上个补丁周期，我们让 DC2 离线，而 DC1 和 RO1 仍然处于活动状态，但发现了上述与身份验证相关的问题。外部用户根本无法进行身份验证，

不幸的是，我不确定这是为什么。DC1，新的控制器，肯定被域所识别。复制正常 - Repadmin /showrepl 成功，并且 /replsum 没有报告错误。所有涉及的内部机器都可以解析它们的主机名并相互ping通。如果我 ping 域，我可以获得任何一个可写 DC，就像我跟踪域一样。我可以在 DC1 上进行编辑并在 DC2 上查看它们，反之亦然（在 DC1 上进行的组策略等更改肯定存在于更大的网络中）。我可以使用 RODC 并告诉它从 DC1 和 DC2 加载记录而不会出现问题。

但是，如果我让 DC2 脱机，那就是事情横向发展的时候。对我们域的 Ping 或 Tracert 失败，外部用户被拒绝访问，内部用户看到我们的 AD 身份验证应用程序失败，并不断要求输入用户名和密码。然而，相反的情况不会发生 - 如果我让新的 DC1 脱机，本地用户有时会有轻微的延迟，就好像他们的机器在故障转移到 DC2 并成功验证之前试图联系 DC1，而外部用户进来就好了。

事件日志中没有什么特别明显的，而且我能想到的所有内容都显示正确配置。我不知道从哪里开始 - 有没有人有类似的症状，他们已经能够纠正？

我有一个 AD 设置，显然存在与证书服务功能相关的漏洞。回想一下我参加过的 MS Server 课程，我什么都不记得了，所以我在网上搜索了一下，我倾向于“不”。

我不会在内部为任何东西生成证书 - 允许工作站进行自签名，并且我的父组织有一些步骤可以在我们的服务器上本地生成证书请求，以将其传递给第三方 CA。这似乎是ADCS的主要功能，我似乎没有使用它。

用户不使用 PKI，只使用用户名和密码，而且似乎 ADCS 与验证与智能卡令牌关联的 CA 有关。我可能记错了，这与此无关。

那么仅删除 ADCS 是否安全？我相信如果您将某些东西提升到域控制器（或至少添加角色），它只是默认安装，但我想不出任何时候我与它进行过交互。

DC 运行 Server 2012 和 2019（前者将在不久的将来某个时候被淘汰，将被 Server 2019 取代）。

我正在使用在 Windows Server 2019 上运行的 IIS10 和 TFS2018。

我最终要做的是设置附件大小，它将使用这个 URL：

http://localhost:8080/tfs/MyTFSProjectCollection/WorkItemTracking/v1.0/ConfigurationSettingsService.asmx?op=SetMaxAttachmentSize

然而，这不起作用。

实际的网站已经启动——它在 IIS 中运行，我可以从网络上的任何工作站获取面向用户的真实数据。但是，我无法从 IIS / TFS 主机访问它，无论是通过该特定 URL 还是进入 IIS 并尝试通过 IIS 控制台“浏览”该网站。不幸的是，这是根据我所知设置最大文件大小的唯一方法。

我只得到：

无法访问此页面

•确保网址正确

•在 Bing 上搜索此网站

•刷新页面

有问题的网站使用 SSL，所以出于好奇，我尝试了该 URL 的 https:// 版本，甚至还有一个带有 https:// 和 :443 的变体。我也刚刚尝试关闭端口，但无济于事。

主机使用代理，我已禁用它无济于事（它设置为绕过本地地址的所述代理，甚至对 localhost 和它自己的 IP 地址有明确的例外）。这没有帮助。

如果我能够在其他地方访问它，是什么阻止我在自己的主机上浏览网站本身？没有太多信息可以尝试解决这个问题，我能找到，而且服务器本身也不会出现。

不久前，我部署了 DNSSEC，因为这样做我减少了需要在本地域的 DNS 上实施的安全配置检查的数量。这些是 Windows Server 2012R2 机器

这似乎工作得很好，除了它会导致我们必须打破的异地备份安排。我们的 DNS 已设置为将单个主机名解析为我们无法控制的负载平衡设备，然后该设备处理传入的数据 - 基本上只是我们将 DPM 备份文件扔到的驱动器空间。这是我们域区域内的委托记录，主机名作为记录的名称，并包含负载均衡器的单个 NS 条目。

花了一些时间才弄清楚 DNSEC 是原因，但在与其他网络团队合作时，这似乎得到了证实，他们没有计划重新配置任何东西以使其最终正常工作。

我似乎没有完全理解 DNSSEC 对此的影响。但是，有没有办法简单地取消 DNSSEC？我当然可以“取消签名”该区域，如 DNS 服务器上的 DNSSEC 菜单所示。但是实际上并没有任何关于这个在线的指导，看起来写得很好或最近。除了简单地取消对该区域的签名之外，还有更多内容吗？

我需要在我的 IIS 应用程序池中配置几个远离默认设置的设置，但我没有找到很好的指导，也没有很幸运的试错实验。

我有两个正在使用的应用程序池。一个托管一个应用程序，另一个托管两个。这些应用程序用于支持我们办公室的日常工作，是用户通过网站或本地 Visual Studio 客户端访问的 TFS 本地实例。该机器是一个虚拟 Windows 主机，最大 RAM 为 16GB，常规使用量在 10.5GB 左右。

有问题的值是回收请求限制、专用内存限制和虚拟内存限制。

这三个的默认值为“0”，表示“无限制”。这是不允许的。

到目前为止，似乎每当我在相关字段中设置任何值时，TFS 的性能都会下降。它仍然可以访问，但明显慢得多。

对于内存限制，我在网上找到了一些指导，应用程序通常只能使用 1.6GB 之类的东西，所以我开始试用两个池的 2GB 限制。这效果不好，所以我一直在增加它，直到我为两个池提供了 16GB 的最大限制（以 kb 表示，所以 16777216kb）。私有内存限制和虚拟内存限制中使用的数量保持不变，因为似乎没有任何迹象表明它们应该分开。

回收的请求限制，另一个不能再为“0”的值，被设置为 35000——这显然是 IIS 6.5 的“最佳实践”。

我不确定为什么性能下降了。在我看来，这些配置更改正在阻止 IIS 应用程序获取所需的所有内存，从而导致它们陷入困境。但是，显然，我允许相关应用程序使用 16GB - 这肯定与“0”相同，因为这是他们能够从 16GB 上的“无限”设置中获取的最大内存RAM 托管虚拟机。

将内存限制设置回“0”会提高性能，而将请求限制设置回会稍微提高一点。

奇怪的是，无论这些设置是什么，机器内存使用似乎都没有偏离。

不幸的是，我不知道如何正确配置它，因为有问题的要求没有任何限制。除了找到关于设置多少数量的建议之外，我也无法找到一个具体的资源来说明如何自己解决这个问题——也就是说，我可以手动插入别人的价值观，但我不清楚我是如何做到的应该能够查看我自己的应用程序并根据某些已知值得出结果。我确实知道 w3wp 进程是一个管理应用程序池的 IIS 工作进程——但它似乎只需要约 228,000K 的峰值——无论如何，根据任务管理器。

我应该如何配置这些内存处理设置，以及我应该根据什么做出决定？我不确定为什么如果我为它提供系统上的最大内存量（16GB），它的性能会不如我提供无限量的内存（无论如何它本身都会受到系统内存限制 16GB 的约束）。