カテゴリ「Microsoft 365」の81件の投稿 Feed

2024年10月11日 (金)

Jm365ccv5red

Microsoft 365 に関わる有志でコミュニティ イベントを開催することになりました! 

Microsoft が主催するイベントとは異なり、実際の企業のユーザー視点だったり、国内の企業を支援する立場から Microsoft 365 を業務で利用するユーザーの方に役立つ情報をお伝えします!

イベントはオンライン開催を2日間実施し、1日のみ対面式でのイベントを日本マイクロソフト社の会場をお借りして実施します。

  • オンライン開催(Microsfot Teams): 2024/11/28-29
  • 対面式: 2024/11/30
  • 参加費: 無料

イベントにご興味を持った方はぜひ下記のリンク先より登録をお願いいたします。

スタッフおよび登壇者全員がボランティアでの開催となりますので、参加者の方もぜひ、イベントの盛り上げにもご協力いただけると幸いです。

ちなみに、登壇者を現在募集中ですが、続々と興味深い(楽しそうな)ブレイクアウト セッションの企画が上がってきています。11月になったらセッション一覧やタイムテーブルの詳細などを公開します。

↓登録はこちら。

🔗Japan Microsoft 365 コミュニティ カンファレンス 2024 - connpass


2024年9月26日 (木)

Adobestock_552355848_2

Power Automate では整数または倍精度浮動小数点数などの数値データを扱えます。

たとえば、変数を追加する際にこうしたデータ型を指定できるようになっています。次の画面は英語表記ですが、Integer(インテジャー)が整数、Float(フロート)が倍精度小数点数です。

20240926_153047

計算する

ではこうした数値データを使って計算を試してみましょう。たとえば、10÷5 を計算します。式としてはdiv関数を用い、「div(10,5)」となります。

20240926_150713

結果は2です。

20240926_151012

小数のある割り算

では、小数のある割り算を行ってみましょう。11÷5 を計算するため式は「div(11,5)」とします。

20240926_150850

結果は2.2 となるはずですが、2 となっています。

20240926_151012_2

整数同士の計算となり、結果は整数部分のみしか返ってきません。そのため小数が返ってくることもあることを前提にするために最初から11と5の数字を倍精度小数点数として扱いましょう。これには float関数を使います。式は「div(float(11),float(5))」です。

20240926_151251

結果は2.2となりました!
20240926_151313

ということで、結果が小数になる場合は変数として用意する場合もFloat型として宣言しておく必要があることがわかります。

ちなみに小数は16桁まで扱えます。次の図は割り切れない 1÷3を行っているところです。

20240926_151333

四捨五入

さて、小数を扱う場合、パーセントに置き換えるときなど四捨五入が必要なことがあります。これはどうやるのでしょうか? 試しに次のように 270÷366 を計算してみましょう。

20240926_151632

結果は次の通りで「0.7377049180327869」が返ってきます。

20240926_172735

ではこれを100分率にするためにmul関数を使って100倍し、整数のみにするために formatNumber関数を使います。式は「formatNumber(mul(div(float(270),float(366)),100),'###') 」です。

20240926_151904

結果は 74 となったことがわかります。もともと100倍すれば、73.77... だったわけですから、小数点第一位で四捨五入されたことがわかります。

丸め誤差

倍精度小数点数を使えるということですが、当然、丸め誤差が生じます。試しに「add(float(0.1), float(0.2))」を計算します。

20240926_154219

すると結果は 0.3 ではなく「0.3000000000000004」となります。20240926_154235

そこで利用したいのが decimal 関数です。変数を初期化する際には decimal は選択できないため式の中で利用する必要があります。式を「add(decimal(0.1), decimal(0.2))」とします。

20240926_155159

これにより結果は0.3 となります。

20240926_155217

まとめ

ここまで見てきたように Power Automate フローの中で演算を行う際にはデータ型に注意し、適切な型を明示して利用する必要があることがわかります。

2024年9月25日 (水)

Adobestock_522400980

