HOWTO: 在 Windows Server 2022 的 Core 环境下配置 NAT 服务
HOWTO: 在 Windows Server 2022 的 Core 环境下配置 NAT 服务
经常会在 Hyper-V 中搭建一些虚拟环境用于测试验证以及实践。尤其是当前算力成本越加低廉的情况下，可以轻松的模拟一个复杂的业务场景或基础架构。这些 Lab 可能要与宿主网络隔离，通常我们会为这些虚机配置一个独立的网络，但如果它们需要访问互联网时就需要借助软路由或 NAT 服务。曾几何时 gOxiA 的虚机模板中总会保留一个 TMG(ISA) VM，之后会用到国内的一款软路由，因为它支持 Hyper-V。现在可能更多的会用到 Windows Server 提供的 RRAS（RemoteAccess）Role，其中包含了 NAT 服务，并且宿主硬件越来越强，内存和磁盘性能可轻松应对一个 WS NAT 虚机，所以最近又开始琢磨起 Server Core 运行 NAT。
因为只用来做 NAT 服务，所以系统越简单，容量越小越好。而 Windows Server 提供的 Core 环境是最佳的选择。如果你对 Server Core 还不了解，可以先阅读官方文档“什么是服务器核心安装选项”。
本例选用了 Windows Server 2022，在 Windows Setup 过程选择了 Core 安装。完成安装后进入系统会发现是一个命令环境，在这里只能运行有限的图形化程序，基本要依靠命令进行相关的管理和配置任务，虽然 Server Core 也提供了一个 SConfig 工具来进行初始配置，但功能有限！如果之前已经有了 Windows 命令的一些基础，可以直接命令上手效率会更高些。
以下是 gOxiA 整理的一些简明扼要的步骤，也避免了大家踩坑！
- 重命名计算机
rename-computer -new natserver - 修改网络名称（因为使用了简中版，强烈建议命令行环境还是用英文为佳）
get-netadapter , 获取网卡信息
rename-netadapter -name "以太网" -newname "Private"
rename-netadapter -anme "以太网 2" -newname "Public" - 修改内网网卡（Private）地址
new-netipaddress -interfacealias Private -ipaddress 192.168.192.254 -prefixlength 24
get-netipaddress , 可查看网卡地址 - 禁止内/外网使用IPv6（看自己喜好或实际需求）
disable-netadapterbinding -componentid ms_tcpip6 -name Public
disable-netadapterbinding -componentid ms_tcpip6 -name Private
get-netadapterbinding , 可查看配置情况 - 允许 ICMP
new-netfirewallrule -name "Allow Ping" -displayname "Allow Ping" -protocol icmpv4 -icmptype 8 -enable true -profile any -action allow
set-netfirewallrule -name CoreNet-Diag-ICMP4-EchoRequest-In-Noscope -enabled true -profile any -action allow , 也可以不新建防火墙策略直接开启默认策略
set-netfirewallprofile -profile domain,public,private -enabled false , 如果考虑以后测试方便，在保障网络安全的前提下，也可以选择禁用防火墙保护 - 安装路由器角色
install-windowsfeature -name routing -includemanagementtools , 根据提示重启服务器 - 使用新模式配置
install-remoteaccess -vpntype routingonly
在新模式下将无法再使用 RRAS 管理器进行配置，如果你在 GUI Mode 下看到这个提示便可确认。如果要恢复，则 Uninstall-remoteaccess
- 使用旧模式配置
sc config remoteaccess start= Auto
sc start remoteaccess
netsh routing ip nat add interface public
netsh routing ip nat set interface public mode=full
netsh routing ip nat add interface private
此外，貌似现在大家更推崇更加简单的方式，即使用系统内置的 new-netnat 命令，实际测试在不安装 Role 的情况下可以直接在 Windows 网络栈上启用 NAT 支持。
- new-netnat -name InternetNAT -internalIPInterfaceAddressPrefix 192.168.192.024
很是神奇，这个命令或者说功能原本是 Hyper-V 虚拟交换机的一个网络功能特性，可直接生成 NAT，而 RRAS 也更加关注的是远程访问的支持。借助这个命令应该也可直接在 Windows Client 上启用 NAT。
参考推荐：
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 时遇到什么问题欢迎与我联系交流。
