はじめに

当社ではMicrosoft Teamsを全社導入しました。

Teamsはチャットやオンライン会議、ファイル共有などを利用できる便利なコラボレーションツールです。一方で、実際に導入・運用を進めると、Teamsそのものの設定だけでは完結しない課題に直面することがあります。

例えば、Teams用に割り当てたMicrosoft 365ライセンスによってExchange Onlineも利用できる状態になったり、チームのメンバー管理が運用負荷になったり、利用者ごとに会議時間の表示が異なるといった問題が発生したりします。

この記事では、当社でMicrosoft Teamsの導入・運用を進める中で実際に対応した、以下の3つのTipsを紹介します。

1. Teams利用環境でExchange Onlineの利用を抑止する
2. ADグループを利用してTeamsメンバー管理を自動化する
3. Teamsの会議時間を正しいタイムゾーンで表示する

いずれも大規模なシステム開発ではなく、Microsoft 365の標準機能やPowerShellを活用して対応した事例です。同様の環境を運用されている方の参考になれば幸いです。

Tips1 Teams利用環境でExchange Onlineの利用を抑止する

背景

購入ライセンス数の関係上、当社では単体ライセンスではなくMicrosoft 365 Enterprise E3として、Microsoft Teamsを全社導入しました。

Microsoft 365 E3にはメールサービスであるExchange Onlineも含まれます。しかし、導入にあたり策定した運用ガイドラインでは、Exchange Onlineは利用を許可するMicrosoft 365サービスに含めませんでした。

ところが、Outlook for Windows（旧称「新しいOutlook for Windows」、以降「Outlook」）を起動した際に、Exchange Onlineのユーザー メールボックスへ自動接続する挙動が確認されました。アカウントを追加する作業も不要で、禁止されたサービスを利用していることが分かりづらいため、Outlookからの利用を強制的に制限することになりました。

Exchange Onlineのユーザー メールボックス管理機能

Exchange Onlineには、メールボックスにアクセスするアプリを制限する機能が存在します。

Exchange管理センターからアプリの設定を無効化すると、以下のようなアプリからのアクセスをブロックできます。

そこで、私のメールボックスに対してOutlook on the webの項目を試しに無効化してみました。WebブラウザーからMicrosoft365.comにサインインし、アプリ一覧からOutlookを選択したところ、エラーメッセージが表示されて利用できませんでした。

ところが、今度はOutlookを起動したところ、メールが格納された受信トレイが表示され、本文の閲覧もできてしまいました。

原因を調べたところ、Outlookにはオフライン状態でもメールを読んだり、下書きメールを作成したりできるオフライン アクセス機能が存在することが分かりました。過去にOutlookを起動しており、キャッシュに残されたメールが表示された状態でした。

幸いにもOutlookの設定からこの機能を無効化でき、Outlookを起動してもエラーメッセージが表示されて利用できなくなりました。

OutlookとOutlook on the webの利用を制限できたため、ユーザー メールボックスに対してメールアプリからのアクセスを無効化することにしました。

ただし、Teamsはユーザーのメールボックスを、1対1のチャットやグループチャット、個人のカレンダーなどのデータを格納する場所として利用します。そのため、メールアプリの無効化によってTeamsの動作に問題が出ないかという懸念がありました。

そこで、一部の利用者に無効化設定を先行適用し、普段通りTeamsのチャットや会議機能を数か月間利用し続けましたが、特に問題は起こりませんでした。また、Microsoft Purview電子情報開示ソリューションのコンテンツ検索を使用して、私のメールボックスを検索したところ、1対1のチャットに書き込んだメッセージを見つけることができ、メールボックスへのデータ格納にも影響が出ないことを確認できました。

しかしながら、全員分のメールボックスに対してメールアプリの設定を変更するにあたり、以下の課題が出てきました。

• Outlookのオフライン アクセス機能を無効化するには、利用者が各自で設定変更する必要がある
• 設定変更後に新規作成されたメールボックスに対して、メールアプリの無効化を自動で行う方法はないか
• 2,500個以上のメールボックスが存在するが、Exchange管理センターから一括で変更する機能が存在しない