Power Automate を使って複数の Excel ファイルを一括生成し、それぞれの Excel ファイルで特定のOffice Scripts を実行するようにフローを組んでいたとします。Office Scripts を実行するわけですから、 Excel Online (Business) コネクターを使います。このコネクターには次の2つのスクリプト実行アクションがあります。

  • SharePoint ライブラリからスクリプトを実行する
  • スクリプトの実行

20240925_190937

このコネクターに最初に追加されたのは「スクリプトの実行」であり、スクリプトはユーザーの OneDrive に格納されている前提でした。ですが、そのあと、スクリプトを SharePoint のドキュメント ライブラリに格納して複数ユーザーで共有利用ができるようになりました。そこで新たに追加されたアクションが " SharePoint ライブラリからスクリプトを実行する" です。

20240925_190421

さて、従来からある "スクリプト実行" アクションは、スクリプトがOneDrive (Business) に格納されていることが前提であるため同時アクセスは考慮されていません。

たとえば、ファイル作成をする際に Apply to each を使って処理するときに Apply to each には「コンカレンシー制御」オプションがあります。既定ではオフで最大50まで指定できます。

20240925_190644

これを使えばファイル作成をバトンリレー式に1つのファイルが作成されてから次のファイルを作成するという処理を複数のファイル作成を同時に一斉作成できるようになります。ならば、このオプションを有効にしてファイル作成後にいっきに各ファイルで Office Script も動かそうか考えるわけですが、この場合はスクリプトファイルへの同時アクセスが生じることになりフローはエラーとなります。

ですが、後発のアクションである「SharePoint ライブラリからスクリプトを実行する」を利用する場合は、最初から複数同時アクセスを考慮しているため Apply to each のコンカレンシー制御を有効にしても問題なくフローが実行できます。

試しにコンカレンシー制御をおこなわずに5つのファイルを一括作成してみたところ、Apply to each には42秒ほどかかりました。

20240925_190615

ですが、コンカレンシー制御を有効化したところわずか9秒に短縮されました。

20240925_190724

このようにコンカレンシー制御はフローのロジックによって向き不向きがありますが、うまく活用できればフローの実行時間が短縮できます。

2024年9月10日 (火)

Adobestock_715101192

Microsoft 365 用の PnP PowerShell とCLI の登録方法が 2024年9月9日より変更されました。

アナウンスされたのが2024/8/22ですから、期限まで1か月もなく、バタバタと対応を迫られたのでまだご存じない方もいるかもしれません。早くブログに書いておこうと思ったものの先週の週末に検証がずれ込み、今日改めて記事にしています。

経緯

以前は、PnP Management Shell はマルチテナントアプリ登録の仕組みを利用してスクリプトに必要な権限を付与することができました。しかし、このマルチテナントアプリ登録は2024年9月9日に削除される予定であり、既存のスクリプトに影響を与える可能性があります。マルチテナントアプリ登録オプションは、オンボーディングする上では非常に有効だったものの、結果的に付与されるスコープが多すぎる問題が生じました。そのため、より少ない権限に絞れるように今回の対応となったという経緯があるようです。

新たな変更では、必要なスコープと権限のみを使用するシングルテナント アプリの登録を推奨します。これにより、セキュリティ対策の強化と改善が見込まれます。ただ、以前と同じくシングル テナント登録にはテナント管理者であり、Entra ID 側で必要な権限を持っている必要があります。

つまり、マルチテナント認証オプションに依存する既存スクリプトは2024年9月9日以降この変更の影響を受けるということです。

既存のスクリプトはどうなる?

シングルテナントアプリケーションの登録により認証が変更された後でも既存のスクリプトは動作します。認証/接続セクションを更新する必要があるかもしれませんが、どのコマンドレット/コマンドも同じように動作します。

インストールとアプリの登録

さて、シングルアプリケーションとしての登録方法について説明していきましょう。PnP Management Shell に関しては、Microsoft Community Learning グループがすでに YouTube に「Getting started with PnP PowerShell - Installation and app registration」としてインストールおよび登録方法についてビデオ解説しています。英語のみです。詳しくデモ付きで説明されているので、しっかり閲覧して手順を確かめるようにしましょう。CLIの方は Coming soon だそうです。


