用 Kiosk 模式固定業務終端 ── Assigned Access・Shell Launcher 的選型與運用設計

「明明應該是接待終端的 PC，訪客卻從工作列打開了 Excel」「裝置操作畫面的背後在播放 YouTube，觸控面板反應遲鈍的抱怨原因就是這個」「展覽會的展示機，早上去看時桌面整個露出來，變成了螢幕保護程式的設定畫面」── 應該只執行特定應用程式的 Windows 終端，放著不管的話，一定會被當成「普通的 PC」來使用。

常見的對策是「設成自動登入，再把業務應用程式登錄到啟動項目」，但這其實什麼都沒有守住。因為 Explorer 外殼整個都還活著，不管是 Alt+Tab 還是 Win 鍵，都能瞬間跳到桌面。話雖如此，Windows 為了 Kiosk 準備了 Assigned Access・Shell Launcher・多應用程式 Kiosk 這幾種機制，而哪一種可用會因版本與 Windows 版本而異，因此「打算在 Pro 終端上組建，結果發現沒有 Shell Launcher」這種返工也經常發生。

本文以想要組建接待終端、工廠操作終端、檢驗裝置操作畫面、展示終端等「只執行一個應用程式的 PC」的開發者・資訊系統部門人員為對象，整理各方式的全貌與版本需求、PowerShell/XML 的設定範例，以及自動登入、從異常終止復原、Windows Update、維護途徑等維運設計，並附上官方文件的佐證。

1. 先講結論

• 「自動登入 + 啟動項目啟動」並不是 Kiosk。只要 Explorer 外殼還活著，使用者就什麼都能做。若想真正防護，就要使用專用機制。
• Assigned Access 的單一應用程式 Kiosk，會在鎖定畫面之上全螢幕執行 UWP 應用程式或 Microsoft Edge，應用程式一旦被關閉就會自動重新啟動。Pro 以上的版本都可以使用。¹
• 在 Windows 11 上，用 Assigned Access 也能把 Win32(桌面)應用程式做成 Kiosk。在 Windows 11(21H2)以後的結構描述新增的 v4:ClassicAppPath 中指定 EXE 的路徑即可。Windows 10 的 Kiosk 僅限 UWP/Edge。²
• Shell Launcher 是把 Explorer.exe 本身替換成業務應用程式(Win32/UWP)的機制，僅限 Enterprise / Education / IoT Enterprise 系列版本。Pro 無法使用。可以宣告式地組態外殼終止時的行為(重新啟動、重新啟動終端等)。³⁴
• 多應用程式 Kiosk(受限使用者體驗)是透過許可應用程式清單與專用開始功能表，打造「只能使用幾個應用程式的共用終端」的方式。AppLocker 規則會自動產生，未經允許的應用程式無法啟動。²
• 組態方式正在持續整合。無論是單一應用程式、多應用程式，還是 Shell Launcher，目前標準做法都是透過 AssignedAccess CSP(Intune 等 MDM)，或是在本機呼叫同一個 CSP 的 WMI 橋接器 + PowerShell 來組態。⁵⁶
• Kiosk 體驗的跳脫預設為 Ctrl+Alt+Del。在 Windows 11 上可以用 BreakoutSequence 變更。請務必在設計中保留維護人員登入的途徑。²
• 就算固定住了終端，如果業務應用程式端的設計(全螢幕 UI・不顯示結束按鈕・例外時自我復原)沒有做到位，仍然會留下漏洞。OS 的機制與應用程式的設計是一套的。

2. 選項總覽 ── 4 種方式的差異在於「能守住什麼」

首先把各種方式並排列出。重要的不是外觀，而是 Explorer 外殼處於什麼狀態，以及 由誰來阻止未經允許的操作。

區分使用的大致感覺如下。

• 訪客或不特定人士會操作的終端(接待・展示・公共瀏覽)適合單一應用程式 Kiosk，能把可觸及的介面縮到最小。
• 使用固定幾個應用程式的共用終端(現場產線終端、教育用途)適合多應用程式 Kiosk。
• 把一支 Win32 業務應用程式當作裝置操作畫面來執行的工業用途適合 Shell Launcher。它的優勢在於源自 Explorer 的 UI(通知、工作列、從邊緣滑動叫出的 UI)本來就不存在，能依結束代碼組態復原動作，也很適合裝置用途。⁴
• 自動登入 + 啟動項目，會被當作上述任一方式的零件(登入的自動化)來使用，但它單獨並不是 Kiosk。

