透過 Cloud SQL 使用代管的 Microsoft AD

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

本頁面說明如何使用 Cloud SQL 執行下列操作：

• 與 Managed Service for Microsoft Active Directory (也稱為 Managed Microsoft AD) 整合。
• 以 AD 使用者身分連線至執行個體。

與 Managed Microsoft AD 整合的 Cloud SQL 執行個體除了支援 SQL 驗證外，也支援 Windows 驗證。

事前準備

1. 在 Google Cloud 控制台中，選取專案名稱。
2. 請確認您已為 Google Cloud 專案啟用計費功能。瞭解如何確認您已啟用專案的計費功能。
3. 安裝並初始化 gcloud CLI。
4. 請確認您的使用者帳戶具有 Cloud SQL Admin 角色。前往「身分與存取權管理」頁面。
5. 請參閱 整合前置條件。

使用 Windows 驗證建立執行個體

您可以在建立執行個體時整合 Managed Microsoft AD，為執行個體啟用 Windows 驗證機制。如要整合，您必須選擇要讓執行個體加入的網域。如果加入網域失敗，則無法建立執行個體。

在準備使用 Windows 驗證建立執行個體時，請參閱提示和限制和替代方案。

系統支援具備公開 IP 的執行個體，只要該執行個體也具備私人 IP；必須為執行個體啟用私人 IP。接著，您可以選擇使用公開 IP 或私人 IP 連線至執行個體 (如果兩者皆可使用)。

以下是建立與 Managed Microsoft AD 整合的執行個體的選項。

gcloud beta sql instances create INSTANCE_NAME \
--database-version=EDITION \
--root-password=PASSWORD \
--active-directory-domain=DOMAIN\
--cpu=CPU \
--memory=MEMORY  \
--network=NETWORK

