應用程式佈建處於隔離狀態
Microsoft Entra 佈建服務會監視設定的健康情況。 也會將狀況不良的應用程式放入「隔離」狀態。 如果對目標系統發出的大部分或所有呼叫一直失敗，則佈建作業會標示為隔離。 例如，失敗是因為管理員認證無效而收到錯誤。
在隔離時：
- 增量週期的頻率逐漸降到一天一次。
- 修正所有錯誤之後，佈建作業就解除隔離，下一個同步週期也會開始。
- 如果佈建作業持續隔離超過四週，佈建作業會停用 (停止執行)。
怎麼知道我的應用程式是否隔離？
有三種方式可以檢查應用程式是否隔離：
在 Microsoft Entra 系統管理中心，瀏覽至 [身分識別] > [應用程式] > [企業應用程式] > <[應用程式名稱] > > [佈建]，並檢閱隔離訊息的進度列。
在 Microsoft Entra 系統管理中心，瀏覽至 [身分識別] > [監視與健康情況] > [稽核記錄] > 依 [活動：隔離] 進行篩選並檢閱隔離歷程記錄。 上述進度列中的檢視指出佈建目前是否隔離。 稽核記錄顯示應用程式的隔離歷程記錄。
使用 Microsoft Graph 要求 Get synchronizationJob，以程式設計方式取得佈建作業的狀態：
GET https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/{jobId}/
檢查您的電子郵件。 將應用程式放入隔離時會傳送一次性通知電子郵件。 如果隔離原因變更，則會傳送更新的電子郵件，以指出隔離的新原因。 如果您沒有看到電子郵件：
- 請確定您已在應用程式的佈建設定中指定有效的 [通知電子郵件]。
- 請確定通知電子郵件收件匣沒有垃圾郵件篩選。
- 請確定您未取消訂閱電子郵件。
- 檢查來自
azure-noreply@microsoft.com的電子郵件
為什麼隔離我的應用程式？
以下是應用程式可能進入隔離的常見原因
| 描述 | 建議的動作 |
|---|---|
| SCIM 合規性問題：傳回「HTTP/404 找不到」回應，而不是預期的「HTTP/200 正常」回應。 在此案例中，Microsoft Entra 佈建服務已向目標應用程式發出要求，並收到非預期的回應。 | 檢查管理員認證區段。 了解應用程式是否需要指定租用戶 URL，以及 URL 是否正確。 如果您沒有看到問題，請洽詢應用程式開發人員，確定其服務符合 SCIM 規範。 https://tools.ietf.org/html/rfc7644#section-3.4.2 |
| 認證無效：嘗試授權、存取目標應用程式時，我們收到目標應用程式的回應，指出提供的認證無效。 | 巡覽至佈建設定 UI 的管理員認證區段，然後使用有效的認證再次授權存取。 如果應用程式在資源庫中，請檢閱應用程式設定教學課程，以取得更多必要的步驟。 |
| 角色重複：從 Salesforce 和 Zendesk 等應用程式匯入的角色必須是唯一的。 | 瀏覽至 Microsoft Entra 系統管理中心的應用程式資訊清單，然後移除重複的角色。 |
取得佈建作業狀態的 Microsoft Graph 要求指出下列隔離原因：
EncounteredQuarantineException表示提供的認證無效。 佈建服務無法在來源系統與目標系統之間建立連線。EncounteredEscrowProportionThreshold表示佈建超過委付閾值。 此狀況是指超過 40% 的佈建事件失敗。 如需詳細資訊，請參閱以下的委付閾值詳細資料。QuarantineOnDemand表示我們偵測到您的應用程式有問題，已手動設定為隔離。
委付閾值
如果達到比例委付閾值，佈建作業會進入隔離。 此邏輯可能改變，但運作方式大致如下所述：
無論管理員認證或 SCIM 合規性等問題的失敗計數，作業都可能進入隔離。 不過，一般而言，最少 5,000 次失敗才會開始評估是否因為失敗太多次而需要隔離。 例如，失敗 4,000 次的作業不會進入隔離。 但是，失敗 5,000 次的作業會觸發評估。 評估使用下列準則：
- 如果超過 40% 的佈建事件失敗，或有超過 40,000 次失敗，佈建作業會進入隔離。 參考失敗不算入 40% 閾值或 40,000 閾值內。 例如，參考失敗可能是無法更新管理員或群組成員。
- 如果作業未成功佈建 45,000 個使用者，因為超過 40,000 閾值，將導致隔離。
- 如果作業有 30,000 個使用者佈建失敗，但成功佈建 5,000 個使用者，因為超過 40% 閾值和 5,000 最低門檻，將導致隔離。
- 如果作業有 20,000 次失敗和 100,000 次成功，因為未超過 40% 失敗閾值或 40,000 失敗上限，不會進入隔離。
- 絕對閾值為 60,000 次失敗，參考和非參考失敗都算在內。 例如，40,000 個使用者佈建失敗，且 21,000 次管理員更新失敗。 總計 61,000 次失敗，超過 60,000 限制。
重試持續時間
此處記載的邏輯可能有別於某些連接器，以確保提供最佳客戶體驗，但失敗之後，我們通常會有下列重試週期：
失敗之後，第一次重試會在 6 小時內發生。
- 第二次重試會在第一次失敗後的 12 小時發生。
- 第三次重試會在第一次失敗後的 24 小時發生。
在第三次重試之後，每隔 24 小時會重試一次。 重試會在第一次失敗之後持續 28 天，之後會移除第三方託管項目並停用作業。
如果上述任一次重試取得成功的回應，作業會自動退出隔離，並應繼續進行定期的同步處理行為。
如何讓我的應用程式解除隔離？
首先，解決導致應用程式進入隔離的問題。
檢查應用程式的佈建設定，確定您已輸入有效的管理員認證。 Microsoft Entra ID 必須與目標應用程式建立信任關係。 請確定您已輸入有效的認證，而且您的帳戶具有必要權限。
檢閱佈建記錄，以進一步調查造成隔離的錯誤，並解決錯誤。 移至 [活動] 區段中的 Microsoft Entra ID>Enterprise Apps> 布建記錄。
解決問題之後，請重新啟動佈建作業。 應用程式佈建設定的某些變更，例如屬性對應或範圍設定篩選，將會自動為您重新開始佈建。 應用程式 [佈建] 頁面上的進度列指出上次開始佈建的時間。 如果您需要手動重新啟動佈建作業，請使用下列其中一種方法：
使用 Microsoft Entra 系統管理中心重新啟動佈建作業。 在應用程式的 [佈建] 頁面上，選取 [重新啟動佈建]。 此動作會完全重新啟動佈建服務，可能需要一些時間。 完整的初始週期將會再次執行，這會清除 escrows、將應用程式從隔離中移除，並清除任何浮水印。 服務接著會再次評估來源系統中的所有使用者，並判斷這些使用者是否在佈建範圍內。 當應用程式目前在隔離中 (如本文所討論)，或您需要變更屬性對應時，這就很有用。 請注意，由於需要評估的物件數目，初始週期需要比一般累加週期花費更長的時間才能完成。 您可在這裡深入了解初始和累加週期的效能。
使用 Microsoft Graph 來重新啟動佈建作業。 您可以完全控制想要重新啟動什麼作業。 您可以選擇清除委付 (重新起算累計導致隔離狀態的委付計數)、解除隔離 (將應用程式解除隔離)，或清除浮水印。 使用下列要求：
POST /servicePrincipals/{id}/synchronization/jobs/{jobId}/restart
將 "{ID}" 換成應用程式識別碼的值，將 "{jobId}" 換成同步作業的識別碼。