ここからは、全社適用に向けてこれらの課題をどのように対処したのかを紹介します。

管理者によるオフライン アクセス機能の一元管理

Outlook on the webおよびOutlookでユーザーが使用できる機能を制御するために、Exchange OnlineではOutlook on the webメールボックスポリシーが用意されています。ポリシーで設定可能な項目の中に、Outlookでオフライン機能が利用可能かどうかを制御するものがあります。

ただし、Exchange管理センターからポリシーを変更する際に表示されるオフライン アクセスの項目は、Outlook on the webに対する設定です。Outlookに対する設定を変更するには、Exchange Online PowerShellを利用する必要があります。

具体的には、Exchange Online PowerShellモジュールをインストールしたWindows端末でPowerShell 5.1を起動し、以下のコマンドレットを実行してExchange Onlineに接続します。

1
Import-Module ExchangeOnlineManagement
2
Connect-ExchangeOnline

サインインは、グローバル管理者、Exchangeの管理者、Exchange受信者管理者のいずれかのMicrosoft Entraロールを持つユーザーで行います。

Outlookのオフライン アクセス機能を利用しないようにするメールボックスポリシーを作成します。

1
New-OwaMailboxPolicy -Name OwaMailboxPolicy-OfflineDisabledWin

既定のメールボックスポリシー OwaMailboxPolicy-Defaultとプロパティが同じになるように作成したポリシーの設定を変更し、加えてOutlookのオフライン アクセス機能を無効化します。

1
$reference = 'OwaMailboxPolicy-Default'
2
$new = 'OwaMailboxPolicy-OfflineDisabledWin'
3

4
$referencePolicy = Get-OwaMailboxPolicy -Identity $reference
5
$newPolicy = Get-OwaMailboxPolicy -Identity $new
6

7
$parameters = @{}
8
$command = Get-Command Set-OwaMailboxPolicy
9
$members = ($referencePolicy | Get-Member -MemberType Property).Name
10

11
$command.Parameters.Keys | Where-Object {
12
    $_ -ne 'Identity' -and
13
    $_ -ne 'Name' -and
14
    $_ -ne 'IsDefault' -and
15
    $members -contains $_ -and
16
    $newPolicy."$_" -ne $referencePolicy."$_"
17
} | ForEach-Object {
18
    $parameters[$_] = $referencePolicy."$_"
19
}
20

21
$parameters['Identity'] = $new
22

23
Set-OwaMailboxPolicy @parameters
24
Set-OwaMailboxPolicy OwaMailboxPolicy-OfflineDisabledWin -OfflineEnabledWin $false

後は、それぞれのメールボックスにポリシーを割り当てます。

1
Set-CASMailbox -Identity <メールボックスのメールアドレス> -OwaMailboxPolicy "OwaMailboxPolicy-OfflineDisabledWin"

ポリシーを割り当てた後に、アプリの設定からOutlook on the webの項目を無効化すると、事前にOutlookからオフライン アクセス機能を無効にしなくても利用できなくなりました。

新規メールボックスに対するメールアプリの自動無効化

Microsoft EntraユーザーにExchange Onlineのライセンスを割り当てると、そのユーザーのメールボックスが作成されます。この際にメールボックスのプロパティを自動的に構成するテンプレートが、メールボックス プランとクライアント アクセス サービス（CAS）メールボックス プランです。

CASメールボックス プランでは、メールボックスに対するメールアプリからのアクセスやOutlook on the webメールボックスポリシーの初期値を設定できます。そのため、プランの内容を変更したうえで既存メールボックスの設定を一度変更すれば、それ以降の追加対応は不要になります。

なお、プランは新規で作成することはできず、サブスクリプションまたはライセンスごとに事前に用意された以下のプランを変更する必要があります。

新しいユーザーにライセンスを割り当てると、対応するプランを使用して、作成された新しいメールボックスの設定が構成されます。また、既存ユーザーに割り当てられているライセンスを変更しても、新しいライセンスに対応するプランの設定がユーザーの既存メールボックスに適用されます。

今回全社導入したライセンスはMicrosoft 365 Enterprise E3なので、ExchangeOnlineEnterpriseの表示名を持つプランだけを変更すればよいのですが、それ以外のライセンスも今後追加導入する可能性を考慮し、すべてのプランを変更することにしました。

