HOWTO: 为单网卡 Windows 10/11 配置多路由网关
HOWTO: 为单网卡 Windows 10/11 配置多路由网关
网络环境还是比较简单的，常见的组网方式，要求无线路由（192.168.2.1）下的网络增加一个网络设备（192.168.2.254），且所有客户端都需要经由该网络设备。
实际安装调试时发现，由于是定制版无线路由，DHCP 不支持高级配置功能，无法指定网关。如果通过关闭路由自带的 DHCP 服务，则 PPPOE 将自动切换为桥接模式，导致无法正常上网，后续配置也就无法再继续下去，考虑多方因素，决定改为客户端手动添加路由的方式。
因为是 Windows 10/11 系统，手动添加路由比较简单，通过网卡的“高级 TCP/IP 设置”即可。注意：这里有两个跃点数：手动添加的网关跃点数和自动跃点。
使用命令对于 IT 人员来说是最为便利的，这里推荐使用 PowerShell，可以先 Get-NetAdapter 获取当前系统的网卡基本信息，确认网卡索引号便于后续操作。
然后使用 New-NetRoute 来手动添加路由，将 192.168.2.254 添加到额外的网关中，参考如下命令行：
New-NetRoute -DestinationPrefix 0.0.0.0/0 -NextHop 192.168.2.254 -InterfaceIndex 19
但在添加后使用 Route Print 或 Get-NetRoute 查看会发现两个网关的跃点要么相同，要么额外添加的网关跃点无法优先于默认网关。此时如果我们去修改前面“高级 TCP/IP”设置中的跃点数和自动跃点数会发现也无济于事。
而且当修改额外网关跃点数为0时还是报错，只能设置为1-9999间的跃点数；如果修改了自动跃点还会发现网关的实际跃点数会被累加。
那该如何解决的？其实可以用 Set-NetRoute 对现有路由表进行修改，参考如下命令：
Set-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceIndex 19 -NextHop 192.168.2.254 -RouteMetric 0
执行后结果如下所示。
接下来，再调整默认网关的跃点数，将其优先级调后即可。那么什么时候需要修改自动跃点呢？当 Windows 系统有多块网卡，需要对网卡优先级进行调整时才需要使用自动跃点。经 gOxiA 学习梳理，在“高级 TCP/IP 设置”中的网关跃点数其实对应的就是 routemetric，而自动跃点数则对应的 interfacemetric。两者数值会进行累加，形成最终的跃点总数，进行优先级的排列，在 Route Print 中会得以体现。两个跃点的说明参考如下。
两者都是用于网络路由和网络接口的度量值，用于确定数据包的传输优先级和路径选择。虽然它们都是用于网络通信的度量标准，但他们的应用对象和作用范围有所不同。
- RouteMetric，应用于路由的度量值，用于确定通过特定路由传输数据包的优先级。当存在多个路由可供选择时，操作系统将使用具有最低路由度量值的路由来传输数据包。如果路由度量值相同，操作系统会使用其他策略（如最长前缀匹配 - PrefixLength / DestinationPrefix）进行决策。
- InterfaceMetric，应用于网络接口的度量值，用于确定通过特点接口传输数据包的优先级。如果有多个网络接口可供选择，操作系统将使用具有最低接口度量值的接口来传输数据包。如果接口度量值相同，操作系统会使用其他策略（如接口绑定顺序）进行决策。
Multi-app Kiosk for Windows 11 - 入门
Multi-app Kiosk for Windows 11 - 入门
一些 Windows 设备可能会被用在单一用途的特殊场景中，例如门店中用于查看商品目录的电脑，或点菜系统；也可能是医疗或工厂中的一线手持终端；又或是学校的图书馆查询电脑或在线考试用途的电脑。它们都需要设备系统被限制在某个应用或多个应用模式下，而不允许访问电脑上的其他程序、设置、目录。
早期，IT人员需要手动进行颗粒化的配置，或借助第三方的解决方案。而后 Windows 逐步推出展台/数字标牌和共享电脑的功能模式，可以轻松的实现我们的需求。要了解 Windows Kiosk Mode 不妨先移步官方文档了解学习 - “在 Windows 桌面版中配置站台和数字签名”。
在 Windows 10 的 Kiosk Mode 中，除了支持单应用模式外还支持多应用模式，这样我们可以定制开始菜单显示可以被运行的程序。此外，这些应用还被分为 UWP 和 Win32 应用，它受 Windows SKU 的限制，具体可了解 - “设置单应用站台”。
在 Windows 11 的早期版本中仅支持单应用的 Kiosk Mode，自 2023年5月24日发布的 Windows configuration updates 提供了对 Multi-app Kiosk mode 的支持。下图是 gOxiA 实践的结果，将被允许的应用（UWP和Win32）固定在了 Windows 11 的开始菜单中，并且会自动运行一个应用（实时字幕）。
可现在我们暂时还无法使用 MDM 或 PPKG 进行配置，而只能使用 MDM Bridge WMI Provider 来实现。这个过程对于刚刚上手的朋友来说可能是一场“噩梦”！因为当发生错误的时候，我们没有更多的参考文档可用于排错，完全依靠不断的尝试来摸索。当然官方文档也提供了“展台模式问题疑难解答”，其中最为有价值的当属事件日志了，gOxiA 在目前的排错中主要依赖 “Microsoft\Windows\AssignedAccess\Operational” 事件日志。例如我们导入了一个 XML 配置，他发生了错误，在 PowerShell 中其实根本看不出报错的主要内容，此时就需要通过事件日志来排查，每一个报错会生成两条事件，请重点查阅两条中的前一个，因为会记录相对详细的提示。如下所示：
OK，通过以上的了解如果你打算开始上手，那么就跟随 gOxiA 一起往下走。首先请准备一台 Windows 11 虚拟机，并安装好相应的 LCU，在 Kiosk mode 中建议分配一个普通权限的账号，创建好检查点以便在不断发生错误的时候能迅速返回上一个正常状态。
要通过 MDM Bridge WMI Provider 配置 Windows 11 的 Multi-app Kiosk 还需要准备一个工具 – PSExec ，因为我们需要利用它启用 PowerShell 才能正常的执行后面的命令行，否则将会出现如下的报错提示。要通过 PSExec 启动 PowerShell 请执行 “psexec64.exe -accepteula -i -d -s cmd”，然后在打开的 CMD 中启动 PowerShell。
此外，在配置 XML 时我们会涉及到 UWP 应用的 AUMID，可以执行 PowerShell 的 “get-startapps” 获取，当然也可以参考官方文档 - “查找已安装应用的 AUMID”中的其他几个方法。
准备就绪，执行以下脚本加载 XML 配置，便可实现 Windows 11 的 Multi-app Mode。
接下来输入官方文档给出的 XML 配置，最后以“"@)”结束输入，再执行 “set-ciminstance -ciminstance $obj” 完成。
<?xml version="1.0" encoding="utf-8" ?>
< AssignedAccessConfiguration
xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config" xmlns:win11="http://schemas.microsoft.com/AssignedAccess/2022/config">
<Profiles>
<Profile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}">
<AllAppsList>
<AllowedApps>
<App AppUserModelId="Microsoft.ZuneMusic_8wekyb3d8bbwe!Microsoft.ZuneMusic" />
<App AppUserModelId="Microsoft.ZuneVideo_8wekyb3d8bbwe!Microsoft.ZuneVideo" />
<App AppUserModelId="Microsoft.Windows.Photos_8wekyb3d8bbwe!App" />
<App AppUserModelId="Microsoft.BingWeather_8wekyb3d8bbwe!App" />
<App AppUserModelId="Microsoft.WindowsCalculator_8wekyb3d8bbwe!App" />
<App DesktopAppPath="%windir%system32mspaint.exe" />
<App DesktopAppPath="C:WindowsSystem32notepad.exe" />
</AllowedApps>
</AllAppsList>
<win11:StartPins>
<![CDATA[
{ "pinnedList":[
{"packagedAppId":"Microsoft.WindowsCalculator_8wekyb3d8bbwe!App"},
{"packagedAppId":"Microsoft.Windows.Photos_8wekyb3d8bbwe!App"},
{"packagedAppId":"Microsoft.ZuneMusic_8wekyb3d8bbwe!Microsoft.ZuneMusic"},
{"packagedAppId":"Microsoft.ZuneVideo_8wekyb3d8bbwe!Microsoft.ZuneVideo"},
{"packagedAppId":"Microsoft.BingWeather_8wekyb3d8bbwe!App"},
{"desktopAppLink":"%ALLUSERSPROFILE%\Microsoft\Windows\StartMenu\Programs\Accessories\Paint.lnk"},
{"desktopAppLink":"%APPDATA%\Microsoft\Windows\StartMenu\Programs\Accessories\Notepad.lnk"}
] }
]]>
</win11:StartPins>
<Taskbar ShowTaskbar="true"/>
</Profile>
</Profiles>
<Configs>
<Config>
< Account>MultiAppKioskUser</Account>
<DefaultProfile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}"/>
</Config>
</Configs>
</AssignedAccessConfiguration>
上述详细的过程可参考 “为 Windows 11 设置多应用展台”。gOxiA 也会继续分享 Multi-app Kiosk 在 Windows 11 上的一些经验心得！
HOWTO: 解决Windows搜索索引性能和容量问题
HOWTO: 解决Windows搜索索引性能和容量问题
当 Windows 搜索性能较差或发现磁盘空间正被索引数据库吞噬时就需要进行相关的优化。通常索引性能受其项目数量和总体大小因素影响。当索引超过40万个项目时，我们便可能觉察到性能问题，它将直接体现在CPU、内存或磁盘利用率上。此外，Windows 搜索还会为 Outlook 邮箱生成索引，如果邮箱包含了超过6万个项目时，索引的性能也可能会降低。
在容量方面，随着索引数量的增长，不管这些项目的大小如何，索引数据库都会大幅增长。当然项目本身的大小也会影响数据库的大小。索引数据库的文件名为“Windows.edb”，该文件位于“%programdata%\Microsoft\Search\Data\Applications\Windows”下，若要检查该数据库的容量不能仅从文件大小来看，而是要进入其文件属性查看“占用空间”来检查其实际占用的磁盘空间。
如我们所见，当索引数量和容量这两个因素加在一起时，会使索引问题复杂化。优化的方式有一些，下来我们来看看如何对 Windows 索引进行调优。
首先，最简单直（Cu）接（Bao）的方法是重建索引。相当于复位了索引数据库，能解决不少问题，但带来的不利因素是重建时所消耗的时间和资源，并且随着时间的推荐，我们的索引依旧会重现数量和容量问题。
第二种方法，为搜索索引排除文件夹，可以打开 Windows 11 的设置应用，定位至“隐私和安全性”，使用“添加要排除的文件夹”按钮来添加。对于 Windows 10 系统可以在设置的搜索框中键入“搜索”或“排除”查找。
第三种方法，更改索引处理特定文件类型的方式。我们可以打开“索引选项”，在“高级选项”下的“文件类型”选项卡内进行配置。
第四种方法，在讲之前我们先了解一个特性！自 Windows 8 开始至 Windows 10/11 索引数据库合并了文件属性和持久索引两类数据，并且会索引整个文件，这种设计是为了提高搜索的召回率和索引以及查询的性能，即全面/综合索引法，这种方法虽然提高了搜索和查询的效率和准确性，但问题也很显而易见，尤其是在小容量固态硬盘普及时期，或小容量系统卷时，大家总会发现硬盘可用容量在不断被吞噬。
而在 Windows 7 时代，索引数据库只包含了文件属性，而持久索引则单独存储在一个扩展名为 .ci 的文件中，并且对于大型文件也只会对前部分进行索引，所以 Windows 7 的索引数据库要小很多，但其缺点也显而易见。由于文件属性和持久性索引数据存储在不同的文件中，因此可能会导致索引数据的不一致性和丢失（这就是为什么 Windows 7 时代搜索故障/问题在 IT HelpDesk 居高不下的原因）；对于大型文件，由于只索引了文件的前部分，这极大增加了搜索结果的不完整和不准确性；如果需要进行全文搜索的文件类型（TXT），其索引速度会慢很多，因为它需要访问 .ci 文件中的持久性索引数据。
全面/综合索引和分离式索引的数据存储方式各自都有一些弊端，但考虑到实际效率，且计算性能的提升以及固态存储成本的降低，前者更适应我们现实需求。
另外，还有一个问题不容忽视，Outlook 的邮箱数据文件！通常我们仅会缓存一年或者半年的邮件，此时并不会遇到很严重的容量问题。但是如果客户端将 Outlook 配置为使用 PST 文件，并且下载了所有数据，那么在 Windows 10/11 平台上，由于前面所描述的特性因素，会发现 Windows.edb 的文件容量非常之大。此时 IT 人员就需要考虑为客户端减少索引范围，然后重新生成索引来缓解。或者使用第四种方法 - 对索引数据库进行碎片整理，为此执行如下命令行。
sc config wsearch start=disabled
net stop wsearch
esentutl.exe /d %programdata%\Microsoft\Search\Data\Applications\windows.edb
sc config wsearch start=delayed-auto
net start wsearch
OK，今天的分享就到这里！如果您在应用和部署 Windows 时遇到什么问题欢迎与我联系交流。