另外，同一台終端無法同時設定 KioskModeApp(單一應用程式 Kiosk)與 Shell Launcher。² 兩者只能擇一。

3. 版本需求 ── Pro 能做到的事、Enterprise 才需要的事

在選定方式之前，請先確認手邊終端的版本。這一步若延後處理，會導致整個設計都得重做。

• Assigned Access(單一應用程式/多應用程式)：Pro / Enterprise / Education / IoT Enterprise(各自的 LTSC 版本亦包含在內)。¹
• Shell Launcher：Enterprise / Enterprise LTSC / Education / IoT Enterprise / IoT Enterprise LTSC。Pro 不可。³
• Keyboard Filter(按鍵抑止)：僅限 Enterprise / Education / IoT Enterprise 系列。Pro 不可。⁸

也就是說，「想在 Pro 終端上只執行一支 Win32 應用程式」這個經典需求：

• 若是 Windows 11，可以直接用 Assigned Access 的 v4:ClassicAppPath 實現。²
• 若是 Windows 10 Pro則沒有選擇，只能改為 UWP 化，或用多應用程式 Kiosk + 自動啟動(rs5:AutoLaunch)來接近目標，或是提升版本。²

若是裝置內嵌或工業用 PC 可以重新選定終端，那麼齊備 Shell Launcher・Keyboard Filter，又不會被強制推送功能更新的 IoT Enterprise LTSC 就是首選。版本選定的思路，在同日發布的「工業用電腦該安裝哪一種 Windows ── Windows IoT Enterprise / LTSC 實戰指南」中有詳細說明。

另一個前提是，Kiosk 體驗需要啟用 UAC，且必須從主控台登入。透過遠端桌面連線，Kiosk 體驗無法運作。¹ 「想用 RDP 連進去確認動作」結果卻動不了而困惑，是初次接觸時的經典陷阱。主控台工作階段與 RDP 工作階段的關係，請參閱「如何理解 Windows 的工作階段隔離」。

4. 用 Assigned Access 建立單一應用程式 Kiosk

設定途徑有 3 種。依照從簡單到複雜的順序，在 4.1〜4.3 中依序介紹，其中本命的組態 XML，還會延伸到實際套用到終端的步驟(4.4)以及確認是否套用成功的方法(4.5)。

4.1 用「設定」應用程式建立(只有 1 台・若是 Edge/UWP 最快)

可以透過精靈完成 Kiosk 專用本機帳戶的建立與對象應用程式的選擇。步驟如下。⁵

1. 開啟設定 > 帳戶 > 其他使用者
2. 按下「設定 Kiosk 模式」(Set up a kiosk)的「開始使用」(Get Started)
3. 在「建立帳戶」對話方塊中輸入帳戶名稱，按下「下一步」(若已經有本機標準使用者，也可以選擇「選取現有帳戶」)
4. 選擇 Kiosk 帳戶登入時要執行的應用程式。若選擇 Microsoft Edge，接下來還要設定以下項目
   • 要設為全螢幕顯示(數位看板)，還是保留部分瀏覽器操作(公用瀏覽器)
   • 登入時要開啟的網址
   • 若選擇公用瀏覽器，持續無操作多久後要重新啟動 Edge 的時間
5. 按下「關閉」

完成設定後重新啟動終端，建立好的本機帳戶就會自動登入，並啟動指定的應用程式。⁵ 如果只有 1 台，而且是 Edge 或單純的 UWP 應用程式，這樣就夠了。

4.2 用 PowerShell Cmdlet 建立(僅限 UWP)

Set-AssignedAccess 可以用一行指令建立「這個本機標準使用者只能用這個 UWP 應用程式」的最小組態(僅限 UWP・僅限本機標準使用者・不可為系統管理員帳戶)。⁹

# 讓本機標準使用者 KioskUser 專用於 UWP 應用程式
Set-AssignedAccess -UserName 'KioskUser' -AppUserModelId 'Contoso.KenkiPanel_abc123!App'

# 解除
Clear-AssignedAccess

傳給參數的 AUMID(AppUserModelID)可以用 Get-StartApps 查詢。這是一個列出已安裝應用程式名稱與 AppID 的 Cmdlet，會回傳 Name 與 AppID 這兩個欄位。¹⁰