各プランに対して、Exchange ActiveSync、Exchange Web サービス、Outlook on the web、POP3、IMAP、MAPIによるアクセスを無効化し、メールボックスポリシー OwaMailboxPolicy-OfflineDisabledWinを割り当てます。

1
Set-CASMailboxPlan -Identity ExchangeOnlineDeskless -ActiveSyncEnabled $false -EwsEnabled $false -OWAEnabled $false -PopEnabled $false -ImapEnabled $false -MAPIEnabled $false -OwaMailboxPolicy OwaMailboxPolicy-OfflineDisabledWin
2
Set-CASMailboxPlan -Identity ExchangeOnline -ActiveSyncEnabled $false -EwsEnabled $false -OWAEnabled $false -PopEnabled $false -ImapEnabled $false -MAPIEnabled $false -OwaMailboxPolicy OwaMailboxPolicy-OfflineDisabledWin
3
Set-CASMailboxPlan -Identity ExchangeOnlineEnterprise -ActiveSyncEnabled $false -EwsEnabled $false -OWAEnabled $false -PopEnabled $false -ImapEnabled $false -MAPIEnabled $false -OwaMailboxPolicy OwaMailboxPolicy-OfflineDisabledWin

変更後の設定を確認したところ、想定通りの内容になっていました。なお、ExchangeOnlineEssentialsについては、Exchange Onlineのドキュメントにも記載がなかったため確認したところ、現在は利用されていないプランでした。

1
Get-CasMailboxPlan | Format-Table DisplayName, ActiveSyncEnabled, EwsEnabled, OWAEnabled, PopEnabled, ImapEnabled, MAPIEnabled, OwaMailboxPolicy
2

3
DisplayName              ActiveSyncEnabled EwsEnabled OWAEnabled PopEnabled ImapEnabled MAPIEnabled OwaMailboxPolicy
4
-----------              ----------------- ---------- ---------- ---------- ----------- ----------- ----------------
5
ExchangeOnlineDeskless               False      False      False      False       False       False OwaMailboxPolicy-OfflineDisabledWin
6
ExchangeOnline                       False      False      False      False       False       False OwaMailboxPolicy-OfflineDisabledWin
7
ExchangeOnlineEnterprise             False      False      False      False       False       False OwaMailboxPolicy-OfflineDisabledWin
8
ExchangeOnlineEssentials              True       True       True       True        True        True OwaMailboxPolicy-Default

既存メールボックス設定の一括変更

今後新規作成されるメールボックスへの対応が完了したので、後は既存メールボックスの設定を変更するだけです。Exchange Online PowerShellモジュールを使用して、すべてのユーザー メールボックスを対象にSet-CASMailboxコマンドレットを実行すれば実現できるはずです。

ただし、対象のメールボックスは2,500個以上あり、PowerShellがすべてのメールボックスを正しく扱えるか不安がありました。そのような状況で、メールボックスを取得する方法にはGet-MailboxコマンドレットとGet-EXOMailboxコマンドレットの2種類が存在することに気づきました。

Get-EXOMailboxがExchange Online PowerShell専用である以外の違いを調べたところ、Get-Mailboxと比べて大量のユーザーでも安定して動作するようになったとの情報がありました。

そこで、Get-EXOMailboxを採用し、既存のユーザー メールボックスに対するメールアプリからのアクセスを以下の手順で制限しました。

1. 以下のコマンドを実行して、Outlookのオフライン アクセス機能を利用不可にするメールボックス ポリシーへ変更する。

1
Get-EXOMailbox -ResultSize unlimited -RecipientTypeDetails UserMailbox | ForEach-Object {
2
    Set-CASMailbox -Identity $_.UserPrincipalName -OwaMailboxPolicy "OwaMailboxPolicy-OfflineDisabledWin"
3
}

2. メールボックス ポリシーの変更から約24時間が経過するのを待つ。

   • Microsoft 365の設定変更は通常1時間程度で反映されることが多いが、まれに24時間程度かかることがあるため。

3. 以下のコマンドを実行して、メール アプリの設定を変更する。