YouTube: Getting started with PnP PowerShell - Installation and app registration

ここからはビデオを見る前にどんな手順になるのかを概略説明しておきましょう。基本手順は次の通り。

  1. PnP Management Shell モジュールのインストール (インストールしていなければ)
  2. Entra ID への App Only アプリの登録
  3. インタラクティブ ログイン用の登録

なお、使用する PnP Managment Shell は 2.10以降が必要です。

インストール

PnP Management Shell モジュールをインストールしてない場合は install-module コマンドを実行します。インストールには PowerShell 7.2 以降が必要です。20240906_162646

必要に応じて -Force オプションを指定して実行してください。

20240906_162953

その他の詳細は下記のリンク先を参照してください。

Installing PnP PowerShell | PnP PowerShell

Entra ID へのアプリケーションの登録

Entra ID へのアプリ登録の詳細は下記に掲載されています。日本語版はありませんので必要があれば日本語に翻訳して読む必要があります。

Register an Entra ID Application to use with PnP PowerShell | PnP PowerShell

以降は主要なポイントのみピックアップしていきます。

非インタラクティブなログイン

接続時に非インタラクティブなログインを行う場合は、Register-PnPEntraIDApp コマンドを使って新たにシングル テナント アプリケーションを作成します。※Register-PnPEntraIDApp は Register-PnPAzureADApp の別名です。コマンドを調べる際には最終的にRegister-PnPAzureADAppの説明ページにたどり着きます。

Register-PnPAzureADApp | PnP PowerShell

たとえば次のコマンドを実行します。

Register-PnPEntraIDApp -ApplicationName <アプリ名> -Tenant <テナント名> -Interactive

このコマンドはアプリ登録時に実行パスに証明書(pfx, cer)を生成します。接続時の認証方法はいくつもありますが、この場合はサービスに続する際にこの証明書を使ってサインインすることも可能です。これによりインタラクティブにユーザー認証の情報を毎回渡す必要がなくなります (Non interactive Authentication)。またアプリのみのコンテキストとしての登録となり、スクリプトはユーザーの介入なしに実行できます。つまり、アプリに対して権限を付与すれば実行ユーザーがサイトに対してアクセス権限を持っていなくても良いということになります。

なお、管理者がユーザーにかわって作成した場合は、pfx をユーザーに渡したうえで次のように pfx をインポートしてもらう必要があります。

Import-PfxCertificate -FilePath "path\to\certificate.pfx" -CertStoreLocation Cert:\CurrentUser\My

インタラクティブログイン

接続の度にインタラクティブログインする場合はアプリ登録時に Register-PnPEntraIDAppForInteractiveLogin コマンドを使用してアプリを登録します。この場合は委任ログインとなります。ユーザーが持っているアクセス権限に基づいて操作は制限されます。

Register-PnPEntraIDAppForInteractiveLogin | PnP PowerShell

アクセス権限

基本的には Entra ID アプリケーションに対して最低限必要な権限を付与することが強く推奨されています。たとえば、Register-PnPEntraIDAppを上記のコマンド通りに実行すると次のように必要な権限が要求されました。

20240910_135521

登録されたアプリでアクセス権限を改めて確認すると次の通りであり、基本的にアプリに対してフル権限が付与されます。

  • Microosft Graph 
    • Group.ReadWrite.All
    • User.ReadWrite.All
  • SharePoint
    • AllSites.FullControl
    • Sites.FullControl.All
    • User.ReadWrite.All


20240910_140909

Register-PnPEntraIDApp コマンドおよびResister-PnPEntraIDAppForInteractiveLogin では既定の制限された権限が付与されますが、特定の権限に明示したい場合は次のようなパラメーターを指定できるようになっています。

  • SharePointApplicationPermissions
  • SharePointDelegatePermissions
  • GraphApplicationPermissions
  • GraphDelegatePermissions

Client ID

登録時に最後に表示される Client ID は接続のたびに指定することになるので控えておきましょう。なお、Client ID は接続のたびに必要になるため、これが煩わしいようならシステム環境変数として登録しておくようにしましょう。手順は次のリンク先に詳しく書かれています。

