Charon's Blog

Integrating a Brother Scanner with SharePoint Using IIS FTP and Power Automate

Wed, 22 Jul 2026 00:00:00 GMT

Introduction

As our organization gradually migrated its document storage to SharePoint Online, we encountered a new challenge.

Traditional multifunction printers (MFPs) typically support:

Scan to Email
Scan to SMB
Scan to FTP

However, most Brother printers—especially entry-level and mid-range models—do not support scanning directly to SharePoint Online.

Continuing to use a traditional SMB shared folder would mean scanned documents remain outside the SharePoint ecosystem, losing the benefits of centralized permission management, version control, and collaboration.

Our objective was straightforward:

Keep the scanning experience unchanged for end users while ensuring every scanned document ultimately ends up in SharePoint.

Solution Architecture

After evaluating several options, we adopted the following architecture:

Brother Scanner
        │
Scan to FTP
        │
Windows Server IIS FTP
        │
Power Automate
        │
SharePoint Document Library

The entire process is completely transparent to end users.

Users simply select Scan to FTP on the Brother printer.

The system automatically performs the remaining tasks:

Save the scanned document to the FTP server.
Detect the newly created file.
Upload it to the designated SharePoint document library.

No manual intervention is required.

Environment

Server

Windows Server 2016 Standard

Printer

Brother DCP-L2640DW

Automation

Microsoft Power Automate
On-premises Data Gateway

Destination

SharePoint Online

FTP Server

IIS FTP Server

Installing IIS FTP

Windows Server does not install the FTP service by default.

Open Server Manager and launch the Add Roles and Features Wizard.

Server Manager
    ↓
Add Roles and Features

Select:

Web Server (IIS)

Under Role Services, install the FTP components in addition to the default IIS features:

Web Server (IIS)
├── Common HTTP Features
├── Health and Diagnostics
├── Performance
├── Security
├── ...
└── FTP Server
    ├── FTP Service
    └── FTP Extensibility

These two components serve different purposes:

FTP Service provides the core FTP functionality.
FTP Extensibility enables advanced authentication methods and future extensibility, so it is recommended to install it together with the FTP Service.

After the installation completes, a new FTP Sites node will appear in IIS Manager.

Creating an FTP Site

In this solution, the FTP server is used only as a temporary staging area for scanned documents.

Create a dedicated directory on the server:

C:\FTPScan

Then open IIS Manager:

Server Manager
    ↓
Tools
    ↓
Internet Information Services (IIS) Manager

Expand the server node:

PRINTER

Right-click Sites and select:

Add FTP Site...

Configure the site using the following settings:

Site Name
Scanner FTP

Physical Path
C:\FTPScan

IP Address
192.168.x.x

Port
21

SSL
No SSL

[!NOTE] Why not use FTPS?

The Brother DCP-L2640DW supports standard FTP out of the box, while FTPS (FTP over SSL) compatibility varies depending on the printer model and firmware version.

Since our initial goal was to validate the complete workflow, we chose standard FTP for the first deployment. Because both the FTP server and the printer reside within the internal corporate network, this approach provides a reasonable balance between simplicity and functionality.

If security or compliance requirements change in the future, upgrading to FTPS can be considered without changing the overall architecture.

For authentication, select:

Basic Authentication

For authorization:

Specified users

Grant access only to the dedicated FTP account used by the scanner.

Creating a Dedicated FTP Account

Instead of using an administrator account, create a dedicated local user with the minimum permissions required.

Open:

Computer Management
    ↓
Local Users and Groups
    ↓
Users
    ↓
New User...

Create the following account:

Username
scanftp

Using a dedicated account follows the principle of least privilege and simplifies future auditing and maintenance.

Planning the Directory Structure

Although this deployment initially included only a single printer, it is worth planning a scalable directory structure from the beginning.

For example:

C:\FTPScan
├── MTL-P73
├── MTL-P74
├── QC-P01
└── HR

Each Brother printer is configured to use its own Store Directory.

For example:

Store Directory

MTL-P73

This allows Power Automate to monitor different folders and automatically upload documents to different SharePoint document libraries without requiring any changes to the printer configuration.

It also makes the solution easy to expand as additional printers are deployed.

Troubleshooting #1: Windows Defender Firewall

Local FTP testing worked perfectly.

However, client computers were unable to connect to the FTP server.

Verify the FTP Service, FTP Site, and Port 21

Run the following commands on the FTP server:

PS C:\Windows\system32> systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

OS Name:    Microsoft Windows Server 2016 Standard
OS Version: 10.0.14393 N/A Build 14393

PS C:\Windows\system32> Get-Service ftpsvc

Status     Name     DisplayName
------     ----     -----------
Running    ftpsvc   Microsoft FTP Service

PS C:\Windows\system32> Get-WebSite

Name             ID     State     Physical Path                 Bindings
----             --     -----     -------------                 --------
Default Web Site 1      Started   %SystemDrive%\inetpub\wwwroot http *:80:
Scanner FTP      2      Started   C:\FTPScan                    ftp 192.168.1.129:21:

PS C:\Windows\system32> netstat -ano | findstr :21

TCP    0.0.0.0:21                  0.0.0.0:0              LISTENING
TCP    [::]:21                     [::]:0                 LISTENING

Analysis

✅ The FTP service is running.

Running    ftpsvc

✅ The FTP Site has started successfully.

Scanner FTP      Started

✅ Port 21 is listening.

0.0.0.0:21    LISTENING

At this point, there were no obvious issues on the server side.

Test the TCP Connection

Open PowerShell on a client computer and run:

Test-NetConnection 192.168.1.129 -Port 21

Output:

WARNING: TCP connect to (192.168.1.129 : 21) failed

ComputerName     : 192.168.1.129
RemoteAddress    : 192.168.1.129
RemotePort       : 21
SourceAddress    : 192.168.1.191
PingSucceeded    : True
TcpTestSucceeded : False

Check the Firewall Rules

Run the following command on the FTP server:

Get-NetFirewallRule -DisplayGroup "FTP Server" | Select DisplayName, Enabled

Output:

DisplayName                                 Enabled
-----------                                 -------
FTP Server (FTP Traffic-In)                 True
FTP Server (FTP Traffic-Out)                True
FTP Server Secure (FTP SSL Traffic-In)      True
FTP Server Secure (FTP SSL Traffic-Out)     True
FTP Server Passive (FTP Passive Traffic-In) True

Everything appeared to be configured correctly.

[!NOTE] Since this server is joined to an Active Directory domain, we suspected that the Domain Firewall Profile might be blocking FTP traffic.

To verify this assumption, we temporarily disabled the Domain Firewall Profile.

Run:

Set-NetFirewallProfile -Profile Domain -Enabled False

After disabling the Domain Firewall Profile, the result changed to:

TcpTestSucceeded : True

This confirmed that:

Windows Defender Firewall (or a firewall policy applied through Group Policy) was blocking the FTP connection.

Do Not Leave the Firewall Disabled

Re-enable the firewall:

Set-NetFirewallProfile -Profile Domain -Enabled True

Instead of relying on the firewall rules created automatically by IIS, we created an explicit inbound rule for FTP.

Run:

New-NetFirewallRule `
    -DisplayName "Scanner FTP 21" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 21 `
    -Action Allow `
    -Profile Domain

After adding this firewall rule, FTP connections worked successfully.

Troubleshooting #2: FTP Passive Mode

After resolving the firewall issue, the client was finally able to establish an FTP connection.

However, a new problem appeared.

The FTP session could be established successfully, but file uploads still failed.

At this point, we knew that:

Port 21 was reachable.
The FTP service was running normally.
Authentication succeeded.

The problem occurred after the control connection had been established.

Understanding FTP Passive Mode

FTP uses two separate connections:

Control Connection (TCP 21)
Data Connection (a dynamically assigned TCP port)

When using Passive Mode, the server opens a random TCP port for the data connection.

If these dynamic ports are not allowed through the firewall, the FTP client can log in successfully but will fail when transferring files.

This is a common issue when deploying an FTP server on Windows Server.

Configure a Passive Port Range

Open IIS Manager.

Select the server node, then open:

FTP Firewall Support

Configure a dedicated passive port range.

For example:

Data Channel Port Range

50000-50050

Using a fixed range makes firewall configuration much simpler than allowing all dynamic ports.

Allow the Passive Ports Through Windows Firewall

After configuring the passive port range in IIS, Windows Defender Firewall must also allow those ports.

Run:

New-NetFirewallRule `
    -DisplayName "FTP Passive Ports" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 50000-50050 `
    -Action Allow `
    -Profile Domain

Restart FTP service

Restart-Service ftpsvc

Printer Configuration

Configuring the Brother printer is very straightforward.

FTP Server:

192.168.x.x

Port:

Passive Mode:

Enable

Store Directory:

MTL-P73

For the Username and Password, enter the local account that was created earlier.

One thing to note is:

The Store Directory is a path relative to the FTP Root.

For example:

Root

C:\FTPScan

Store Directory:

MTL-P73

The actual file storage location will be:

C:\FTPScan\MTL-P73

Power Automate

Since the files are stored on a local server, we used:

On-premises Data Gateway

to connect to the local file system.

The Flow itself is very simple:

When a file is created
        │
Get file content
        │
Create file (SharePoint)

No scripts are required.

The entire workflow uses only Microsoft official connectors.

Step 1: Verify that the Gateway Is Installed

Do not create the Flow yet.

On the server (PRINTER), first verify whether the following is already installed:

On-premises data gateway

Search the Start menu for:

gateway

If you see:

On-premises data gateway

then it is already installed.

If not, install it first.

Download it from:

https://aka.ms/onpremgateway

During the installation, configure the following:

Mode: Standard
Sign in with your username@contasco.com
Gateway Name: For example, PRINTER-GW
Recovery Key: Create a strong password and store it securely. It will be required if the Gateway needs to be migrated or restored in the future.

Step 2: Create an Automated Cloud Flow

Open:

https://make.powerautomate.com

Then navigate to:

Create → Automated cloud flow

Enter the following:

Flow Name

FTP Scan to SharePoint

Choose your flow's trigger

Search for:

File System

Select:

When a file is created (properties only)

Step 3: Create the Connection

Field	Value
Connection name	`PRINTER File System`
Root folder	`C:\FTPScan`
Authentication Type	`Windows`
Username	The local account created earlier
Password	The password for the Windows account
Gateway	Select the `PRINTER-GW` gateway created earlier

Step 4: Configure the Trigger

Trigger:

When a file is created (properties only)

Folder

Click the folder icon on the right (if available), or manually enter the path relative to the Root Folder:

/MTL-P73

Since the Root Folder is already:

C:\FTPScan

the Trigger is actually monitoring:

C:\FTPScan\MTL-P73

Step 5: Add the File Content Action

Click the ➕ button in the middle.

Select:

Add an action

Search for:

File System

Select:

Get file content

For Get file content → File, select:

body/Id

After that, click the ➕ button below to add the next action:

SharePoint — Create file

Configure the action:

For File Name and File Content, select the dynamic content returned by Get file content.

Click Save in the upper-right corner to save the Flow.

The final Power Automate workflow is:

When a file is created (properties only)
             │
             ▼
Get file content
             │
             ▼
SharePoint Create file

Final Result

The final workflow becomes:

Scan
    │
    ▼
FTP
    │
    ▼
Power Automate
    │
    ▼
SharePoint

For end users, nothing changes in the scanning process.

However, every scanned document is ultimately stored in SharePoint, where it benefits from:

Permission management
Online collaboration
Version control
Centralized Microsoft 365 management

Throughout the entire deployment, the printer does not need to support SharePoint, nor is any third-party software required.

This approach is also easy to replicate for other printers.

Toolbox

The following PowerShell and Windows commands were used throughout this deployment and can serve as a reference for future deployments and troubleshooting.

1. Check the FTP Service Status

Verify that the IIS FTP service is running.

Get-Service ftpsvc

Start the FTP service:

Start-Service ftpsvc

Stop the FTP service:

Stop-Service ftpsvc

Restart the FTP service:

Restart-Service ftpsvc

2. Check Whether Port 21 Is Listening

Verify that the FTP server is listening on TCP port 21.

netstat -ano | findstr :21

If you see:

LISTENING

then IIS has successfully bound to port 21.

3. Test Network Connectivity

Verify that the client can reach the FTP server.

Test-NetConnection 192.168.x.x -Port 21

Pay attention to:

TcpTestSucceeded

True — Network connectivity is working.
False — Continue troubleshooting the firewall or network configuration.

4. Test FTP Login

Use the built-in Windows FTP client to test the connection.

ftp 192.168.x.x

After logging in successfully, use:

dir

to list the directory contents.

Exit the session with:

bye

5. Check the Windows Firewall Status

View the status of all Firewall Profiles.

Get-NetFirewallProfile

6. Temporarily Disable the Firewall (Troubleshooting Only)

Use this only to verify whether the firewall is causing the issue.

Set-NetFirewallProfile -Profile Domain -Enabled False

Re-enable it afterward:

Set-NetFirewallProfile -Profile Domain -Enabled True

It is not recommended to leave the firewall disabled. This should only be used for troubleshooting.

7. Create an FTP Firewall Rule

Allow the FTP control connection (TCP 21).

New-NetFirewallRule `
    -DisplayName "Scanner FTP" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 21 `
    -Action Allow `
    -Profile Domain

8. View Firewall Rules

List all FTP-related firewall rules.

Get-NetFirewallRule |
Where-Object DisplayName -like "*FTP*"

9. Recommended Troubleshooting Order

It is recommended to troubleshoot in the following order instead of changing multiple settings at the same time:

Is the FTP service running?
Is port 21 listening?
Can you log in to the FTP server locally?
Does Test-NetConnection succeed?
Is the firewall blocking the connection?
Is Passive Mode configured correctly?
Does the Brother FTP Test pass?
Is the file successfully written to the FTP Root?
Is Power Automate triggered?
Does the file successfully appear in SharePoint?

Following this sequence makes it much easier to isolate the root cause and avoids making unnecessary configuration changes.

Brother 扫描仪无缝接入 SharePoint —— IIS FTP + Power Automate 自动上传方案

Wed, 22 Jul 2026 00:00:00 GMT

前言

随着公司文件逐步迁移到 SharePoint，我们遇到了一个新的问题。

传统的多功能打印机（MFP）通常支持：

Scan to Email
Scan to SMB
Scan to FTP

但是大多数型号，尤其是中低端 Brother 设备，并不支持直接扫描到 Scan to email/SharePoint Online。

如果继续使用传统 SMB 共享目录，那么扫描件就会脱离 SharePoint 的权限管理、版本控制以及协作体系。

我们的目标很明确：

保持用户使用习惯不变，同时让所有扫描文件最终进入 SharePoint。

最终架构

最终采用了下面的架构：

Brother Scanner
        │
Scan to FTP
        │
Windows Server IIS FTP
        │
Power Automate
        │
SharePoint Document Library

整个过程对于用户完全透明。

用户只需要在打印机上按下 Scan to FTP。

系统会自动完成：

扫描到 FTP
检测新文件
上传至 SharePoint

无需任何人工参与。

环境

服务器：

Windows Server 2016 Standard

打印机：

Brother DCP-L2640DW

文件上传：

Microsoft Power Automate
On-premises Data Gateway

目标平台：

SharePoint Online

FTP：

IIS FTP Server

安装 IIS FTP

Windows Server 默认并不会安装 FTP 服务。

需要通过 Server Manager 添加 IIS（Internet Information Services）相关角色。

打开：

Server Manager
→ Add Roles and Features

选择：

Web Server (IIS)

在 Role Services 中，除了默认的 Web Server 组件外，还需要额外安装 FTP 相关服务：

Web Server (IIS)
├── Common HTTP Features
├── Health and Diagnostics
├── Performance
├── Security
├── ...
└── FTP Server
    ├── FTP Service
    └── FTP Extensibility

其中：

FTP Service：提供 FTP 服务本身。
FTP Extensibility：支持扩展身份验证和后续高级功能，建议一并安装。

安装完成后，在 IIS Manager 中即可看到 FTP Sites 节点。

创建 FTP Site

本项目中，FTP 仅作为扫描文件的临时缓冲区（Staging Area）。

因此，我们在服务器上创建了专用目录：

C:\FTPScan

随后在 IIS 中新建 FTP Site：打开IIS manager

Server Manager
    ↓
Tools
    ↓
Internet Information Services (IIS) Manager

打开：

PRINTER

创建新的 FTP Site

右键：

Sites
    ↓
Add FTP Site...

参考配置如下

Site Name
Scanner FTP

Physical Path
C:\FTPScan

IP Address
192.168.x.x

Port
21

No SSL

[!NOTE] 为什么不用 SSL？ Brother DCP-L2640DW 支持普通 FTP，而 FTPS（FTP over SSL）兼容性因型号和固件而异。我们的目标是先验证整个流程，等以后如果有合规要求，再升级到 FTPS。因为服务器和打印机都在公司内网，先用普通 FTP 是一个合理的起点。

身份验证选择：

Basic Authentication

授权方式：

Specified users

仅允许用于扫描的 FTP 用户访问。

创建新的FTP专用账户

打开：

Computer Management
    ↓
Local Users and Groups
    ↓
Users
    ↓
New User...

创建：

Username:
scanftp

建议提前规划目录结构

虽然目前只有一台打印机，但建议一开始就按照打印机或部门划分目录。

例如：

C:\FTPScan
├── MTL-P73
├── MTL-P74
├── QC-P01
└── HR

每台 Brother 打印机配置自己的 Store Directory。

例如：

Store Directory

MTL-P73

这样可以让后续 Power Automate 根据目录自动上传到不同的 SharePoint Library，而无需修改打印机配置，也方便未来扩展更多设备。

第一个坑：Windows Firewall

FTP 本地测试一切正常。

但是客户端始终无法连接。

确认FTP服务运行，FTP Site启动，监听21端口

PS C:\Windows\system32> systeminfo | findstr /B /C:"OS Name" /C:"OS Version" 
OS Name:    Microsoft Windows Server 2016 Standard 
OS Version: 10.0.14393 N/A Build 14393 

PS C:\Windows\system32> Get-Service ftpsvc 
Status     Name     DisplayName 
------     ----     ----------- 
Running    ftpsvc   Microsoft FTP Service 

PS C:\Windows\system32> Get-WebSite 
Name             ID     State     Physical Path                 Bindings 
----             --     -----     -------------                 -------- 
Default Web Site 1      Started   %SystemDrive%\inetpub\wwwroot http *:80: 
Scanner FTP      2      Started   C:\FTPScan                    ftp 192.168.1.129:21: 

PS C:\Windows\system32> netstat -ano | findstr :21 
TCP 0.0.0.0:21 0.0.0.0:0 LISTENING 8504 
TCP 192.168.1.xx:21290 4.174.148.129:443 ESTABLISHED 8684 
TCP 192.168.1.xx:21291 4.174.148.129:443 ESTABLISHED 5624 
TCP [::]:21 [::]:0 LISTENING 8504

分析

✅ FTP 服务运行中

Running  ftpsvc

✅ FTP Site 已启动

Scanner FTP   Started

✅ 21 端口正在监听

0.0.0.0:21 LISTENING

所以 服务器端已经没有明显问题

测试TCP连接

打开一台客户端的Powershell, 执行：

Test-NetConnection 192.168.1.129 -Port 21

输出：

WARNING: TCP connect to (192.168.1.129 : 21) failed 
ComputerName : 192.168.1.129 
RemoteAddress : 192.168.1.129 
RemotePort : 21 
InterfaceAlias : 
Ethernet 4 SourceAddress : 192.168.1.191 
PingSucceeded : True 
PingReplyDetails (RTT) : 1 ms 
TcpTestSucceeded : False

检测防火墙规则

在FTP服务器执行：

Get-NetFirewallRule -DisplayGroup "FTP Server" | Select DisplayName, Enabled

输出：

DisplayName Enabled 
----------- ------- 
FTP Server (FTP Traffic-In) True 
FTP Server (FTP Traffic-Out) True 
FTP Server Secure (FTP SSL Traffic-In) True 
FTP Server Secure (FTP SSL Traffic-Out) True 
FTP Server Passive (FTP Passive Traffic-In) True

看起来没有问题

[!NOTE] Windows Firewall 因为这台服务器加入了AD域，也许domain的Firewall Profile 影响到了FTP，我们先关掉来测试一下

在服务器执行：

Set-NetFirewallProfile -Profile Domain -Enabled False

关闭Domain Firewall Rule 之后，TcpTestSucceeded : True 这说明：

就是 Windows Defender Firewall（或者域 GPO 控制的防火墙）导致的。

先不要一直关着防火墙

把它重新打开：

Set-NetFirewallProfile -Profile Domain -Enabled True

我们不要依赖 IIS 自动创建的 FTP Rule。

直接自己创建一条明确的规则。

服务器执行：

New-NetFirewallRule `
    -DisplayName "Scanner FTP 21" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 21 `
    -Action Allow `
    -Profile Domain

