Viva ラーニングに SharePoint 上のコンテンツを公開できるという記事を以前書きました。

[関連記事]

• Microsoft Viva ラーニングに SharePoint上のコンテンツを公開しよう (SharePoint Technical Notes) (weblogs.jp)
• Microsoft Viva ラーニングとは? (SharePoint Technical Notes) (weblogs.jp)

以前は、Microsoft 365 全体管理者または知識管理者の役割を付与されたユーザーだけが全社的に SharePointサイト上のコンテンツを追加できていたわけです。

これに加え、新しい機能として Microsoft Teams 上のタブとして Viva ラーニングが追加できるようになり、ここに従業員自らSharePoint 上のコンテンツを追加できるようになりました。もちろん、SharePoint 上のコンテンツ以外にも従来通り LinkedIn Learning や Microsoft Learn のコンテンツも複数組み合わせることができます。つまりチームごとに自分たちの判断で必要なコンテンツ(教材)をタブに追加して、「これちゃんと勉強して理解しておいてね」という情報共有がしやすくなったのです。

とはいえ、この機能を使うにはMicrosoft 365 管理センター上で管理者が事前に次の機能を有効にしておく必要があります(既定ではオン)。

[設定]>[組織設定]>Viva ラーニング> "従業員が SharePoint から Microsoft Teams のチャットおよびチャネルの Viva ラーニング タブに独自のコンテンツを追加できるようになる" がオンになっていること

あとは任意のチャットまたはチャネルで Viva ラーニング タブを追加していくだけです。

以上の手順で、SharePoint 上のビデオや PowerPoint などのコンテンツを公開できます。

秘密度ラベルを適用したMicrosoft 365 グループを作成することで、最初から秘密度ラベルで保護されたチームサイトを作成できます。

こうしたグループ作成は SharePoint REST API または Microsoft Graph APIを用いて作成できますが、PowerShellを使う場合には委任の設定が別途必要になります。詳しくは下記の情報が詳しいです。

Create M365 Group with Sensitivity Label programmatically

Creating the M365 group with Sensitivity Label starts the modern Team site with desired protection. This can be done with SPO Rest API or Microsoft Graph API, both require delegated permissions. The following sample scripts use AAD App ROPC authentication flow (Resource Owner Password Credentials)...

そこで、そういえば Power Automate を使う方法もあるなぁと思いせっかくなので SharePoint コネクターを使った場合のスクリーンショットを共有しておきます。利用するURLは " _api/GroupSiteManager/CrateGroupEx " 。もちろん、これを実行できるのは Microsoft 365 グループが作成できる権限を持っているユーザーに限られます。

以上で追加設定は特に不要です。

ちなみに、SPSiteLanguage はサイトの既定の言語を指定する LCID (ロケールID) で、日本語だと 1041、英語だと1033です。秘密度ラベルは、CreationOptions 内でラベルIDを指定します。このように作成すればチームサイトは最初から秘密度ラベル適用済みになります。

この方法がわかっていれば、SensitiveLabelは必須ではないので単純な Microsoft 365 グループを作ることもできますよ。

*********************************

秘密度ラベルを使った Microsoft 365 のデータ保護については弊社でオリジナル研修を行っていますので、こちらも併せてどうぞ。

【オフィスアイ株式会社】Microsoft Purview コンプライアンス入門～Microsoft 365ファイルおよびメール・チャットに対する機密情報保護と情報ガバナンス～ (office-i-corp.jp)

以前下記の記事で Microsoft 365 SharePoint サイトのホームページを不意に削除してしまった場合の対処方法について書きました。

SharePoint - ごみ箱のURLを覚えておこう (SharePoint Technical Notes) (weblogs.jp)

ただし、この方法は既定の Home.aspx  を削除してしまった場合の話でした。

ですが、Home.aspx ではないページをホームページに指定していて、かつ、ついうっかり複数のサイトページを一括して削除して待ったという場合はどうしよう? 

もちろん、削除したページすべてを復元するという荒療治もできますが、不要なファイルは復活させたくないものです。そもそも、ホームページに設定していたページはどれなのか。これを探るには SharePoint REST API や PowerShellコマンドを使えばわかるのですが、もっと簡単に確認したい。

一番手っ取り早いのはやはり SharePoint REST APIを使う方法なのですが、コーディングは不要で単純にWebブラウザーで次のURLを指定します。

️ https://<サイトのURL>/_api/web

これでサイトの情報が XML形式で取得でき、ブラウザー上に表示されます。この中の「<d:WelcomePage>SitePages/"ページ名"</d:WelcomePage>」を見つけ出すと、これがサイトのホームページです。

上記の例では "後から作ったホーム.aspx" となっています。

後はこのファイルのみをごみ箱から復元すればよいわけです。

SharePoint のドキュメント ライブラリにはOneDrive へのショートカットを作成する機能が用意されています。これと OneDrive 同期アプリ を併用する場合は注意が必要です。