Set a default Client ID | PnP PowerShell

ちなみに、先に紹介した YouTube の手順では$env:ENTRAID_APP_ID = "XXX" というような環境変数を使っていますが、これは当該セッションで使う一時的なもので永続的なものではありませんので注意してください(この辺はてっちゃん(@techan_k)さんに別途、情報提供いただきました。ありがとうございます!)。

登録されたアプリの確認

コマンド実行後は Entra ID にアプリ登録が無事に登録されていることがわかります。接続時に必要な クライアントIDも確認できます。

 

20240906_173834

接続

では接続してみましょう。次のように証明書を使う場合は、非インタラクティブ認証を利用できます。接続先は任意のSharePoint サイトのURLなどです。

connect-PnPOnline -Url <テナント>.sharepoint.com -ClientID <クライアントID> - CertificatePath <証明書(pfx)へのパス>

インタラクティブログインの場合は、次のように指定します。

connect-PnPOnline -Url <テナント>.sharepoint.com -ClientID <クライアントID> -Interactive

他にも特定のデバイスやブラウザーを指定するなど複数の認証方法があります。詳しくは下記のリンク先を確認するようにしてください。

Authentication | PnP PowerShell

関連情報

2024年9月 6日 (金)

Adobestock_261207157

2024年8月22日付で次の更新機能がアナウンスされました。

  • 受信者への取り消し通知のオプション
  • 取り消し可能なメッセージ世代の最大値
  • 外部ラウンド トリップルーティング

Exchange Online Message Recall Updates - Microsoft Community Hub

受信者への取り消し通知のオプション

これまで組織内のユーザー宛のメールは送信主が相手に知らせることなく送信済みメールをこっそりと取り消すことができていました。とはいえ、一度、受けとったことを目にしているユーザーもしくは一度目を通したユーザーにとっては「あれ、あったはずのメールがない!」ということになり混乱を招くこともあったのです。

そんな背景から、新たにテナント管理者は取消し通知を宛先に指定したユーザーに対して有効にできるようになりました。次の2つのいずれかのオプションを指定できます。

  • 全ての取り消されたメッセージ
  • 受信者が読んだ取り消したメッセージのみ

要するに全社はすべての送信済みメールに対して取り消したことを知らせる。後者は読んだ人にだけ、「あっ、あのメール取り消しましたからね。もうないんですよ」という旨を知らせることができるわけです。

この設定は PowerShellコマンドからも実行できますが、Exchange 管理センターから確認するのがわかりやすいでしょう。まず、[設定]>[メールフロー]の順にアクセスします。

20240904_150431

次に表示される画面から「メッセージの取り消し」セクションにある “受信者のリコール アラートを有効にする” をオンにします。この時に「すべてのリコール済みメッセージ」または「受信者によって読み取られた取り消されたメッセージの場合のみ」のいずれかを指定します。あとは、「保存」を押下するだけです。この設定変更は以上の設定は1時間ほど反映されるまで時間がかかるそうです。

20240904_150444

メッセージを取り消す

では、送信済みのメール(組織内宛て)をメッセージ取り消してみます。

20240904_171657

しばらくすると送信対象者に取り消しを知らせるメッセージが届きます。

20240906_204254

取り消し可能なメッセージ世代の最大値

ちなみに、上記設定の下にある「これより古いメッセージの取り消しを送信者に許可しない」オプションでは、取り消しが可能な送信後の日数を指定できるようになっています。既定値は 365です。最低5分~最大10年まで指定できます。

20240906_201842

外部へのラウンド トリップルーティングのサポート

設計上、メッセージの取り消しは Exchange Online のサービス境界外へと送信されたメッセージの取り消しには対応していません。しかし、一部の管理者は、テナント内のメール(送信者と受信者が同じテナントにある場合)を Exchange Online からサードパーティのサービスまたはオンプレミスのシステムに転送して追加処理を行った後、再び Exchange Online に転送して配信しています。従来では、このシナリオでは取り消しは失敗していました。

ですがアップデートにより現在は外部を経由して Exchange Online に戻って配信されるテナント内メッセージの取り消しもできるようになったそうです。