2026-02-24

Microsoft 365 データの場所 - 参照権限とタイムラグ

Microsoft365を会社で使っていると、取引先から、データがどの国で保管されているかの確認を求められることがあります。（セキュリティチェックのなかの越境移転規制とかGDPR準拠の確認ですね）

M365管理センターの　管理 → 組織設定 → 組織のプロファイル → データの場所で確認がすることができます。

MSの情報などに明記されていませんが、グローバル管理者権限が必要です。
グローバル閲覧者でも見れるかも。

グローバル管理者権限を無効化しているテナントの場合、グローバル管理者権限を有効化（アクティブ化）する必要があります。

権限をアクティブにしてから　データの場所　が閲覧できる様になるまでにタイムラグが存在します。私の場合　1時間ほどかかりました。

さくっと見られる設定だと思ったので　ちょっと焦りました

2026-02-19

ロートルITサービス管理者のITIL4Foundation受験振り返り

ITIL4Foundation合格しました

正答率87%（40問中 35問正解）でした *65%（26問）が合格ラインです

記憶力に自信のないロートルでも、多少の頭を使いながらサービス運用をやってきていれば、合格はたやすいと思います。

とはいえ、受験料7万円は安くないので、準備はしっかりしました

私について

ITインフラエンジニア歴30年弱
SIerでサービス導入コンサル→情シスでサービスマネージャー
（サービスマネージャーは人を管理できなくてもできるのでいわゆる管理職ではない）
- Sierの導入コンサルで運用設計するときに　IT全般に関するガバナンスとマネジメントのフレームワーク"COBIT"を軽く読んだ事がありました
- 情シスでは　他の人が作ってくれたITIL準拠のプラットフォーム上で　サポートチームとして運用をしていました
ITIL4を学んだ事はありませんでしたが、実務経験の中で　なんとなく見たり聞いたりした考え方は正しくて「それをITIL4でいうとこう」用語や定義を覚えるだけで事足りました。

試験対策・勉強法

UdemyのITIL4Foundation模擬問題集を自腹で買って40問×6セットをざっとやる
弱点を明らかにする
私の場合は　とにかく覚えることを覚えるしかない
ITIL4の用語や定義を、種類と構成アイテム個数で覚える
言葉さえ出てくれば　日本語的な意味で何を言わんとしているかは分かる
1. ITIL4の5つの概念
2. サービスバリュースステムの5つのコンポーネント
3. 7つのガイド原則
4. サービスバリューチェーンの6つのアクティビティ
5. サービスマネージメントの4側面
6. 継続的改善モデルの7ステップ
頻出プラクティスのステップを理解する
1. 問題管理
2. インシデント管理
3. 変更管理
4. 関係管理
5. サプライヤ管理
再び模擬問題集を正答率85％になるまで繰り返す
3/4で覚えた知識を引き出す反復練習と
問題文の読み取り注意点・かかりやすい引っかけ対策

2022-05-21

Migration MSOnline to Microsoft Graph PowerShell for license and serviceplan management

2022年8月26日の Microsoft Azure ActiveDirectory Graph API サポート終了にともなう、MSOnline PowerShell のライセンス管理系コマンドレットサポート終了の対策についてのまとめです。

※コードを整形済みテキストで書き直すかも

情報（日本語版）収集

jpazureid.github.io

（オリジナルのUSの情報は、影響範囲を断定した書き方になっていないのでちょっと困惑しました）

サポート終了となるPowerShellコマンド

MSOnline PowerShell モジュールの SetMsolUserLicense
MSOnline PowerShell モジュールの New-MsolUser

-LicenseAssignment -LicenseOptions オプションを使用している場合
Azure AD PowerShell モジュールの Ser-AzureADUserLicense

このほかに、Azure AD Graph APIの assignLicense コマンドも提示されています。

これはPowerShellコマンドレットではないので、いったん置いておきます。

我々がMigrationすべきツール探し

対象のツールで、廃止されるコマンドレットが使われているか調べます。

こんなこともあろうかと、とは思っていませんでしたが、あまり実装方法をばらつかせてしまうと収集がつかなくなると考えて、我々のチームでは

Set-MsolUserLicense だけを使うようにしていました。