# 從清單中目視尋找
Get-StartApps

# 用名稱的一部分篩選(可用萬用字元)。AppID 欄位的值就是 AUMID
Get-StartApps -Name '*KenkiPanel*' | Format-Table Name, AppID -AutoSize

輸出格式如下(值依環境而異)。¹⁰

Name              AppID
----              -----
KenkiPanel        Contoso.KenkiPanel_abc123!App

需要特別注意的是，Get-StartApps 回傳的是「執行中的使用者」已安裝的應用程式。如果想查詢為 Kiosk 帳戶佈建的應用程式，請用該帳戶登入後再執行。用系統管理員帳戶執行卻找不到，是常見的踩坑點。同時也請注意，UWP 應用程式更新後 AUMID 有可能改變(這種情況下需要重建組態)。⁷

4.3 組態 XML + AssignedAccess CSP(本命)

這是涵蓋指定 Win32 應用程式、自動登入、變更跳脫按鍵在內的本命方法。從 Intune 等 MDM 端會送到 ./Vendor/MSFT/AssignedAccess/Configuration，而在獨立終端上，則是透過 WMI 橋接器，從具有 SYSTEM 權限的 PowerShell 送入同一份 XML。⁵ XML 的重點如下。

<AssignedAccessConfiguration
    xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config"
    xmlns:rs5="http://schemas.microsoft.com/AssignedAccess/201810/config"
    xmlns:v4="http://schemas.microsoft.com/AssignedAccess/2021/config">
  <Profiles>
    <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}">
      <!-- Windows 11:把 Win32 應用程式做成 Kiosk(也可以傳遞引數) -->
      <KioskModeApp v4:ClassicAppPath="%ProgramFiles%\Contoso\KenkiPanel.exe"
                    v4:ClassicAppArguments="--line 3" />
      <!-- 把跳脫按鍵從預設的 Ctrl+Alt+Del 變更 -->
      <v4:BreakoutSequence Key="Ctrl+Alt+K" />
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <!-- 由 Windows 自行建立並管理專用的本機標準使用者,自動登入 -->
      <AutoLogonAccount rs5:DisplayName="接待終端" />
      <DefaultProfile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}" />
    </Config>
  </Configs>
</AssignedAccessConfiguration>

若是 UWP 應用程式，則在 KioskModeApp 中指定 AppUserModelId(AUMID)。需要注意的是，UWP 應用程式更新後 AUMID 有可能改變，此時需要更新組態。⁷ 另外，Kiosk 設定檔只能指派給使用者，無法指派給群組。²

4.4 用 WMI 橋接器實際套用

沒有 MDM 的終端，要透過 MDM 橋接器 WMI 提供者 呼叫同一個 CSP。這是步驟中最容易卡關的地方，因此依序寫下來。⁵

步驟 1：以 SYSTEM 身分啟動 PowerShell。裝置設定的 WMI 橋接器必須以 SYSTEM(LocalSystem)帳戶執行。系統管理員權限的 PowerShell 並不夠。⁵ 官方指引的方法是使用 Sysinternals 的 PsExec。

:: 以系統管理員身分開啟命令提示字元,啟動具有 SYSTEM 權限的互動式 PowerShell
psexec.exe -i -s powershell.exe

步驟 2：確認啟動的 PowerShell 是否為 SYSTEM。沒有確認這一步就繼續進行，結果變成「沒有出現錯誤卻不生效」，是常見的狀況。

# 顯示 NT AUTHORITY\SYSTEM 即為 OK
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name

步驟 3：把 XML 進行 HTML 編碼後送入。在該 SYSTEM 權限的 PowerShell 工作階段中執行。

$assignedAccessConfiguration = @"
<?xml version="1.0" encoding="utf-8"?>
<AssignedAccessConfiguration xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config" xmlns:rs5="http://schemas.microsoft.com/AssignedAccess/201810/config" xmlns:v4="http://schemas.microsoft.com/AssignedAccess/2021/config">
  <Profiles>
    <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}">
      <KioskModeApp v4:ClassicAppPath="%ProgramFiles%\Contoso\KenkiPanel.exe" v4:ClassicAppArguments="--line 3" />
      <v4:BreakoutSequence Key="Ctrl+Alt+K" />
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <AutoLogonAccount rs5:DisplayName="接待終端" />
      <DefaultProfile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}" />
    </Config>
  </Configs>
</AssignedAccessConfiguration>
"@