OneDrive へのショートカットを作ると、文字通り OneDrive for Business にショートカットが作成されます。このショートカット内にあるドキュメント ライブラリ内のファイルも同期されるようになります。つまり、OneDrive同期アプリでの同期先を変更することなく、SharePoint サイト内のファイルを同期することができる手軽さがあります。しかし、OneDrive 同期アプリが同期できるファイル数の推奨される上限数は 30万ファイルまでとなっています。

➡️Restrictions and limitations in OneDrive and SharePoint (microsoft.com)

これはもし個人のOneDriveも同期しているならこれも合算した数です。実質、OneDrive 同期アプリは for Business も個人用も同じエンジンをローカルで動作させているためこの上限も共有することになります。

ですから、やみくもに SharePoint サイトのドキュメント ライブラリを同期してしまうと、あっという間にファイル数の上限に達してしまう可能性があるわけです。その点に注意しましょう。

二重同期の問題

うっかりドキュメント ライブラリも同期し、OneDrive へのショートカットも作成してしまったとしたら? どうなるでしょうか。

これを行うと二重の同期となり、正常に同期が行えなくなることが起こるようです。ショートカットを利用するのか、もしくはSharePoint ドキュメント ライブラリを直接同期しないのかいずれかにしましょう。

ドキュメント ライブラリ側で同期をさせないようにするには?

ライブラリ単位で同期を禁止する設定も可能です。ライブラリの詳細設定で「オフライン クライアントの使用制限」を"いいえ" にすることで、OneDrive 同期アプリによる同期はできなくなります。

この設定により、ライブラリの「同期」メニューも非表示になります。

既定値では同期は可能で操作メニューに表示される

同期しないように設定したため同期メニューが表示されなくなる

ところでこのように設定したライブラリのショートカットを OneDrive に追加した場合は、同期はどうなるのでしょうか?

試すとエラーとなります。同期ができないように設定しているライブラリであるため当該ショートカットの削除を促されます。

ことの経緯は2021年の後半あたりから。気が付くと私が使っている Microsoft 365 テナントの1つでSharePoint 管理センターの API アクセスページが正常に表示されなくなる問題が起きていることに気が付きました。ここは SharePoint Framework で開発をする際に Microsoft Graph API を利用するときに使う大事な場所です。

エラーのメッセージは次の通り。

「Could not retrieve Global Service Principal ID Error: Error: {}」

GUI がだめなら PowerShell から試してみようとアクセスするのですが「 Directory.AccessAsUser.All の OAuth アクセス許可が見つかりませんでした」というエラーメッセージが表示され、こちらからもアクセスできません。

まず、アクセス許可を解決しないとどうにもならないのですが、なにをどうしたらよいものか。

色々と調べてみると同じような状況にあっている人が世界中に何人かいることがわかりましたが、解決できた人もいればそのままだったり。さて、同じような問題を抱えている方の多くがたどり着くのが下記の記事のようです。

SharePoint Online- Bad service principal breaks SharePoint Admin API Access “Global Service Principal ID Error: Error: {}” Resolved – Solving SharePoint Issues – Eric Schrader (eschrader.com)

残念ながらこの記事とは現象が異なっていたので、この方法では解決しなかったのですが多くのヒントを得ることがで来ました。

SharePoint 管理センターの APIアクセスのページと大きく関わりがあるのが Azure AD 側のエンタープライズアプリケーションであり、次の2つが関わってきます。

• SharePoint Online Client Extensibility Web Application Principal
• SharePoint Online Client Extensibility Web Application Principal Helper

ちなみに、この2つのアプリは SharePoint 管理センターの API アクセスページにアクセスする際に、初回に基本的に自動生成されるもので本来は何も設定は必要ありません。

ということでこの2つにターゲットを絞りました。まず末尾に Helper とついているアプリを削除して、自動的に再作成するのを待ってみましたがこれでも状況は変わらず。

幸い、正常に動作している別のテナントが手元に3つほどあったのでこれと徹底的に比較しようと。でまずは、AccessAsUser.All を解決する必要があります。それぞれで API のアクセス許可の設定を比較してみます。すると、末尾に Helper とついている方がアクセス許可が全く構成されていません。

正常な状態

エラーが発生しているアプリ

ということで、このアプリのマニフェストを見てみるとエラーのあるアプリでは下記の部分がすっかり抜け落ちている。これを書き足すと正常に戻りました。

この赤枠部分の　signInAudience 属性に "AzureADMyOrg" という値が格納されていますが、これによって、現在のアプリケーションでサポートされるアカウントが決まります。

Azure Active Directory のアプリ マニフェストについて - Microsoft identity platform | Microsoft Docs

以上。なぜ、こうした状況になったのかは不明ですが、私の環境では何とかエラーを解決したので、この記事を共有することにしました。

同じ状況が発生する頻度は低いでしょうが、困っている人がいるかもしれない。もちろん、まったく同じ原因ではないかもしれないし問題解決できないケースもあるでしょうが、一縷の望みを託しておこうと。

参考になれば幸いです。