Power Platform の Data Gateway を CoE Starter Kit ぽく取得する
2021/7 現在、Power Platform CoE Starter Kit ではオンプレミス データ ゲートウェイの収集は行われていないので、シンプルに作ってみたという記録
コンポーネント
今後自身のプロジェクトでも使用する可能性が若干あるため、Unmanaged Solution として GitHub にあげてみた。
現状のコンポーネントのできること
現段階では最小限ということで、組織でインストールされているゲートウェイの一覧を取得するまでの機能しか持ち合わせていない。
将来的には各ゲートウェイがどのようなコネクタを許可しているか、誰と共有しているのかといったことも追加したい。(したいな…時間があれば。)
Power Platform Admin View アプリへの組み込みや、CoE Dashboard への組み込みはご自由に。
コンポーネントの展開
基本的には Microsoft が公開している CoE Starter Kit が展開されている環境に追加できるように構成したので、インポート自体は問題無いはず。
標準の Power Automate コネクタだけでは難しいので、コンポーネントの中にはカスタム コネクタを追加してあり、いくつかの展開手順を踏む必要があることに注意が必要で、ざっくり手順を。(基本的には CoE Starter Kit の Office 365 Management API の時と変わらない。)
1. Azure AD アプリの登録
Power BI - App registration tool から Azure AD アプリ登録を登録する。
アプリに与える権限は最小限にしたいので、「Read all gateways」だけにチェックを入れておく。
※ アプリの登録が完了したら、いつも通り client id と client secret をコピーしておく。
2. ソリューションのインポート
ここでようやく今回のコンポーネントをインポートする。
インポートが完了すると接続の設定が聞かれるものの、まだカスタム コネクタの構成が完了していないのでスルーする。
3. カスタム コネクタの設定
カスタム コネクタ (Power BI REST APIs) の設定 (2. セキュリティ) を開き、前述でコピーしておいた client id などを設定してコネクタを更新する。
Power Apps Portal での Business Rules の挙動を確認してみる
Power Apps Portal を全然触ってこなかったので、冬休み期間を利用して少し挙動を確認してみた。
今回確認したのは、Dataverse にある Business rules がどのように動作するかという点について。(Community には基本的にサポートしてないと書いてあった。)
Docs を見ると、Canvas app と Model-driven app に関する記述しかないため、サポートは無さそうということは薄々感じてはいるものの、具体的な挙動は知らなかったので試してみた。
結果
OK : 動いたもの
- : 動かなかったもの
| Business rules action | Canvas | Model-driven | Portal |
|---|---|---|---|
| Recommendation | - | OK | - |
| Lock / Unlock | - | OK | - |
| Show Error Message | OK | OK | OK? (どんなエラーかは表示されなかった) |
| Set Field Value | OK | OK | OK? (フォーム上には表示されず、保存されたデータには反映される) |
| Set Default Value | OK | OK | - |
| Set Business Required | OK | OK | - |
| Set Visibility | - | OK | - |
気になったこと
Office 365 の PowerShell 運用を PaaS 化してみる
背景
いくつもの Office 365 プロジェクトで Azure AD Connect サーバーや PowerShell 専用サーバーに運用スクリプトを配置するという場面に多く出くわしてきました。
「簡単な PowerShell じゃん」と言う人もいるでしょう。それによて運用・管理者はトイルが溜まるんです。
そんな現場が減ることを願って PowerShell の PaaS 化を手順化してみました。
想定シナリオ
Contoso 社はサイトコレクション管理のため、定期的に PowerShell でサイトコレクションの一覧をエクスポートしています。エクスポートされた情報からを容量の統計情報などを Power BI を通してチェックしています。
PowerShell ファイルは現在オンプレミスの Windows Server 上で動作しているため、OS のアップデートメンテナンスの影響を受けたり、資格情報をスクリプト内に記載するなど、運用に耐えられない状態です。
これらの問題を解決するため、Azure Automation を使用して、既存 PowerShell を PaaS 化してサーバーから切り離すことにしました。
諸注意
以降の手順はあくまでも検証目的のものです。
当然ですが、運用環境ではそれ相応の構成や設定を実装しましょう。
特にこんなところ
- 実行アカウントの Service Principal 化
- ソース管理連携 (しない理由が無い)
- Azure Automation の仕様確認 (課金、制約など)
本日の献立
メイン : PowerShell の PaaS 化
1. Azure Automation をデプロイする
1. まずは Azure Resource Group を作成します。
2. 作成した Resource Group で新しいリソース「オートメーション (Azure Automation)」を追加します。
3. Azure Automation のリソース名や場所を選択して「作成ボタン」をクリックします。
※ 今回「Azure 実行アカウント」は使用しないので、「いいえ」を選択します。
リソースのデプロイが完了した後に Azure Automation を開くと、こんな画面に。
4. メニューの中から「モジュール」を選択して、モジュールの追加をします。
既定では主に Azure 系のモジュールが登録されています。
5. 今回は PnP PowerShell を使うため、検索ボックスに「pnp」を入力して検索を実施します。
6. 「インポート」ボタンをクリックして、Azure Automation にモジュールを追加します。
7. モジュールの追加が完了したら、メニューの「資格情報」で「資格情報の追加」を行います。
※ 冒頭にも記載していますが今回は検証目的なので、「MFA を設定していない SharePoint 管理者アカウント」を指定しています。本番では Service Principal を変数に登録して利用するのが良いはず。
「MFA 無しアカウント」「共有アカウント」を運用で使用するのは、個人的に「無し」の方針です。
2. PowerShell スクリプトを登録する
いよいよ PowerShell スクリプトの移植を進めていきます。
1. メニューの「Runbook」から「Runbook の作成」を行います。
※ 「Runbook の種類」は「PowerShell」を選択します。
2. Runbook の作成が完了すると自動的に PowerShell の編集画面が表示されるので、まずはテストがてらテナント内のサイトコレクション一覧を出力するコードを書いてみます。
※ 既に資格情報は登録してあるので「Get-AutomationPSCredential」で読み込むことができます。
※ 冒頭にも記載したように、あくまで検証実装なので直接編集しています。運用環境では Azure Repos (Azure DevOps) とのソース管理連携を行いましょう。
3. Runbook 編集画面の「テストウィンドウ」をクリックすることで、現在の状態の PowerShell をテストすることができるので、試しに実行してみます。
4. Runbook の編集画面に戻り、データを SharePoint のライブラリにアップロードするように PowerShell コードを編集します。
5. 前述と同じように「テストウィンドウ」で実行して処理が完了すると、CSV ファイルが保存されていることが確認できます。
このままだとこれまでの PowerShell 同様にテナント情報などをべた書きしたままなので、一部の情報を Azure Automation リソース内で共有できる「変数」として扱うように設定します。
6. Azure Automation の画面まで戻って、メニューの「変数」を開いて「変数の追加」を行います。
※ ここでは変数名を「TenantName」として検証テナントの名前 (.onmicrosoft.com の前の部分) を登録します。
7. Runbook の編集画面を開き、「Get-AutomationVariable」を使って変数を読み込みます。
8. とは言え、後から CSV ファイル保存先となるサイトコレクションやライブラリを簡単に変えられるように、パラメーターを定義します。
9. 最後に「公開」をクリックして、この Runbook が利用できるようにします。
3. スケジュールを登録する
Runbook を定期実行するために 「スケジュール」を追加します。
これで Azure Automation の定期実行の登録は完了です。
オプション : Flow を使用した PowerShell の実行と活用
今回の PowerShell では利用する機会がないかもしれませんが、このように Microsoft Flow / Logic Apps を利用することで、その他のイベントをトリガーに PowerShell を実行することも可能です。
もちろん Microsoft Flow のアクションの中で Runbook パラメーターを指定できるので、Runbook を定期実行しつつ「こんな条件で実行しておきたい」なんて時には Microsoft Flow から個別に実行できるように作れたりといったことも考えられます。