$namespaceName = "root\cimv2\mdm\dmmap"
$className     = "MDM_AssignedAccess"

$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className
# 不要直接傳入 XML,而是先進行 HTML 編碼再傳遞
$obj.Configuration = [System.Net.WebUtility]::HtmlEncode($assignedAccessConfiguration)
Set-CimInstance -CimInstance $obj

步驟 4：重新啟動終端。設定會從重新啟動後的登入開始生效。重新啟動後，由 AutoLogonAccount 建立的本機帳戶會自動登入，並啟動指定的應用程式。⁵

若要解除，同樣從具有 SYSTEM 權限的 PowerShell 把 Configuration 設為 $null，然後重新啟動。⁵

$obj = Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_AssignedAccess"
$obj.Configuration = $null
Set-CimInstance -CimInstance $obj

4.5 如何確認是否套用成功

為了釐清「沒有出現錯誤卻不生效」的狀況，先準備 3 種確認手段。

(a) 啟用事件記錄檔並查看。官方指引的確認位置就是這個頻道。⁷ 組態 XML 的驗證錯誤與執行階段失敗都會顯示在這裡。

事件檢視器
  > 應用程式與服務記錄
    > Microsoft
      > Windows
        > AssignedAccess
          > Operational

預設情況下可能是停用的，請先選取該頻道，按下右側窗格的「啟用記錄檔」，再重現問題。

(b) 用登錄檔確認寫入的組態。Assigned Access 的組態會記錄在下列機碼中。⁷

(c) 從 CSP 讀回確認。在送入之後，立刻用同一個 SYSTEM 權限的 PowerShell 讀回，就能當場知道值有沒有寫進去。

$obj = Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_AssignedAccess"
$obj.Configuration

# 若以編碼狀態傳回導致難以閱讀,可以解碼後目視確認
[System.Net.WebUtility]::HtmlDecode($obj.Configuration)

若結果為空，代表套用本身失敗；若已寫入卻不動作，就要懷疑 XML 的內容(應用程式路徑、Profile 與 Config 的 GUID 不一致、版本需求)，可以用這種方式來釐清問題。若在步驟 3 出現錯誤，請先回到步驟 2 確認是否為 SYSTEM。

5. 用 Shell Launcher 把 Win32 應用程式當作外殼

若能使用 Enterprise 系列版本，對於像裝置操作畫面這種「Explorer 的存在本身就是妨礙」的終端，Shell Launcher 是最有力的選擇。Shell Launcher v2(Windows 10 1809 以後)由 CustomShellHost.exe 取代 Explorer.exe 來啟動・監控業務應用程式，無論 Win32 還是 UWP 都能當作外殼。³

組態使用專用的 XML，能依結束代碼分別宣告應用程式終止時的復原動作是最大的特色。⁴

<ShellLauncherConfiguration
    xmlns="http://schemas.microsoft.com/ShellLauncher/2018/Configuration"
    xmlns:V2="http://schemas.microsoft.com/ShellLauncher/2019/Configuration">
  <Profiles>
    <DefaultProfile>
      <!-- 維護人員等未指派設定檔的使用者,使用一般的 Explorer -->
      <Shell Shell="%SystemRoot%\explorer.exe" />
    </DefaultProfile>
    <Profile Id="{自行採號的GUID}">
      <Shell Shell="%ProgramFiles%\Contoso\KensaPanel.exe" V2:AppType="Desktop"
             V2:AllAppsFullScreen="true">
        <ReturnCodeActions>
          <ReturnCodeAction ReturnCode="0"  Action="RestartShell"/>   <!-- 正常結束 → 重新啟動 -->
          <ReturnCodeAction ReturnCode="10" Action="RestartDevice"/>  <!-- 要求重新啟動 -->
        </ReturnCodeActions>
        <DefaultAction Action="RestartShell"/>
      </Shell>
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <AutoLogonAccount/>  <!-- 自動建立、自動登入本機標準使用者「Kiosk」 -->
      <Profile Id="{自行採號的GUID}"/>
    </Config>
  </Configs>
</ShellLauncherConfiguration>

Profile Id 的 GUID 並不是向哪裡申請、由誰核發的值。它是為了在 XML 內保持唯一性而自行採號的值，可以用 PowerShell 的 New-Guid 產生。⁴

# 產生一個帶大括號的形式。把這個字串貼到 XML 中
"{$((New-Guid).Guid.ToUpper())}"