全てのライセンス管理オペレーションは、こんな感じのPowerShelスクリプトで実装してあります。

Set-MsolUserLicense -UserPrincipalName $UPN `

-addLicense <ライセンス名>

-LicenseOptions <ライセンスオプションオブジェクト> `

-RemoveLicense <ライセンス名>

修正でやること

コマンドレットの置き換え

Connect-MSOLService -> Connect-MGGraph

New-MsolLicenseOptions -> New-Object -TypeName 'Microsoft.Graph.PowerShell.Models.MicrosoftGraphAssignedLicense'

Set-MsolUserLicense -> Set-MgUserLicense

修正の注意点・所感

テナントへの接続は Connect-MgGraph コマンドレットを使いますが、-Scopes の指定が必須。
ライセンス付与・削除をする場合、スコープは "Organization.Read.All","User.ReadWrite.All" です。
- このスコープは、参考にしたサイトのマネをしていますが、どうやってこのスコープを見つけ出すのかが理解できていません。
  このあたりが、今回の対応の最大の闇かなと思います。
  ここを解き明かさずに実装してしまうと、将来なにか仕様変更があったときに対応出来る人がいないかもしれません。
ライセンスの追加・削除は、-AddLicense/-RemoveLicense オプションを使うところは同じ。
ただし、以下の差異有り
- ライセンスは、ライセンス名ではなくライセンスSKUID で指定する。
- Add、Remove どちらかしかしない場合でも、必ずAdd/Remove両方のオプション指定が必須。ダミーのオプションでは、パラメータを $null にすればいいみたい。
特定のアプリを利用制限する場合、DisabledPlans にオプトアウトアプリをセットする考え方はMSOnlineと同じ。ただしオプトアウトするアプリは、アプリ名ではなくIDで指定する様に変わっている。

#Sample: add M365(Business Premium) license and disabled stream.

Connect-MgGraph -Scopes "Organization.Read.All","User.ReadWrite.All"

$UserID = 'user@tenantdomain'

$ObjectName = 'Microsoft.Graph.PowerShell.Models.MicrosoftGraphAssignedLicense'

$LicenseSkuID = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'

$LicenseOption = New-Object -TypeName $ObjectName -Property @{SkuId = $LicenseSkuID ;DisabledPlans = @('743dd19e-1ce3-4c62-a3ad-49ba8f63a2f6') }

Set-MgUserLicense -UserId $UserID -AddLicenses @($LicenseOption) -RemoveLicenses @()

2022-04-01

Teams チャットの検索、期間指定クエリの書き方

Teamsのチャットを、KQL（キーワードクエリ言語）で検索する方法です。

個人的に、後から見返す必要がありそうなものはTeamsのチャットに残すな！OneNoteかSharePointOnlineに書き残せ！派 です。

しかし、ユーザの多くは、情報のライフタイムを考えません。
軽い気持ちで大事なことをチャットで伝えて、1年ぐらいしてから「どこにあったかな」と私に聞いてきます。

私のチームでは、エンドユーザからの問合せもうけていますが、こんな問合せがよく来ます。

Q：1年ぐらい前のチャットを見返したいのですが、一覧とか出せないですか？

A：システム担当に頼んでも一覧抽出はできません。
チャット件数が少ない場合：頑張ってスクロールしましょう。
チャット件数が多くてスクロールするのが大変でがんばれない場合：検索しましょう

Teamsのチャット画面で「Ctrl+F」
検索ボックスに、sent>=YYYY-MM-DD AND sent<=YYYY-MM-DD とか書いてEnter
左ペインに検索メッセージが列挙される

あとは、見つかった古いメッセージを選択して、右ペインに、その近辺のチャットが表示されるので、スクロールがんばってください

リファレンス
support.microsoft.com

docs.microsoft.com

2022-03-21

SPOサイトの引っ越しで新サイトへのリダイレクトを構成するレベルの低い方法

SharePoint Online で、古いサイトから新しいサイトへ引っ越しするとき、古いサイトのURLでアクセスするユーザを新サイトへ自動転送する方法。

作業の背景

昔からろくな管理をされていないサブサイトを引き継ぎました。
親サイトの管理者から「別サイトに出て行ってくれ」といわれました。

