MSがOffice 365に関わるPACファイルを作成してくれる件
Office 365を利用する場合、Office 365が指定するURLにインターネット接続できる必要があります。そのURLは以前より以下のページで公開されていました。
Office 365 URLs and IP address ranges - Office 365
また、XMLファイル形式やRSSでのUpdate情報も配信されています。
- XML形式:https://go.microsoft.com/fwlink/?LinkId=533185
- RSS形式:https://go.microsoft.com/fwlink/p/?linkid=236301
今回新たに、pacファイルのサンプルをMSが提供し出しました。
Managing Office 365 endpoints - Office 365
提供されるPACファイルのパターンは3パターンのようです。
パターン1
このパターン1についてはよくわかりません。どうやらMSがIPアドレスを管理しているものはFWに、そうでないものはプロキシにで通信経路を分ける目的のPACファイルと思われます。が、MSがIPアドレスを管理していないもの = 主にakamaiなどのCDNを使っているものと思われますが、疑問として
- そういうものをプロキシに飛ばす必要があるのか
- 仮にそうだとしても、URLの分類基準が分からない
→例えば、compliance.outlook.comというURLは「MSがIPを管理していないからプロキシに飛ばす」となっています。このURLをOffice 365 URLとIPのページで探すと、Office 365 portal and shared “23 Optional: Security and Compliance export "に分類されているのですが、同じくここに分類されている"protection.office.com"などはPACファイル上はプロキシではなくFWに飛ぶようなPACとなっている。つまり、Office 365 URLとIPアドレスのページからPACファイルを導き出せないえす。
この他にも、分類URLの中に"www.google-analytics.com"や"www.youtube.com"があったり、最初にproxyserver2があるのにpacファイル中に出てこなかったり(これはおそらく末尾の"//Catchall for all other traffic to another proxy"がproxyserver2;であるべきなんでしょうが)とにかくいろいろ謎。
パターン2.
パターン2はExpressRouteとExpressRouteを経由せずInternet経由でOffice 365にアクセスする必要があるURLを分けています。ExpressRoute for O365を契約していても、ライセンス認証などの通信はExpressRouteじゃなくインターネット経由でアクセスしないといけないので、PACファイルまたはL4スイッチのソリューションで経路を分けてやる必要があります。
これはパターン1と違ってしっかりとURLが記載されている様子。ただし、Microsoft Stream、Yammer、Sway、PlannerのURLが入っていないです。おそらく、Office 365 URLとIPのページで、これらの製品のExpressRouteのカラムがないからと思われます。ないならないで、プロキシに振っておいてくれればいいのに…。
パターン3.
これは一番シンプルで、Office 365で使用されるURLを全てリストアップしプロキシサーバーに投げるというもの。ただ、この程度なら今までMSが提供してくれていたXMLを解析すれば作成できるので、他の2つに比べると新しい意味は少ないか。
MSが作ってくれたPACファイルでうれしい事
パターン1のPACファイルの意味は分からないけど、パターン2はうれしいリリース。今までのXMLやRSSによる情報配信はERを使わないOffice 365 URLのみ経路を分ける、という要件に対応できなかったため、いちいちOffice 365 URLとIPのページを確認する必要があったが、このPACファイルによってある程度正規化された情報が手に入る事になった。Microsoft Streamなどに対応していないものの使っている環境の方が少ないので実用性はあるかなと。
注意点としてこのPACファイルを丸コピーはダメで、ちゃんとプロキシのIPを指定したり、sharepointのURLを自社のものに書き換える必要がある。
まぁこんなPACファイルを作ってくれなくても、製品,URL,ERの有無などOffice 365 URLとIPアドレスのページに記載されている情報を正規化した形でくれればいいんですけどね…。
Outlook for iOSから他人の予定表が見れるようになった様子
どうやらOutlook for iOS / Active Syncで他人の予定表が見れるようになったようです。 ※ 青チェックの所に、他人のユーザー名が表示され、予定表が閲覧できるようになっている。
動作確認したのは以下の端末。
iOSバージョン:10.3.3 (14G69) Outlook for iOSバージョン:2.42.0
ただ、発生条件は今のところ不確かで、私の周りでも見れている人見れない人がいる様子…。 周りの話を総合すると、
- 2日前くらいから見れるようになった
- Outlook for iOS側で能動的にユーザーを追加する事が出来ない
- PC版Outlookで予定表を追加したユーザー、あるいはよくやり取りする(?)ユーザーの予定表が自然にOutlook for iOSに表示される
ようです。
使い勝手としては微妙ですが、Outlook for iOS側で自由にユーザーを追加・削除する事が出来れば、今までの悩みである、モバイルから他人の予定表が見れない、というのが解消しそうです。
なお、Outlook for iOSで予定が見られて何かうれしいの?OWA(Outlook on the Web)でいいじゃん、という話ですが、企業によってはOWAの利用は非推奨というのがそれなりに多く。理由としては
などがあります。OWAの方がアプリ配布不要で機能的には(予定表も含めて)満たしている、というメリットもあるんですけど。
発生条件が分かりました→Office 365 (Exchange Online)の新しい予定表共有について - 今日も元気にIT屋さん
UTFとか文字コードの話とExcelやpowershellなどのアプリケーション対応を調べた
迂闊ながら職場で"SJISでデータ下さい"って言ったらゴミを見るような目で見られたので調べます(メールでデータ送るから、って言われたから流れでSJISって言っちゃったねん
登場人物(文字コード編)
UTF-8系
UTF-8と言っても2つあり、BOMありとBOMなし。BOMというのはバイトオーダーマークで、これがあればプログラムがファイルを読み込むときに確実にUTF-8と分かるが、BOM付ファイルを1バイト目から実データ部分と扱って処理しようとすると死亡する。なおExcelはUTF-8(BOM付)なら文字化けせず開けるらしい
UTF-16系
wikipediaさんによると、UTF-16は5種類あるらしい。
BEとLEというのはビッグエンディアンとリトルエンディアンというもので、実装方法(?)によって差があるあるらしいが、ファイルが読み込めるか否かはBEやLEに関係なく、BOMが目印になるか、そもそもUTF-16に対応したファイルかによる様子。
どうもWindowsの世界ではUnicode = UTF-16 LEになる様子。UTF-16はBOMなしだとBEと判定されるらしい。となると、UTF-16 BE,UTF-16 BOMなし(BE)の違いが分からなかったので、UTF-16 BOMなし(BE)は除外して調べる。
登場人物(プログラム編)
- Excel 2016:時に方眼紙、時にユーザー一覧出力先とITの世界で大活躍する一線級ソフトウェア
- サクラエディタ:私の愛する最強エディタ。インストール不要で客先にも持ち込みやすい
- メモ帳:ゴミだがサーバーにはこれしかない事多し。
- powershell ISEのエディタ部分:実はサーバー上でメモ帳以上に使えるもう1つのエディタ。正規表現も使えるよ
- VisualStudioCode:powershell ISE以上のエディタ。1度慣れるとISEには戻れないしサクラエディタの地位も怪しい。起動に1秒くらいかかるのが欠点。
- powershell v5:cmd.exeを過去のものにしたWindows標準のコマンドラインツール。サーバーへのリモートアクセスからWebスクレイピングもがんばりゃ出来る優れもの。
チェック結果
読み込み
- | Excel 2016 | サクラエディタ | メモ帳 | ISEエディタ部分 | vscode | ps v5 |
---|---|---|---|---|---|---|
UTF-8 | × | ○ | ○ | × | △ ※1 | △ ※2 |
UTF-8(BOM付) | ○ | ○ | ○ | ○ | ○ | ○ |
UTF-16 BE | × | ○ | × | × | × | × |
UTF-16 LE | × | ○ | × | × | × | × |
UTF-16 BOM BE | × | ○ | ○ | ○ | ○ | ○ |
UTF-16 BOM LE | ○ | ○ | ○ | ○ | ○ | ○ |
- ※1 自動判別できない。読み込んだ後、手動で文字コードを指定すれば読み込み可能
- ※2 -Encording オプションを明示的に指定する事で読み込み可能
書き出し
- | Excel 2016 | サクラエディタ | メモ帳 | ISEエディタ部分 | vscode | ps v5 |
---|---|---|---|---|---|---|
UTF-8 | × | ○ | × | × | ○ | △ ※5 |
UTF-8(BOM付) | △ ※3 | ○ | ○ | ○ ※4 | ○ | ○ |
UTF-16 BE | × | ○ | × | × | × | × |
UTF-16 LE | × | ○ | × | × | × | × |
UTF-16 BOM BE | × | ○ | ○ | ○ ※4 | ○ | ○ |
UTF-16 BOM LE | ○ ※4 | ○ | ○ | ○ ※4 | ○ | ○ |
- ※3 2016年10月の最新版Excelでcsv形式のみエクスポート可能
- ※4 タブ区切り形式のみエクスポート可能
- ※5 開いた文字コードと同じ形式でしか保存できない
- ※6 -Encording オプションを明示的に指定する事で読み込み可能
結論と注意点
- WindowsではUTF-8(BOM付)か、UTF-16 BOM付 LEを使えば、基本的に読めない事はない
- サクラエディタでUTF-8で保存する際、デフォルトではBOMにチェックが入っておらずBOMなしで保存されてしまうので注意
- Excelで作成したデータをUTF-8(BOM付)、UTF-16 BOM付 LEに保存する際は、一度SJISなどで保存してからメモ帳で変換するのがよい(MS公式もアナウンスしている)
- powershellで-encordingに何も指定しないと、unicode(UTF-16 BOM付 LE)で保存される
- となると全てのファイルをunicode(UTF-16 BOM付 LE)で保存すればいいじゃんと思ったりしてしまうが、UTF-8に比べてファイルサイズが1.5倍くらいになってしまうので悩ましい
- よって場面によっては多少面倒だが、UTF-8(BOM付)で保存するのがよい
参考
「Azure AD Connect のシングル サインオンは冗長化できない」と誤解していた話
ちょっと前に「Azure AD Connect(AADC)使ってシングルサインオン出来るぞー!もうADFS必要ないんじゃーい!」みたいなニュースがありました。
- ADFSなしでOffice365へのシングルサインオンを実現する(2) | Always on the clock
- Azure AD Connect のシングル サインオン & パススルー認証 (プレビュー) によるクラウド完結のユーザー認証インフラの実現 – MS Japan Office 365 Tech Blog
これ見て、すげー!と思ったものの「AADCって冗長化サポートされてないじゃん…そんなんに認証基盤任せられるかよ…解散」となっていましたが。記事をよーく見たら冗長化サポートされていたのでした。(風呂入ってるときに「いくらなんでも冗長化されてないままリリースしないよな。もう1回確認しよ」と思って調べ直したのがきっかけ)
誤解1:AADCのシングルサインオンは冗長化できない → できる
の
パススルー認証を運用環境デプロイで使用することを計画している場合は、別のサーバー (Azure AD Connect と最初のコネクタを実行しているサーバー以外) に 2 つ目のコネクタをインストールすることを強くお勧めします。
にある通り、
AADApplicationProxyConnectorInstaller.exe REGISTERCONNECTOR=“false” /q
手順 2: パススルー認証用にコネクタを Azure AD に登録する
.\RegisterConnector.ps1 -modulePath “C:\Program Files\Microsoft AAD App Proxy Connector\Modules\” -moduleName “AppProxyPSModule” -Feature PassthroughAuthentication
とします。Azure AD側で複数のコネクタが存在すると認識し、使用できるコネクタに対して認証要求を投げるようです。ここらへんはAzure AD Health Serverとか使ってるのかな?
誤解2:AADCのシングルサインオンが使えない場合、Office365にログインできない → できる
仮にAADCが全て停止した場合、AzureADの認証先であるAADCが使えないためO365にログインできない…と思ってましたが、これはADFSの発想でした。AADCの場合、サービス停止時は、単純にO365に直接ログインする形になるようです。
シームレス SSO は便宜的な機能であり、何らかの理由で失敗した場合、ユーザーのサインイン エクスペリエンスはその通常の動作に戻ります。つまり、ユーザーはサインイン ページでパスワードを入力する必要があります。
ADFSと違ってO365上のドメインがFederetedにならないので、このような動作になるんですね。そういった意味ではADFSを冗長化するよりも耐障害性が強いと言えます。
これらを考慮すると、Azure AD Connectシングルサインオン構成は利点しかない、という事が分かりました。強いて言うなら、AADC稼働中と障害中でユーザーのオペレーションが違うという事くらいですが、ほとんどの会社では気にしないでしょう。
第19回 Office 365 勉強会:感想
第19回 Office 365 勉強会というのに行ってきました。初参加でした。気になったところだけ感想です。
今の Office 365ってこんな感じ?
Groups/Teams周りと変わりつつあるO365サービスについて。
MyAnalytics
E5でついてくる機能。本命はMyAnalyticsの企業版であるWorkPlaceAnalyticsらしい。MSとしてはこの機能をプッシュしたいらしい。ということで、僕個人の会社アカウントもMyAnalyticsが有効になっているのだが、正直使えないという印象がある。というのは、Outlookの予定表を正としてデータ分析をしているのだが、午前半休だからOutlookの予定表に"午前半休"と4時間くらいの予定をぶっこむと、それを"会議"と認識したりする。原因として、Outlookで予定を作成する時に、"空き時間",“予定あり”,“外出中"くらいしかまともな選択肢がなく、細かい属性に落とし込めない。これが他社のスケジューラーだともうちょい選択肢があったりするのだが…。一案として、Outlookの"分類"をGPOで縛って特定の選択肢を必ず表示するようにし、それをユーザーが選ぶことを強制させる事があるが、それをMyAnalyticsに連携するのは無理なんだろうな…。
また「会議中にメールを送る事は悪なのか?」「メールは送ってないかもしれないけど、IMはしてるかもしれないし、ネットサーフィンしてるかもしれない。IMやネットサーフィンはMyAnalyticsでは検知できない」など、いろいろとツッコミがある。少なくとも、その会議が「有用かどうか判定」は、会議中の内職の内容を全て把握し、それが会議から派生した事柄かまでを判定しないといけないので、現状もこれからも正直厳しいと思う。
…と僕は感じており、MyAnalyticsのAIに対する納得感がないので、アドバイスを信用できない、という感情になる。WorkPlaceAnalyticsのリリース時にそれらがどこまで改善できているかが気になりますが…。
Flow/PowerApps/Forms周りの話、社内のpoweruserを味方につける
Flowくらいしか使ってないので正直実感がないですが、便利は便利なんだろうな、と思います。1点気になるのはNotes → Sharepoint移行の時によくある「昔○○さんが作ったワークフローを勝手に使ってるんですよー。辞めちゃって誰も仕組み分からないんですけど」や「Notesのアプリってたくさんあるけど何が使われてるかよくわからないから、念のため全部移行したいよね」問題。便利さの対極に発生する問題なのでどうしようもないが、情シスが管理できないサービスの利用が進めば進むほどOffice365へのロックインが進んで、他社サービスに移行し辛くなる気がするな。
なので展開にあたってはある程度ガバナンスを利かせたい。例えば、1人5つまでしかFlowを作れないようにするとか(適当)。そうすれば、実際に使っているFlowだけが残りやすくなる。あと1年毎に棚卸をして、不要なFlowやPowerAppsは消すとか。けどそれが出来ないから各社Notes移行の時に苦労してるんだろうな。
この辺りをMyAnalyticsで通知してくれればいいかも。例えば「このFlowは○ヵ月トリガーを検知していません」とか「このフローは動いていますが、リアクションを取っているユーザーがいません。」とか。Teamsには非アクティブのチームを自動的に削除する設定が追加されるらしいし、ILMも意識した管理者設定が出来れば助かるな。
Hololens…ではなくPowerBIの話
Hololensデモはテンションが上がる!もうなんでもかんでもHololens使ってデモしようw PowerBIの話。PowerBIもそうだが、Teams,Flow,PowreAppsも使ってみようと思わないと使えない。受け身では使えない。例えばWindowsにフリーソフトたくさん入れてるような人は自然に使うだろうし、そうじゃない人は使えない。現状、うちの会社もExcel中心で業務をやっているが、その中でPowerBIを使った方が便利なものはどんどん移管していくべきだな、と思ったとはいえ、こういう系のデモだとBtoCの想定が主であるため、BtoBが中心のSIerでどうやって使おうかなぁ…と考えつつ、結局使ってないのが現状です。
私、PowerBIとかPowerAppsってあんまりワクワクしなくて、管理者設定系の方が気になっちゃいます。管理者があれこれ試行錯誤して、ユーザーの皆様にサービスを提供するような。それは多分職業柄ってのと、その方が俺が面白いじゃん、って事かな。ユーザーがPowerBIとかPowerApps使ってゴリゴリやる方がみんなが面白いよね、ってのは頭じゃ分かってるんですけど。
あーけどFlowなんかは自分で使ってみてすげー便利だと思うからみんなにも進めたいと思うし、やっぱPowerBIとかPowerAppsの便利さが自分で分かってないだけなのかな…。うーん。
SfBBotの話
自分でがんばって作ろうとして挫折してたので非常に助かりました!!!めっちゃよかった~。開発者じゃないので、お作法系が分からず詰まってましたがこのセッションを受けたからには必ず作りきろうと思います。
座談会
印象に残ったのは、Office 365で障害が発生した時にどう伝える?というのと、Sharepointをファイルサーバーに出来るのか、という点。前者は、大声で伝えるとか電話で連絡するとかFAXするとか、昭和の古典的なソリューションで面白かったです。弊社の場合、Office 365に限らずシステムがよく落ちるので(…)「なんか調子悪いなー」「今メール見れないっぽいよ」「んじゃ飯行こう」で終わりそうです。。。Sharepointファイルサーバー問題は、現行のファイルサーバーの闇の深さによると思ってて、闇が深いとSI側も闇にとらわれる、というイメージ…。あとは使い勝手ですね。やっぱエクスプローラーでファイル一覧みたいじゃん、ブラウザ不便じゃん、と。僕はOD4B同期ツールを使ってドキュメントライブラリを同期する事でエクスプローラー閲覧を実現しているのですが、ドキュメントライブラリに大容量ファイルを置かれてたまに死にます。ファイルサーバーをそのまま移行というより、SPOのメリット・デメリットを把握した上で、ユーザーの使い方も変える前提で展開しないとクレームになると思います。
以上です。
初めての勉強会で馴染めるか不安でしたが、良い意味でセミナーみたいで、内輪なアットホーム感もありつつ初めての人を歓迎する雰囲気もあり、よかったです。座談会でディスカッション出来て、みんな同じような事に悩んでるんだな、と分かりました(Microsoftさんなんとかしてください。)
レポ書くのに写真1枚も撮ってない事に気づきました…。せめてお菓子くらいは撮影しとけばよかったです。次回参加時の反省にします。
Azure上に作成した仮想マシンを作業時だけサイズ変更して快適に利用する(その他仮想マシン作成後のメモ)
Azure上の仮想マシン、最低サイズのBasic_A0だと料金は約1000円/月なのですが、これだとまともに操作できないレベルに遅い。快適に操作するならBasic_A3くらいだが、約5000円/月くらいとなり辛い。
作業時以外はマシンをシャットダウンして課金を抑えるのもいいが、ADのような常時起動前提のサーバーの場合、長期間シャットダウンするとトラブルの元となるため、作業時のみサイズ変更をして終わったら元に戻すスクリプトを作成する。
powershellでログイン
スクリプトのみで自動ログインをする場合、こちらとなる。
$secpasswd = ConvertTo-SecureString "[パスワード]" -AsPlainText -Force $mycreds = New-Object System.Management.Automation.PSCredential ("[ID]", $secpasswd) Login-AzureRmAccount -Tenant "[テナントID]" -Credential $mycreds -ServicePrincipal
ただし上記は組織アカウント(xxx@テナント名.onmicrosoft.comのようなアカウント)を使った場合で、マイクロソフトアカウント(xxx@gmail.comとかxxx@yahoo.comとか、MS以外のアカウント)の場合、上記手順は使用できず、単純にLogin-AzureRmAccountで対話的にログインする必要がある。
ではマイクロソフトアカウントでAzureを契約(会社で契約しない限りそれが普通)した場合はどうなるか?以下のブログにある通り、最初にテナントを作成したのがマイクロソフトアカウントの場合、サブスクリプションもそれに紐づいているので、組織アカウントを共同管理者として設定する必要がある。
Azure PowershellでMicrosoftアカウントを利用してのAdd-AzureAccountについて https://social.msdn.microsoft.com/Forums/ja-JP/fd253f40-539a-46c0-8fd2-0500f8712918/azure-powershellmicrosoftaddazureaccount?forum=windowsazureja
サイズ変更
仮想マシンのディスク サイズを Azure PowerShell から拡張する方法 - Japan Azure Technical Support Engineers' Blog https://blogs.technet.microsoft.com/jpaztech/2016/04/18/azure-vm-disk-resize/
Azure 仮想マシンをPowerShellからスケールアップする - 浅草橋青空市場 http://asazure.hatenablog.jp/entry/2015/08/24/173456
を参照に
スケールアップ
$vmconfig = get-azurermvm -name [マシン名] -ResourceGroupName [RG名] $vmconfig.HardwareProfile.VmSize = "Standard_A3" $res = Update-AzureRmVM -ResourceGroupName [RG名] -VM $vmconfig if($res.StatusCode -ne "OK") {"StatusCodeがOKではありません"}
スケールダウン
$vmconfig = get-azurermvm -name [マシン名] -ResourceGroupName [RG名] $vmconfig.HardwareProfile.VmSize = "Basic_A0" $res = Update-AzureRmVM -ResourceGroupName [RG名] -VM $vmconfig if($res.StatusCode -ne "OK") {"StatusCodeがOKではありません"}
サイズ変更~マシン再起動までを実施するのでコマンド終了まで数分かかる。
余談:OS停止/起動
Azure PowerShell にて新ポータル (ARM) の VM を自動的に停止・開始・再起動する - Japan Azure Technical Support Engineers' Blog https://blogs.technet.microsoft.com/jpaztech/2016/02/23/vmstop-start-restart/
Stop-AzureRmVM -ResourceGroupName [RG名] -Name [マシン名] -Force Start-AzureRmVM -ResourceGroupName [RG名] -Name [マシン名] Restart-AzureRmVM -ResourceGroupName [RG名] -Name [マシン名]
メンバーサーバーなど使用しないとき以外はシャットダウンするマシンはこちらを使う
余談:OSデプロイ後の日本語化
OSデプロイ後は言語もタイムゾーンも全て英語で、細かい設定をいろいろ実施しなければいけないのですが…全てスクリプトで完結されている神がいました。ありがとうございます。
Azure IaaS 上に作成した Windows Server 2016 仮想マシンの UI を日本語化する | 焦げlog http://kogelog.com/2016/10/18/20161018-01/
Azure VM の日本語 UI を PowerShell で設定 at SE の雑記 http://blog.engineer-memo.com/2013/11/24/azure-vm-%E3%81%AE%E6%97%A5%E6%9C%AC%E8%AA%9E-ui-%E3%82%92-powershell-%E3%81%A7%E8%A8%AD%E5%AE%9A/
余談:ADへの昇格
Windows Server 2016 で AD DS (Active Directory Domain Services) のセットアップ | blog.yottun8.com
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
AD DS のドメイン コントローラーへの昇格 | blog.yottun8.com
$password = ConvertTo-SecureString -String "[パスワード]" -AsPlainText -Force Install-ADDSForest -DomainName "almea.jp" ` -DomainNetbiosName "ALMEA" ` -ForestMode "WinThreshold" ` -DomainMode "WinThreshold" ` -SafeModeAdministratorPassword $password ` -DatabasePath "C:\Windows\NTDS" ` -LogPath "C:\Windows\NTDS" ` -SysvolPath "C:\Windows\SYSVOL" ` -CreateDnsDelegation:$false ` -InstallDns:$true ` -NoRebootOnCompletion:$false ` -Force:$true
余談:AADCのインストール
Azure AD Connect: カスタム インストール | Microsoft Docs https://docs.microsoft.com/ja-jp/azure/active-directory/connect/active-directory-aadconnect-get-started-custom
O365でアプリケーション登録→APIアクセスの続き
認証コード取得の自動化を検討
認証コードは取得から一定時間経過すると無効になってしまうので定期的に取得したい。前回書いた通り
- 以下のフォーマットで認証エンドポイントにアクセス
- https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id=[クライアントID]&resource=https%3a%2f%2foutlook.office365.com%2f&redirect_uri={リダイレクトURL}
- このようなレスポンスがあれば成功
- https://localhost/myapp?code=[認証トークン]&session_state=[セッション情報]]
と、やりたいのはレスポンス先のURL(リダイレクト先URL)に含まれる認証トークン文字列の取り出してある。
Invoke-WebRequestで取得を試みる
Invoke-WebRequest -url "https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id=[クライアントID]&resource=https%3a%2f%2foutlook.office365.com%2f&redirect_uri={リダイレクトURL}"
を実行し戻り値にリダイレクト先のURLが含まれていないか調べたが、存在しなかった。
"リダイレクト先 url 取得"はどの言語でも話題になっており、例えばURLステータスコードが302だからURLを追跡するなどの方法が書いてあったが、上記アクセスは200で返ってくるので追いようがない(というかリダイレクト処理じゃないし)
で、気づいたのが、これはリダイレクト先のWebサイトで開発を行い、ブラウザからのアクセスが発生した場合、code=[認証トークン部分]を自動的に取り出すようなプログラムを実装する必要があるとわかった。今回、ローカルのPC環境から実行したいだけなので、まさかこれだけのためにローカルにWebサーバー立ててプログラム開発するのも面倒なので、手動取得する事にした。
※ 認証API v2.0 だと302で返ってくるらしい
ExchangeOnlineにアクセス
認証コードは手で取る事にして、前回のブログの「4. プログラムからアクセス」でaccess_tokenをゲットします。
$response = Invoke-RestMethod -uri $url -Method Post -Body $body -ContentType $ContentType $response.access_token #> アクセストークン
このアクセストークンをヘッダーに含めてアクセスします。
$headers = @{ "Accept" = "Application/json" "Authorization" = ("Bearer " + $response.access_token) } $ContentType = "Application/json"
例えば、受信トレイの最新10件を取得するスクリプト
Invoke-RestMethod -uri "https://outlook.office.com/api/v1.0/me/folders/inbox/messages?$top=10" -Method Get -ContentType $ContentType -Headers $headers
例えば、JSONファイルの中身の予定を登録するスクリプト(詳細は別エントリで書きます)
Invoke-RestMethod -Uri "https://outlook.office365.com/api/v1.0/me/events" -Method Post -InFile ".\jsontest.json" -ContentType 'application/json' -Headers $headers
が実行できます。
こうなると、繰り返し処理していろいろやりたいところなのですが、アクセストークンには時限があるので定期的に再取得してやる必要があります。めんどくさ…。やっぱv2でアクセスしないといけないのか…。