加入这条防火墙规则之后，FTP就通了

第二个坑：Passive Mode

解决了 21 端口以后。

命令行 FTP 可以正常登录。

但是 Windows Explorer 一直提示：

The operation timed out.

经过排查发现：

Windows Explorer 使用 Passive FTP。

而 IIS 默认并没有配置 Passive Port。

现在配置 Passive Mode

打开 IIS：

服务器
    ↓
Scanner FTP
    ↓
点击最上面的服务器节点

注意：不是 FTP Site，而是左侧树最顶端的服务器名 PRINTER。

然后打开：

FTP Firewall Support

应该能看到：

Data Channel Port Range
External IP Address

设置

Data Channel Port Range

输入：

50000-50050

External IP Address

留空。

（因为我们在内网，不需要填写。）

点击：

Apply

然后放行这些端口

PowerShell：

New-NetFirewallRule `
    -DisplayName "FTP Passive Ports" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 50000-50050 `
    -Action Allow `
    -Profile Domain

最后一步

重启 FTP Service：

Restart-Service ftpsvc

打印机配置

Brother 配置非常简单。

FTP Server：

192.168.x.x

Port：

Passive Mode：

Enable

Store Directory：

MTL-P73

Username和Password填写刚才注册的本地账户

这里需要注意：

Store Directory 是相对于 FTP Root 的路径。

例如：

Root

C:\FTPScan

Store Directory：

MTL-P73

最终文件实际保存位置：

C:\FTPScan\MTL-P73

Power Automate

由于文件位于本地服务器。

最终采用：

On-premises Data Gateway

连接本地文件系统。

整个 Flow 非常简单：

When a file is created
        │
Get file content
        │
Create file (SharePoint)

整个流程无需任何脚本。

全部使用微软官方 Connector。

Step 1：确认 Gateway 是否已安装

先不要创建 Flow。

打开服务器（PRINTER），检查是否已经安装：

On-premises data gateway

开始菜单搜索：

gateway

如果看到：

On-premises data gateway

说明已经安装。

如果没有，我们先安装。

官方下载：

https://aka.ms/onpremgateway

安装时：

Mode：Standard
登录：你的 username@contasco.com
Gateway Name：例如 PRINTER-GW
Recovery Key：设置一个强密码并妥善保存（以后迁移或恢复 Gateway 会用到）。

Step 2：创建 Automated Cloud Flow

打开：

https://make.powerautomate.com

然后：

Create（创建） → Automated cloud flow

填写：

Flow Name

FTP Scan to SharePoint

Choose your flow's trigger

搜索：

File System

选择：

When a file is created (properties only)

Step 3：创建 Connection

字段	填写内容
Connection name	`PRINTER File System`
Root folder	`C:\FTPScan`
Authentication Type	`Windows`
Username	刚才创建的本地账户
Password	对应 Windows 账户密码
Gateway	选择刚刚创建的 `PRINTER-GW`

Step 4：配置 Trigger

Trigger：

When a file is created (properties only) 。

Folder

点击右边的文件夹图标（如果有），或者填写相对于 Root Folder 的路径：

/MTL-P73

因为 Root Folder 已经是：

C:\FTPScan

所以 Trigger 实际监控的是：

C:\FTPScan\MTL-P73

Step 5：添加读取文件内容

点击中间的 ➕。

选择：

Add an action

搜索：

File System

选择：

Get file content

在 Get file content → File 中选择：

body/Id

完成后，点击下方的＋，下一步添加：

SharePoint — Create file

配置Action：

File name 和File Content选择动态内容，接受Get file content的输出

点击右上角 Save 保存 Flow。 Power automate 的最终流程:

When a file is created (properties only)
             │
             ▼
Get file content
             │
             ▼
SharePoint Create file

最终效果

整个流程最终变成：

扫描
    │
    ▼
FTP
    │
    ▼
Power Automate
    │
    ▼
SharePoint

对于最终用户来说。

扫描流程没有任何变化。

但所有文件最终都统一进入 SharePoint，享受：

权限管理
在线协作
版本控制
Microsoft 365 统一管理

整个改造过程中，打印机无需支持 SharePoint，也无需安装任何第三方软件。

这也是一种比较容易复制到其他打印机的部署方式。

Toolbox

下面整理了本次部署过程中使用到的主要 PowerShell 与 Windows 命令，可作为后续部署或排障时的参考。

1. 检查 FTP 服务状态

查看 IIS FTP 服务是否已经启动。

Get-Service ftpsvc

启动 FTP 服务：

Start-Service ftpsvc

停止 FTP 服务：

Stop-Service ftpsvc

重启 FTP 服务：

Restart-Service ftpsvc

2. 检查端口监听状态

确认 FTP Server 是否已经开始监听 TCP 21。

netstat -ano | findstr :21

如果能够看到：

LISTENING

说明 IIS 已经成功绑定到 21 端口。

3. 测试网络连通性

验证客户端是否能够访问 FTP Server。

Test-NetConnection 192.168.x.x -Port 21

重点关注：

TcpTestSucceeded

True：网络连接正常
False：需要继续检查防火墙或网络配置

4. 测试 FTP 登录

使用 Windows 自带 FTP Client 测试登录。

ftp 192.168.x.x

登录成功后可以使用：

dir

查看目录内容。

退出：

bye

5. 查看 Windows Firewall 状态

查看各 Firewall Profile 是否启用。

Get-NetFirewallProfile

6. 临时关闭 Firewall（仅用于排障）

验证问题是否由防火墙导致。

Set-NetFirewallProfile -Profile Domain -Enabled False

恢复：

Set-NetFirewallProfile -Profile Domain -Enabled True

不建议长期关闭防火墙，仅用于快速定位问题。

7. 创建 FTP Firewall Rule

开放 FTP 控制连接（TCP 21）。

New-NetFirewallRule `
    -DisplayName "Scanner FTP" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 21 `
    -Action Allow `
    -Profile Domain

8. 查看 Firewall Rules

列出 FTP 相关规则。

Get-NetFirewallRule |
Where-Object DisplayName -like "*FTP*"

9. 常见排障顺序

建议按照下面的顺序进行排查，而不是同时修改多个配置：

FTP 服务是否启动？
21 端口是否监听？
本机是否可以 FTP 登录？
Test-NetConnection 是否成功？
Firewall 是否阻挡？
Passive Mode 是否配置？
Brother FTP Test 是否通过？
文件是否成功写入 FTP Root？
Power Automate 是否触发？
SharePoint 是否成功收到文件？

按照以上流程，可以快速定位问题所在，避免盲目修改配置。

一次 Windows Hello for Business (Key Trust) 的完整排障记录

Fri, 17 Jul 2026 00:00:00 GMT

最近在部署 Windows Hello for Business 的时候，踩了一个非常大的坑。整个过程持续了两天，最后发现并不是某一个配置出了问题，而是几个历史遗留问题叠加在一起，导致整个认证链全部失效。这篇文章记录一下整个排障过程，也希望以后自己再遇到类似问题的时候，不用重新踩一遍。

环境

本地 Active Directory
Microsoft Entra ID Hybrid Join
Microsoft Intune
Windows Hello for Business
Key Trust 部署
Enterprise CA（AD CS） Windows 11 已经完成 Hybrid Join，也已经自动加入 Intune。理论上，只需要下发 Windows Hello Policy，就可以直接使用 PIN 登录。事实证明，没有这么简单。

故障现象

这次排障的起点是一个普通的用户反馈。

用户在设置 Windows Hello PIN 后，原本以为以后可以直接使用 PIN 登录 Windows。

结果锁屏之后，点击 PIN 登录，系统直接提示：

该选项暂时不可用。

请使用其他方式登录。

（英文对应为：That option is temporarily unavailable. For now, please use a different sign-in method.）

也就是说，PIN 已经设置成功，但是真正登录的时候却被拒绝了。

与此同时，Windows Hello 设置页面并没有任何异常，也没有提示 PIN 创建失败。

最开始，我怀疑是不是 PIN 本身没有创建成功。

于是第一件事就是检查 Windows Hello 的状态：

dsregcmd /status

发现：

NgcSet : NO

进一步查看 Windows Hello Prerequisite，又发现：

PreReqResult : WillNotProvision

这说明问题甚至还没有进入认证阶段。

Windows Hello 连 Provisioning 都没有完成。

于是，整个排查的第一阶段就变成了：

为什么 Windows Hello 根本不愿意开始 Provisioning？

第一阶段：先让 Windows Hello 开始工作

看到 WillNotProvision 之后，我决定先停下来，重新梳理一下 Windows Hello for Business 的工作流程。

很多人（包括刚开始的我）都会把 Windows Hello 理解成"设置一个 PIN"。

其实并不是。

对于 Windows Hello for Business 来说，PIN 只是用来解锁本地保存的密钥，并不是用户真正的密码。

整个流程大致可以分成两个阶段。

Provisioning
Authentication

第一阶段：Provisioning

第一次启用 Windows Hello 时，系统会完成一系列初始化工作，包括：

检查设备是否满足部署条件；
检查策略是否允许启用 Windows Hello；
在 TPM（或软件密钥存储）中生成一对新的公私钥；
将公钥注册到身份系统（例如 Active Directory 或 Microsoft Entra ID）；
完成 Windows Hello 的初始化。

只有这一切都完成之后，用户才能成功创建 PIN。

如果 Provisioning 失败，那么后面的登录流程根本不会开始。

而我当时看到的：

PreReqResult : WillNotProvision

正说明系统停在了这一阶段。

第二阶段：Authentication

Provisioning 完成之后，Windows Hello 才真正进入日常使用阶段。

以后每次输入 PIN 登录时，Windows 会使用之前生成的密钥完成身份验证。

如果这一阶段出现问题，就会表现为：

PIN 可以创建；
Windows Hello 已经启用；
但是输入 PIN 后仍然无法登录。

而这是我后来遇到的第二个问题。

我的首要目标，是先让 Windows Hello 能够完成 Provisioning。

检查Intune配置

Windows Hello for Business 在 Intune 里面其实有两个容易混淆的配置位置。

第一个是：

Devices → Windows → Enrollment → Windows Hello for Business

这里属于 Enrollment 配置。

它决定的是设备是否启用 Windows Hello，一些简单的配置

第二个是：

Devices → Windows → Configuration → Policies

这里属于 Configuration Profile。

它的作用是向设备下发具体配置，例如 PIN 复杂度、生物识别、TPM 要求，以及其他 Windows 设置，以及使用哪一种部署模式，例如 Cloud Trust、Key Trust 或 Certificate Trust。可以把它理解成 Windows Hello 的"全局策略"。

虽然这两个地方都会影响 Windows Hello，但职责并不一样。

简单来说：

Enrollment 决定 Windows Hello 能不能开始工作；
Configuration Policy 决定 Windows Hello 应该怎样工作。

检查后发现，configuration profile里开启了cloud trust，而我们本地的Hybrid Domain并没有准备好。

由于之前一直在测试 Cloud Trust 和 Key Trust，两种部署方式之间来回切换过不少次，因此这里的配置也经历过多次修改。

继续折腾 Cloud Trust 并不是一个好的选择。

我们的环境里仍然保留着 Windows Server 2012 的 Domain Controller。虽然 Cloud Trust 并不是完全不能部署，但如果要认真验证和推广，应该作为后续单独的项目来规划，而不是在修复故障的时候一边排障、一边调整整个认证架构。

这次的目标其实很简单：

先让用户能够正常使用 PIN 登录。

于是，我决定暂时关闭 Cloud Trust，先回到目前环境更容易验证的 Key Trust 部署方式。

调整策略之后，再次查看设备状态：

NgcSet : dsregcmd /status

需要重点观察的部分：

+----------------------------------------------------------------------+
| Ngc Prerequisite Check                                               |
+----------------------------------------------------------------------+

            IsDeviceJoined : YES
             IsUserAzureAD : YES
             PolicyEnabled : YES
          PostLogonEnabled : YES
            DeviceEligible : YES
        SessionIsNotRemote : YES
            CertEnrollment : enrollment authority
          AdfsRefreshToken : YES
             AdfsRaIsReady : YES
    LogonCertTemplateReady : YES ( StateReady )
              PreReqResult : WillProvision
+----------------------------------------------------------------------+

这一次，用户终于可以正常创建 PIN 了。

这说明 Windows Hello 已经成功完成了 Provisioning。

第二阶段：PIN 已经创建，为什么还是不能登录？

关闭 Cloud Trust 之后，Windows Hello 终于完成了 Provisioning，用户也可以正常设置 PIN。

但在锁屏界面尝试使用 PIN 登录时，系统仍然提示：

该选项暂时不可用。

请使用其他方式登录。

这一次，问题已经和前面不同了。

前面是 Windows Hello 无法开始 Provisioning；现在 PIN 已经创建成功，说明初始化流程至少已经走完了大半。

接下来需要确认的是：

Windows Hello 是否真的进入了 Authentication，以及认证失败发生在哪一端。

从 Windows Hello 日志确认认证失败

我没有通过 Event Viewer 图形界面检查，而是直接使用 PowerShell 读取 Windows Hello 的 Operational 日志：

Get-WinEvent `
    -LogName "Microsoft-Windows-HelloForBusiness/Operational" `
    -MaxEvents 50 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-List

输出：

TimeCreated Id LevelDisplayName Message ----------- -- ---------------- ------- 
2026-07-17 10:17:39 AM 7001 Error A user failed to sign into the device with the following information:... 
2026-07-17 10:17:39 AM 5702 Information Windows Hello wrote following protector properties to disk: HResult = 0... 
2026-07-17 10:17:38 AM 5002 Information A user is signing into the device with the following gesture informatio... 
2026-07-17 10:15:34 AM 5205 Information Windows Hello for Business on-premise authentication configurations: ... 
2026-07-17 10:12:26 AM 8045 Success Windows Hello processing completed successfully.... 
2026-07-17 10:12:26 AM 8510 Success Windows Hello key registration completed successfully. 
2026-07-17 10:12:25 AM 3510 Information Windows Hello key registration started. 2026-07-17 10:12:25 AM 8225 Success Windows Hello key creation completed successfully.... 
2026-07-17 10:12:25 AM 8067 Success Windows Hello set a certificate property on a Windows Hello key.... 
2026-07-17 10:12:24 AM 5225 Information Creating a hardware Windows Hello key with result 0x0. 
2026-07-17 10:12:24 AM 8632 Success Windows Hello for Business successfully added a user entry to the Usern... 
2026-07-17 10:12:24 AM 5205 Information Windows Hello for Business on-premise authentication configurations: ... 
2026-07-17 10:12:24 AM 5205 Information Windows Hello for Business on-premise authentication configurations: ... 
2026-07-17 10:12:24 AM 3225 Information Windows Hello key creation started. 2026-07-17 10:12:24 AM 8055 Success Windows Hello container provisioning completed successfully.... 
2026-07-17 10:12:24 AM 5702 Information Windows Hello wrote following protector properties to disk: HResult = 0... 
2026-07-17 10:12:24 AM 5702 Information Windows Hello wrote following protector properties to disk: HResult = 0... 
2026-07-17 10:12:24 AM 5225 Information Creating a software Windows Hello key with result 0x0. 2026-07-17 10:12:24 AM 5225 Information Creating a software Windows Hello key with result 0x0. 
2026-07-17 10:12:24 AM 5555 Information Windows Hello is validating that the device can satisfy all applicable ... 
2026-07-17 10:12:24 AM 5702 Information Windows Hello wrote following protector properties to disk: HResult = 0... 
2026-07-17 10:12:17 AM 5004 Information Windows Hello for Business Enabled Policy successfully enforced for the... 
2026-07-17 10:12:17 AM 3055 Information Windows Hello container provisioning started. 
2026-07-17 10:12:17 AM 6611 Warning Windows Hello could not delete the container as no container currently ...

日志中可以看到 Windows Hello 已经成功完成了前面的处理流程，包括密钥创建和注册。查看7001和5702 event：

Get-WinEvent -FilterHashtable @{
    LogName = "Microsoft-Windows-HelloForBusiness/Operational"
    Id      = 7001
} -MaxEvents 3 |
Format-List TimeCreated, Id, LevelDisplayName, Message

Get-WinEvent -FilterHashtable @{
    LogName = "Microsoft-Windows-HelloForBusiness/Operational"
    Id      = 5205
} -MaxEvents 5 |
Format-List TimeCreated, Id, Message

Event 7001 显示：

TimeCreated : 2026-07-17 10:17:47 AM 
Id : 7001 
LevelDisplayName : 
Error Message : A user failed to sign into the device with the following information: 
Username: SYSTEM 
User SID: S-1-5-18 
Credential Type: Software Key Deployment 
Type: Key Trust 
Software Lockout Counter: 0 
Authentication Error Status: 0xC000006D 
Authentication Error Substatus: 0xC0000380

错误代码本身没有直接告诉我哪一项配置有问题，但它至少确认了两件事：

当前部署类型确实是 Key Trust；
失败发生在 Authentication，而不是 Provisioning。

接下来要查的是 Key Trust 认证链本身。

确认 Windows Hello 公钥是否已经写入 AD

Key Trust 的基本逻辑是：

客户端生成一对公私钥；
私钥保存在本地，并由 PIN 解锁；
公钥写入 Active Directory 用户对象；
登录时，Domain Controller 使用该公钥验证客户端签名。

因此，我先检查用户对象的 msDS-KeyCredentialLink 属性：