resource "google_sql_database_instance" "instance_with_ad" {
  name             = "database-instance-name"
  region           = "us-central1"
  database_version = "SQLSERVER_2019_STANDARD"
  root_password    = "INSERT-PASSWORD-HERE"

  depends_on = [google_service_networking_connection.private_vpc_connection]

  settings {
    tier = "db-custom-2-7680"
    active_directory_config {
      domain = "ad.domain.com"
    }
    ip_configuration {
      ipv4_enabled    = "false"
      private_network = google_compute_network.private_network.id
    }
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

{
   "databaseVersion":"database-version",
   "name":"instance-id",
   "region":"region",
   "rootPassword":"password",
   "settings":{
      "tier":"machine-type",
      "ipConfiguration":{
         "privateNetwork":"network"
      },
      "activeDirectoryConfig":{
         "domain":"domain"
      }
   }
}

使用 Windows 驗證更新執行個體

您可以更新現有執行個體的網域，變更或新增網域。

如要進一步瞭解如何更新執行個體，請參閱「編輯執行個體」。

如果執行個體目前已與受管理的 AD 網域建立連結，則會先從該網域取消連結，再連結至新網域。如果更新失敗，執行個體可能就無法再加入任何網域。

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=DOMAIN

{
   "settings":{
      "activeDirectoryConfig":{
         "domain":"domain"
      }
   }
}

與其他專案中的受管理 AD 網域整合

您可以將執行個體與位於不同專案中的 Managed Microsoft AD 網域整合。

規劃整合時，請查看限制條件。

啟用網域對等互連

請先啟用網域對等連線，再繼續執行下列各節中的步驟，讓您的網域可供所有必要的專案使用，並搭配 SQL Server 適用的 Cloud SQL 執行個體。

如要取得其他專案中已可用的網域清單，您可以指定下列項目：

`gcloud active-directory peerings list`

詳情請參閱「列出網域對等連線」。

gcloud active-directory peerings list 指令需要 managedidentities.peerings.list 權限。下列角色具備此權限：

• roles/managedidentities.peeringViewer
• roles/managedidentities.viewer

詳情請參閱「使用身分與存取權管理功能控管存取權」一文。

建立服務帳戶

針對包含您要整合的 Cloud SQL for SQL Server 執行個體的每個專案，重複執行這些步驟。

1. 請參閱建立服務帳戶的背景資訊。

2. 使用類似下方的指令建立服務帳戶。指定包含 SQL Server 適用的 Cloud SQL 執行個體的專案 ID：

   gcloud beta services identity create --service=sqladmin.googleapis.com \
   --project=[PROJECT_ID]

3. 使用 Managed Microsoft AD 執行個體，在專案中授予 managedidentities.sqlintegrator 角色。指定包含 Managed Microsoft AD 執行個體的專案 ID：

   gcloud projects add-iam-policy-binding [PROJECT_ID] \
   --member=serviceAccount:SERVICE_ACCOUNT --role=roles/managedidentities.sqlintegrator

啟用跨專案 Windows 驗證

您可以使用 gcloud 指令或 Cloud SQL REST API，與其他專案中的 AD 網域整合。無論選擇哪一種做法，您都必須指定完整的網域資源名稱。

建立或更新 Cloud SQL for SQL Server 執行個體時，請指定完整的網域資源名稱。系統支援兩種格式：

• projects/PROJECT_ID/locations/global/domains/DOMAIN_NAME
• projects/PROJECT_NUMBER/locations/global/domains/DOMAIN_NAME

以下是使用 gcloud 的範例：

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=projects/PROJECT_ID/locations/global/domains/DOMAIN_NAME

如果您使用短網域資源名稱 (例如 DOMAIN_NAME)，系統會假設您的代管 Microsoft AD 網域與 SQL Server 適用的 Cloud SQL 執行個體位於相同專案中。

與其他專案整合的限制

如果您要整合其他專案中的受管理 AD 網域，則適用下列限制：

• 最多可有 10 個網路與位於不同專案中的一個 Managed Microsoft AD 執行個體共用 Cloud SQL for SQL Server 執行個體。
• Google Cloud 主控台僅支援位於同一專案中的受管理 Microsoft AD 執行個體。您可以使用 gcloud 指令或 Cloud SQL REST API 進行整合，而非使用 Google Cloud 控制台。
• 如果使用 VPC Service Controls，Cloud SQL for SQL Server 執行個體和受管理的 Microsoft AD 執行個體必須位於相同範圍內。

此外，如果執行個體與不同專案中的受管理 AD 網域整合，Google Cloud 控制台中顯示的完整網域名稱 (FQDN) 可能會與該執行個體不符。具體來說，在該執行個體的「Overview」頁面「Connect to this instance」下方，FQDN 可能包含以斜線分隔的字串，您可以忽略這些字串。舉例來說，不準確的 FQDN 可能會顯示為：

private.myinstance.myregion.myproject.projects/mydirectory/locations/global/domains/mydomain.com

在這種情況下，正確的 FQDN 為：

private.myinstance.myregion.myproject.cloudsql.mydomain.com

從執行個體中移除 Windows 驗證

您可以從現有執行個體移除 Windows 驗證，進而移除受管理的 Microsoft AD 整合。

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=

{
   "settings":{
      "activeDirectoryConfig":{
         "domain":""
      }
   }
}

以使用者身分連線至執行個體

針對 SQL Server 適用的 Cloud SQL，預設使用者為 sqlserver。

將執行個體與 Managed Microsoft AD 整合後，您可以使用 sqlserver 使用者連線至執行個體，如下所示：

1. 根據 Windows 使用者或群組建立 SQL Server 登入，如下所示：

   CREATE LOGIN [domain\user_or_group] FROM WINDOWS

2. 使用 Windows 驗證功能，並使用執行個體的 DNS 名稱登入執行個體。以下是可指定的執行個體 DNS 名稱範例：

   • 如要透過私人 IP 連線：

     private.myinstance.us-central1.myproject.cloudsql.mydomain.com

   • 如要透過公開 IP 連線：

     public.myinstance.us-central1.myproject.cloudsql.mydomain.com

   • 如要透過 Cloud SQL 驗證 Proxy 連線 (請參閱下方的說明)：

     proxy.myinstance.us-central1.myproject.cloudsql.mydomain.com

   如果您使用的是執行個體 IP 位址，則必須設定 Kerberos 用戶端，以支援 IP 主機名稱。Cloud SQL 不支援透過信任關係連結的網域登入。

使用 Cloud SQL 驗證 Proxy 搭配 Windows 驗證

您可以將 Cloud SQL 驗證 Proxy 與 Managed Microsoft AD 整合。

開始前，請先查看：

• 關於 Cloud SQL 驗證 Proxy

• 使用 Cloud SQL 驗證 Proxy 連線

Windows 驗證步驟

如要瞭解啟動 Cloud SQL 驗證 Proxy 的背景資訊，請參閱「啟動 Cloud SQL 驗證 Proxy」。

如要使用 Windows 驗證，您必須在 1433 通訊埠上執行 Cloud SQL 驗證 Proxy。如要將預先定義的服務主體名稱 (SPN) 項目對應至 Cloud SQL 驗證 Proxy 位址，請使用：

proxy.[instance].[location].[project].cloudsql.[domain]

在本機執行 Cloud SQL 驗證 Proxy

如果您在本機執行 Cloud SQL 驗證 Proxy，請使用主控台檔案將下列項目對應至 127.0.0.1：

proxy.[instance].[location].[project].cloudsql.[domain]

舉例來說，您可以將下列內容新增至主機檔案 (例如 c:\windows\system32\drivers\etc\hosts)：

127.0.0.1 proxy.[instance].[location].[project].cloudsql.[domain]

在該範例中，您可以使用以下指令執行 Cloud SQL 驗證 Proxy，並在 127.0.0.1:1433 上提供該 Proxy：

cloud-sql-proxy.exe --credentials-file credential.json project:name

在非本機上執行 Cloud SQL 驗證 Proxy

如要在非本機上執行 Cloud SQL 驗證 Proxy，請按照「在本機上執行 Cloud SQL 驗證 Proxy」一文的操作說明操作，但在 Hosts 檔案中使用不同的項目。

具體來說，如果非本機主機為 MyOtherHost，您可以將下列內容新增至主機檔案：

127.0.0.1 MyOtherHost proxy.[instance].[location].[project].cloudsql.[domain]

排解用戶端的 NTLM 備用問題

如果您使用 Windows 驗證和執行個體 IP 位址登入執行個體，就必須設定 Kerberos 用戶端，以支援 IP 主機名稱。

Cloud SQL 不支援 NTLM 驗證，但某些 Kerberos 用戶端可能會嘗試改用 NTLM 驗證。如本節所述，如果您嘗試連線至 SQL Server Management Studio (SSMS)，並且出現下列錯誤訊息，可能的原因是 NTLM 備用：

Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. (Microsoft SQL Server, Error: 18452)

NTLM 是一組 Microsoft 安全性通訊協定，用於驗證。另請參閱「NTLM 備用方案的原因」。

驗證 Windows 用戶端的 NTLM 備用機制

如要透過 Windows 確認 NTLM 備用機制導致錯誤，請按照下列步驟操作：

1. 使用所需的內部憑證登入 (請勿使用「以...身分執行」)。
2. 開啟命令提示字元。
3. 執行 klist purge。
4. 透過 SSMS，嘗試使用 Windows 驗證連線至 SQL Server。
5. 執行 klist，並檢查是否有針對 "MSSQLSvc/<address>:1433 @ domain" 發出的支援單。
6. 如果沒有這類票證，則 NTLM 備用機制很可能是導致錯誤的原因。
7. 如果有這類票證，請確認 SQL Server 驅動程式不會強制執行 NTLM 驗證。另外，請檢查是否透過群組政策強制執行 NTLM 驗證。

驗證 Linux 用戶端的 NTLM 備用機制

從 Ubuntu 16.04 開始，如要驗證 NTLM 備用機制導致錯誤，請按照本節中的步驟操作。步驟與其他 Linux 發行版本類似。

設定 Kerberos 驗證

1. 設定 Kerberos 用戶端：

   sudo apt-get install krb5-user
   

2. 系統提示您輸入預設領域時，請輸入內部網域名稱 (大寫字母)。

3. 執行下列指令，安裝 SQL Server 指令列工具：

   curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
   curl https://packages.microsoft.com/config/ubuntu/16.04/prod.list | sudo tee /etc/apt/sources.list.d/msprod.list
   sudo apt-get update
   sudo apt-get install mssql-tools unixodbc-dev
   

連結至 Windows 驗證

1. 執行 kinit 工具，如下所示：kinit <user_account>
2. 如要連線至 Windows 驗證，請執行： /opt/mssql-tools/bin/sqlcmd -S <address >>
3. 執行 klist 指令，並檢查是否有專門針對以下項目核發的支援單："MSSQLSvc/<address>:1433 @ domain"
4. 如果未發出憑證，上述錯誤可能表示發生導致 NTLM 備用模式的問題。

NTLM 備用機制的原因

備援至 NTLM 是用戶端設定錯誤，可能與下列情況有關：

• 根據預設，如果主機名稱是 IP 位址，Windows 就不會嘗試為主機進行 Kerberos 驗證。如要啟用受管理網域的 Kerberos 驗證，請嘗試使用 Microsoft 說明文件中所述的方法。當您必須使用 FQDN 時，這個方法不適用於內部部署憑證。
• 透過外部信任關係進行 Kerberos 驗證無法運作。請改用這裡所述的森林信任。
• Kerberos 驗證需要名稱後置字元路由，才能在其他樹系中尋找服務。請嘗試這裡所述的方法。
• 如果服務未註冊 SPN，Kerberos 驗證就無法運作。請僅使用從 Google Cloud 主控台取得的 FQDN 或 IP 位址，連線至 Windows 驗證。

內部 AD 使用者：建立 Windows 登入資訊

您可以使用內部 AD 使用者建立 Windows 登入帳戶，以便登入 Cloud SQL for SQL Server。

舉例來說，您可以使用在 Google Cloud 專案虛擬私有雲 (VPC) 中代管的 Windows VM 上執行的 SQL Server Management Studio (SMSS) 進行連線。

在這個情況下，SQL Server 適用的 Cloud SQL 僅支援 Kerberos 通訊協定。針對以 Kerberos 為基礎的 Windows 驗證，用戶端必須解析內部 AD 和受管理的 Microsoft AD 的 DNS 名稱。

設定單向或雙向信任關係

一開始，請決定要使用單向或雙向信任關係。

然後，按照操作說明在內部部署的 AD 網域和 Managed Microsoft AD 網域之間建立信任關係。

設定 Windows VM 並建立 Windows 登入資訊

在內部部署的 AD 網域和受管理的 Microsoft AD 網域之間建立信任關係後，請完成下列步驟。舉例來說，這些步驟會使用在 Windows VM 上執行的 SQL Server Management Studio (SSMS)，並在 Google Cloud 專案的 VPC 中代管：

1. 建立 Windows VM。
   • 建立 VM，並使用Managed Microsoft AD 支援的 Windows 版本。
   • 在代管 Managed Microsoft AD 網域的專案中建立 VM。如果有共用虛擬私有雲是已授權的網路，您也可以在任何服務專案中建立虛擬機器。
   • 在 VPC 網路中建立 VM，該網路是受管理的 Microsoft AD 網域的授權網路，且已設定 Cloud SQL 的私人服務存取權。
2. 將 Windows VM 加入代管的 Microsoft AD 網域。
3. 在 Windows VM 上安裝 SSMS。
4. 在 VPC 網路中解析內部部署網域。
   • 在 Windows VM 執行的授權網路中，按照「Resolve queries for non-Managed Microsoft AD objects」頁面上的步驟，啟用內部 DNS 解析。該頁面上的步驟是讓以 Kerberos 為基礎的 Windows 驗證功能對內部部署使用者生效的必要條件。

5. 為內部部署使用者建立 Windows 登入資訊。

   • 請按照建立登入說明的操作說明，為內部部署使用者建立 Windows 登入資訊。例如，指定類似以下的指令：

   CREATE LOGIN [DOMAIN_NAME\USER_NAME] FROM WINDOWS
   

6. 請按照應用程式專屬操作說明，登入 SQL Server 適用的 Cloud SQL 執行個體，以便登入內部使用者。舉例來說，如果您使用 SQL Server Management Studio，請參閱這篇文章的操作說明。

解決內部 AD 使用者相關問題

如果在登入 Cloud SQL for SQL Server 執行個體時發生問題，請執行以下驗證：

• 請按照建立內部部署網域信任關係的操作說明，驗證內部部署網路和專案授權虛擬私人雲端的防火牆設定。
• 驗證名稱後置字路由是否適用於內部部署信任關係。
• 請確認您可以從執行 SSMS 的 Windows VM 執行這些 DNS 解析作業：
  • nslookup fqdn-for-managed-ad-domain
  • nslookup fqdn-for-on-premises-ad-domain
  • nslookup fqdn-for-cloud-sql-server-instance

提示

• 系統支援具備公開 IP 的執行個體，只要該執行個體也具備私人 IP；必須為執行個體啟用私人 IP。接著，您可以選擇使用公開 IP 或私人 IP 連線至執行個體 (如果兩者皆可用)。
• 建立執行個體 (包括替代執行個體) 前，請視需要查看下列項目：
  • 瞭解如何使用私人 IP
  • 設定公開 IP
• 支援 Terraform。
• 如果您收到下列任一錯誤訊息，請確認您已符合所有 整合前置條件：
  • 「找不到每個產品/專案的服務帳戶」
  • 「Insufficient permission to integrate with Managed Service for Microsoft Active Directory domain」
• 如果收到「找不到網域」錯誤訊息，請確認網域名稱是否正確無誤 (區分大小寫)。
• 如果透過信任關係連線的網域 Windows 驗證失敗，請確認 Windows 驗證是否可用於受管理網域的使用者。如果是，請按照下列步驟操作：
  1. 請確認您使用了 DNS 名稱。系統不支援使用信任關係連結的網域 IP 位址。
  2. 請確認您已按照所有步驟建立具有內部部署網域的信任，包括開啟所有防火牆通訊埠。
  3. 驗證信任關係。
  4. 確認信任關係的方向，確保網域 (透過信任關係連線) 的使用者可在受管理的網域中進行驗證。
  5. 確認在透過信任關係連結的網域上設定了名稱後置字元路由。
  6. 確認信任關係在未使用 SQL Server 適用的 Cloud SQL 的情況下運作：
     1. 建立 Windows VM。
     2. 將其加入代管的 Microsoft AD 網域。
     3. 例如，嘗試以透過信任關係連結的網域使用者身分執行記事本。
  7. 重新啟動用戶端 VM，並重新測試 Windows 驗證。
• 您可能會嘗試建立 SQL Server 登入，但收到以下錯誤訊息：「找不到 Windows NT 使用者或群組網域/名稱。請再次檢查名稱」這可能是因為系統不支援網域本機群組，如果適用，請改用通用群組。
• 如果使用者透過信任關係連線至網域，並發出 SQL Server 查詢，可能會導致以下錯誤：「無法取得 Windows NT 群組/使用者相關資訊」。舉例來說，如果您透過信任關係建立與網域連結的登入資訊，就可能發生這個錯誤。如果您是透過信任關係連結網域，為登入作業授予權限，也可能會發生這個錯誤。在這些情況下，重試作業通常會成功。如果重試失敗，請關閉連線並開啟新的連線。

• 如果您收到「無法取得 Windows NT 群組/使用者相關資訊」的錯誤訊息，請使用 Cloud Logging 中的記錄檔 active_directory.log 檢查與 SQL Server 適用 Cloud SQL 執行個體的網路連線。這個檔案包含以下與內部部署網域連線變更相關的診斷資訊：

  • Cloud SQL for SQL Server 執行個體信任的內部部署網域。舉例來說，下列記錄顯示從沒有信任的網域變更為兩個新的信任網域，其 NetBIOS 名稱為 ONPREM 和 CHILD：

    2023-06-12 20:55:09.975 Detected change in trusted onprem domains: Previously trusted onprem domains: []. Current trusted onprem domains: [ONPREM CHILD]

    如果未列出內部部署網域，或是系統記錄為不受信任，請檢查 Managed AD 網域是否存在信任關係，並驗證該信任關係。如果代管 AD 網域和內部部署網域之間是單向信任關係，您可能看不到內部部署網域信任的其他內部部署網域。
  • 使用 SQL Server 適用的 Cloud SQL 執行個體定期執行 ping 時，可連線和無法連線的內部網域。舉例來說，以下記錄顯示從無法存取的網域變更為兩個新的可存取網域 onprem.com 和 child.onprem.com：

    2023-06-12 20:55:10.664 Detected change in reachable onprem domains: Previously reachable onprem domains: []. Current reachable onprem domains: [onprem.com child.onprem.com]

    如果某個網域未列在可及性記錄中，請先確認該網域是否已登錄為信任的網域。否則不會檢查可及性。我們一向會在含有內部部署執行個體的專案與 Google Cloud 專案之間建立虛擬私人雲端對等互連。即使再增加一個虛擬私有雲對等互連，也會導致遞移對等互連連線，而 Cloud SQL 不支援這類連線。建議您改用 VPN 通道，將內部部署網域連線至 Cloud SQL。在內部部署專案和具有 SQL Server 適用 Cloud SQL 執行個體的 Google Cloud 專案之間，最多只能建立一個對等連線。
  • 從 SQL Server 適用的 Cloud SQL 執行個體向內部網域發出的 Microsoft 遠端程序呼叫 (MSRPC) 通訊內容，成功和失敗的情況。舉例來說，以下記錄顯示從沒有可供 MSRPC 執行 ping 的網域，變更為兩個新的可供 MSRPC 執行 ping 的網域 ONPREM 和 CHILD：

    2023-06-12 20:55:10.664 Detected change in MSRPC pingable domains: Previously pingable onprem domains: []. Current pingable onprem domains: [ONPREM CHILD]

    MSRPC 通訊內容會納入額外診斷資訊，但在某些設定下可能無法運作。您仍可透過前兩項診斷工具驗證內部網域連線。

• 如果 SQL Server 查詢導致「The login is from an untrusted domain」(登入來自不受信任的網域) 錯誤訊息，請注意，如果使用者透過信任關係連線至網域，則系統不支援 IP 位址。此外，下列動作可能會解決這個問題：

  • 如果您使用 IP 位址連線到受管理網域的使用者，請按照這些操作說明操作。
  • 請避免使用任何 Proxy，並一律使用相同的 DNS 名稱連線至 Cloud SQL for SQL Server，因為您會在 Google Cloud 控制台中看到該名稱。
  • 清除現有的 Kerberos 票證。如果您有最近已連線至 SQL Server 適用的 Cloud SQL 執行個體的用戶端，且該執行個體已停止及啟動，就可能發生上述錯誤。或者，如果您先停用 Windows 驗證，然後再重新啟用 SQL Server 適用的 Cloud SQL 執行個體，也可能會發生錯誤。如果用戶端使用 Windows 憑證快取，請鎖定及解鎖用戶端工作站，或執行 klist purge。

• 嘗試啟用 Windows 驗證功能時，可能會發生「這個執行個體需要較新的建立日期，才能支援 Microsoft Active Directory 的 Managed Service」錯誤。請注意下列與此錯誤相關的事項：

  • 在 Cloud SQL 中，如果 Cloud SQL for SQL Server 執行個體是在 2021 年 3 月 12 日當天或之前建立，就無法與 Managed Microsoft AD 整合。
  • 在某些情況下，如果您建立 Cloud SQL for SQL Server 執行個體，但未在建立時啟用 Managed Microsoft AD，可能會收到相同的錯誤。查看本節的其他提示後，請建立新的執行個體，並在建立執行個體時啟用 Managed Microsoft AD。

• 嘗試建立 Cloud SQL for SQL Server 執行個體時，可能會發生「此執行個體不支援 Managed Service for Microsoft Active Directory」的錯誤。如果收到這則錯誤訊息，表示專案可能不受支援；請嘗試使用其他專案。

• 如果執行個體持續發生 Windows 驗證問題 (無論執行個體是否最近更新)，請嘗試取消加入受管理的 Active Directory 網域，然後重新加入。如要這麼做，請使用更新程序取消加入，然後重新加入網域。這麼做不會移除資料庫中任何已驗證的 Windows 使用者或登入資訊。不過，移除 Windows 驗證功能會導致執行個體重新啟動。

• 使用 AD 診斷工具，在 Google Cloud 控制台中排解貴機構內部網域和 Cloud SQL for SQL Server 執行個體的 AD 設定問題。

疑難排解

如需詳細資訊，請按一下表格中的連結：

後續步驟

• 請確認您已詳閱 總覽頁面，瞭解限制和不支援的功能。這個頁面也提供其他說明文件的連結。