由於法規合規性限制，某些客戶永遠無法移過第 1 階段。 這不是問題，而且在必要時仍可維持此狀態。 其他客戶可以繼續進行階段 2 和 3，以完全採用 DINE 和 Modify 原則，以協助其 Azure 環境的原則導向治理。

本文中所述的案例和方法不適用於或建議給大多數客戶。 請先檢閱為何使用 DINE 和修改原則一節 ？ ，再決定這些原則是否適合且適合您的環境。

階段 1：停用 DINE 和修改原則自動化動作

當您指派原則時，預設 會套用原則定義中所定義的效果 。 建議您保留原則定義。 例如，將原則指派效果保留為 DeployIfNotExists 。

您可以改為使用原則指派上的功能，以最少的努力來影響此行為，而不是變更原則定義或其效果。

使用 Azure 入口網站 將強制模式設定為 [已停用]

此螢幕快照顯示如何使用 Azure 入口網站，在原則指派上將強制模式設定為 [已停用 ]。 Disabled 也稱為 DoNotEnforce。

使用ARM範本將強制模式設定為 DoNotEnforce

此程式代碼範例示範如何使用 ARM 樣本，在原則指派上將 設定 enforcementMode 為 DoNotEnforce 。 DoNotEnforce 也稱為 Disabled 。

藉由使用 強制模式 ，您可以看到原則對現有資源的影響，而不需在 Azure 活動記錄中起始或觸發專案。 我們通常稱此為「假設狀況」，而且符合安全部署的做法。

即使強制 模式設定為 DoNotEnforce ， 也可以手動觸發補救工作 。 您可以補救特定不符合規範的資源。 如果強制模式設定為 Default ，您也可以查看 DINE 或修改原則會執行的動作。

當強制模式設定為 DoNotEnforce 時，不會產生 Azure 活動記錄中的專案。 如果您想要在建立不符合規範的資源時收到通知，請考慮此因素。

永久停留在階段 1 狀態

如<方法概觀 >一節所述 ，某些客戶可能需要長期或甚至因為其需求而永久留在 第 1 階段。 此狀態有效，客戶可以隨時留在該狀態中。

也許你需要永久或長期留在這個狀態，像幾年。 若是如此，最好是採用 AuditIfNotExists （AINE） 原則效果和相關聯的定義，並將強制模式設定回 Default 。

藉由變更為使用 AINE 原則，並將強制模式設定為 Default ，您仍然可以達到停用 DINE 的相同目標。

當您從 DINE 變更為 AINE，並將強制模式設定回 Default 為階段 1 的長期或永久方法時，您將取得原則合規性狀態的 Azure 活動記錄專案。 您可以在整體平臺管理作業中，從這些記錄專案建置自動化工作流程。

您將失去執行手動補救工作的功能。 不同於 DINE 原則，AINE 原則不會執行任何部署，無論是自動化或手動部署。

請記得更新原則定義以接受並允許原則 AuditIfNotExists 指派效果。

下表摘要說明不同類型的原則效果和強制模式組合的選項和含意：

如果您打算根據原則狀態事件建置自己的自動化，請檢閱 Reacting to Azure 原則 狀態變更事件 中的 指引，以瞭解是否使用 Azure 事件方格 與 Azure 原則 整合提供適當的方法。

階段 2：在特定原則上啟用 DINE 和修改原則，或縮小範圍

在這裡階段中，您將瞭解如何在原則指派上將強制模式設定為 Default 。

完成 第 1 階段之後，您決定要測試並試用特定原則上或縮小範圍上的 DINE 和 Modify 原則的完整自動化功能。 您想要使用沙箱管理群組或非生產工作負載訂用帳戶。

若要執行此程式，首先您必須識別將用來測試及嘗試 DINE 和 Modify 原則的完整自動化功能的原則或縮減範圍。

您可能想要檢閱及實 作企業級 平台的測試方法。 如此一來，您就可以在相同租使用者內的個別管理群組階層中測試原則和其他平台變更。

這種方法也稱為「Canary」部署。

下表顯示一些建議的範圍和原則範例：

您也可以決定在有限的範圍或一組資源上使用手動補救工作，以測試這些原則如何影響您的環境。 如需如何建立補救工作的詳細資訊，請參閱建立補救工作 Azure 原則 檔 。

識別出原則或原則，以及指派原則的縮減範圍之後，下一個步驟是指派原則，並將強制模式設定為 Default 。 保留原則效果，例如 或 Modify ， DeployIfNotExists 如同您選取的範圍縮小。

使用 Azure 入口網站 將強制模式設定為 [已啟用]

此螢幕快照顯示如何使用 Azure 入口網站，將強制模式設定為 在原則指派上啟用 。 Enabled 也稱為 Default。

使用 ARM 範本將強制模式設定為預設值

此程式代碼範例示範如何使用 ARM 樣本，在原則指派上將 設定 enforcementMode 為 Default 。 Default 也稱為 Enabled 。

此階段的最後一個步驟是執行必要的測試。 您想要確認 DINE 或 Modify 原則是否會影響和變更工作負載、程式代碼、工具和程式。

執行多個測試以擷取工作負載的整個生命週期。 您想要確保您完全瞭解 DINE 或修改原則的變更和方式。

測試的一些範例包括：

階段 3：在任何地方啟用 DINE 和修改原則

在這裡階段中，您將瞭解如何在原則指派上將強制模式設定為 Default 。

我們假設您在 階段 2 結束時 的測試已成功通過。 或者，您可能滿意您現在瞭解 DINE 或修改原則如何與您的工作負載互動。 現在，您可以擴充在 Azure 環境其餘部分使用 DINE 和 Modify 原則。

若要繼續進行，請遵循與階段 2 中 步驟類似的步驟。 這一次，您會在所有 DINE 和修改整個 Azure 環境的原則指派上，將強制模式設定為 Default 。

以下是您在這個階段中執行的步驟概觀：

雖然在階段 3 中，建議您針對 Azure 環境中的所有 DINE 和 Modify 原則，將強制模式設定為 Default ，但這個選擇仍然是選擇性的。 您可以根據每個原則做出這個選擇，以符合您的需求和需求。

進階原則管理

若要大規模管理 Azure 原則，請考慮實 作企業原則即程序代碼 （EPAC） 來管理原則。 EPAC 提供使用 IaC 的具狀態管理體驗。 它通常適用於具有複雜需求的大型原則管理案例。