1
Get-EXOMailbox -ResultSize unlimited -RecipientTypeDetails UserMailbox | ForEach-Object {
2
    Set-CASMailbox -Identity $_.UserPrincipalName -ActiveSyncEnabled $false -EwsEnabled $false -OWAEnabled $false -PopEnabled $false -ImapEnabled $false -MAPIEnabled $false
3
}

懸念していたPowerShellのエラーも発生せず、2,500個以上のメールボックス設定を変更できました。また、先行適用しなかった利用者にOutlookを試しに利用してもらったところ、想定通りエラーメッセージが表示されました。

これで、Microsoft 365運用ガイドラインを誤って破ってしまう事態を、システム的に防ぐことができました。

Tips2 ADグループを利用してTeamsメンバー管理を自動化する

背景

Teamsのチームやチャネルを部署やプロジェクト単位で作成すると、メンバー管理が運用負荷になります。異動や入退社のたびにTeams側のメンバーを個別に追加・削除するのは手間がかかります。また、更新が漏れると「異動した人がまだチームに残っている」「新しく配属された人がチームに入れていない」といった状態が発生しがちです。

一方で、社内には人事情報と連動したActive Directory セキュリティグループ（以下、ADグループ）がすでに存在し、部署やプロジェクトのメンバー構成が管理されているケースもあります。

Teamsの裏側で使われているMicrosoft 365 グループのメンバーをADグループと連動できれば、Teams側での二重管理を避けられます。

この記事では、Microsoft 365 グループとADグループを同期する仕組みについて、実装方法と注意点を紹介します。

前提として、Microsoft Entra Connectを使用した環境が必要です。

同期ロジック

同期は、AD側を正としてMicrosoft 365 グループ側のメンバーを合わせにいく、一方向の処理とします。具体的な流れは以下の通りです。

1. 同期元のADグループのメンバー一覧を取得
2. 同期先のMicrosoft 365 グループのメンバー一覧を取得
3. 双方を比較し、ADグループにのみ存在するメンバーをMicrosoft 365 グループへ追加
4. Microsoft 365 グループにのみ存在するメンバーをMicrosoft 365 グループから削除
5. 所有者についても、ADグループの管理者情報をもとに同様の追加・削除

タスクスケジューラーで上記処理を記述したスクリプトを定期的に実行することで、AD側のメンバー変更を一定時間ごとにMicrosoft 365 グループへ反映できます。

グループメンバーの取得（処理1,2）

同期元のADグループ、同期先のMicrosoft 365 グループについて、それぞれのメンバー名（UPN）を取得します。

ADグループはSamAccountName、Microsoft 365 グループはメールアドレスを一意なプロパティとして検索します。

1
# 同期元のADグループメンバー名を取得
2
$ad_group_members_name = (Get-ADGroupMember -Identity <ADグループのSamAccountName> -Recursive).Name
3
$ad_group_members = @()
4
for ($count = 0; $count -lt $ad_group_members_name.Count; $count++) {
5
    $ad_group_members += (Get-ADUser -Identity $ad_group_members_name[$count]).UserPrincipalName
6
}
7
-----出力例------
8
aaa@example.co.jp
9
ccc@example.co.jp
10
-----------------
11

12
# 同期先のMicrosoft 365 グループメンバー名を取得
13
$azure_group_id = (Get-MgGroup -Filter "mail eq '<Microsoft 365 グループのメールアドレス>'").Id
14
$azure_group_members = (Get-MgGroupMember -All -GroupId $azure_group_id).AdditionalProperties.userPrincipalName
15
-----出力例------
16
aaa@example.co.jp
17
bbb@example.co.jp
18
ddd@example.co.jp
19
-----------------

Microsoft 365 グループへのメンバー追加・削除（処理3,4）

取得した各グループのメンバー名を比較し、追加メンバーと削除メンバーを決定します。

1
# 追加メンバー
2
$missing_members = $ad_group_members | Where-Object { $azure_group_members -notcontains $_ }
3
-----出力例------
4
ccc@example.co.jp
5
-----------------
6