Get-ADUser test.user `
    -Properties msDS-KeyCredentialLink |
    Select-Object -ExpandProperty msDS-KeyCredentialLink

输出中已经存在多条 Key Credential 数据。

完整内容很长，类似下面这种结构：

B:828:00020000200001...
B:828:00020000200001...

这一步非常关键。

它证明：

Windows Hello 密钥已经成功生成；
公钥已经写入 Active Directory；
Key Registration 已经完成；
Entra Connect 和 AD 用户对象并不是当前的阻塞点。

到这里，客户端该完成的工作基本都已经完成了。

问题开始指向 Domain Controller。

Key Trust 为什么依赖 Domain Controller 证书？

Key Trust 虽然不需要给每个用户签发登录证书，但并不代表整个环境不需要 PKI。

在混合 Key Trust 部署中，Domain Controller 上的 KDC 仍然需要一张合适的 Kerberos 证书，才能完成基于公钥的初始身份验证。

换句话说：

用户不需要证书，但 KDC 需要。

于是，我开始检查 Domain Controller 的 KDC 日志。

Get-WinEvent `
    -LogName "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational" `
    -MaxEvents 50 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-List

日志中出现了 Event 200，核心信息是：

The Key Distribution Center (KDC) cannot find a suitable certificate
to use for smart card logons, or the KDC certificate could not be verified.

这就是第一条真正指向根因的证据。

客户端已经有密钥，AD 里也已经有公钥，但 KDC 没有合适的证书，无法完成 Key Trust 所需要的 Kerberos 公钥认证。

检查 Domain Controller 的证书

接下来，我分别在两台 Domain Controller 上检查本机计算机证书存储：

certutil -store My

结果并不理想。

其中一台 Domain Controller 的本机证书存储中，没有任何可以供 KDC 使用的证书。

另一台虽然有一张证书，但只是历史遗留的自签名证书，并不是由当前受信任的 Enterprise CA 签发的 Kerberos Authentication 证书。

我也没有找到有效的：

Template: Kerberos Authentication

到这里，故障链条已经基本清楚了：

Windows Hello Provisioning
        ↓ 成功

公钥写入 msDS-KeyCredentialLink
        ↓ 成功

客户端使用 PIN 发起 Key Trust 登录
        ↓

Domain Controller 的 KDC 没有合适的 Kerberos 证书
        ↓

Authentication Failed

发现已经退役的 Enterprise CA

继续检查 PKI 环境后，我发现 Active Directory 中仍然发布着旧 Enterprise CA 的对象。

例如：

CONTOSO-DC02-CA
contoso.local

但对应的 CA 服务器早已退役。

也就是说，Active Directory 还保留着旧 PKI 的发布信息，但已经没有一台正常工作的 Enterprise CA 可以：

签发新的 Domain Controller 证书；
处理自动注册；
更新或续订 KDC 所需要的证书。

这也解释了为什么 Domain Controller 一直没有获得有效的 Kerberos Authentication 证书。

问题已经不只是某一张证书过期，而是整个 Enterprise PKI 实际上已经失效。

重新部署 Enterprise CA

由于旧 CA 已经不存在，也没有可以恢复的服务器，我决定重新部署一套 Enterprise Root CA。

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

新的 CA 配置为：

Install-AdcsCertificationAuthority `
    -CAType EnterpriseRootCA `
    -CACommonName "CONTOSO-ROOT-CA" `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256 `
    -ValidityPeriod Years `
    -ValidityPeriodUnits 10 `
    -Force

完成 AD CS 部署后，使用下面的命令确认 CA 已经能够被域环境发现：

certutil -config - -ping

DC01.contoso.local\CONTOSO-ROOT-CA

说明新的 Enterprise CA 已经正常工作。

让 Domain Controller 自动申请证书

Enterprise CA 建立后，我重新触发了组策略和证书自动注册：

gpupdate /force
certutil -pulse

随后再次检查两台 Domain Controller 的本机证书：

certutil -store My

这一次，两台 DC 都成功获得了新的证书，包括：

Kerberos Authentication
Domain Controller Authentication
Directory Email Replication

签发者为：

CONTOSO-ROOT-CA

我还确认了新的 CA 证书已经发布到 Enterprise NTAuth 存储：

certutil -enterprise -verifystore NTAuth

输出中可以看到：

CONTOSO-ROOT-CA

这一步很重要。

只有 CA 被发布并信任到 NTAuth，域控制器签发的认证证书才能被用于域身份验证。

确认 KDC 已经加载新证书

证书申请成功后，我再次检查 KDC Operational 日志：

Get-WinEvent `
    -LogName "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational" `
    -MaxEvents 50 |
    Where-Object Id -in 200, 302 |
    Select-Object TimeCreated, Id, Message |
    Format-List

之前看到的是 Event 200：

No suitable certificate

现在出现了 Event 302，内容表明 KDC 已经选中了新的证书：

Issuer    : CONTOSO-ROOT-CA
Template  : Kerberos Authentication
Thumbprint: <REDACTED>

这说明 PKI 和 KDC 部分已经修复。

到这里，Key Trust 所需要的几个关键条件都已经满足：

Windows Hello Provisioning 成功；
公钥已经写入 Active Directory；
客户端正在使用 Key Trust；
Domain Controller 已获得 Kerberos Authentication 证书；
KDC 已经加载并使用该证书。

最终原因

Intune 中启用了尚未准备好的 Cloud Trust，导致 Windows Hello 最初无法 Provision；
关闭 Cloud Trust 后，Windows Hello 成功创建并注册了 Key Trust 凭据；
旧 Enterprise CA 已经退役，但相关 AD 对象仍然存在；
Domain Controller 没有有效的 Kerberos Authentication 证书；
KDC 因此无法完成 Key Trust Authentication；
重建 Enterprise CA 并重新签发 DC 证书后，KDC 恢复正常；
客户端仍保留着调整前的认证状态，重启后才完整刷新。

Troubleshooting Toolbox

下面是这次 Windows Hello for Business Key Trust 排障中使用到的主要命令。

示例中的名称均已匿名化：

域名：contoso.local
用户：test.user
客户端：CLIENT-01
域控制器：DC01 / DC02
企业 CA：CONTOSO-ROOT-CA

1. 检查设备加入和 Windows Hello 状态

dsregcmd /status

重点检查以下字段：

AzureAdJoined
DomainJoined
DeviceAuthStatus
NgcSet
AzureAdPrt
CloudTgt
OnPremTgt

Windows Hello Provisioning 相关状态位于：

+----------------------------------------------------------------------+
| Ngc Prerequisite Check                                               |
+----------------------------------------------------------------------+

            IsDeviceJoined
             IsUserAzureAD
             PolicyEnabled
          PostLogonEnabled
            DeviceEligible
        SessionIsNotRemote
            CertEnrollment
          AdfsRefreshToken
             AdfsRaIsReady
    LogonCertTemplateReady
              PreReqResult

常见结果：

NgcSet       : NO
PreReqResult : WillNotProvision

表示 Windows Hello 尚未完成 Provisioning。

NgcSet       : YES
PreReqResult : WillProvision

表示设备已经满足 Provisioning 条件，或者 Windows Hello 已完成初始化。

需要查看更详细的设备注册过程时，可以使用：

dsregcmd /status /debug

2. 检查 Windows Hello 策略注册表

检查 Windows Hello 是否被配置为使用 Cloud Trust：

Get-ItemProperty `
    -Path "HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork" `
    -ErrorAction SilentlyContinue

重点观察：

Enabled
UseCertificateForOnPremAuth
UseCloudTrustForOnPremAuth

也可以单独读取：

Get-ItemPropertyValue `
    -Path "HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork" `
    -Name "UseCloudTrustForOnPremAuth" `
    -ErrorAction SilentlyContinue

Get-ItemPropertyValue `
    -Path "HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork" `
    -Name "UseCertificateForOnPremAuth" `
    -ErrorAction SilentlyContinue

我们最终确认的状态是：

UseCloudTrustForOnPremAuth    : 0
UseCertificateForOnPremAuth  : 0

这表示：

没有使用 Cloud Trust；
没有使用 Certificate Trust；
当前部署目标是 Key Trust。

检查完 Intune 策略后，可以强制刷新策略：

gpupdate /force

3. 查询 Windows Hello Operational 日志

列出最近的 Windows Hello 事件：

Get-WinEvent `
    -LogName "Microsoft-Windows-HelloForBusiness/Operational" `
    -MaxEvents 100 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-List

只查看失败或警告事件：

Get-WinEvent `
    -FilterHashtable @{
        LogName = "Microsoft-Windows-HelloForBusiness/Operational"
        Level   = 2, 3
    } `
    -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-List

查看 Authentication 事件：

Get-WinEvent `
    -FilterHashtable @{
        LogName = "Microsoft-Windows-HelloForBusiness/Operational"
        Id      = 7001
    } `
    -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message |
    Format-List

当时看到的关键信息包括：

Deployment Type          : Key Trust
Authentication Error     : 0xC000006D
Authentication SubStatus : 0xC00002F9

后面的测试中还出现过：

Authentication Error : 0xC0000380

查询用于确认部署模式的事件：

Get-WinEvent `
    -FilterHashtable @{
        LogName = "Microsoft-Windows-HelloForBusiness/Operational"
        Id      = 5205
    } `
    -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message |
    Format-List

关键结果：

Certificate Required : False
Use Cloud Trust      : False
Deployment Type      : Key Trust

按关键词过滤日志：

Get-WinEvent `
    -LogName "Microsoft-Windows-HelloForBusiness/Operational" `
    -MaxEvents 200 |
    Where-Object {
        $_.Message -match "Authentication|Key Trust|Cloud Trust|Provision"
    } |
    Select-Object TimeCreated, Id, Message |
    Format-List

4. 检查 Windows Hello Key 是否写入 Active Directory

首先导入 Active Directory 模块：

Import-Module ActiveDirectory

检查用户的 msDS-KeyCredentialLink：

Get-ADUser test.user `
    -Properties msDS-KeyCredentialLink |
    Select-Object SamAccountName, msDS-KeyCredentialLink

只显示 Key Credential 内容：

Get-ADUser test.user `
    -Properties msDS-KeyCredentialLink |
    Select-Object -ExpandProperty msDS-KeyCredentialLink

只统计写入了多少条 Key Credential：

(
    Get-ADUser test.user `
        -Properties msDS-KeyCredentialLink
).msDS-KeyCredentialLink.Count

输出通常类似：

B:828:00020000200001...

这些内容很长，不需要手动解析。

只要属性不是空的，就说明 Windows Hello 公钥已经成功写入用户对象。

5. 检查 AD 和 Forest Functional Level

检查 Forest Functional Level：

Get-ADForest |
    Select-Object Name, ForestMode

检查 Domain Functional Level：

Get-ADDomain |
    Select-Object DNSRoot, DomainMode

当时环境中确认到：

Forest Functional Level : Windows2008R2Forest
Domain Functional Level : Windows2012R2Domain

6. 检查域控制器的本机证书

在 Domain Controller 上查看本机计算机证书存储：

certutil -store My

筛选 Kerberos 相关内容：

certutil -store My |
    Select-String `
        -Pattern "Kerberos Authentication|Domain Controller Authentication|Issuer|Subject|Template"

使用 PowerShell 查看本机证书：

Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Subject, Issuer, Thumbprint, NotBefore, NotAfter,
        EnhancedKeyUsageList

筛选带有 Kerberos Authentication EKU 的证书：

Get-ChildItem Cert:\LocalMachine\My |
    Where-Object {
        $_.EnhancedKeyUsageList.FriendlyName -contains "Kerberos Authentication"
    } |
    Select-Object Subject, Issuer, Thumbprint, NotBefore, NotAfter,
        EnhancedKeyUsageList

检查即将过期的证书：

Get-ChildItem Cert:\LocalMachine\My |
    Where-Object {
        $_.NotAfter -lt (Get-Date).AddDays(60)
    } |
    Select-Object Subject, Issuer, Thumbprint, NotAfter

7. 查询 KDC Operational 日志

列出最近的 KDC 事件：

Get-WinEvent `
    -LogName "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational" `
    -MaxEvents 100 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-List

只查看 Event 200 和 Event 302：

Get-WinEvent `
    -FilterHashtable @{
        LogName = "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational"
        Id      = 200, 302
    } `
    -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-List

Event 200 表示 KDC 找不到合适的证书，常见信息类似：

The Key Distribution Center cannot find a suitable certificate
to use for smart card logons, or the KDC certificate could not
be verified.

Event 302 表示 KDC 已经成功加载证书，关键字段包括：

Issuer
Template
Thumbprint

筛选证书相关 KDC 事件：

Get-WinEvent `
    -LogName "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational" `
    -MaxEvents 200 |
    Where-Object {
        $_.Message -match "certificate|Kerberos Authentication|KDC"
    } |
    Select-Object TimeCreated, Id, Message |
    Format-List

8. 检查 Enterprise CA 是否可用

列出域内可用的 Enterprise CA：

certutil -config - -ping

正常情况下会返回类似：

DC01.contoso.local\CONTOSO-ROOT-CA

查看 Enterprise CA 配置：

certutil -config - -

检查 CA 服务：

Get-Service CertSvc

启动 CA 服务：

Start-Service CertSvc

重启 CA 服务：

Restart-Service CertSvc

检查 AD CS 角色：

Get-WindowsFeature AD-Certificate

列出所有已安装的 AD CS 相关角色服务：

Get-WindowsFeature |
    Where-Object {
        $_.Name -like "ADCS*"
    }

9. 检查 NTAuth Enterprise Store

验证 Enterprise NTAuth 存储：

certutil -enterprise -verifystore NTAuth

在输出中确认新的 CA：

CONTOSO-ROOT-CA

查看 NTAuth 中发布的所有证书：

certutil -enterprise -viewstore NTAuth

也可以从 Active Directory 中读取 NTAuthCertificates 对象：

$configurationNamingContext = (
    Get-ADRootDSE
).configurationNamingContext

Get-ADObject `
    -Identity "CN=NTAuthCertificates,CN=Public Key Services,CN=Services,$configurationNamingContext" `
    -Properties cACertificate

10. 检查 Active Directory 中发布的旧 CA

获取 Configuration Naming Context：

$configurationNamingContext = (
    Get-ADRootDSE
).configurationNamingContext

查看 Enrollment Services 中注册的 Enterprise CA：

Get-ADObject `
    -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,$configurationNamingContext" `
    -LDAPFilter "(objectClass=pKIEnrollmentService)" `
    -Properties * |
    Select-Object Name, dNSHostName, DistinguishedName

查看 Certification Authorities 容器：

Get-ADObject `
    -SearchBase "CN=Certification Authorities,CN=Public Key Services,CN=Services,$configurationNamingContext" `
    -LDAPFilter "(objectClass=certificationAuthority)" `
    -Properties * |
    Select-Object Name, DistinguishedName

查看 AIA 容器：

Get-ADObject `
    -SearchBase "CN=AIA,CN=Public Key Services,CN=Services,$configurationNamingContext" `
    -LDAPFilter "(objectClass=certificationAuthority)" `
    -Properties * |
    Select-Object Name, DistinguishedName

查看 CDP 容器：

Get-ADObject `
    -SearchBase "CN=CDP,CN=Public Key Services,CN=Services,$configurationNamingContext" `
    -Filter * |
    Select-Object Name, ObjectClass, DistinguishedName

这些命令可以帮助确认 Active Directory 中是否仍然残留已经退役的 CA 对象。

不要在没有备份和影响评估的情况下直接删除这些对象。

11. 触发证书自动注册

刷新计算机组策略：

gpupdate /force

触发证书自动注册：

certutil -pulse

以本机系统账户重新触发自动注册：

certutil -pulse

检查自动注册相关事件：

Get-WinEvent `
    -LogName "Microsoft-Windows-CertificateServicesClient-AutoEnrollment/Operational" `
    -MaxEvents 100 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-List

筛选失败事件：

Get-WinEvent `
    -FilterHashtable @{
        LogName = "Microsoft-Windows-CertificateServicesClient-AutoEnrollment/Operational"
        Level   = 2, 3
    } `
    -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message |
    Format-List

完成自动注册后，再次检查证书：

certutil -store My

应当能看到：

Kerberos Authentication
Domain Controller Authentication
Directory Email Replication

快速诊断顺序

遇到类似问题时，可以按照这个顺序进行：

1. dsregcmd /status
2. 检查 NgcSet 和 PreReqResult
3. 检查 Intune Windows Hello 策略
4. 查询 HelloForBusiness Operational 日志
5. 检查 msDS-KeyCredentialLink
6. 查询 KDC Operational 日志
7. 检查 DC 的 Kerberos Authentication 证书
8. 检查 Enterprise CA 和 NTAuth
9. 触发 DC 证书自动注册
10. 确认 KDC Event 302
11. 重启客户端并重新测试 PIN

这套顺序的重点不是把所有命令都运行一遍，而是先判断故障发生在：

Provisioning
        或
Authentication

确定阶段之后，再继续缩小范围。

Windows Hello for Business (Key Trust) Troubleshooting in a Hybrid AD Environment

Thu, 16 Jul 2026 00:00:00 GMT

Recently, while deploying Windows Hello for Business, I ran into a much larger problem than expected. The troubleshooting process lasted two days. In the end, the issue was not caused by a single misconfiguration, but by several historical problems that had accumulated over time and broken the entire authentication chain.

This article documents the full troubleshooting process so that I will not have to repeat the same investigation the next time I encounter a similar issue.

Environment

On-premises Active Directory
Microsoft Entra ID Hybrid Join
Microsoft Intune
Windows Hello for Business
Key Trust deployment
Enterprise CA (AD CS)

The Windows 11 device had already completed Hybrid Join and had been automatically enrolled in Intune.

In theory, deploying a Windows Hello policy should have been enough to allow users to sign in with a PIN. In practice, it was not that simple.

Symptoms

The investigation began with a routine user report.

The user had successfully configured a Windows Hello PIN and expected to use it for future Windows sign-ins.

However, after locking the device and selecting PIN sign-in, Windows displayed the following message:

That option is temporarily unavailable.

For now, please use a different sign-in method.

In other words, the PIN appeared to have been configured successfully, but the actual sign-in attempt was rejected.

At the same time, the Windows Hello settings page showed no obvious problem and did not report that PIN creation had failed.

My first assumption was that the PIN had not actually been provisioned correctly.

The first step was therefore to check the Windows Hello state:


dsregcmd /status

The result showed:


NgcSet : NO

Further down, under the Windows Hello prerequisite check, I found:


PreReqResult : WillNotProvision

This meant the problem had not even reached the authentication stage.

Windows Hello had not completed provisioning.

The first phase of the investigation therefore became:

Why was Windows Hello refusing to begin provisioning?

Phase 1: Getting Windows Hello to Provision

After seeing WillNotProvision, I stopped and reviewed how Windows Hello for Business actually works.

Many people, including me at the beginning of this investigation, think of Windows Hello as simply “setting a PIN.”

That is not what it is.

With Windows Hello for Business, the PIN only unlocks a locally stored key. It is not the user's actual password.

The process can be divided into two main stages:

Provisioning
Authentication

Stage 1: Provisioning

When Windows Hello is enabled for the first time, Windows performs several initialization tasks, including:

Checking whether the device meets the deployment requirements;
Checking whether policy allows Windows Hello to be enabled;
Generating a new public/private key pair in the TPM or software key storage;
Registering the public key with the identity system, such as Active Directory or Microsoft Entra ID;
Completing Windows Hello initialization.

Only after all of these steps are complete can the user successfully create a PIN.

If provisioning fails, the sign-in process never begins.

The value I had found:


PreReqResult : WillNotProvision

confirmed that the process was stopping at this stage.

Stage 2: Authentication

After provisioning is complete, Windows Hello enters its normal day-to-day use phase.

Each time the user enters the PIN, Windows uses the previously generated key to authenticate the user.

If this stage fails, the symptoms are different:

The PIN can be created;
Windows Hello appears to be enabled;
The user still cannot sign in with the PIN.

This became the second problem later in the investigation.

For now, the immediate goal was to get Windows Hello to complete provisioning.

Reviewing the Intune Configuration

Windows Hello for Business has two Intune configuration locations that are easy to confuse.

The first is:

Devices → Windows → Enrollment → Windows Hello for Business

This is the Enrollment configuration.

It controls whether Windows Hello is enabled for devices and includes several basic settings. The second location is:

Devices → Windows → Configuration → Policies

This is a Configuration Profile

It applies more detailed settings to the device, such as PIN complexity, biometric settings, TPM requirements, other Windows settings, and the deployment model to use, such as Cloud Trust, Key Trust, or Certificate Trust. It can be thought of as the broader Windows Hello policy.

Although both locations affect Windows Hello, they serve different purposes.

In simple terms:

Enrollment determines whether Windows Hello can start working;
Configuration Policy determines how Windows Hello should work.

The investigation showed that Cloud Trust had been enabled in the configuration profile, but the on-premises hybrid domain was not ready for it.

Because Cloud Trust and Key Trust had both been tested previously, the environment had switched between the two deployment models several times, and the configuration profile had been modified repeatedly.

Continuing to troubleshoot Cloud Trust was not the best choice.

The environment still contained Windows Server 2012 domain controllers. Although Cloud Trust was not necessarily impossible to deploy, properly validating and rolling it out should have been treated as a separate project rather than something to redesign in the middle of an incident.

The immediate objective was simple:

Restore working PIN sign-in for the user.

I therefore disabled Cloud Trust temporarily and returned to the Key Trust deployment model, which was easier to validate in the existing environment.

After the policy change, I checked the device state again:


dsregcmd /status

The important section was:


+----------------------------------------------------------------------+

| Ngc Prerequisite Check                                               |

+----------------------------------------------------------------------+

  

            IsDeviceJoined : YES

             IsUserAzureAD : YES

             PolicyEnabled : YES

          PostLogonEnabled : YES

            DeviceEligible : YES

        SessionIsNotRemote : YES

            CertEnrollment : enrollment authority

          AdfsRefreshToken : YES

             AdfsRaIsReady : YES

    LogonCertTemplateReady : YES ( StateReady )

              PreReqResult : WillProvision

+----------------------------------------------------------------------+

This time, the user was finally able to create the PIN successfully.

Windows Hello provisioning had completed.

Phase 2: The PIN Was Created, So Why Did Sign-In Still Fail?

After Cloud Trust was disabled, Windows Hello completed provisioning and the user was able to configure a PIN.

However, when the user tried to sign in from the lock screen, Windows still displayed:

That option is temporarily unavailable.

For now, please use a different sign-in method.

This was now a different problem.

Earlier, Windows Hello had been unable to begin provisioning. Now the PIN had been created, which meant the initialization process had at least progressed much further.

The next question was:

Had Windows Hello reached the authentication stage, and where was authentication failing?

Confirming the Authentication Failure in the Windows Hello Logs

I did not use the Event Viewer GUI. Instead, I read the Windows Hello Operational log directly with PowerShell:


Get-WinEvent `

    -LogName "Microsoft-Windows-HelloForBusiness/Operational" `

    -MaxEvents 50 |

    Select-Object TimeCreated, Id, LevelDisplayName, Message |

    Format-List

The output included:


TimeCreated Id LevelDisplayName Message

----------- -- ---------------- -------

2026-07-17 10:17:39 AM 7001 Error A user failed to sign into the device with the following information:...

2026-07-17 10:17:39 AM 5702 Information Windows Hello wrote following protector properties to disk: HResult = 0...

2026-07-17 10:17:38 AM 5002 Information A user is signing into the device with the following gesture informatio...

2026-07-17 10:15:34 AM 5205 Information Windows Hello for Business on-premise authentication configurations: ...

2026-07-17 10:12:26 AM 8045 Success Windows Hello processing completed successfully....

2026-07-17 10:12:26 AM 8510 Success Windows Hello key registration completed successfully.

2026-07-17 10:12:25 AM 3510 Information Windows Hello key registration started.

2026-07-17 10:12:25 AM 8225 Success Windows Hello key creation completed successfully....

2026-07-17 10:12:25 AM 8067 Success Windows Hello set a certificate property on a Windows Hello key....

2026-07-17 10:12:24 AM 5225 Information Creating a hardware Windows Hello key with result 0x0.

2026-07-17 10:12:24 AM 8632 Success Windows Hello for Business successfully added a user entry to the Usern...

2026-07-17 10:12:24 AM 5205 Information Windows Hello for Business on-premise authentication configurations: ...

2026-07-17 10:12:24 AM 5205 Information Windows Hello for Business on-premise authentication configurations: ...

2026-07-17 10:12:24 AM 3225 Information Windows Hello key creation started.

2026-07-17 10:12:24 AM 8055 Success Windows Hello container provisioning completed successfully....

2026-07-17 10:12:24 AM 5702 Information Windows Hello wrote following protector properties to disk: HResult = 0...

2026-07-17 10:12:24 AM 5702 Information Windows Hello wrote following protector properties to disk: HResult = 0...

2026-07-17 10:12:24 AM 5225 Information Creating a software Windows Hello key with result 0x0.

2026-07-17 10:12:24 AM 5225 Information Creating a software Windows Hello key with result 0x0.

2026-07-17 10:12:24 AM 5555 Information Windows Hello is validating that the device can satisfy all applicable ...

2026-07-17 10:12:24 AM 5702 Information Windows Hello wrote following protector properties to disk: HResult = 0...

2026-07-17 10:12:17 AM 5004 Information Windows Hello for Business Enabled Policy successfully enforced for the...

2026-07-17 10:12:17 AM 3055 Information Windows Hello container provisioning started.

2026-07-17 10:12:17 AM 6611 Warning Windows Hello could not delete the container as no container currently ...

The log showed that Windows Hello had successfully completed the earlier stages, including key creation and key registration.

I then queried Events 7001 and 5205 directly:


Get-WinEvent -FilterHashtable @{

    LogName = "Microsoft-Windows-HelloForBusiness/Operational"

    Id      = 7001

} -MaxEvents 3 |

Format-List TimeCreated, Id, LevelDisplayName, Message


Get-WinEvent -FilterHashtable @{

    LogName = "Microsoft-Windows-HelloForBusiness/Operational"

    Id      = 5205

} -MaxEvents 5 |

Format-List TimeCreated, Id, Message

Event 7001 showed:


TimeCreated : 2026-07-17 10:17:47 AM

Id : 7001

LevelDisplayName : Error

Message : A user failed to sign into the device with the following information:

Username: SYSTEM

User SID: S-1-5-18

Credential Type: Software Key

Deployment Type: Key Trust

Software Lockout Counter: 0

Authentication Error Status: 0xC000006D

Authentication Error Substatus: 0xC0000380

The error codes did not identify the exact configuration problem, but they confirmed two important facts:

The active deployment type was Key Trust;
The failure occurred during authentication, not provisioning.

The next step was to inspect the Key Trust authentication chain itself.

Confirming That the Windows Hello Public Key Was Written to Active Directory

The basic Key Trust workflow is:

The client generates a public/private key pair;
The private key remains on the client and is unlocked by the PIN;
The public key is written to the user's Active Directory object;
During sign-in, the domain controller uses that public key to verify the client's signature.

I therefore checked the user's msDS-KeyCredentialLink attribute:


Get-ADUser test.user `

    -Properties msDS-KeyCredentialLink |

    Select-Object -ExpandProperty msDS-KeyCredentialLink