請把產生出來的值，以相同的形式(含大括號)同時寫入 Profiles 端與 Configs 端。直接複製上面的範例卻無法運作，就是因為需要進行這項替換。第 4 章 Assigned Access 組態 XML 中出現的 Profile Id / DefaultProfile Id，也是同性質的值。

動作有 RestartShell / RestartDevice / ShutdownDevice / DoNothing 4 種。若結束代碼沒有對應到任何動作，DefaultAction 也未定義，就會「什麼都不會發生」，也就是停在黑畫面。請務必定義 DefaultAction。⁴ 套用方式：若是 MDM，送到 ./Vendor/MSFT/AssignedAccess/ShellLauncher；若是本機，則透過與 Assigned Access 相同的 WMI 橋接器，把 XML 設定到 MDM_AssignedAccess 的 ShellLauncher 屬性中。⁶ 依環境不同，有時需要事先透過「開啟或關閉 Windows 功能」，啟用裝置鎖定底下的 Shell Launcher 功能(Client-EmbeddedShellLauncher)。

以下列出 Shell Launcher 特有的 3 個陷阱。³

• 啟動另一個處理程序後自身就結束的應用程式，無法當作外殼。Shell Launcher 監控的是指定處理程序的終止，如果指定的是啟動器類型的 EXE(官方文件的範例是 write.exe)，就會立刻被判定為「已終止」。
• 外殼是以登入使用者的權限執行的。如果把外殼指派給系統管理員帳戶，就會以該權限做任何事都可以；而如果外殼應用程式本身要求系統管理員權限提升，就必須停用 UAC 才能啟動。應該在走到這一步之前，就把應用程式設計成不需要權限提升。
• Shell Launcher 並不會防止其他應用程式啟動。因為它只是替換外殼，透過業務應用程式內的檔案對話方塊啟動 EXE 之類的途徑仍然存在。對於無法信任操作者的終端，需要併用 AppLocker 或 Keyboard Filter。

6. 維運設計 ── 自動登入・復原・Update・維護途徑

選好方式並完成設定並不代表結束。能讓終端在無人狀態下持續運轉的設計，才是 Kiosk 的本體。

自動登入優先採用組態 XML 中的 AutoLogonAccount。因為由 Windows 自行建立並管理專用的本機標準使用者，所以不需要保管密碼。²⁴ 傳統的 Winlogon 登錄檔方式(AutoAdminLogon/DefaultUserName/DefaultPassword)也能使用，但密碼會以明文形式留存。另外，在套用了 EAS 密碼限制的終端上，自動登入無法運作，這是規格所致，請確認是否與 MDM 原則衝突。⁷

應用程式當機時的第一線復原交給 OS 端處理。Assigned Access Kiosk 在應用程式關閉後會自動重新啟動。¹ Shell Launcher 則用 DefaultAction/ReturnCodeActions 組態復原動作。⁴ 除此之外，為了應對「重新啟動後仍持續因同一個例外而當機」的情況，事先安排夜間定期重新啟動的工作，能提升復原能力(工作的組建方式請參閱「工作排程器的安全維運設計」)。

Windows Update 不是要停止它，而是要控制時間。官方建議的組態是：把使用中時段配合營業時間，設為自動下載 + 夜間排程安裝，並關閉包含重新啟動警告在內的通知。⁷ 請務必在實機上確認，重新啟動後能自動接續到「自動登入 → Kiosk 復原」為止。電源設定也一樣，把睡眠或關閉顯示器的逾時時間設為 0(停用)，並停用電源按鈕。⁷ 挪用筆記型電腦的終端，以及 Modern Standby 機種，行為特別容易有怪癖，請一併確認「睡眠・休眠・Modern Standby 與長時間執行的應用程式」。

鍵盤與觸控的漏洞依方式而不同。在多應用程式 Kiosk(受限使用者體驗)中，Alt+F4・Alt+Tab・Ctrl+Alt+Del 預設不會被封鎖。⁷ 用來封鎖這些按鍵的是 Keyboard Filter，可以抑止實體與螢幕鍵盤雙方的按鍵組合(用 Dism /online /Enable-Feature /FeatureName:Client-KeyboardFilter 啟用，僅限 Enterprise 系列)。⁸ 在平板型終端上，要把 LockDown/AllowEdgeSwipe 原則設為停用(0)，避免從螢幕邊緣滑動叫出系統 UI。