7
# 削除メンバー
8
$surplus_members = $azure_group_members | Where-Object { $ad_group_members -notcontains $_ }
9
-----出力例------
10
bbb@example.co.jp
11
ddd@example.co.jp
12
-----------------

不足しているメンバーはNew-MgGroupMemberで追加し、余剰のメンバーはRemove-MgGroupMemberByRefで削除します。

1
# メンバーを追加
2
for ($count = 0; $count -lt $missing_members.Count; $count++) {
3
    $add_user = (Get-MgUser -UserId $missing_members[$count]).Id
4
    New-MgGroupMember -GroupId $azure_group_id -DirectoryObjectId $add_user
5
}
6

7
# メンバーを削除
8
for ($count = 0; $count -lt $surplus_members.Count; $count++) {
9
    $remove_user = (Get-MgUser -UserId $surplus_members[$count]).Id
10
    Remove-MgGroupMemberByRef -GroupId $azure_group_id -DirectoryObjectId $remove_user
11
}

所有者の追加・削除（処理5）

今回の同期処理でポイントとなるのが、メンバー用のADグループと所有者用のADグループをそれぞれ用意することです。ただし、この状態だと同期対象が増えるたびに2つのグループを処理内で指定する必要があります。

その解決策として、メンバー用ADグループの管理者に所有者用ADグループを指定します。ADグループの管理者（ManagedBy属性）には、ユーザーだけでなくグループも指定できます。

この方法であれば、スクリプト側はメンバー用ADグループを1つ指定するだけで、その管理者情報から所有者用ADグループをたどって所有者一覧を取得できます。対象グループが増えても管理が煩雑になりません。

具体的には、ManagedBy属性の値をグループとして取得し、そのグループからメンバーを展開することで使用できます。

1
# メンバー用ADグループの管理者（所有者用ADグループ）を取得
2
$ad_group_owner_group = Get-ADGroup (Get-ADGroup $ad_group_name -Properties *).ManagedBy
3
# 管理者グループのメンバー一覧を取得
4
$ad_group_owner_name = (Get-ADGroupMember $ad_group_owner_group -Recursive).Name
5
$ad_group_owner = @()
6
for ($count = 0; $count -lt $ad_group_owner_name.Count; $count++) {
7
    $ad_group_owner += (Get-ADUser -Identity $ad_group_owner_name[$count]).UserPrincipalName
8
}
9
-----出力例------
10
ccc@example.co.jp
11
-----------------
12

13
# Microsoft 365 グループの所有者を取得
14
$azure_group_owner = (Get-MgGroupOwner -All -GroupId $azure_group_id -ErrorAction Stop).AdditionalProperties.userPrincipalName
15
-----出力例------
16
aaa@example.co.jp
17
ddd@example.co.jp
18
-----------------

所有者もメンバーと同様に各グループの差分から追加・削除の対象を決定します。

不足している所有者はNew-MgGroupOwnerByRef、余剰の所有者はRemove-MgGroupOwnerByRefで削除します。

New-MgGroupOwnerByRefについては、所有者情報を含むハッシュテーブルをパラメータに指定する必要があります（参考 ⧉）。

1
# 追加所有者
2
$missing_owner = $ad_group_owner | Where-Object { $azure_group_owner -notcontains $_ }
3
-----出力例------
4
ccc@example.co.jp
5
-----------------
6

7
# 削除所有者
8
$surplus_owner = $azure_group_owner | Where-Object { $ad_group_owner -notcontains $_ }
9
-----出力例------
10
aaa@example.co.jp
11
ddd@example.co.jp
12
-----------------
13

14
# 所有者を追加
15
for ($count = 0; $count -lt $missing_owner.Count; $count++) {
16
    $add_owner = (Get-MgUser -UserId $missing_owner[$count]).Id
17
    $new_owner = @{
18
        "@odata.id" = "https://graph.microsoft.com/v1.0/users/$add_owner"
19
    }
20
    New-MgGroupOwnerByRef -GroupId $azure_group_id -BodyParameter $new_owner
21
}
22

23
# 所有者を削除
24
for ($count = 0; $count -lt $surplus_owner.Count; $count++) {
25
    $remove_owner = (Get-MgUser -UserId $surplus_owner[$count]).Id
26
    Remove-MgGroupOwnerByRef -GroupId $azure_group_id -DirectoryObjectId $remove_owner
27
}