The output contained multiple Key Credential entries.

The complete values were very long and followed a structure similar to:


B:828:00020000200001...

B:828:00020000200001...

This was an important result.

It proved that:

The Windows Hello key had been generated successfully;
The public key had been written to Active Directory;
Key registration had completed;
Entra Connect and the AD user object were not the current blocking point.

At this stage, the client had completed almost everything expected of it.

The investigation began to point toward the domain controllers.

Why Does Key Trust Depend on a Domain Controller Certificate?

Key Trust does not require each user to receive a sign-in certificate, but that does not mean the environment can operate without PKI.

In a hybrid Key Trust deployment, the KDC on the domain controller still requires a suitable Kerberos certificate to complete the initial public-key-based authentication.

In other words:

The user does not need a certificate, but the KDC does.

I then examined the KDC Operational log on the domain controllers:


Get-WinEvent `

    -LogName "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational" `

    -MaxEvents 50 |

    Select-Object TimeCreated, Id, LevelDisplayName, Message |

    Format-List

The log contained Event 200 with the following key message:


The Key Distribution Center (KDC) cannot find a suitable certificate

to use for smart card logons, or the KDC certificate could not be verified.

This was the first piece of evidence that pointed directly toward the root cause.

The client had a key, and Active Directory contained the public key, but the KDC did not have a suitable certificate and therefore could not complete the Kerberos public-key authentication required by Key Trust.

Checking the Domain Controller Certificates

I checked the Local Computer certificate store on both domain controllers:


certutil -store My

The results were not good.

One domain controller had no certificate that the KDC could use.

The other had only an old self-signed certificate. It was not a valid Kerberos Authentication certificate issued by a currently trusted Enterprise CA.

I also could not find a valid certificate with:


Template: Kerberos Authentication

At this point, the failure chain was becoming clear:


Windows Hello provisioning

        ↓ Successful

  

Public key written to msDS-KeyCredentialLink

        ↓ Successful

  

Client attempts Key Trust PIN sign-in

        ↓

  

The KDC on the domain controller has no suitable Kerberos certificate

        ↓

  

Authentication fails

Discovering a Retired Enterprise CA

Further PKI investigation showed that Active Directory still contained objects for old Enterprise CAs.

For example:


CONTOSO-DC02-CA

contoso.local

However, the corresponding CA servers had already been retired.

Active Directory still contained the published PKI information, but there was no functioning Enterprise CA capable of:

Issuing new domain controller certificates;
Processing certificate auto-enrollment;
Renewing or replacing the certificates required by the KDC

This explained why the domain controllers had never received a valid Kerberos Authentication certificate.

The issue was no longer just one expired certificate. The Enterprise PKI itself was effectively no longer operational.

Redeploying the Enterprise CA

Because the old CA no longer existed and there was no server available to recover, I deployed a new Enterprise Root CA.


Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

The new CA was configured with:


Install-AdcsCertificationAuthority `

    -CAType EnterpriseRootCA `

    -CACommonName "CONTOSO-ROOT-CA" `

    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `

    -KeyLength 4096 `

    -HashAlgorithmName SHA256 `

    -ValidityPeriod Years `

    -ValidityPeriodUnits 10 `

    -Force

After AD CS was installed, I verified that the CA could be discovered from the domain:


certutil -config - -ping

The command returned:


DC01.contoso.local\CONTOSO-ROOT-CA

This confirmed that the new Enterprise CA was available.

Triggering Domain Controller Certificate Enrollment

After the Enterprise CA was operational, I refreshed Group Policy and triggered certificate auto-enrollment:


gpupdate /force

certutil -pulse

I then checked the Local Computer certificate store on both domain controllers again:


certutil -store My

This time, both domain controllers had successfully obtained new certificates, including:


Kerberos Authentication

Domain Controller Authentication

Directory Email Replication

The issuer was:


CONTOSO-ROOT-CA

I also confirmed that the new CA certificate had been published to the Enterprise NTAuth store:


certutil -enterprise -verifystore NTAuth

The output contained:


CONTOSO-ROOT-CA

This step matters because a domain controller authentication certificate must chain to a CA that is trusted through NTAuth before it can be used for domain authentication.

Confirming That the KDC Loaded the New Certificate

After certificate enrollment completed, I checked the KDC Operational log again:


Get-WinEvent `

    -LogName "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational" `

    -MaxEvents 50 |

    Where-Object Id -in 200, 302 |

    Select-Object TimeCreated, Id, Message |

    Format-List

Previously, Event 200 had reported:


No suitable certificate

Now Event 302 appeared and showed that the KDC had selected the new certificate:


Issuer    : CONTOSO-ROOT-CA

Template  : Kerberos Authentication

Thumbprint: <REDACTED>

This confirmed that the PKI and KDC portions of the authentication chain had been repaired.

At this point, all major Key Trust requirements were satisfied:

Windows Hello provisioning had completed;
The public key had been written to Active Directory;
The client was using Key Trust;
The domain controllers had received Kerberos Authentication certificates;
The KDC had loaded and was using the certificate.

Root Cause

The incident was caused by several overlapping problems:

Cloud Trust had been enabled in Intune even though the environment was not ready for it, preventing Windows Hello from provisioning initially;
After Cloud Trust was disabled, Windows Hello successfully created and registered Key Trust credentials;
The old Enterprise CA had been retired, but related AD objects still remained;
The domain controllers did not have valid Kerberos Authentication certificates;
The KDC therefore could not complete Key Trust authentication;
After the Enterprise CA was rebuilt and new domain controller certificates were issued, the KDC began functioning normally again;
The client still retained authentication state from before the repair, and a reboot was required before the corrected state was fully loaded

Troubleshooting Toolbox

The following commands were used during this Windows Hello for Business Key Trust investigation.

The names in the examples have been anonymized:


Domain: contoso.local

User: test.user

Client: CLIENT-01

Domain controllers: DC01 / DC02

Enterprise CA: CONTOSO-ROOT-CA

1. Check Device Join and Windows Hello Status


dsregcmd /status

Review these fields:


AzureAdJoined

DomainJoined

DeviceAuthStatus

NgcSet

AzureAdPrt

CloudTgt

OnPremTgt

Windows Hello provisioning status appears under:


+----------------------------------------------------------------------+

| Ngc Prerequisite Check                                               |

+----------------------------------------------------------------------+

  

            IsDeviceJoined

             IsUserAzureAD

             PolicyEnabled

          PostLogonEnabled

            DeviceEligible

        SessionIsNotRemote

            CertEnrollment

          AdfsRefreshToken

             AdfsRaIsReady

    LogonCertTemplateReady

              PreReqResult

Common results:


NgcSet       : NO

PreReqResult : WillNotProvision

This indicates that Windows Hello provisioning has not completed.


NgcSet       : YES

PreReqResult : WillProvision

This indicates that the device meets the provisioning requirements or that Windows Hello has already been initialized.

For more detailed device registration information:


dsregcmd /status /debug

2. Check Windows Hello Policy Registry Values

Check whether Windows Hello is configured to use Cloud Trust:


Get-ItemProperty `

    -Path "HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork" `

    -ErrorAction SilentlyContinue

Review:


Enabled

UseCertificateForOnPremAuth

UseCloudTrustForOnPremAuth

The values can also be queried individually:


Get-ItemPropertyValue `

    -Path "HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork" `

    -Name "UseCloudTrustForOnPremAuth" `

    -ErrorAction SilentlyContinue


Get-ItemPropertyValue `

    -Path "HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork" `

    -Name "UseCertificateForOnPremAuth" `

    -ErrorAction SilentlyContinue

The final state in this case was:


UseCloudTrustForOnPremAuth   : 0

UseCertificateForOnPremAuth : 0

This means:

Cloud Trust is not being used;
Certificate Trust is not being used;
The intended deployment model is Key Trust.

After changing the Intune policy, force a policy refresh:


gpupdate /force

3. Query the Windows Hello Operational Log

List recent Windows Hello events:


Get-WinEvent `

    -LogName "Microsoft-Windows-HelloForBusiness/Operational" `

    -MaxEvents 100 |

    Select-Object TimeCreated, Id, LevelDisplayName, Message |

    Format-List

Show only warning and error events:


Get-WinEvent `

    -FilterHashtable @{

        LogName = "Microsoft-Windows-HelloForBusiness/Operational"

        Level   = 2, 3

    } `

    -ErrorAction SilentlyContinue |

    Select-Object TimeCreated, Id, LevelDisplayName, Message |

    Format-List

Query authentication failures:


Get-WinEvent `

    -FilterHashtable @{

        LogName = "Microsoft-Windows-HelloForBusiness/Operational"

        Id      = 7001

    } `

    -ErrorAction SilentlyContinue |

    Select-Object TimeCreated, Id, Message |

    Format-List

Important values observed during the incident included:


Deployment Type          : Key Trust

Authentication Error     : 0xC000006D

Authentication SubStatus : 0xC00002F9

A later test also produced:


Authentication Error : 0xC0000380

Query the event that confirms the deployment configuration:


Get-WinEvent `

    -FilterHashtable @{

        LogName = "Microsoft-Windows-HelloForBusiness/Operational"

        Id      = 5205

    } `

    -ErrorAction SilentlyContinue |

    Select-Object TimeCreated, Id, Message |

    Format-List

Important values:


Certificate Required : False

Use Cloud Trust      : False

Deployment Type      : Key Trust

Filter by relevant keywords:


Get-WinEvent `

    -LogName "Microsoft-Windows-HelloForBusiness/Operational" `

    -MaxEvents 200 |

    Where-Object {

        $_.Message -match "Authentication|Key Trust|Cloud Trust|Provision"

    } |

    Select-Object TimeCreated, Id, Message |

    Format-List

4. Check Whether the Windows Hello Key Was Written to Active Directory

Import the Active Directory module:


Import-Module ActiveDirectory

Inspect the user's msDS-KeyCredentialLink attribute:


Get-ADUser test.user `

    -Properties msDS-KeyCredentialLink |

    Select-Object SamAccountName, msDS-KeyCredentialLink

Show only the Key Credential values:


Get-ADUser test.user `

    -Properties msDS-KeyCredentialLink |

    Select-Object -ExpandProperty msDS-KeyCredentialLink

Count the number of Key Credential entries:


(

    Get-ADUser test.user `

        -Properties msDS-KeyCredentialLink

).msDS-KeyCredentialLink.Count

The output usually resembles:


B:828:00020000200001...

The values are long and normally do not need to be parsed manually.

If the attribute is not empty, the Windows Hello public key has been written to the user's AD object.

5. Check Domain and Forest Functional Levels

Check the forest functional level:


Get-ADForest |

    Select-Object Name, ForestMode

Check the domain functional level:


Get-ADDomain |

    Select-Object DNSRoot, DomainMode

The environment in this case reported:


Forest Functional Level : Windows2008R2Forest

Domain Functional Level : Windows2012R2Domain

6. Check Local Certificates on the Domain Controllers

View the Local Computer personal certificate store:


certutil -store My

Filter for Kerberos-related information:


certutil -store My |

    Select-String `

        -Pattern "Kerberos Authentication|Domain Controller Authentication|Issuer|Subject|Template"

Inspect certificates with PowerShell:


Get-ChildItem Cert:\LocalMachine\My |

    Select-Object Subject, Issuer, Thumbprint, NotBefore, NotAfter,

        EnhancedKeyUsageList

Find certificates with the Kerberos Authentication EKU:


Get-ChildItem Cert:\LocalMachine\My |

    Where-Object {

        $_.EnhancedKeyUsageList.FriendlyName -contains "Kerberos Authentication"

    } |

    Select-Object Subject, Issuer, Thumbprint, NotBefore, NotAfter,

        EnhancedKeyUsageList

Find certificates that expire within 60 days:


Get-ChildItem Cert:\LocalMachine\My |

    Where-Object {

        $_.NotAfter -lt (Get-Date).AddDays(60)

    } |

    Select-Object Subject, Issuer, Thumbprint, NotAfter

7. Query the KDC Operational Log

List recent KDC events:


Get-WinEvent `

    -LogName "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational" `

    -MaxEvents 100 |

    Select-Object TimeCreated, Id, LevelDisplayName, Message |

    Format-List

Show only Events 200 and 302:


Get-WinEvent `

    -FilterHashtable @{

        LogName = "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational"

        Id      = 200, 302

    } `

    -ErrorAction SilentlyContinue |

    Select-Object TimeCreated, Id, LevelDisplayName, Message |

    Format-List

Event 200 indicates that the KDC cannot find a suitable certificate. A typical message is:


The Key Distribution Center cannot find a suitable certificate

to use for smart card logons, or the KDC certificate could not

be verified.

Event 302 indicates that the KDC has successfully loaded a certificate. Important fields include:


Issuer

Template

Thumbprint

Filter certificate-related KDC events:


Get-WinEvent `

    -LogName "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational" `

    -MaxEvents 200 |

    Where-Object {

        $_.Message -match "certificate|Kerberos Authentication|KDC"

    } |

    Select-Object TimeCreated, Id, Message |

    Format-List

8. Check Whether the Enterprise CA Is Available

List Enterprise CAs available in the domain:


certutil -config - -ping

A working result should resemble:


DC01.contoso.local\CONTOSO-ROOT-CA

View Enterprise CA configuration:


certutil -config - -

Check the CA service:


Get-Service CertSvc

Start the CA service:


Start-Service CertSvc

Restart the CA service:


Restart-Service CertSvc

Check the AD CS role:


Get-WindowsFeature AD-Certificate

List installed AD CS role services:


Get-WindowsFeature |

    Where-Object {

        $_.Name -like "ADCS*"

    }

9. Check the Enterprise NTAuth Store

Verify the Enterprise NTAuth store:


certutil -enterprise -verifystore NTAuth

Confirm that the new CA appears in the output:


CONTOSO-ROOT-CA

View all certificates published to NTAuth:


certutil -enterprise -viewstore NTAuth

The NTAuthCertificates object can also be read directly from Active Directory:


$configurationNamingContext = (

    Get-ADRootDSE

).configurationNamingContext

  

Get-ADObject `

    -Identity "CN=NTAuthCertificates,CN=Public Key Services,CN=Services,$configurationNamingContext" `

    -Properties cACertificate

10. Check for Old CA Objects Published in Active Directory

Get the Configuration Naming Context:


$configurationNamingContext = (

    Get-ADRootDSE

).configurationNamingContext

List Enterprise CAs registered under Enrollment Services:


Get-ADObject `

    -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,$configurationNamingContext" `

    -LDAPFilter "(objectClass=pKIEnrollmentService)" `

    -Properties * |

    Select-Object Name, dNSHostName, DistinguishedName

Inspect the Certification Authorities container:


Get-ADObject `

    -SearchBase "CN=Certification Authorities,CN=Public Key Services,CN=Services,$configurationNamingContext" `

    -LDAPFilter "(objectClass=certificationAuthority)" `

    -Properties * |

    Select-Object Name, DistinguishedName

Inspect the AIA container:


Get-ADObject `

    -SearchBase "CN=AIA,CN=Public Key Services,CN=Services,$configurationNamingContext" `

    -LDAPFilter "(objectClass=certificationAuthority)" `

    -Properties * |

    Select-Object Name, DistinguishedName

Inspect the CDP container:


Get-ADObject `

    -SearchBase "CN=CDP,CN=Public Key Services,CN=Services,$configurationNamingContext" `

    -Filter * |

    Select-Object Name, ObjectClass, DistinguishedName

These commands help identify objects for retired CAs that may still remain in Active Directory.

Do not delete these objects without a backup and an impact assessment.

11. Trigger Certificate Auto-Enrollment

Refresh computer Group Policy:


gpupdate /force

Trigger certificate auto-enrollment:


certutil -pulse

Check certificate auto-enrollment events:


Get-WinEvent `

    -LogName "Microsoft-Windows-CertificateServicesClient-AutoEnrollment/Operational" `

    -MaxEvents 100 |

    Select-Object TimeCreated, Id, LevelDisplayName, Message |

    Format-List

Show only warning and error events:


Get-WinEvent `

    -FilterHashtable @{

        LogName = "Microsoft-Windows-CertificateServicesClient-AutoEnrollment/Operational"

        Level   = 2, 3

    } `

    -ErrorAction SilentlyContinue |

    Select-Object TimeCreated, Id, Message |

    Format-List

After auto-enrollment completes, check the certificate store again:


certutil -store My

The domain controller should now have certificates such as:


Kerberos Authentication

Domain Controller Authentication

Directory Email Replication

Quick Diagnostic Order

For similar incidents, use the following sequence:


1. Run dsregcmd /status

2. Check NgcSet and PreReqResult

3. Review the Intune Windows Hello policies

4. Query the HelloForBusiness Operational log

5. Check msDS-KeyCredentialLink

6. Query the KDC Operational log

7. Check the domain controller's Kerberos Authentication certificate

8. Check the Enterprise CA and NTAuth

9. Trigger domain controller certificate auto-enrollment

10. Confirm KDC Event 302

11. Reboot the client and test PIN sign-in again

The purpose of this sequence is not to run every command blindly. The first objective is to determine whether the failure occurs during:


Provisioning

        or

Authentication

Once the failed stage is identified, the investigation can be narrowed accordingly.

Complete Troubleshooting Guide for Windows Time Synchronization Issues in an Active Directory Domain

Fri, 10 Jul 2026 00:00:00 GMT

Introduction

In Active Directory, time synchronization is a foundation for almost every authentication process.

Kerberos, Active Directory replication, certificates, Group Policy, and many other components all depend on accurate time.

The recommended domain time hierarchy is not complicated:

Internet NTP
     │
     ▼
PDC Emulator
     │
     ▼
Other Domain Controllers
     │
     ▼
Domain Members

However, we encountered an unusual issue in our environment:

The PDC Emulator was already configured to use public NTP servers
The Domain Controllers could communicate with one another
DNS was working
Active Directory was healthy
The Secure Channel was healthy

Yet some Domain Controllers continued to use:

Local CMOS Clock

The final investigation showed that the issue was not with the public NTP servers, DNS, basic network connectivity, or Active Directory itself. The fault was isolated to the local Windows Time Service configuration or service state on the affected Domain Controller.

This article documents the complete troubleshooting process and the reasoning that proved most useful along the way.

NTP Fundamentals in an Active Directory Domain

Before troubleshooting, it is important to understand how time synchronization works in a Windows domain.

In a workgroup environment, each Windows device can synchronize directly with a specified public NTP server. In an Active Directory environment, however, Windows normally relies on the domain hierarchy provided by Windows Time Service.

The Windows Time Service is named:

W32Time

It maintains the Windows system clock and provides the time foundation required by Kerberos, Active Directory, certificate validation, and other time-sensitive services.

Why Time Matters in a Domain

Active Directory does not require every device to have exactly the same clock value, but the difference between systems must stay within an acceptable range.

Kerberos is the most common example. Kerberos tickets include timestamps to help prevent replay attacks. If a client, server, and Domain Controller differ too much in time, the environment may experience:

Users being unable to sign in with domain accounts
Kerberos authentication failures
Repeated password prompts when accessing file shares
Group Policy processing failures
Active Directory replication or Secure Channel problems
Certificates being treated as not yet valid or already expired
Inconsistent timestamps across logs

Time synchronization in a domain is therefore not only about displaying the correct time in the taskbar. It is part of the authentication architecture itself.

Domain Time Hierarchy

In a single-forest, single-domain environment, the standard time hierarchy normally looks like this:

Public NTP Server
        │
        ▼
Forest Root Domain PDC Emulator
        │
        ▼
Other Domain Controllers
        │
        ▼
Domain Member Servers and Workstations

The PDC Emulator in the forest root domain sits at the top of the domain time hierarchy.

It should obtain time from a reliable external source, such as:

An internal GPS clock
A trusted network device
A public NTP service

Other domain devices then synchronize through the Active Directory hierarchy.

The Role of the PDC Emulator

Active Directory has five FSMO roles. In addition to password updates, account lockout handling, and compatibility-related functions, the PDC Emulator also has a central role in domain time synchronization.

To identify the current PDC Emulator:

netdom query fsmo

You can also use the Active Directory PowerShell module:

Get-ADDomain | Select-Object PDCEmulator

Only the current PDC Emulator should normally be explicitly configured as the reliable external time source for the domain.

For example:

w32tm /config `
    /manualpeerlist:"time.cloudflare.com,0x8 time.google.com,0x8" `
    /syncfromflags:manual `
    /reliable:yes `
    /update

The parameters mean:

/manualpeerlist: Specifies the external NTP peers
/syncfromflags:manual: Uses the manually configured time sources
/reliable:yes: Marks the server as a reliable time source for the domain
/update: Tells Windows Time Service to reload its configuration

After configuration, restart the service and request synchronization:

Restart-Service w32time
w32tm /resync /force

The Difference Between `NT5DS` and `NTP`

Use the following command to view the current synchronization mode:

w32tm /query /configuration

The most important value is:

Type

`Type: NTP`

This means the computer uses manually specified NTP peers.

This mode is commonly appropriate for:

The PDC Emulator
Non-domain devices
Special isolated systems
Devices that cannot use the Active Directory time hierarchy

`Type: NT5DS`

This means the computer discovers a time source through the Active Directory domain hierarchy.

This mode is normally appropriate for:

Non-PDC Domain Controllers
Domain member servers
Domain-joined workstations

A non-PDC server should generally not point directly to a public NTP server. It should remain configured as:

Type: NT5DS

Member Servers Do Not Always Synchronize Directly with the PDC

Using NT5DS does not mean that every domain member connects directly to the PDC Emulator.

A member server may show:

Source: DC01.example.local

instead of:

Source: PDC01.example.local

This is not necessarily a problem.

As long as DC01 ultimately receives correct time from the PDC Emulator, the following chain is valid:

Public NTP
    │
    ▼
PDC Emulator
    │
    ▼
DC01
    │
    ▼
Member Server

When validating time synchronization, do not look only at whether one server points directly to the PDC. Confirm that the complete upstream chain ultimately traces back to the PDC Emulator.

Useful Diagnostic Commands

View the current time source:

w32tm /query /source

View detailed synchronization status:

w32tm /query /status

View the full configuration:

w32tm /query /configuration

View manually configured peers:

w32tm /query /peers

Check the time status of all Domain Controllers:

w32tm /monitor

Measure the time offset from a specified source:

w32tm /stripchart /computer:PDC01.example.local /samples:5 /dataonly

View recent Windows Time Service events:

Get-WinEvent -LogName System |
    Where-Object {
        $_.ProviderName -eq "Microsoft-Windows-Time-Service"
    } |
    Select-Object -First 20 `
        TimeCreated,
        Id,
        LevelDisplayName,
        Message

Troubleshooting Environment

All server names, domain names, and IP addresses in this article have been anonymized.

The affected environment was a long-running, single-forest, single-domain Active Directory deployment with four Domain Controllers:

Example Name	Role	Expected Time Source
PDC01	PDC Emulator and FSMO role holder	External public NTP
DC01	Standard Domain Controller	Domain hierarchy
DC02	Standard Domain Controller	Domain hierarchy
DC03	Standard Domain Controller	Domain hierarchy

The domain also contained multiple Windows member servers and workstations.

The expected time architecture was:

External NTP
      │
      ▼
PDC01 — PDC Emulator
      │
      ▼
DC01 / DC02 / DC03
      │
      ▼
Member Servers and Workstations

The intended configuration was:

PDC01 uses Type: NTP
PDC01 is the only server explicitly configured as the reliable external time source
Other Domain Controllers use Type: NT5DS
Member servers and workstations use Type: NT5DS
Domain members may synchronize with another healthy Domain Controller instead of connecting directly to the PDC

Symptoms

On the affected Domain Controller, I first checked the current time source:

w32tm /query /source

The result was:

Local CMOS Clock

I then checked the detailed status:

w32tm /query /status

The important values were:

Stratum: 1
ReferenceId: LOCL
Source: Local CMOS Clock

This meant that the Domain Controller was not using an upstream domain time source. It was relying directly on its own hardware clock.

For a non-PDC Domain Controller, this was clearly not the expected state.

Step 1: Identify the PDC Emulator

I first confirmed all FSMO role holders:

netdom query fsmo

The output showed that all FSMO roles were located on:

PDC01.example.local

The PDC role also correctly pointed to PDC01.

I then used the PDC Locator directly:

nltest /dsgetdc:example.local /PDC

The result was similar to:

DC: \\PDC01.example.local
Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV

This confirmed that Active Directory could correctly identify the current PDC Emulator.

Step 2: Validate the PDC External Time Source

On PDC01, I checked the current time source:

w32tm /query /source

The output showed the configured public sources:

time.cloudflare.com,time.google.com

I then checked the synchronization status:

w32tm /query /status

The important values were similar to:

Leap Indicator: 0 (no warning)
Stratum: 4
Source: time.cloudflare.com,time.google.com
Last Successful Sync Time: <timestamp>

Next, I reviewed the complete configuration:

w32tm /query /configuration

The important values were:

Type: NTP
AnnounceFlags: 5
NtpServer: time.cloudflare.com,time.google.com

These results confirmed that:

The PDC Emulator could synchronize with the external NTP sources
Windows Time Service was running correctly on the PDC
The external NTP configuration was not the main cause of the incident

Step 3: Inspect the Actual Configuration on the Affected DC

Back on DC01, I checked the full configuration:

w32tm /query /configuration

The key result was:

Type: NT5DS

This meant DC01 was configured to discover a time source through the Active Directory domain hierarchy.

As a non-PDC Domain Controller, it should locate an appropriate upstream domain time source. In this single-domain environment, its time chain should ultimately trace back to the PDC Emulator.

However, another source check still returned:

w32tm /query /source

Local CMOS Clock

This revealed the first major contradiction:

The configuration said the server should use NT5DS
The actual runtime state showed Local CMOS Clock

For this reason, Type: NT5DS alone was not enough to conclude that the server was healthy. The configuration had to be compared with the active source and synchronization status.

Step 4: Use `w32tm /monitor` to Check the Entire Domain

To determine whether the problem affected only DC01, I ran:

w32tm /monitor

The output showed several notable conditions:

DC01
    RefID: LOCL
    Stratum: 1
    Offset: approximately -61 seconds

PDC01
    RefID: external NTP source
    Stratum: 4

DC02
    RefID: another external NTP source

DC03
    NTP query timeout

This suggested that the environment had more than one time configuration issue:

DC01 had fallen back to Local CMOS Clock
DC02 might still have a historical configuration that synchronized directly with a public NTP source
DC03 did not respond to the NTP query
Only PDC01 matched the expected design

Although the incident was first noticed on DC01, the monitor output exposed historical inconsistencies across the domain time configuration.

Step 5: Validate the Active Directory Foundation

Because NT5DS depends on Active Directory to discover a domain time peer, I next verified that DC01 could access the domain, locate the PDC, and maintain a healthy Secure Channel.

Check the Secure Channel

Test-ComputerSecureChannel -Verbose

Output:

True

I also verified it with:

nltest /sc_verify:example.local

Result:

NERR_Success

This confirmed that the machine account and Secure Channel were healthy.

Locate the PDC Emulator Explicitly

nltest /dsgetdc:example.local /PDC

Result:

DC: \\PDC01.example.local

This confirmed that the PDC Locator worked correctly.

List All Domain Controllers

nltest /dclist:example.local

All Domain Controllers appeared in the list, and PDC01 was correctly marked as the PDC.

Confirm the FSMO Roles Again

netdom query fsmo

The roles still pointed correctly to PDC01.

Check DNS and Basic Connectivity

nslookup PDC01

The name resolved successfully.

ping PDC01

Basic network connectivity was also successful.

At this stage, the following components had been validated:

Secure Channel
DC Locator
PDC Locator
FSMO role ownership
DNS
Basic network communication

The issue still remained.

Step 6: Review the Windows Time Service Logs

I then reviewed Windows Time Service events in the System log:

Get-WinEvent -LogName System |
    Where-Object {
        $_.ProviderName -eq "Microsoft-Windows-Time-Service"
    } |
    Select-Object -First 20 `
        TimeCreated,
        Id,
        LevelDisplayName,
        Message

The log contained Event ID 129:

NtpClient was unable to set a domain peer to use as a time source because of discovery error.

The error was:

The entry is not found.

This was the most important event in the investigation.

It showed that the problem was not simply that Windows had selected a time source but failed to receive time data.

More precisely, Windows Time Service failed during the domain peer discovery stage.

In other words:

This was not merely NTP packet loss after selecting the PDC
W32Time had failed to establish the Domain Peer it was supposed to use

That distinction changed the direction of the troubleshooting process.

Step 7: Analyze the Local W32Time Configuration

I checked the configuration again:

w32tm /query /configuration

The following combination appeared:

Type: NT5DS
AnnounceFlags: 5

Type: NT5DS meant that the server should discover its time source through the Active Directory hierarchy.

AnnounceFlags: 5 is commonly associated with a server advertising itself as a reliable time source.

It is important to note that a Domain Controller acting as both a time client and a time server is not inherently a conflict. A DC can synchronize from an upstream server while providing time to downstream domain members.

The important issue was the combination of the following facts:

DC01 was not the current PDC Emulator
It was still marked as a reliable time source
It was using only Local CMOS Clock
Windows Time Service was reporting a Domain Peer discovery failure

This suggested that the local W32Time configuration or service state on DC01 might contain historical manual settings, remnants from a previous role configuration, or another inconsistent local state.

AnnounceFlags: 5 alone did not prove that it was the only direct cause of Event ID 129. However, when combined with all other findings, it was reasonable to isolate the fault to the local Windows Time Service configuration or state on DC01.

At this point, repeatedly running the following command was unlikely to help:

w32tm /resync

The service had not established a valid Domain Peer in the first place.

Step 8: Re-register Windows Time Service

Instead of adding more registry settings or NTP configuration on top of the existing state, I decided to return Windows Time Service to a cleaner default state.

Stop the service:

net stop w32time

Unregister Windows Time Service:

w32tm /unregister

w32tm /register

Start the service:

net start w32time

Then explicitly restore the expected domain hierarchy mode for a non-PDC Domain Controller:

w32tm /config /syncfromflags:domhier /reliable:no /update

Finally, request synchronization and force domain rediscovery:

w32tm /resync /rediscover

Note that the following command does not exist as a standalone command:

w32tm /rediscover

/rediscover must be used as a parameter of /resync.

Step 9: Verify the Repair

After the repair, I checked the source again:

w32tm /query /source

The result immediately changed to:

PDC01.example.local

This confirmed that Windows Time Service had rediscovered the correct domain time source.

I then checked:

w32tm /query /status

The important values to confirm were:

Source pointed to a healthy domain time source
Last Successful Sync Time had updated
ReferenceId was no longer LOCL
Stratum was no longer the local reference clock value of 1

I also reviewed the complete configuration again:

w32tm /query /configuration

The server still correctly showed:

Type: NT5DS

and the non-PDC Domain Controller was no longer configured as a reliable root time source.

Finally, I checked the recent events again:

Get-WinEvent -LogName System |
    Where-Object {
        $_.ProviderName -eq "Microsoft-Windows-Time-Service"
    } |
    Select-Object -First 10 `
        TimeCreated,
        Id,
        LevelDisplayName,
        Message

No new Event ID 129 entries continued to appear after the repair.

Step 10: Why Some Member Servers Still Synchronized with DC01

After DC01 was repaired, I checked several member servers and found that:

w32tm /query /source

returned:

DC01.example.local

At first, this could suggest that a Group Policy had previously forced those servers to use DC01.

I then checked:

w32tm /query /configuration

The important values were:

Type: NT5DS (Local)
AnnounceFlags: 10 (Local)
NtpServer Enabled: 0 (Local)

This showed that:

The server was not using a manually configured NTP peer
The local NTP Server Provider was disabled
The server was automatically selecting a source through the Active Directory hierarchy
Selecting DC01 as its current time partner was normal behavior

The actual time chain was:

External NTP
      │
      ▼
PDC01
      │
      ▼
DC01
      │
      ▼
Member Server

As long as DC01 remained synchronized with PDC01, this was a normal and supported domain time hierarchy.

Additional Check: Was the Configuration Applied by Group Policy?

You can generate a Resultant Set of Policy report with:

gpresult /h C:\Temp\gpresult.html

Search the report for:

Configure Windows NTP Client
Enable Windows NTP Client
Enable Windows NTP Server

w32tm /query /configuration also shows the effective source of each setting, for example:

Type: NT5DS (Local)

In this case, the effective configuration appeared as a local default state. There was no evidence that Group Policy had forced the member server to use a specific NTP server.

Root Cause and Evidence Boundaries

The investigation confirmed that the problem was not caused by:

The PDC Emulator external NTP configuration
DNS name resolution
Active Directory DC Locator
The Secure Channel
Basic communication between Domain Controllers

The fault was isolated to Windows Time Service on DC01.

The DC01 configuration contained:

Type: NT5DS
AnnounceFlags: 5

This showed that the effective W32Time configuration did not fully match the server's current role.

However, AnnounceFlags: 5 alone was not enough to prove that it was the sole direct cause of Event ID 129.

What could be confirmed was:

W32Time could not establish a valid Domain Peer
After re-registering W32Time and restoring domhier, DC01 immediately began synchronizing with PDC01
The fault therefore existed in the local Windows Time Service configuration or service state on DC01
Active Directory, DNS, the network, and the PDC Emulator were not the primary causes of the incident

Final Time Synchronization Architecture

The domain should maintain the following design:

External NTP
      │
      ▼
PDC Emulator — the only server explicitly configured with public NTP
      │
      ▼
Other Domain Controllers — NT5DS
      │
      ▼
Member Servers and Workstations — NT5DS

The main rules are:

Only the PDC Emulator is configured with public NTP servers
Other Domain Controllers use NT5DS
Domain members use NT5DS
Member servers may synchronize with any healthy Domain Controller
Every time chain should ultimately trace back to the PDC Emulator

Troubleshooting Approach Summary

The most valuable part of this incident was not the final repair command. It was the process of narrowing the fault domain step by step.

When a server shows:

Local CMOS Clock

it is not safe to assume immediately that the public NTP service, UDP 123, or a firewall is the problem.

A better approach is to identify the server's role in the domain hierarchy and determine at which stage the time source was lost.

General Troubleshooting Sequence

Identify the device role
      │
      ▼
Confirm the PDC Emulator and FSMO roles
      │
      ▼
Validate the PDC external NTP source
      │
      ▼
Check Source, Status, and Type on the affected server
      │
      ▼
Use w32tm /monitor to inspect the entire domain
      │
      ▼
Validate Secure Channel, DNS, and PDC Locator
      │
      ▼
Review Windows Time Service events
      │
      ▼
Determine whether the failure is discovery, communication, or local configuration
      │
      ▼
Restore W32Time and rejoin the domain time hierarchy
      │
      ▼
Validate the complete synchronization chain

Common Symptoms and What to Check First


Symptom	First Checks
PDC uses `Local CMOS Clock`	External NTP, UDP 123, PDC configuration
Non-PDC DC uses `Local CMOS Clock`	`NT5DS`, DC Locator, Event ID 129
`No time data was available`	Current peer, network connectivity, event logs
Standard DC shows `Type: NTP`	Historical manual configuration or Group Policy
Member server synchronizes with a standard DC	Usually normal; validate the upstream chain
`w32tm /monitor` times out	W32Time service, firewall, UDP 123
`RefID: LOCL`	The computer is currently using its local clock

The Most Important Diagnostic Principle

Windows Time problems generally fall into one of the following categories:

Configuration error: The device uses a Type or peer that does not match its role.
Discovery failure: W32Time cannot establish a Domain Peer through the domain hierarchy.
Communication failure: A source has been selected, but time data cannot be received.
Local service problem: The configuration appears correct, but the runtime state does not match it.
Normal domain hierarchy behavior: A member server selects a standard Domain Controller instead of the PDC directly.

When a server displays Local CMOS Clock, the real question is not:

Which public NTP server should I configure instead?

The real question is:

What is this server's role in the domain time hierarchy, and at which stage did it lose its correct time source?

Only after determining whether the failure occurred during configuration, discovery, communication, or synchronization should corrective settings be applied. Otherwise, troubleshooting may simply add another layer of historical configuration.

Command Toolbox

Role and Domain Discovery

netdom query fsmo
Get-ADDomain | Select-Object PDCEmulator
nltest /dsgetdc:example.local /PDC
nltest /dclist:example.local

Secure Channel

Test-ComputerSecureChannel -Verbose
nltest /sc_verify:example.local

Windows Time Status

w32tm /query /source
w32tm /query /status
w32tm /query /configuration
w32tm /query /peers
w32tm /monitor

Time Offset Test

w32tm /stripchart /computer:PDC01.example.local /samples:5 /dataonly

Event Log Review

Get-WinEvent -LogName System |
    Where-Object {
        $_.ProviderName -eq "Microsoft-Windows-Time-Service"
    } |
    Select-Object -First 20 `
        TimeCreated,
        Id,
        LevelDisplayName,
        Message

Restore Windows Time Service on a Non-PDC Domain Controller

net stop w32time
w32tm /unregister
w32tm /register
net start w32time
w32tm /config /syncfromflags:domhier /reliable:no /update
w32tm /resync /rediscover

Group Policy Check

gpresult /h C:\Temp\gpresult.html

Windows Server 域环境中 DC 时间同步异常排障记录

Fri, 10 Jul 2026 00:00:00 GMT

前言

在 Active Directory 中，时间同步几乎是所有身份认证的基础。

Kerberos、AD Replication、Certificate、Group Policy……几乎所有组件都依赖准确的时间。

微软推荐的域时间架构并不复杂：

Internet NTP
     │
     ▼
PDC Emulator
     │
     ▼
Other Domain Controllers
     │
     ▼
Domain Members

然而，我们的环境中却出现了一个比较奇怪的问题：

PDC Emulator 已经配置公网 NTP
Domain Controller 之间可以正常通信
DNS 正常
Active Directory 正常
Secure Channel 正常

但是部分 Domain Controller 却一直使用：

Local CMOS Clock

最终确认，问题并不在公网 NTP 服务、DNS、基础网络通信或 Active Directory 本身，而是集中在异常 DC 本机的 Windows Time Service 配置或服务状态。

本文记录完整的排障过程，以及这次问题中最值得保留的判断思路。

Active Directory 域环境中的 NTP 基础知识

在开始排查之前，需要先理解 Windows 域环境中的时间同步机制。

在普通工作组环境中，每台 Windows 设备可以直接向指定的公网 NTP Server 同步时间。但在 Active Directory 域环境中，Windows 默认依赖 Windows Time Service 的域层级同步机制。

Windows Time Service 的服务名称是：

W32Time

它负责维护 Windows 系统时间，并为 Kerberos、Active Directory、证书验证和其他依赖时间的服务提供基础。

为什么域环境对时间敏感

Active Directory 并不要求所有设备时间完全一致，但设备之间的偏差必须处于允许范围内。

其中最典型的是 Kerberos。Kerberos 使用带有时间戳的 Ticket 来防止重放攻击。如果客户端、服务器和 Domain Controller 之间存在较大的时间偏差，可能出现：

用户无法登录域账户
Kerberos 身份验证失败
访问共享文件夹时反复要求输入密码
Group Policy 无法正常应用
域复制或 Secure Channel 出现异常
证书被判断为尚未生效或已经过期
日志时间线无法准确对应

因此，域环境中的时间同步不只是让任务栏上的时钟准确，它本身就是身份认证体系的一部分。

域时间同步层级

在单林、单域环境中，标准的时间同步链通常如下：

Public NTP Server
        │
        ▼
Forest Root Domain PDC Emulator
        │
        ▼
Other Domain Controllers
        │
        ▼
Domain Member Servers and Workstations

森林根域中的 PDC Emulator 位于整个域时间层级的顶部。

它应该从可靠的外部时间源获取时间，例如：

企业内部 GPS Clock
核心网络设备提供的时间源
公网 NTP 服务

其他域设备则通过 Active Directory 的域层级逐级同步。

PDC Emulator 的作用

Active Directory 中有五个 FSMO Roles。PDC Emulator 除了承担密码更新、账户锁定和兼容性相关功能外，还承担域时间层级中的核心角色。

确认当前 PDC Emulator：

netdom query fsmo

也可以使用 Active Directory PowerShell Module：

Get-ADDomain | Select-Object PDCEmulator

只有当前 PDC Emulator 应该被明确配置为外部可靠时间源。

例如：

w32tm /config `
    /manualpeerlist:"time.cloudflare.com,0x8 time.google.com,0x8" `
    /syncfromflags:manual `
    /reliable:yes `
    /update

参数含义：

/manualpeerlist：指定外部 NTP Peer
/syncfromflags:manual：使用手动配置的时间源
/reliable:yes：将本机标记为域内可靠时间源
/update：通知 Windows Time Service 重新读取配置

配置完成后，可以重启服务并请求同步：

Restart-Service w32time
w32tm /resync /force

`NT5DS` 和 `NTP` 的区别

使用以下命令查看当前时间同步模式：

w32tm /query /configuration

重点关注：

Type

`Type: NTP`

表示设备使用手动指定的 NTP Peer。

这种模式通常用于：

PDC Emulator
非域设备
特殊隔离系统
无法使用 AD 域层级的设备

`Type: NT5DS`

表示设备按照 Active Directory 域层级寻找时间源。

这种模式通常用于：

非 PDC Domain Controller
Domain Member Server
Domain-joined Workstation

非 PDC 服务器一般不应该直接指定公网 NTP，而应该保持：

Type: NT5DS

成员服务器不一定直接同步 PDC

使用 NT5DS 并不表示每台域成员都会直接连接 PDC Emulator。

一台成员服务器可能显示：

Source: DC01.example.local

而不是：

Source: PDC01.example.local

这并不一定是异常。

只要 DC01 本身最终从 PDC Emulator 获取正确时间，下面的同步链就是有效的：

Public NTP
    │
    ▼
PDC Emulator
    │
    ▼
DC01
    │
    ▼
Member Server

因此，验证时间同步时，不能只看一台服务器是否直接指向 PDC，还要确认整个时间链最终能够追溯到 PDC Emulator。

常用检查命令

查看当前时间源：

w32tm /query /source

查看详细同步状态：

w32tm /query /status

查看完整配置：

w32tm /query /configuration

查看手动配置的 Peer：

w32tm /query /peers

检查所有 Domain Controller 的时间状态：

w32tm /monitor

测试与指定时间源之间的偏差：

w32tm /stripchart /computer:PDC01.example.local /samples:5 /dataonly

查看最近的 Windows Time Service 事件：

Get-WinEvent -LogName System |
    Where-Object {
        $_.ProviderName -eq "Microsoft-Windows-Time-Service"
    } |
    Select-Object -First 20 `
        TimeCreated,
        Id,
        LevelDisplayName,
        Message

本次排障环境

本文中的服务器名称、域名和 IP 地址均已匿名化。

本次排障环境为一个已经运行多年的单林、单域 Active Directory 环境，共有四台 Domain Controller：

示例名称	角色	预期时间源
PDC01	PDC Emulator，持有 FSMO Roles	外部公网 NTP
DC01	普通 Domain Controller	Domain Hierarchy
DC02	普通 Domain Controller	Domain Hierarchy
DC03	普通 Domain Controller	Domain Hierarchy

域成员包括多台 Windows Member Server 和 Workstation。

预期的时间同步架构为：

External NTP
      │
      ▼
PDC01 — PDC Emulator
      │
      ▼
DC01 / DC02 / DC03
      │
      ▼
Member Servers and Workstations

其中：

PDC01 使用 Type: NTP
PDC01 是域内唯一明确配置的可靠外部时间源
其他 DC 使用 Type: NT5DS
Member Server 和 Workstation 使用 Type: NT5DS
域成员不一定直接同步 PDC，也可能同步其他健康 DC

故障现象

首先在异常 DC 上查看当前时间来源：

w32tm /query /source

输出：

Local CMOS Clock

继续查看状态：

w32tm /query /status

输出中的关键内容：

Stratum: 1
ReferenceId: LOCL
Source: Local CMOS Clock

这说明当前 DC 没有使用域内上游时间源，而是直接使用本机硬件时钟。

对于非 PDC Domain Controller，这显然不是预期状态。

第一步：确认 PDC Emulator

首先确认整个域的 FSMO Roles：

netdom query fsmo

输出显示所有 FSMO Roles 均位于：

PDC01.example.local

其中 PDC Role 也正确指向 PDC01。

继续使用 PDC Locator 明确查找 PDC Emulator：

nltest /dsgetdc:example.local /PDC

返回类似：

DC: \\PDC01.example.local
Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV

这说明 Active Directory 能够正确识别当前 PDC Emulator。

第二步：验证 PDC 的外部时间源

随后在 PDC01 上检查当前时间源：

w32tm /query /source

输出显示已配置的公网时间源：

time.cloudflare.com,time.google.com

继续查看状态：

w32tm /query /status

关键结果类似：

Leap Indicator: 0 (no warning)
Stratum: 4
Source: time.cloudflare.com,time.google.com
Last Successful Sync Time: <timestamp>

再查看完整配置：

w32tm /query /configuration

关键项为：

Type: NTP
AnnounceFlags: 5
NtpServer: time.cloudflare.com,time.google.com

这些结果说明：

PDC Emulator 已经能够同步外部 NTP
PDC 的 Windows Time Service 正常运行
外部 NTP 不是本次故障的主要问题

第三步：检查异常 DC 的实际配置

回到异常的 DC01，查看完整配置：

w32tm /query /configuration

关键输出：

Type: NT5DS

这表示 DC01 已经配置为通过 Active Directory 域层级发现时间源。

作为非 PDC Domain Controller，它应该通过域层级找到合适的上游时间源。在当前单域环境中，其时间链最终应能够追溯到 PDC Emulator。

但是再次查询：

w32tm /query /source

仍然显示：

Local CMOS Clock

这里出现了第一个明显矛盾：

配置声明它应该使用 NT5DS
实际状态却使用 Local CMOS Clock

因此，不能只看到 Type: NT5DS 就认为配置正常，还必须结合 source 和 status 判断实际运行状态。

第四步：使用 `w32tm /monitor` 查看整个域

为了确认问题是否只发生在 DC01，执行：

w32tm /monitor

结果显示了多个值得注意的现象：

DC01
    RefID: LOCL
    Stratum: 1
    Offset: approximately -61 seconds

PDC01
    RefID: external NTP source
    Stratum: 4

DC02
    RefID: another external NTP source

DC03
    NTP query timeout

这说明环境中可能不只有一个时间配置问题：

DC01 已经退回 Local CMOS Clock
DC02 可能仍保留直接同步公网 NTP 的历史配置
DC03 没有响应 NTP 查询
只有 PDC01 的状态符合预期

因此，本次故障虽然最先在 DC01 上被发现，但也暴露出整个域的 Windows Time 配置可能存在历史遗留和不一致。

第五步：检查 Active Directory 基础状态

由于 NT5DS 依赖 Active Directory 发现 Domain Peer，下一步需要确认 DC01 是否能够正确访问域、定位 PDC 并保持正常的 Secure Channel。

检查 Secure Channel

Test-ComputerSecureChannel -Verbose

输出：

True

继续验证：

nltest /sc_verify:example.local

NERR_Success

说明机器账户和 Secure Channel 正常。

明确定位 PDC Emulator

nltest /dsgetdc:example.local /PDC

DC: \\PDC01.example.local

说明 PDC Locator 正常。

列出所有 Domain Controller

nltest /dclist:example.local

列表中能够看到所有 DC，并且 PDC01 被正确标记为 PDC。

再次确认 FSMO Roles

netdom query fsmo

输出仍然正确指向 PDC01。

检查 DNS 和基础网络

nslookup PDC01

名称能够正确解析。

ping PDC01

基础网络连通正常。

至此可以确认：

Secure Channel 正常
DC Locator 正常
PDC Locator 正常
FSMO Role 正常
DNS 正常
基础网络通信正常

问题仍然存在。

第六步：查看 Windows Time Service 日志

随后检查 System Log 中的 Windows Time Service 事件：

Get-WinEvent -LogName System |
    Where-Object {
        $_.ProviderName -eq "Microsoft-Windows-Time-Service"
    } |
    Select-Object -First 20 `
        TimeCreated,
        Id,
        LevelDisplayName,
        Message

发现 Event ID 129：

NtpClient was unable to set a domain peer to use as a time source because of discovery error.

The error was:

The entry is not found.

这是整个排障过程中最重要的一条日志。

它说明故障不只是“已经选中了时间源，但没有收到时间数据”。

更准确地说，Windows Time Service 在设置 Domain Peer 的发现阶段就已经失败了。

换句话说：

不是已经选择 PDC 后发生 NTP 数据包丢失
而是 W32Time 没有正确建立应该使用的 Domain Peer

这个区别直接改变了后续排查方向。

第七步：分析本机 W32Time 配置

再次查看：

w32tm /query /configuration

发现以下组合：

Type: NT5DS
AnnounceFlags: 5

Type: NT5DS 表示服务器应通过 Active Directory 域层级发现时间源。

而 AnnounceFlags: 5 通常用于让服务器将自己声明为可靠时间源。

需要注意：

一台 Domain Controller 同时作为时间客户端和时间服务器，本身并不冲突。DC 可以从上游同步时间，同时为下游域成员提供时间。

真正值得注意的是：

DC01 并不是当前 PDC Emulator
它却被标记为可靠时间源
它自身又只使用 Local CMOS Clock
Windows Time Service 同时报告 Domain Peer Discovery 失败

这表明 DC01 的 W32Time 本地配置或服务状态可能保留了过去的手动配置、角色迁移遗留状态，或其他不一致配置。

仅凭 AnnounceFlags: 5 不能证明它就是 Event ID 129 的唯一直接原因，但结合当前所有现象，可以合理地把故障范围集中到 DC01 本机的 Windows Time Service。

此时继续反复执行：

w32tm /resync

意义有限，因为服务甚至没有正确建立 Domain Peer。

第八步：重新注册 Windows Time Service

最终决定不再继续叠加新的注册表或 NTP 配置，而是将 Windows Time Service 恢复到较干净的默认状态。

停止服务：

net stop w32time

注销 Windows Time Service：

w32tm /unregister

重新注册：

w32tm /register

重新启动服务：

net start w32time

随后明确恢复为非 PDC DC 应有的域层级模式：

w32tm /config /syncfromflags:domhier /reliable:no /update

然后重新同步并触发重新发现：

w32tm /resync /rediscover

需要注意，下面这个命令并不存在：

w32tm /rediscover

/rediscover 应该作为 /resync 的参数使用。

第九步：验证修复结果

修复完成后再次查询：

w32tm /query /source

输出立即变为：

PDC01.example.local

这说明 Windows Time Service 已经重新发现了正确的域时间源。

继续检查：

w32tm /query /status

应重点确认：

Source 指向健康的域时间源
Last Successful Sync Time 已更新
ReferenceId 不再是 LOCL
Stratum 不再是本地参考时钟的 Stratum 1

再检查完整配置：

w32tm /query /configuration

确认：

Type: NT5DS

并且该非 PDC DC 不再被配置为可靠根时间源。

最后再次检查事件日志：

Get-WinEvent -LogName System |
    Where-Object {
        $_.ProviderName -eq "Microsoft-Windows-Time-Service"
    } |
    Select-Object -First 10 `
        TimeCreated,
        Id,
        LevelDisplayName,
        Message

确认修复之后没有持续产生新的 Event ID 129。

第十步：为什么部分成员服务器仍然同步 DC01

修复 DC01 后，检查部分 Member Server 时发现：

w32tm /query /source

DC01.example.local

一开始这很容易让人怀疑：是不是之前有 Group Policy 强制把服务器指向了 DC01？

继续查看：

w32tm /query /configuration

关键配置为：

Type: NT5DS (Local)
AnnounceFlags: 10 (Local)
NtpServer Enabled: 0 (Local)

这说明：

该服务器没有使用手动 NTP Peer
它没有启用本机 NTP Server Provider
它正在通过 Active Directory 域层级自动选择时间源
当前选择 DC01 作为 Time Partner 是正常行为

此时时间链为：

External NTP
      │
      ▼
PDC01
      │
      ▼
DC01
      │
      ▼
Member Server

只要 DC01 自身能够稳定同步 PDC01，这就是正常且受支持的域时间同步链路。

正确配置参考

PS C:\Windows\system32> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 6 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0620454s
Root Dispersion: 0.1516282s
ReferenceId: 0xC0A80107 (source IP:  192.168.1.7)
Last Successful Sync Time: 7/22/2026 2:32:00 PM
Source: DC1.example.com
Poll Interval: 10 (1024s)

PS C:\Windows\system32> w32tm /query /configuration
[Configuration]

EventLogFlags: 2 (Local)
AnnounceFlags: 10 (Local)
TimeJumpAuditOffset: 28800 (Local)
MinPollInterval: 6 (Local)
MaxPollInterval: 10 (Local)
MaxNegPhaseCorrection: 4294967295 (Local)
MaxPosPhaseCorrection: 4294967295 (Local)
MaxAllowedPhaseOffset: 300 (Local)

FrequencyCorrectRate: 4 (Local)
PollAdjustFactor: 5 (Local)
LargePhaseOffset: 50000000 (Local)
SpikeWatchPeriod: 900 (Local)
LocalClockDispersion: 10 (Local)
HoldPeriod: 5 (Local)
PhaseCorrectRate: 1 (Local)
UpdateInterval: 100 (Local)


[TimeProviders]

NtpClient (Local)
DllName: C:\Windows\system32\w32time.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
CrossSiteSyncFlags: 2 (Local)
AllowNonstandardModeCombinations: 1 (Local)
ResolvePeerBackoffMinutes: 15 (Local)
ResolvePeerBackoffMaxTimes: 7 (Local)
CompatibilityFlags: 2147483648 (Local)
EventLogFlags: 1 (Local)
LargeSampleSkew: 3 (Local)
SpecialPollInterval: 3600 (Local)
Type: NT5DS (Local)

VMICTimeProvider (Local)
DllName: C:\Windows\System32\vmictimeprovider.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
NtpServer (Local)
DllName: C:\Windows\system32\w32time.dll (Local)
Enabled: 0 (Local)
InputProvider: 0 (Local)

PS C:\Windows\system32> w32tm /query /source
DC1.example.com
PS C:\Windows\system32> w32tm /monitor
PDC.example.com *** PDC ***[192.168.xx.xx:123]:
    ICMP: 0ms delay
    NTP: +0.0000000s offset from PDC.example.com
        RefID: time.cloudflare.com [162.159.200.123]
        Stratum: 4
DC1.example.com[192.168.x.xx:123]:
    ICMP: 0ms delay
    NTP: -0.0063029s offset from PDC.example.com
        RefID: dc2k12.example.com [192.168.xx.xx]
        Stratum: 5
DC2.example.com[192.168.x.xx:123]:
    ICMP: 0ms delay
    NTP: +0.0046926s offset from PDC.example.com
        RefID: ntp1.torix.ca [206.108.0.131]
        Stratum: 2

Warning:
Reverse name resolution is best effort. It may not be
correct since RefID field in time packets differs across
NTP implementations and may not be using IP addresses.

补充：如何检查是否由 GPO 配置

可以生成 Resultant Set of Policy 报告：

gpresult /h C:\Temp\gpresult.html

在报告中搜索：

Configure Windows NTP Client
Enable Windows NTP Client
Enable Windows NTP Server

w32tm /query /configuration 也会在配置项后显示来源，例如：

Type: NT5DS (Local)

本次成员服务器的有效配置显示为本地默认状态，没有证据表明 GPO 将其强制指定为某一台 NTP Server。

根因与证据边界

本次排查可以确认，问题不在以下组件：

PDC Emulator 的外部 NTP 配置
DNS 名称解析
Active Directory DC Locator
Secure Channel
DC 之间的基础网络通信

故障集中在 DC01 本机的 Windows Time Service。

DC01 的配置中同时出现：

Type: NT5DS
AnnounceFlags: 5

这说明服务器的 W32Time 配置存在不符合当前角色预期的状态。

不过，仅凭 AnnounceFlags: 5 不能证明它就是 Event ID 129 的唯一直接原因。

能够确定的是：

W32Time 无法正确建立 Domain Peer
重新注册 W32Time 并恢复 domhier 配置后，DC01 立即开始同步 PDC01
因此，故障根源位于 DC01 本机的 Windows Time Service 配置或服务状态
Active Directory、DNS、网络和 PDC Emulator 本身均不是这次故障的主要原因

最终时间同步架构

整个域应该保持如下配置：

External NTP
      │
      ▼
PDC Emulator（唯一明确配置公网 NTP）
      │
      ▼
Other Domain Controllers（NT5DS）
      │
      ▼
Member Servers and Workstations（NT5DS）

其中：

只有 PDC Emulator 配置公网 NTP
其他 Domain Controller 使用 NT5DS
Domain Member 使用 NT5DS
成员服务器可以同步任意健康 DC
所有时间链最终应追溯到 PDC Emulator

本次故障的排查思路总结

这次问题最值得记录的，并不是最终执行了哪一条修复命令，而是如何逐层缩小故障范围。

面对：

Local CMOS Clock

不能直接假设是公网 NTP、UDP 123 或防火墙故障。

更有效的方法是先理解服务器在域时间层级中的角色，再判断失败发生在哪个阶段。

通用排查顺序

确认设备角色
      │
      ▼
确认 PDC Emulator 和 FSMO Roles
      │
      ▼
确认 PDC 外部 NTP 正常
      │
      ▼
检查故障服务器的 Source、Status 和 Type
      │
      ▼
使用 w32tm /monitor 检查全域状态
      │
      ▼
验证 Secure Channel、DNS 和 PDC Locator
      │
      ▼
检查 Windows Time Service 事件日志
      │
      ▼
判断是发现失败、通信失败还是本地配置异常
      │
      ▼
恢复 W32Time 并重新加入域时间层级
      │
      ▼
验证完整时间同步链

常见现象与检查方向

现象	优先检查
PDC 使用 `Local CMOS Clock`	外部 NTP、UDP 123、PDC 配置
非 PDC DC 使用 `Local CMOS Clock`	`NT5DS`、DC Locator、Event ID 129
`No time data was available`	当前 Peer、网络连通、事件日志
普通 DC 显示 `Type: NTP`	手动配置或 GPO 遗留
成员服务器同步普通 DC	通常正常，检查完整上游链路
`w32tm /monitor` 查询超时	W32Time 服务、防火墙、UDP 123
`RefID: LOCL`	当前设备正在使用本地时钟

最重要的判断原则

面对 Windows Time 问题时，需要区分以下几种情况：

配置错误：设备使用了不符合其角色的 Type 或 Peer。
发现失败：W32Time 无法通过域层级建立 Domain Peer。
通信失败：已经选择时间源，但无法获得时间数据。
本地服务异常：配置看似正确，但实际运行状态与配置不一致。
正常域层级行为：成员服务器选择普通 DC，而不是直接选择 PDC。

当服务器显示 Local CMOS Clock 时，真正需要回答的不是：

应该换成哪个公网 NTP？

而是：

这台服务器在域时间层级中的角色是什么，它在哪一个阶段失去了正确的时间源？

只有先判断失败发生在配置、发现、通信还是同步阶段，后续修复才不会继续叠加新的历史配置。

命令工具箱

角色与域发现

netdom query fsmo
Get-ADDomain | Select-Object PDCEmulator
nltest /dsgetdc:example.local /PDC
nltest /dclist:example.local

Secure Channel

Test-ComputerSecureChannel -Verbose
nltest /sc_verify:example.local

Windows Time 状态

w32tm /query /source
w32tm /query /status
w32tm /query /configuration
w32tm /query /peers
w32tm /monitor

时间偏差测试

w32tm /stripchart /computer:PDC01.example.local /samples:5 /dataonly

日志检查

Get-WinEvent -LogName System |
    Where-Object {
        $_.ProviderName -eq "Microsoft-Windows-Time-Service"
    } |
    Select-Object -First 20 `
        TimeCreated,
        Id,
        LevelDisplayName,
        Message

恢复非 PDC DC 的 Windows Time Service

net stop w32time
w32tm /unregister
w32tm /register
net start w32time
w32tm /config /syncfromflags:domhier /reliable:no /update
w32tm /resync /rediscover

Group Policy 检查

gpresult /h C:\Temp\gpresult.html

使用 PowerShell 批量补全 Active Directory 用户邮箱属性

Fri, 01 Aug 2025 00:00:00 GMT

在一次部署支持 LDAP Sync 的系统时，我发现不少用户同步完成后都没有邮箱信息。检查 Active Directory 后才发现，并不是 LDAP 配置有问题，而是很多用户对象根本没有填写 mail 属性。这是一个历史遗留问题。多年来，公司里的 AD 用户一直由不同的 IT 人员手动创建。由于 Windows 登录和 Exchange 并不会依赖这个属性，因此即使留空，用户平时也完全不会察觉，大家也就一直没有处理。

好在公司的邮箱命名规则比较统一，例如：

<sAMAccountName>@yourdomain.com

那么就可以通过 PowerShell 根据用户的登录名自动补全缺失的邮箱属性。

PowerShell 脚本

# 加载 Active Directory 模块
Import-Module ActiveDirectory

# 指定需要处理的 AD 组
$groupName = "changeme"

# 遍历组内所有用户
Get-ADGroupMember -Identity $groupName -Recursive |
    Where-Object { $_.objectClass -eq 'user' } |
    ForEach-Object {
        $user = Get-ADUser -Identity $_ -Properties mail

        if (-not $user.mail) {
            $email = "$($user.SamAccountName)@yourdomain.com"
            Set-ADUser -Identity $user.SamAccountName -EmailAddress $email
            Write-Host "已设置邮箱：$($user.SamAccountName) -> $email" -ForegroundColor Green
        }
        else {
            Write-Host "邮箱已存在：$($user.SamAccountName) -> $($user.mail)" -ForegroundColor Yellow
        }
    }

脚本说明

该脚本会执行以下操作：

获取指定 AD 组中的所有用户（包含嵌套组）。
检查每个用户的 mail 属性是否为空。
如果为空，则使用 sAMAccountName 自动生成邮箱地址。
将生成的邮箱写入 Active Directory 的 mail 属性。
已经存在邮箱的用户将自动跳过，不会被覆盖。

注意事项

将 changeme 修改为需要处理的 AD 组名称。
将 yourdomain.com 修改为实际使用的邮箱域名。
运行脚本的账户需要具有修改 Active Directory 用户属性的权限。
建议先在测试环境或少量用户上验证，再应用到生产环境。

Bulk Populate Missing Email Addresses in Active Directory

Fri, 01 Aug 2025 00:00:00 GMT

During the deployment of a system that supports LDAP synchronization, I noticed that many users were successfully synced but had no email address associated with their accounts.

After checking Active Directory, I found that the issue wasn't with the LDAP configuration at all. Instead, many user objects simply had an empty mail attribute.

This turned out to be a historical issue. Over the years, AD accounts had been created manually by different IT staff members. Since neither Windows logon nor Exchange depends on the mail attribute, users could work normally even if it was left blank, so the missing values went unnoticed for a long time.

Fortunately, our organization follows a consistent email naming convention, for example:

<sAMAccountName>@yourdomain.com

With a predictable naming convention, it's easy to populate the missing mail attributes automatically using PowerShell.

PowerShell Script

# Load Active Directory module if not already loaded
Import-Module ActiveDirectory

# Define the group name
$groupName = "changeme"

# Process users and update missing emails
Get-ADGroupMember -Identity $groupName -Recursive |
    Where-Object { $_.objectClass -eq 'user' } |
    ForEach-Object {
        $user = Get-ADUser -Identity $_ -Properties mail

        if (-not $user.mail) {
            $email = "$($user.SamAccountName)@yourdomain.com"
            Set-ADUser -Identity $user.SamAccountName -EmailAddress $email
            Write-Host "Set email for $($user.SamAccountName): $email" -ForegroundColor Green
        }
        else {
            Write-Host "Email already set for $($user.SamAccountName): $($user.mail)" -ForegroundColor Yellow
        }
    }

What the Script Does

The script performs the following actions:

Retrieves all users from the specified AD group, including nested groups.
Checks whether the mail attribute is empty.
If the attribute is missing, generates an email address using the user's sAMAccountName.
Writes the generated email address back to the mail attribute in Active Directory.
Skips users who already have an email address configured, ensuring that existing values are not overwritten.

Notes

Replace changeme with the target Active Directory group.
Replace yourdomain.com with your organization's email domain.
The account running the script must have permission to modify Active Directory user objects.
Always test the script against a small pilot group before running it in a production environment.

Systemd Quick Reference

Sun, 28 Jul 2024 00:00:00 GMT

Common Commands

List all service units that are configured to start automatically at boot.

systemctl list-unit-files --type=service --state=enabled

List all currently running services.

systemctl list-units --type=service --state=running

Check whether a service is enabled at boot and whether it is currently running.

systemctl is-enabled nginx.service
systemctl is-active nginx.service

Start, stop, restart, enable, and check the status of a service.

systemctl start nginx
systemctl stop nginx
systemctl restart nginx
systemctl enable nginx
systemctl status nginx

Create a Custom Spring Boot Service

cat <<'EOF' >/etc/systemd/system/hello.service
[Unit]
Description=Spring Boot HelloWorld
After=syslog.target
After=network.target

[Service]
User=username
Type=simple
ExecStart=/usr/bin/java -jar /root/hello.jar
Restart=always
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=helloworld

[Install]
WantedBy=multi-user.target
EOF

Default Locations of systemd Unit Files

(See man systemd.unit for more details.)

Table 1. Load path when running in system mode (--system).

┌────────────────────┬─────────────────────────────┐
│ Path               │ Description                 │
├────────────────────┼─────────────────────────────┤
│ /etc/systemd/system│ Local configuration         │
├────────────────────┼─────────────────────────────┤
│ /run/systemd/system│ Runtime units               │
├────────────────────┼─────────────────────────────┤
│ /lib/systemd/system│ Units of installed packages │
└────────────────────┴─────────────────────────────┘

[!NOTE]

/etc/systemd/system contains locally created or customized unit files.

/lib/systemd/system (or /usr/lib/systemd/system on many modern distributions) contains unit files installed by software packages.

/run/systemd/system is used for runtime-generated or temporary unit files.

Reload systemd After Modifying a Unit

systemctl daemon-reload

Whenever you create or modify a unit file, you should reload the systemd manager.

Reloading the configuration does not restart the service automatically, so you will usually need to run:

systemctl restart hello.service

Verify the Syntax of a Unit File

systemd-analyze verify /etc/systemd/system/hello.service

List Failed Units

systemctl --failed

List only failed services.

systemctl --failed --type=service

View Service Logs

journalctl -u hello.service
journalctl -u hello.service -b
journalctl -u hello.service -f
journalctl -u hello.service --since "30 minutes ago"

Clear the Failed State

If a service still shows as failed after fixing the issue:

systemctl reset-failed hello.service

Then start the service again:

systemctl start hello.service

Use Drop-in Overrides Instead of Editing Package Files

Avoid modifying package-managed unit files directly, such as:

/lib/systemd/system/nginx.service

Your changes may be overwritten during package upgrades.

Instead, create a drop-in override:

systemctl edit nginx.service

Example:

[Service]
Restart=on-failure
RestartSec=5s

View the merged configuration:

systemctl cat nginx.service

Remove all local overrides and restore the original configuration:

systemctl revert nginx.service

Find Which Package Installed a Unit File

dpkg-query -S /lib/systemd/system/* | sort -u

Example output:

dpkg-query: no path found matching pattern /lib/systemd/system/ecs_mq.service
dpkg-query: no path found matching pattern /lib/systemd/system/SplunkForwarder.service
dpkg-query: no path found matching pattern /lib/systemd/system/system-systemd\x2dcryptsetup.slice
accountsservice: /lib/systemd/system/accounts-daemon.service
apparmor: /lib/systemd/system/apparmor.service
apt: /lib/systemd/system/apt-daily.service
apt: /lib/systemd/system/apt-daily.timer
apt: /lib/systemd/system/apt-daily-upgrade.service
apt: /lib/systemd/system/apt-daily-upgrade.timer
at: /lib/systemd/system/atd.service
auditd: /lib/systemd/system/auditd.service
base-files: /lib/systemd/system/motd-news.service
base-files: /lib/systemd/system/motd-news.timer

[!NOTE]

If dpkg-query cannot find a matching package, it simply means that no package recorded ownership of that path in the dpkg database. The unit file may have been created manually, installed by a third-party installer, generated by a package installation script, or generated dynamically by a systemd generator. Installing a package manually with dpkg -i does not normally prevent dpkg-query -S from identifying files that belong to that package.

systemd 使用笔记

Sun, 28 Jul 2024 00:00:00 GMT

常用命令

列出已配置为开机启用的 service unit

systemctl list-unit-files --type=service --state=enabled

查看当前正在运行的服务：

systemctl list-units --type=service --state=running

分别判断开机启动和当前运行状态：

systemctl is-enabled nginx.service
systemctl is-active nginx.service

开启，关闭，重启，设为开机自启，查看状态

systemctl start nginx
systemctl stop nginx
systemctl restart nginx
systemctl enable nginx
systemctl status nginx

创建一个自定义的Springboot service

cat <<'EOF' >/etc/systemd/system/hello.service
[Unit]
Description=Spring Boot HelloWorld
After=syslog.target
After=network.target

[Service]
User=username
Type=simple
ExecStart=/usr/bin/java -jar /root/hello.jar
Restart=always
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=helloworld

[Install]
WantedBy=multi-user.target
EOF

service文件的位置(详情参考 man systemd.unit)

 Table 1.  Load path when running in system mode (--system).
       ┌────────────────────┬─────────────────────────────┐
       │Path                │ Description                 │
       ├────────────────────┼─────────────────────────────┤
       │/etc/systemd/system │ Local configuration         │
       ├────────────────────┼─────────────────────────────┤
       │/run/systemd/system │ Runtime units               │
       ├────────────────────┼─────────────────────────────┤
       │/lib/systemd/system │ Units of installed packages │
       └────────────────────┴─────────────────────────────┘

[!NOTE] 注释 /etc/systemd/system文件夹里的是本地创建的服务。 /lib/systemd/system路径里的是软件包创建的服务。（/usr/lib/systemd/system） /run/systemd/system 用于运行时临时配置

修改 unit 后重新加载

systemctl daemon-reload

只要创建或修改了 unit 文件，就应该运行它。它不会自动重启服务，通常还需要：

systemctl restart hello.service

检查 unit 文件语法

systemd-analyze verify /etc/systemd/system/hello.service

查看失败的 unit

systemctl --failed

仅查看失败的服务：

systemctl --failed --type=service

查看服务日志

journalctl -u hello.service
journalctl -u hello.service -b
journalctl -u hello.service -f
journalctl -u hello.service --since "30 minutes ago"

清除 failed 状态

修复问题后，如果服务仍显示 failed：

systemctl reset-failed hello.service

然后重新启动：

systemctl start hello.service

查看/lib/systemd/system路径下的服务是由什么软件包创建的

dpkg-query -S /lib/systemd/system/* | sort -u

Output:

dpkg-query: no path found matching pattern /lib/systemd/system/ecs_mq.service
dpkg-query: no path found matching pattern /lib/systemd/system/SplunkForwarder.service
dpkg-query: no path found matching pattern /lib/systemd/system/system-systemd\x2dcryptsetup.slice
accountsservice: /lib/systemd/system/accounts-daemon.service
apparmor: /lib/systemd/system/apparmor.service
apt: /lib/systemd/system/apt-daily.service
apt: /lib/systemd/system/apt-daily.timer
apt: /lib/systemd/system/apt-daily-upgrade.service
apt: /lib/systemd/system/apt-daily-upgrade.timer
at: /lib/systemd/system/atd.service
auditd: /lib/systemd/system/auditd.service
base-files: /lib/systemd/system/motd-news.service
base-files: /lib/systemd/system/motd-news.timer

<aside>
💡 可以看到dpkg找不到前三个服务对应的软件包。这可能是因为这些服务的由deb文件手动安装的，比如所splunk forwarder

</aside>

[!NOTE] 注释 dpkg-query 找不到这些文件，表示 dpkg 数据库中没有软件包声明拥有该路径。它们可能是手工创建、由第三方安装脚本创建、由软件包安装脚本动态生成，或由 systemd generator 生成。仅仅使用 dpkg -i 手动安装 .deb，通常不会导致 dpkg-query -S 无法找到包内文件。

Linux auditd Cheat Sheet

Thu, 25 Jul 2024 00:00:00 GMT

auditd

Configuration File

The main configuration file for auditd is located at:

/etc/audit/auditd.conf

This file controls the behavior of auditd itself, including log writing, log rotation, and how auditd responds to disk space shortages or errors.

# Log writing behavior
flush = INCREMENTAL
freq = 20

# Log rotation
num_logs = 5
max_log_file = 6
max_log_file_action = ROTATE

# Dispatcher
disp_qos = lossy
dispatcher = /sbin/audispd
name_format = NONE

# Disk space threshold
space_left = 75

# The "_action" options determine how errors or disk space issues should be handled:
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND

Note

max_log_file is measured in MB.

num_logs only takes effect when max_log_file_action is set to ROTATE.

Modern Linux distributions (such as RHEL 9 and Ubuntu 24.04) have integrated the functionality of audispd into auditd. As a result, some systems no longer run a separate audispd process, although the configuration option may still exist for compatibility.

Audit Rules

Audit Rules can be divided into three categories:

Control Rules — Control the behavior of the Linux Audit Framework.
File Watch Rules (also referred to as File System Rules) — Audit specific files or directories.
System Call Rules — Audit specific system calls.

Modern Linux distributions typically recommend placing custom rules under:

/etc/audit/rules.d/*.rules

Then run:

augenrules --load

to automatically generate and load:

/etc/audit/audit.rules

Although editing audit.rules directly is still supported, using the rules.d directory is the recommended approach because it is easier to maintain and manage.

Example Rules

# ----------------------------
# Control Rules
# ----------------------------

# Delete all existing rules
-D

# Kernel backlog queue size
## Increase the buffers to survive stress events.
## Make this bigger for busy systems
-b 8192

# Set failure mode
# 0 = silent
# 1 = printk
# 2 = panic
-f 2


# ----------------------------
# File Watch Rules
# ----------------------------

-w /etc/passwd  -p wa -k passwd_changes
-w /etc/group   -p wa -k group_changes
-w /etc/shadow  -p wa -k shadow_changes
-w /etc/sudoers -p wa -k sudoers_changes

Where:

Option	Description
`-w`	Watch a specific file or directory
`-p`	Permission types (`r`, `w`, `x`, `a`)
`-k`	Assign a key to the rule for easier searching with `ausearch -k`

Permission flags:

Flag	Meaning
`r`	Read
`w`	Write
`x`	Execute
`a`	Attribute Change (such as `chmod`, `chown`, and `touch`)

For example:

ausearch -k passwd_changes

Component	Function
Linux Audit Framework	A kernel subsystem that generates Audit Events based on configured Audit Rules.
auditd	Receives Audit Events and writes them to audit logs.
auditctl	Dynamically manages Audit Rules stored in the Kernel.
augenrules	Merges and loads rules from `/etc/audit/rules.d/`.
ausearch	Searches Audit Logs based on specified criteria.
aureport	Generates summary reports from Audit Logs.

Linux auditd 使用笔记

Thu, 25 Jul 2024 00:00:00 GMT

auditd

配置文件

auditd 的主配置文件位于：

/etc/audit/auditd.conf

用于控制 auditd 自身的行为，例如日志写入方式、日志轮转以及磁盘空间不足时的处理策略。

# Log writing behavior
flush = INCREMENTAL
freq = 20

# Log rotation
num_logs = 5
max_log_file = 6
max_log_file_action = ROTATE

# Dispatcher
disp_qos = lossy
dispatcher = /sbin/audispd
name_format = NONE

# Disk space threshold
space_left = 75

#The "_action" options determine how errors or disk space issues should be handled:
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND

Note

max_log_file 的单位为 MB。

num_logs 仅在 max_log_file_action = ROTATE 时生效。

较新的 Linux 发行版（如 RHEL 9、Ubuntu 24.04）已将 audispd 的功能整合到 auditd 中，因此部分系统可能没有独立的 audispd 进程，但配置项仍可能保留用于兼容。

Audit Rules

Audit Rule 可分为三种类型：

Control Rules —— 控制 Auditd 的行为。
File Watch Rules（File System Rules）—— 审计指定文件或目录。
System Call Rules —— 审计指定的 System Call。

现代 Linux 通常建议将自定义规则放在：

/etc/audit/rules.d/*.rules

然后执行：

augenrules --load

自动生成并加载：

/etc/audit/audit.rules

虽然仍然可以直接编辑 audit.rules，但官方更推荐使用 rules.d 的方式，便于维护和版本管理。

示例规则

# ----------------------------
# Control Rules
# ----------------------------

# Delete all existing rules
-D

# Kernel backlog queue size
## Increase the buffers to survive stress events. 
## Make this bigger for busy systems
-b 8192

## Set failure mode to panic
# 0 = silent
# 1 = printk
# 2 = panic
-f 2


# ----------------------------
# File Watch Rules
# ----------------------------

-w /etc/passwd  -p wa -k passwd_changes
-w /etc/group   -p wa -k group_changes
-w /etc/shadow  -p wa -k shadow_changes
-w /etc/sudoers -p wa -k sudoers_changes

其中：

Option	Description
`-w`	监控指定文件或目录
`-p`	权限类型（r、w、x、a）
`-k`	为规则添加 Key，方便使用 `ausearch -k` 搜索

权限说明：

Flag	Meaning
`r`	Read
`w`	Write
`x`	Execute
`a`	Attribute Change（如 chmod、chown、touch 等）

例如：

ausearch -k passwd_changes

补充阅读：什么是 auditd？

在 Linux 中，几乎所有与安全相关的操作最终都会经过 Kernel（内核）。

例如：

用户登录或注销
执行 sudo
启动一个程序
修改 /etc/passwd
修改文件权限（chmod）
删除文件
创建新的进程

这些操作最终都会转换成一个或多个 System Call（系统调用），由 Linux Kernel 处理。为了满足安全审计（Security Auditing）和合规（Compliance）的需求，Linux Kernel 内置了一套 Linux Audit Framework，用于记录这些安全相关事件。而 auditd（Linux Audit Daemon），则是这套框架对应的用户空间（Userspace）守护进程。

它负责：

接收 Kernel 发送的 Audit Event
将事件写入 /var/log/audit/audit.log
管理日志轮转（Log Rotation）
将事件转发给其他插件或日志系统（如 rsyslog、SIEM）

整个流程可以理解为：

System Call / File Change
            │
            ▼
Linux Kernel (Audit Framework)
            │
      Generate Audit Event
            │
            ▼
         auditd
            │
            ▼
/var/log/audit/audit.log

整个过程中，可以简单理解为：

管理员加载 Audit Rules。
Linux Kernel 根据这些规则监控系统行为。
当发生匹配事件时，Kernel 生成一个 Audit Event。
auditd 接收该事件，并写入 /var/log/audit/audit.log。
管理员使用 ausearch、aureport 等工具查询或分析日志。
因此，各组件的职责分别是：

Component	Function
Linux Audit Framework	Kernel 内置的审计框架，负责根据规则产生 Audit Event。
auditd	接收 Audit Event，并保存到日志。
auditctl	动态管理 Kernel 中的 Audit Rules。
augenrules	将 `/etc/audit/rules.d/` 中的规则合并并加载。
ausearch	根据条件搜索 Audit Log。
aureport	根据 Audit Log 生成统计报告。

理解这一点之后，很多现象就变得容易解释了。例如：

为什么 auditctl 修改规则后立即生效？
- 因为它直接修改的是 Kernel 中的 Audit Rules，而不是修改配置文件。
为什么重启之后规则消失？
- 因为 auditctl 修改的是运行时规则，重启后需要重新从配置文件加载。
为什么 auditd 停止以后，系统依然可能继续产生 Audit Event？
- 因为真正负责审计的是 Linux Kernel，只是没有用户空间进程继续接收并写入日志。

可以把整个 Linux Audit System 理解成一句话： > Audit Rules 告诉 Kernel 要监控什么；Kernel 负责发现事件；auditd 负责保存事件；ausearch 和 aureport 负责分析事件。

Expressive Code Example

Wed, 10 Apr 2024 00:00:00 GMT

Here, we'll explore how code blocks look using Expressive Code. The provided examples are based on the official documentation, which you can refer to for further details.

Expressive Code

Syntax Highlighting

Regular syntax highlighting

console.log('This code is syntax highlighted!')

Rendering ANSI escape sequences

ANSI colors:
- Regular: [31mRed[0m [32mGreen[0m [33mYellow[0m [34mBlue[0m [35mMagenta[0m [36mCyan[0m
- Bold:    [1;31mRed[0m [1;32mGreen[0m [1;33mYellow[0m [1;34mBlue[0m [1;35mMagenta[0m [1;36mCyan[0m
- Dimmed:  [2;31mRed[0m [2;32mGreen[0m [2;33mYellow[0m [2;34mBlue[0m [2;35mMagenta[0m [2;36mCyan[0m

256 colors (showing colors 160-177):
[38;5;160m160 [38;5;161m161 [38;5;162m162 [38;5;163m163 [38;5;164m164 [38;5;165m165[0m
[38;5;166m166 [38;5;167m167 [38;5;168m168 [38;5;169m169 [38;5;170m170 [38;5;171m171[0m
[38;5;172m172 [38;5;173m173 [38;5;174m174 [38;5;175m175 [38;5;176m176 [38;5;177m177[0m

Full RGB colors:
[38;2;34;139;34mForestGreen - RGB(34, 139, 34)[0m

Text formatting: [1mBold[0m [2mDimmed[0m [3mItalic[0m [4mUnderline[0m

Editor & Terminal Frames

Code editor frames

console.log('Title attribute example')

<!-- src/content/index.html -->
<div>File name comment example</div>

Terminal frames

echo "This terminal frame has no title"

Write-Output "This one has a title!"

Overriding frame types

echo "Look ma, no frame!"

# Without overriding, this would be a terminal frame
function Watch-Tail { Get-Content -Tail 20 -Wait $args }
New-Alias tail Watch-Tail

Text & Line Markers

Marking full lines & line ranges

// Line 1 - targeted by line number
// Line 2
// Line 3
// Line 4 - targeted by line number
// Line 5
// Line 6
// Line 7 - targeted by range "7-8"
// Line 8 - targeted by range "7-8"

Selecting line marker types (mark, ins, del)

function demo() {
  console.log('this line is marked as deleted')
  // This line and the next one are marked as inserted
  console.log('this is the second inserted line')

  return 'this line uses the neutral default marker type'
}

Adding labels to line markers

// labeled-line-markers.jsx
<button
  role="button"
  {...props}
  value={value}
  className={buttonClassName}
  disabled={disabled}
  active={active}
>
  {children &&
    !active &&
    (typeof children === 'string' ? <span>{children}</span> : children)}
</button>

Adding long labels on their own lines

// labeled-line-markers.jsx
<button
  role="button"
  {...props}

  value={value}
  className={buttonClassName}

  disabled={disabled}
  active={active}
>

  {children &&
    !active &&
    (typeof children === 'string' ? <span>{children}</span> : children)}
</button>

Using diff-like syntax

+this line will be marked as inserted
-this line will be marked as deleted
this is a regular line

--- a/README.md
+++ b/README.md
@@ -1,3 +1,4 @@
+this is an actual diff file
-all contents will remain unmodified
 no whitespace will be removed either

Combining syntax highlighting with diff-like syntax

  function thisIsJavaScript() {
    // This entire block gets highlighted as JavaScript,
    // and we can still add diff markers to it!
-   console.log('Old code to be removed')
+   console.log('New and shiny code!')
  }

Marking individual text inside lines

function demo() {
  // Mark any given text inside lines
  return 'Multiple matches of the given text are supported';
}

Regular expressions

console.log('The words yes and yep will be marked.')

Escaping forward slashes

echo "Test" > /home/test.txt

Selecting inline marker types (mark, ins, del)

function demo() {
  console.log('These are inserted and deleted marker types');
  // The return statement uses the default marker type
  return true;
}

Word Wrap

Configuring word wrap per block

// Example with wrap
function getLongString() {
  return 'This is a very long string that will most probably not fit into the available space unless the container is extremely wide'
}

// Example with wrap=false
function getLongString() {
  return 'This is a very long string that will most probably not fit into the available space unless the container is extremely wide'
}

Configuring indentation of wrapped lines

// Example with preserveIndent (enabled by default)
function getLongString() {
  return 'This is a very long string that will most probably not fit into the available space unless the container is extremely wide'
}

// Example with preserveIndent=false
function getLongString() {
  return 'This is a very long string that will most probably not fit into the available space unless the container is extremely wide'
}

Collapsible Sections

// All this boilerplate setup code will be collapsed
import { someBoilerplateEngine } from '@example/some-boilerplate'
import { evenMoreBoilerplate } from '@example/even-more-boilerplate'

const engine = someBoilerplateEngine(evenMoreBoilerplate())

// This part of the code will be visible by default
engine.doSomething(1, 2, 3, calcFn)

function calcFn() {
  // You can have multiple collapsed sections
  const a = 1
  const b = 2
  const c = a + b

  // This will remain visible
  console.log(`Calculation result: ${a} + ${b} = ${c}`)
  return c
}

// All this code until the end of the block will be collapsed again
engine.closeConnection()
engine.freeMemory()
engine.shutdown({ reason: 'End of example boilerplate code' })

Line Numbers

Displaying line numbers per block

// This code block will show line numbers
console.log('Greetings from line 2!')
console.log('I am on line 3')

// Line numbers are disabled for this block
console.log('Hello?')
console.log('Sorry, do you know what line I am on?')

Changing the starting line number

console.log('Greetings from line 5!')
console.log('I am on line 6')

Simple Guides for Fuwari

Mon, 01 Apr 2024 00:00:00 GMT

Cover image source: Source

This blog template is built with Astro. For the things that are not mentioned in this guide, you may find the answers in the Astro Docs.

Front-matter of Posts

---
title: My First Blog Post
published: 2023-09-09
description: This is the first post of my new Astro blog.
image: ./cover.jpg
tags: [Foo, Bar]
category: Front-end
draft: false
---

Attribute	Description
`title`	The title of the post.
`published`	The date the post was published.
`description`	A short description of the post. Displayed on index page.
`image`	The cover image path of the post.<br/>1. Start with `http://` or `https://`: Use web image<br/>2. Start with `/`: For image in `public` dir<br/>3. With none of the prefixes: Relative to the markdown file
`tags`	The tags of the post.
`category`	The category of the post.
`draft`	If this post is still a draft, which won't be displayed.

Where to Place the Post Files

Your post files should be placed in src/content/posts/ directory. You can also create sub-directories to better organize your posts and assets.

src/content/posts/
├── post-1.md
└── post-2/
    ├── cover.png
    └── index.md

Markdown Example

Sun, 01 Oct 2023 00:00:00 GMT

An h1 header

Paragraphs are separated by a blank line.

2nd paragraph. Italic, bold, and monospace. Itemized lists look like:

this one
that one
the other one

Note that --- not considering the asterisk --- the actual text content starts at 4-columns in.

Block quotes are written like so.

They can span multiple paragraphs, if you like.

Use 3 dashes for an em-dash. Use 2 dashes for ranges (ex., "it's all in chapters 12--14"). Three dots ... will be converted to an ellipsis. Unicode is supported. ☺

An h2 header

Here's a numbered list:

first item
second item
third item

Note again how the actual text starts at 4 columns in (4 characters from the left side). Here's a code sample:

# Let me re-iterate ...
for i in 1 .. 10 { do-something(i) }

As you probably guessed, indented 4 spaces. By the way, instead of indenting the block, you can use delimited blocks, if you like:

define foobar() {
    print "Welcome to flavor country!";
}

(which makes copying & pasting easier). You can optionally mark the delimited block for Pandoc to syntax highlight it:

import time
# Quick, count to ten!
for i in range(10):
    # (but not *too* quick)
    time.sleep(0.5)
    print i

An h3 header

Now a nested list:

First, get these ingredients:
- carrots
- celery
- lentils
Boil some water.

Dump everything in the pot and follow this algorithm:

 find wooden spoon
 uncover pot
 stir
 cover pot
 balance wooden spoon precariously on pot handle
 wait 10 minutes
 goto first step (or shut off burner when done)

Do not bump wooden spoon or it will fall.

Notice again how text always lines up on 4-space indents (including that last line which continues item 3 above).

Here's a link to a website, to a local doc, and to a section heading in the current doc. Here's a footnote [^1].

[^1]: Footnote text goes here.

Tables can look like this:

size material color

9 leather brown 10 hemp canvas natural 11 glass transparent

Table: Shoes, their sizes, and what they're made of

(The above is the caption for the table.) Pandoc also supports multi-line tables:

keyword text

red Sunsets, apples, and other red or reddish things.

green Leaves, grass, frogs and other things it's not easy being.

A horizontal rule follows.

Here's a definition list:

apples : Good for making applesauce. oranges : Citrus! tomatoes : There's no "e" in tomatoe.

Again, text is indented 4 spaces. (Put a blank line between each term/definition pair to spread things out more.)

Here's a "line block":

| Line one | Line too | Line tree

and images can be specified like so:

Inline math equations go in like so: $\omega = d\phi / dt$. Display math should get its own line and be put in in double-dollarsigns:

$$I = \int \rho R^{2} dV$$

$$ \begin{equation*} \pi =3.1415926535 ;8979323846;2643383279;5028841971;6939937510;5820974944 ;5923078164;0628620899;8628034825;3421170679;\ldots \end{equation*} $$

And note that you can backslash-escape any punctuation characters which you wish to be displayed literally, ex.: `foo`, *bar*, etc.

Include Video in the Posts

Tue, 01 Aug 2023 00:00:00 GMT

Just copy the embed code from YouTube or other platforms, and paste it in the markdown file.

---
title: Include Video in the Post
published: 2023-10-19
// ...
---

<iframe width="100%" height="468" src="https://www.youtube.com/embed/5gIf0_xpFPI?si=N1WTorLKL0uwLsU_" title="YouTube video player" frameborder="0" allowfullscreen></iframe>

YouTube

Bilibili

Charon's Blog

Integrating a Brother Scanner with SharePoint Using IIS FTP and Power Automate

Introduction

Solution Architecture

Environment

Installing IIS FTP

Creating an FTP Site

Creating a Dedicated FTP Account

Planning the Directory Structure

Troubleshooting #1: Windows Defender Firewall

Verify the FTP Service, FTP Site, and Port 21

Analysis

Test the TCP Connection

Check the Firewall Rules

Do Not Leave the Firewall Disabled

Troubleshooting #2: FTP Passive Mode

Understanding FTP Passive Mode

Configure a Passive Port Range

Allow the Passive Ports Through Windows Firewall

Printer Configuration

Power Automate

Step 1: Verify that the Gateway Is Installed

Step 2: Create an Automated Cloud Flow

Step 3: Create the Connection

Step 4: Configure the Trigger

Folder

Step 5: Add the File Content Action

Final Result

Toolbox

1. Check the FTP Service Status

2. Check Whether Port 21 Is Listening

3. Test Network Connectivity

4. Test FTP Login

5. Check the Windows Firewall Status

6. Temporarily Disable the Firewall (Troubleshooting Only)

7. Create an FTP Firewall Rule

8. View Firewall Rules

9. Recommended Troubleshooting Order

Brother 扫描仪无缝接入 SharePoint —— IIS FTP + Power Automate 自动上传方案

前言

最终架构

环境

安装 IIS FTP

创建 FTP Site

创建新的 FTP Site

创建新的FTP专用账户

建议提前规划目录结构

第一个坑：Windows Firewall

确认FTP服务运行，FTP Site启动，监听21端口

分析

测试TCP连接

检测防火墙规则

先不要一直关着防火墙

第二个坑：Passive Mode

现在配置 Passive Mode

设置

然后放行这些端口

最后一步

打印机 配置

Power Automate

Step 1：确认 Gateway 是否已安装

Step 2：创建 Automated Cloud Flow

Step 3：创建 Connection

Step 4：配置 Trigger

Folder

Step 5：添加读取文件内容

最终效果

Toolbox

1. 检查 FTP 服务状态

2. 检查端口监听状态

3. 测试网络连通性

4. 测试 FTP 登录

5. 查看 Windows Firewall 状态

6. 临时关闭 Firewall（仅用于排障）

7. 创建 FTP Firewall Rule

8. 查看 Firewall Rules

9. 常见排障顺序

一次 Windows Hello for Business (Key Trust) 的完整排障记录

环境

故障现象

打印机配置

The Difference Between `NT5DS` and `NTP`

`Type: NTP`

`Type: NT5DS`