確保維護途徑與封鎖操作一樣重要。Assigned Access Kiosk 的跳脫預設為 Ctrl+Alt+Del(在 Windows 11 上可以用 BreakoutSequence 變更)，從那裡以系統管理員帳戶登入。² 若用 Keyboard Filter 連 Ctrl+Alt+Del 都封鎖，Keyboard Filter 端的跳脫按鍵(預設是連按左 Windows 鍵 5 次)就會成為回到歡迎畫面的最後途徑。⁸ 另外，Keyboard Filter 在安全模式下無效，也可以將系統管理員帳戶設為排除套用。⁸ Kiosk 體驗僅限主控台使用，但系統管理員的 RDP 維護可以併用，保留遠端途徑能減少現場出動的次數。發生問題時，事件記錄檔的「AssignedAccess > Operational」頻道會是組態錯誤的第一手資訊。⁷

7. 業務應用程式端的設計與實務定石(判斷表)

不管把 OS 端固定得多牢固，只要應用程式還是「普通的桌面應用程式」，漏洞就依然存在。以下列出搭載於 Kiosk 上的應用程式設計要求。

• 自行維持全螢幕・無邊框。雖然 Shell Launcher 有 V2:AllAppsFullScreen，但基本上應該由應用程式自身維持最大化・最前面・無標題列，並設計成失去焦點時把自己拉回最前面。
• 不顯示結束按鈕。畫面上不放置關閉手段，改用只有維護人員知道的隱藏操作(例如依序點按畫面四個角落 + 輸入密碼)叫出維護選單。只要把結束代碼區分開來，就能用 Shell Launcher 的 ReturnCodeActions 做到「從維護選單結束 → 為了回到 Explorer 而不做任何事」「更新後結束 → 重新啟動終端」這樣的連動。⁴
• 發生例外時自我復原。最糟糕的情況是把未處理例外吞掉，畫面停在無法操作的狀態。應該寫下記錄後立即結束自身處理程序，交由 OS 端的重新啟動機制(Kiosk 的自動重新啟動・Shell Launcher 的 RestartShell)接手。
• 防止多重啟動。自動重新啟動系機制與自行實作的重新啟動處理疊加時，容易發生重複啟動。應加入以 Mutex 進行的多重啟動防止機制(「防止 Windows 應用程式重複啟動」)。
• 不要求權限提升。Kiosk 帳戶原則上應為標準使用者，在 Shell Launcher 中，需要提升權限的外殼會被迫停用 UAC。³ 需要系統管理員權限的處理應事先分離出來(「Windows 應用程式中把「僅需要系統管理員權限的處理」分離出來的具體寫法」)。

最後附上判斷表。

8. 總結

• 「自動登入 + 啟動項目啟動」並不是 Kiosk。只要 Explorer 還活著就什麼都守不住，因此要使用 Assigned Access 或 Shell Launcher。
• Assigned Access 在 Pro 以上就能使用，可以組態單一應用程式 Kiosk(UWP/Edge，Windows 11 上也可用 Win32)以及多應用程式的受限使用者體驗。
• Shell Launcher 是把 Explorer.exe 替換成業務應用程式的機制，僅限 Enterprise / Education / IoT Enterprise 系列，可以依結束代碼分別宣告復原動作(RestartShell 等)。
• 組態已整合到 AssignedAccess CSP 中，即使沒有 MDM，也能透過 WMI 橋接器 + PowerShell(SYSTEM 權限)套用同一份 XML。
• 維運設計的骨幹是：透過 AutoLogonAccount 進行的自動登入、OS 重新啟動機制 + 定期重新啟動所做的復原、Windows Update 的時間控制，以及 BreakoutSequence・跳脫按鍵・遠端維護等跳脫途徑的確保。
• 最後的堡壘是業務應用程式的設計。唯有滿足維持全螢幕・沒有結束按鈕・例外時自我復原・防止多重啟動・不需要權限提升，「只執行一個應用程式的 PC」才算真正完成。

相關文章

• 工業用電腦該安裝哪一種Windows ── Windows IoT Enterprise / LTSC 實戰指南
• 防止 Windows 應用程式重複啟動 ── 具名 Mutex 與重複執行時的視窗前置
• 如何理解 Windows 的工作階段隔離 ── Session 0・RDP・多使用者同時執行
• 睡眠・休眠・Modern Standby 與長時間執行的應用程式 ── 用設計預防「半夜停止運轉」
• 工作排程器的工作不執行、以 0x1 結束 ── 原因排查與安全的維運設計
• Windows 應用程式中把「僅需要系統管理員權限的處理」分離出來的具體寫法