ライセンス上の注意点

Microsoft 365 グループの中には、Teamsのチームと連携しているものがあります。Teamsのチーム作成時に自動生成されるMicrosoft 365 グループは、AdditionalProperties内のresourceProvisioningOptionsというプロパティに"Team"という値を持ちます。

1
Key                         Value
2
---                         -----
3
resourceProvisioningOptions {Team}

Web画面で確認したい場合は、Microsoft 365 管理センター ⧉にアクセスし、チームとグループ > アクティブなチームとグループ で表示されるグループ一覧を確認します。「Teamsの状態」にTeamsアイコンがあれば連携済みです。

Teamsと連携しているグループにメンバーを追加する際は、注意が必要です。Teamsの利用にはライセンス（Microsoft 365 E3などに含まれるTeamsのサービスプラン）が必要です。ライセンスを持たないユーザーをそのグループへ追加すると、意図せずライセンス違反の状態を作ってしまう可能性があります。

そこで、Teamsと連携しているグループについては、メンバー追加前に対象ユーザーのライセンスを確認する処理を組み込みます。Get-MgUserLicenseDetailでユーザーのライセンス情報を取得し、ServicePlansプロパティの中にTeamsのサービスプラン（TEAMS1など）がSuccess（有効）の状態で含まれているかを判定します。

1
# 所持ライセンスを表示（SKU）
2
Get-MgUserLicenseDetail -UserId <メンバーまたは所有者のUPN> | Format-List
3
-----出力例------
4
Id                   : LuTE1qTZ_kS17YxtEb6rchem6QVhAu5Mu0QTjT712WU
5
ServicePlans         : {REMOTE_HELP, Intune-MAMTunnel, Intune_ServiceNow, INTUNE_P2...}
6
SkuId                : 05e9a617-0261-4cee-bb44-138d3ef5d965
7
SkuPartNumber        : SPE_E3
8
AdditionalProperties : {}
9

10
Id                   : LuTE1qTZ_kS17YxtEb6rcpK4DfPpB-lHg3yAcn9G_T0
11
ServicePlans         : {EXCHANGE_S_FOUNDATION, DYN365_CDS_VIRAL, FLOW_P2_VIRAL}
12
SkuId                : f30db892-07e9-47e9-837c-80727f46fd3d
13
SkuPartNumber        : FLOW_FREE
14
AdditionalProperties : {}
15
-----------------
16

17
# Teamsが使用可能なサービスプランがあるか判定
18
$has_teams_license = (Get-MgUserLicenseDetail -UserId <メンバーまたは所有者のUPN>).ServicePlans |
19
    Where-Object { $_.ServicePlanName -eq "TEAMS1" -and $_.ProvisioningStatus -eq "Success" }
20
-----出力例------
21
AppliesTo ProvisioningStatus ServicePlanId                        ServicePlanName
22
--------- ------------------ -------------                        ---------------
23
User      Success            57ff2da0-773e-42df-b2af-ffb7a2317929 TEAMS1
24
-----------------

対象ユーザーが多い場合、1人ずつライセンスを確認すると処理時間が長くなります。取得済みのライセンス情報をキャッシュしたり、並列処理を使ったりすることで、全体の処理時間を抑える工夫が必要です。

実装時の注意点

ライセンス確認の処理を組み込むにあたって、他にも気をつけたい点があります。

退職済みユーザーが同期対象に含まれる可能性がある

Get-ADGroupMemberでADグループのメンバーを取得する場合、退職済みユーザー用の組織単位（OU）に移動済みのユーザーが、実行アカウントの権限によっては取得結果に含まれることがあります。

取得したメンバーの識別名（DistinguishedName）を確認し、退職済みユーザー用のOUに含まれるユーザーを同期対象から明示的に除外しておくと安全です。

まとめ

ADグループとMicrosoft 365 グループを同期する仕組みについて、その処理の流れと、Teams連携時に注意すべきライセンスの考え方を紹介しました。