内容的に、なんでこの親サイトの下にあるのか謎なサブサイトでしたので、別のサイトを立ち上げ、そちらにコンテンツを移行しました。

新サイトへのリダイレクトを設定しようとしたのですが、

システム的にはテナント管理権限を持つ私ですが、業務管掌的には親サイトの設定変更する権限がない
親サイトの管理者はサイトリダイレクトをご存じない。教えてやってもらうのも厳しい感じ

→正攻法をあきらめ、サブサイト限定の管理者でも実施可能な <meta http-equiv> タグによるサイト転送を設定しました。

不要になった旧サイトは削除できませんが、管理状態がよくない組織であればやむをえないでしょう。

作業の前提

SharePoint Desighner 2013でサイトに接続できること

なお、SPD2013でSPOサイトを編集することは、2022年3月時点ではMicrosoftは非サポートになっています。

不具合が出て困る場合は、正当な管理者をみつけて、正攻法で対処したほうが良いかもしれません。

手順

ブラウザでサイトにアクセスして旧ホームページのファイル名を調べる
SharePoint desighner でサイトに接続
旧ホームページのファイル名を探す
1. サイトページの下にあるかも
右クリック→ファイル名を変更する。
ファイル名の末尾に _bakとかつける
右クリック→新規作成で新ホームページファイルをする。
同じ場所に、同じ拡張子で
右クリック→ファイルを詳細モードで開く
<header>セクションの中に、<meta>タグを追加
- 例
  <meta http-equiv="refresh" content="10;URL=https://<テナント名>.sharepoint.com/sites/hogeNew/">
Ctrl+S で保存
右クリック→ホームページに設定
動作確認

あとがき

こういう方法をとらなくて済むように、サイト管理者は責任をもって管理し、退職するときはちゃんと引き継ぎましょう。

ルールを決めても従わなければどうしようもありません。

2022-01-26

Usine Redmine REST API with PowerShell

Redmine を PowerShell から REST API で操作する方法のメモです。
「してみた」系の、Issueを大雑把なフィルタ指定で取得するゆるい記事ではちょっと物足りないので、試行錯誤しました。
普段の運用業務で Microsoft の Windows や Office365 などを相手にする PowerShell ヘビーユーザのため、PowerShell の Invoke-RestMethod を使用します。

必要なもの

APIキー
- RedmineにREST APIアクセスするユーザでログイン→画面上バーの「個人設定」→画面右「APIキー」で表示される文字列がAPIキーです。
- REST APIによる操作は、Keyの取得に使用したユーザの権限で行われます。
redmine URL
- http://url of redmine/resource.xml
- http://url of redmine/resource.json
- Request Body の Content-Type に合わせて使い分けます（あまりよくわかっていません）
Redmine API Reference
- https://www.redmine.org/projects/redmine/wiki/rest_api
- 最新版のものですが、旧バージョンによっては実装されてないAPIがあります。バージョンサポートに起因する問題は、よく掲示板などで見つかります。

このほかに、ちょっとしたテストのため

Advanced REST client（Chrome 拡張機能）
- https://chrome.google.com/webstore/detail/advanced-rest-client/hgmloofddffdnphfgcellkdfbfbjeloo/details?hl=ja-JP

も適宜使用しています。

実行環境

PowerShell Ver5.1
Redmine Ver2.3.1
実行ユーザは、'システム管理者'ロールを割り当てています

Get issue by issue ID

Redmine APIリファレンスにある id,issue_id のフィルタは、Redmine ver.3.3 から実装されているようです。私の環境の Redmine は Ver2.3.1 のため、id のフィルタを指定しても機能せず、最新から limit=25 件のチケットを取得するだけでした。私の環境でIDを指定してIssueを取得するには、サンプルような .../Issues/ID.xml 形式のURLで取得する必要がありました。

# Web API の URI
$URL = 'http://urlofredmine'

# 取得した API Key
$ApiKey = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

# Request Header
$headers = @{
    'X-Redmine-API-Key' = $ApiKey
}

# Request Body
$body = @{
    limit = 1
    page = 0
}