相關諮詢領域

合同會社小村軟體處理接待終端、工廠操作終端、檢驗裝置操作畫面等 Kiosk 終端的方式選定與組態，能承受 Kiosk 環境的業務應用程式(全螢幕 UI・自我復原・權限分離)的設計・開發，以及既有終端的「重新固定」。

• Windows 業務應用程式開發
• 裝置整合・軟即時控制應用程式開發
• 技術諮詢・設計審查
• 聯絡我們

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

常見問題

整理諮詢這個主題時常見的問題。

Assigned Access 在 Windows Pro 上也能使用嗎？

可以使用。Assigned Access(單一應用程式 Kiosk 與多應用程式的受限使用者體驗)在 Pro / Enterprise / Education / IoT Enterprise(各自的 LTSC 版本亦包含在內)上都受支援。另一方面，把 Explorer.exe 本身替換成業務應用程式的 Shell Launcher 僅限 Enterprise / Education / IoT Enterprise 系列，Pro 無法使用。此外，Kiosk 體驗需要啟用 UAC，且必須從主控台登入，透過遠端桌面連線並不支援 Kiosk 體驗。

要把 Win32(桌面)應用程式做成 Kiosk，一定要用 Shell Launcher 嗎？

在 Windows 11 上已經不是必須的了。Windows 11(21H2 以後的結構描述)的 Assigned Access，可以透過 KioskModeApp 元素的 v4:ClassicAppPath 屬性指定桌面應用程式的執行檔路徑，即使在 Pro 終端上也能組態 Win32 應用程式的單一應用程式 Kiosk。Windows 10 的 Assigned Access Kiosk 僅限於 UWP 應用程式與 Microsoft Edge，因此若只想執行一支 Win32 應用程式，現實的解法是使用 Shell Launcher(僅限 Enterprise 系列)，或是在多應用程式組態中使用 AutoLaunch。請先確認版本與方式的對應關係，再進行設計。

如果 Kiosk 應用程式異常終止，會自動復原嗎？

行為會依方式而異。Assigned Access 的單一應用程式 Kiosk，規格上是應用程式一旦被關閉就會自動重新啟動。在 Shell Launcher 中，可以用 DefaultAction 與 ReturnCodeActions 宣告式地組態作為外殼的應用程式終止時的行為，可從 RestartShell(重新啟動外殼)・RestartDevice(重新啟動終端)・ShutdownDevice・DoNothing 中選擇。若結束代碼沒有對應的動作、也沒有定義 DefaultAction，就什麼都不會發生，畫面會停在黑畫面上，因此請務必定義 DefaultAction。應用程式端也需要設計成:發生未處理例外時自行結束，銜接到復原動作。

維護人員該如何以系統管理員身分登入？

Assigned Access 的 Kiosk 體驗，預設可以用 Ctrl+Alt+Del 跳出到登入畫面，在 Windows 11 上可以用 BreakoutSequence 元素變更這組按鍵組合。在用 Keyboard Filter 連 Ctrl+Alt+Del 都封鎖的組態下，可以保留 Keyboard Filter 側的跳脫按鍵(預設是連按左 Windows 鍵 5 次)作為回到歡迎畫面的途徑。Kiosk 體驗本身僅限主控台使用，但以系統管理員帳戶進行的遠端桌面維護可以作為另一個工作階段併用。重要的是不要把所有跳脫途徑都封死，變成只能靠現場作業才能復原的終端。

把自動登入的密碼寫進登錄檔安全嗎？

不建議這麼做。Winlogon 的 AutoAdminLogon 方式，DefaultPassword 會以明文形式留在登錄檔中。Assigned Access 與 Shell Launcher 的組態 XML 中都有 AutoLogonAccount 元素，使用這個元素，Windows 會自行建立並管理一個專用的本機標準使用者來自動登入，因此不需要自行保管密碼。原則上，Kiosk 專用帳戶應設為最小權限的本機標準使用者，並避免挪用網域帳戶。另外也請注意，在套用了 Exchange ActiveSync 密碼限制原則的終端上，自動登入將無法運作。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。