ADグループの構成をそのままMicrosoft 365 グループへ反映するだけでは、ライセンスの制約や、想定していない属性を持つユーザーの存在によって思わぬ不具合につながることがあります。同様の仕組みを検討する際は、ライセンスの確認処理やユーザーの属性チェックを組み込んでおくことをおすすめします。

Tips3 Teamsの会議時間を正しいタイムゾーンで表示する

背景

当社にTeamsを導入して間もなく、「Teamsのカレンダーから会議を設定しようとすると、人によってタイムゾーンが異なっており、正しい空き時間が分からない」といった問い合わせがありました。

Teams上のカレンダーの実態は、裏側で動いているExchange Onlineの予定表データです。そのため最初は、Exchange管理センターかPowerShellを使って、全社員のタイムゾーンを一括で変更すれば解決するだろうと考えていました。

しかし、調査を進めるとそう簡単ではないことが分かりました。

調査結果

調べていくうちに、TeamsとExchange Onlineの周りには、以下の3つの異なるタイムゾーン設定が存在することが分かりました。

1. Exchange Online上のタイムゾーン
   • 管理者がPowerShell（Set-MailboxRegionalConfiguration）で一括設定可能
   • 個人でもMicrosoftのマイアカウントページから変更可能
2. Teams上のカレンダーのタイムゾーン
   • OSのタイムゾーンを参照している
3. 会議時間のタイムゾーン
   • Teams上でスケジュールを作成する際に実際に参照しているタイムゾーン

今回、スケジュールの空き時間に影響していたのは、3つ目の「会議時間のタイムゾーン」でした。

管理者では一括変更できない？

PowerShellを使い、検証用アカウントの「Exchange Online上のタイムゾーン」を変更するテストを行いました。

1
Connect-ExchangeOnline
2

3
Get-MailboxRegionalConfiguration user@example.com
4
Identity             Language        DateFormat TimeFormat TimeZone
5
--------             --------        ---------- ---------- --------
6
XXXXX                 ja-JP           yyyy/MM/dd H:mm       UTC
7

8
Set-MailboxRegionalConfiguration user@example.com -TimeZone "Tokyo Standard Time"
9

10
Get-MailboxRegionalConfiguration user@example.com
11
Identity             Language        DateFormat TimeFormat TimeZone
12
--------             --------        ---------- ---------- --------
13
XXXXX               ja-JP           yyyy/MM/dd H:mm       Tokyo Standard Time

設定変更後、Exchange Online上のタイムゾーンは「Tokyo Standard Time」に変更されました。

しかし、この設定を変更しても、スケジュールの検索で参照される「会議時間のタイムゾーン」は連動して変わりませんでした。

結論として、「会議時間のタイムゾーン」は管理者権限では一括設定できませんでした。

OSのタイムゾーンと「会議時間のタイムゾーン」にズレがある場合、ユーザーのTeams予定表設定画面に以下のような注意書きが表示されます。

今後の対応方針

「管理者が一括で設定できるだろう」という当初の想定とは異なりましたが、仕様が明確になったため、社内向けに以下の対応手順を周知しました。

• OSのタイムゾーンを「（UTC+09:00）」に設定する。
• Teamsの予定表設定画面に「はい、更新します」ボタンが表示されている場合は、各自で押してもらう。

なお、Exchange Online上のタイムゾーンも念のため揃えておくのが理想ですが、現状は業務影響がないため、今後Exchange Onlineを本格利用するタイミングで一括設定を検討することにしました。

おわりに

今回は、Microsoft Teamsの導入・運用で実際に対応した以下の3つのTipsを紹介しました。

• Teams利用環境でExchange Onlineの利用を抑止する
• ADグループを利用してTeamsメンバー管理を自動化する
• Teamsの会議時間を正しいタイムゾーンで表示する

Teamsの導入自体は比較的容易ですが、実際の運用ではサービス利用制御、メンバー管理、利用者サポートなど、さまざまな課題が発生します。

また、TeamsはExchange OnlineやMicrosoft 365 グループ、OSの設定など、複数の要素と密接に連携しています。そのため、Teamsだけを見ていると原因が分かりづらい場合があります。

今回紹介した内容が、これからTeamsを導入する方や、既に運用を担当されている方の参考になれば幸いです。