#Issue IDを使用したURIを生成する
$issue_id = '735997'
$AppUri = $URL + '/issues/' + $issue_id + '.xml'

# GET API を叩く
$Issues = Invoke-RestMethod -Method Get -Uri $AppUri -Body $body -Headers $headers
$Issues.Issue
$Issues.Issue.Project
$Issues.Issue.tracker
$Issues.Issue.status
$Issues.Issue.priority
$Issues.Issue.author
$Issues.Issue.assigned_to
$Issues.Issue.custom_fields.custom_field

Create issue

Project_id を指定して、Issue を作成します。
サンプルは最低限。このほかのプロパティ名や、custom_field のセット方法は、Redmine API リファレンスを見ながら実装する必要があります。
なぜか配列で指定するとどうやっても「題名を指定してください」エラーを消せななったので、RequestBody を JSON で記述しています。
Issueの作成に成功すると、作成した Issue が返されるので、作成された Issue の検査などに使用します。

# Web API の URI
$URL = 'http://urlofredmine'
$URI = '/issues.json'
$AppUri = $URL + $URI

# 取得した API Key
$ApiKey = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

# Request Header
$headers = @{
    'X-Redmine-API-Key' = $ApiKey
　'Content-Type'='application/json'
}

# Request Body - json
# クォーティングに注意
$body = '
{"issue":
 {"project_id":25,
  "subject":"Redmine issue for with REST API"
 }
}'
# GET API を叩く
$Issue = Invoke-RestMethod -Method POST -Uri $AppUri -Body $body -Headers $headers

2021-07-03

Office365(Microsoft 365)展開と、私のこれまでと、これから

現在の会社に転職してすぐ、Office365展開プロジェクト～運用をしてきたことと、これからの展望を書いてみたいと思います。

Office365(Microsoft 365)展開のこれまで

2016年、転職してすぐ、Microsoft 365 導入の定石に準じて、Office365展開を進めてきました。

オンプレミスActiveDirectoryのオブジェクト整理
オンプレミスActiveDirectory→Azure ActiveDirectory のオブジェクト同期
ユーザのライセンス展開
サービス展開

ただ「機能をオンにしましたので、あとはどうぞ」というスタンスでは、上手くいきません。

弊社は、IT専業では無い普通の事業会社ですので、一般社員のITリテラシーは決して高くありません。
ITシステムに関わる部門がある一方、スマホを持ってない人・スマホしか持ってない(PCスキルが無い)人などが数百～数千人おります。

「クイックスタート/スモールスタート」と「みんな残さず連れて行く」を両方考えないといけません。
（前者と後者は、大抵の場合、別々のステークホルダーが主張するので、意見調整も仕事のうちとなります）

サービス展開は、以下の順番で進めてきました。

*：私が直接担当してきたもの
太字：利用者向けに重要とされたもの

SharePoint Online*
Exchange Online*
Teams
OneDrive
Planner,Form,Stream,Yammer
PowerPlatform←いまここがHot!

私を取り巻く環境

常に新しい機能の展開を求められ続けながら、
移行過渡期はオンプレミスも並行運用し、
様々なシステムの運用やトラブルにも忙殺されてきました。

ここに至るまでの6年間で、私の部署は、10名～40名ほどに拡大しましたが、メンバーの多くは離任や退職し、当初から残っているのは私だけとなりました。

こんな状況が続いてきたので

放置されたゴミデータの整理
作りきれなかったルールの整備
使われなくなったサービスの廃止
サービス機能拡張の取り込み展開
サービス機能のやりこみ/使い込み

という部分が手つかずのままでした。

このブログは、日々の業務の中で見つけたエッセンスを書き残していくために立ち上げていますが、この6年間で書けた記事はたったの4件でした。

これから

私が、ITコンサル会社から事業会社のIT部門に転職した理由
「自分の専門領域で、サービスのバージョンアップを手がけたい」
というものでした。

手をつけられない状況がようやく終息を迎え、自分が本来やりたかったことに手を着けられる状況が見えてきました。

このブログに、身につけたことや発見を書いていきたいと思います。

syg_hira's tech-work memo

某人材サービス会社の情報共有インフラ担当のおぼえがきです。MicrosoftのEnterprise製品多め。