O365でアプリケーション登録→APIアクセスしようとして
はまったわー
やりたいこと
- Office365を契約
- AzureADにアプリケーションを登録
- アプリケーションのアプリケーションID,秘密鍵を使ってアクセストークンを取得
- プログラムからアクセス
1. Office365を契約,AzureADにサインアップ
O365はE5を契約。
サインアップ後、裏でデプロイされたAzureADにアプリケーション登録しようとAzureクラシックポータルにアクセスするが、AzureADサインアップ時にエラーになる。
パターン1. サインアップでエラー
電話による認証、クレジットカードによる認証を進めたところ、サインアップでエラーになった。原因不明。
パターン2. 電話による本人確認でエラー
そんな事を繰り返していたら、電話認証で番号を入れたタイミングで「アカウントを確認できませんでした。サポートにお問い合わせください。 」というエラーが出るようになった。想像だが、同じ電話番号で何度も認証していたらこのエラーが出るのではないか。証拠として、適当な電話番号を入力したときはエラーが出ずに認証コード入力画面になった(その番号の人、すいません)
2. AzureADにアプリケーションを登録
AzureADにアプリケーション登録をする手順は3つあるようです。
- Azureクラシックポータルから登録
- Azureポータル(以前、プレビューと言われていたものから登録)
- Office 365 ユーザーとエンタープライズ ユーザーのサインインを可能にする – Microsoft ID プラットフォームから登録
1.は今までのセオリーだったもの。
2について。最近、AzureクラシックポータルからAzureポータルへの機能移転が進んでおり、旧来Azureクラシックポータルでやっていたアプリ登録もAzureポータルから出来るようになったようです。
左ペインのAzure Active directory -> アプリの登録 -> ＋追加からアプリを登録。適切な権限を付与してキーを作成する。ただし、この機能はプレビュー版なので動作が怪しい可能性があります。(今回は大丈夫だったぽい)
んで、3はいったいなんなの?という話ですが、どうやらMSは商用のOffice365も私用のOutlook.comも同じコードで開発できるよう、RESTのエンドポイントを統一し、組織アカウントでログインすれば商用O365を、個人アカウントでログインすれば、Outlook.com側を触るようなAPIを実装しているらしい。
v2.0 endpoint の OAuth を使った Client 開発 (Azure AD と MSA への対応) – Tsmatz
そのアプリ登録のフロントエンドが、上記リンクの「Microsoft ID プラットフォーム」というわけ。ここからアプリ登録すると、裏側の仕組みとしてはログインした組織アカウントのAzureADにアプリ登録されるだけ。しかも、現状では「Microsoft ID プラットフォーム」画面からはGraph API関連の権限しか付与できず、outlook APIの権限はコントロールできない様子。
将来的に、製品個別のAPIがGraph APIに統一されるのを見越せば、本命は「Microsoft ID プラットフォーム」なんだろうけど、現時点では特別にこれを使う理由はなさそうです。
認証API v1.0 と v2.0について
よくわかってないです。
- API エンドポイントが違う
- 使える機能が違う(ほんと?)
- v2.0 認証エンドポイント プレビューを使用した Office 365 API と Outlook.com API の認証 | MSDN
- 現時点では、メール、連絡先、予定表のみ
- GraphAPIだから、それだけしか使えないんじゃないの?
- Outlook API v1.0 と v2.0とは関係ない(ほんと?)
- なので、認証はv2.0を使うのがよさそう?
3. アプリケーションのアプリケーションID,秘密鍵を使ってアクセストークン(認証トークン)を取得
認証API v1.0での認証手順
- 以下のフォーマットで認証エンドポイントにアクセス
- 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を不一致としていたら、認証コードが取れなくてめちゃくちゃハマった。リダイレクトURLを"https://portal.office.com"に設定していたせいかもしれないが…。以下のようなレスポンスしか返ってこなかった。
ひとまずマニュアル通り、https://localhost/myapp宛にリダイレクトする設定にした。ここでもハマって、どこかのサンプルでhttp://localhost/myappをリダイレクト先に指定していたのでコピペしたら、実はhttpsでないと全て無効なURLとなってしまうらしいことが分かった。どこにも書いてないんですが…。
認証API v2.0での認証手順
Get Started with the Outlook REST APIs - Outlook Dev Center
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
- 以下のフォーマットで認証エンドポイントにアクセス
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=[クライアントID]&redirect_uri=[リダイレクトURL]]p&response_type=code&scope=[スコープ]]
スコープはこんな感じで指定する↓
v2.0 認証エンドポイント プレビューを使用した Office 365 API と Outlook.com API の認証 | MSDN
今回、自分で登録したカスタムアプリを認証API v2で認証しようとしたところ、ブラウザバーに
Application+[クライアントID]+is+not+supported+for+this+API+version.
という表記が返り、エラーとなってしまった。おそらく、アプリケーションにめちゃくちゃ権限を付与してしまい、その権限のうち1つが認証API v2ではノンサポだからではないか。…となると、認証APIのバージョンによって使える機能も違うという事?認証API 1.0専用の権限をアプリに付与してしまうと、認証API 2.0で許可されない?
ということで、認証API v1.0だけで進めることにします。
メモ：参考にした記事
- Office 365 API 入門 – Tsmatz
- Get Started with the Outlook REST APIs - Outlook Dev Center
- Using PowerShell and the Office 365 REST API with OAuth. – Ron Ben Artzi
v2が出て一年以内だからか、v1とv2が混在してるのでややこしい。
4. プログラムからアクセス
3.で取得した認証トークンを元に、postを投げてやる
$url = 'https://login.microsoftonline.com/common/oauth2/token' $Body = @{ "grant_type" = "authorization_code" "code" = [認証コード] "client_id" = [クライアントID] "client_secret" = [クライアント秘密鍵] "redirect_uri" = "https://localhost/myapp" "resource" = "https://outlook.office365.com/" } $ContentType = "application/x-www-form-urlencoded" Invoke-RestMethod -uri $url -Method Post -Body $body -ContentType $ContentType
結果、
token_type : Bearer
scope : Calendars.Read Calendars.Read.All Calendars.Read.Shared Calendars.ReadWrite Calendars.ReadWrite.All Calendars.ReadWrite.Shared Contacts.Read Contacts.Read.All Contacts.Read.Shared Contacts.ReadWrite Contacts.ReadWrite.All Contacts.ReadWrite.Shared Directory.AccessAsUser.All Directory.Read.All
Directory.ReadWrite.All email Exchange.Manage Files.Read Files.Read.All Files.Read.Selected Files.ReadWrite Files.ReadWrite.All Files.ReadWrite.AppFolder Files.ReadWrite.Selected full_access_as_user Group.Read.All Group.ReadWrite.All IdentityRiskEvent.Read.All Mail.Read Mail.Read.All Mail.Read
.Shared Mail.ReadWrite Mail.ReadWrite.All Mail.ReadWrite.Shared Mail.Send Mail.Send.All Mail.Send.Shared MailboxSettings.ReadWrite Notes.Create Notes.Read Notes.Read.All Notes.ReadWrite Notes.ReadWrite.All Notes.ReadWrite.CreatedByApp offline_access openid People.Read People.ReadWrite profile
Reports.Read.All Sites.Read.All Sites.ReadWrite.All Tasks.Read Tasks.Read.Shared Tasks.ReadWrite Tasks.ReadWrite.Shared User.Read User.Read.All User.ReadBasic.All User.ReadWrite User.ReadWrite.All
expires_in : 3600
ext_expires_in : 0
expires_on : 1478335851
not_before : 1478331951
resource : https://outlook.office365.com/
access_token : アクセストークン
refresh_token : リフレッショトークン
id_token : IDトークン
権限めっちゃついてるw 自分でつけたんだけど…。
注意
サンプルコードに"resource"の指定がなかったため抜かすと、
"error":"invalid_resource","error_description":"AADSTS50001: Resource identifier is not provided.\r\nTrace ID
みたいなエラーが出た。エラーコード"AADSTS50001"でググると以下のURLがヒット(ppt注意)
Cloud Authentication Troubleshooting and Recipes for Developers
結論としては、resourceの指定は必要でした。
疲れたので今日はここまで。
Microsoft Tech Summit 2016に行ってきたメモ
行ってきました。
Microsoft Tech Summit｜Microsoft
月並みな表現だけどエキサイティングでした。地に足の着いた技術と未来の技術がセットになってて面白かったです。
Day1
キーノート
- Security! Management! !Inovation
- セキュリティ担保したモバイル利用、devops、クラウド基盤を利用したリアルタイムモニタリングとかすごいよ
- 旧来型っぽい大企業でも採用して上手くいってるよ
- なので「うちの会社は無理そう…」とかないし
- AIはヤバイ
- botもくる
- エンタープライズで導入始まってる
- どっちもMSで基盤持ってる
- HoloLens日本で売るよ
- 詳しくは動画参照：【Tech Summit】KEY001 いま、企業の IT が求めるセキュリティと管理、そして IT ヒーローによるイノベーション - YouTube
- 詳しくはまとめ記事参照：Microsoft Tech Summit基調講演：マイクロソフトは「セキュリティ」「管理」「イノベーション」で企業のデジタルトランスフォーメーションを強力に支援 (1/2) - ＠IT
11:30-12:20 Office 365 で実現する一歩先の情報漏えい対策(SEC002)
- 最近のクラウド時代の流行り→CASB:Cloud Access Security Broker
- クラウドに侵入されたら検知したいけど、ふつーの環境だと平均200日くらい経ってから気づくのでやられたい放題
- そこでOffice 365 Advabced Security Management
- 怪しいOffice365ユーザーを見つけて、管理者に通報する機能
- ありえない移動とか、大量のファイルのダウンロードなどを検知
- 管理者がやることはたった3つ
- 高度なセキュリティの管理を有効にする
- アラートメールが来たらポータルで確認する
- 脅威と認められたらユーザーを制御
- Cloud App Security
- ライセンス
- Advanced Security Management：E5付属。単品で300円/人
- Cloud App Security：EM+S E5付属。単品で売ってる?
- 組織にE3とE5のユーザーが混在してたりする場合はどうするんだろう?
- SRに略(★Todo2)
- アクティビティログ：180日保持 アラート：永久保存
- アクティビティログはエクスポート可能
- 使用できるOffice365ライセンスはE5
12:45-13:35 Azure ネットワーク設計と運用のツボ(DEP005)
- 多分このセッションはスライド資料の方が理解が深まる
- パブリックIPなくても中から外に繋がる。
- サブネットに対してNSGをつけられる。(仮装マシン個々につけてもいいがサブネットにつける方が自然
- NSGないとつるつる
- 絶対にNSGを削除しないでね
- ユーザー定義ルート
- サブネットの内側に定義できるルーティング設定
- 複数NICマジ無駄。オンプレと違って倍速とかならない
- リージョン間の距離
- VNETピアリング
- 複数のVNETを簡単に接続できる
- 旧VNETと新VNETも繋げちゃう
- なので旧でVNET組んだから移行できない…とかはない
- 1GB一円
- AXN
- 超早い。40～50Gbps
- そのうち全部のIaaSマシンに乗りそう
- azure内の通信はMS内で閉じるが、CDN宛のものはインターネット出る
- azureのipは毎週水曜日にリリースされている
- VPNゲートウェイでBGPサポートしたから自由度増えた
- ただしStandard以上
- プラン説明とか→About VPN Gateway| Microsoft Azure
- インフラエンジニアもJSONでテンプレ作って展開しよう
- そんでバージョン管理してInfrastructure as Code (IaC)
- canary vm
- ネットワークのサポートは絶対入ってね〜!!!
14:00-14:45 アイデンティティのMVPが語るAzureADとアプリ連携の勘所(SEC020)
- ID管理を導入するにあたって注意すべき事
現実的な対応
- 識別子
- アプリケーションの認証プロトコル
- OIDC/SAMLじゃないっす対応
- 対応すまで待とう、は無理なので…
- パスワードSSO
- ブラウザにアドオンを入力し、ID/Passwordを代理入力
- Chormeで自動でID/Pass覚えるのとあんま変わらん
- ログインURLが静的じゃないとだめなど製薬あり
- ブラウザにアドオンを入力し、ID/Passwordを代理入力
- Azure AD WAP
- Kerberosじゃないとだめ、などの制約
- AzureADWAP + PingAccess連携(ヘッダー認証)
- WAM連携
- パスワードSSO
- などに逃げる
- WAN連携とヘッダー認証がよくわかってなかったので勉強する(★Todo3)
- ネットワークの問題
- 拠点ネットワークを絞り込み、無理な場合は例外ユーザーとか作る。
- マイナー拠点対応、偉い人対応、みたいな
- 拠点ネットワークを絞り込み、無理な場合は例外ユーザーとか作る。
- デバイス
- 聞きそびれた
表1
| AAD側 | - | アプリ側 | - |
|---|---|---|---|
| UPN | 123@foo.jp | LoginID | emp1234 |
| displayname | 山田太郎 | displayname | 山田太郎 |
| ExtensionAttribute1 | emp1234 |
- 表2
| 属性 | SAMLトークン属性 |
|---|---|
| UPN | nameid-fornat:unspecified |
| nameid-fornat:unspecified | |
| Onpremisessamaccountname | nameid-fornat:WindowsDomainQualifiedName |
| ExtentionAttribute1-15 | nameid-fornat:emailaddress |
| extractmailperfix() | nameid-fornat:emailaddress |
15:15-16:05 他と同じOffice365で満足ですか?Office365のAPIでオリジナルサービスに進化させる(APP009)
- AzureADにアプリケーション登録
- 組織で開発中のアプリケーション
- クライアントID と クライアントキー取得
- アプリケーションのアクセス許可、デリゲートされたアクセス許可
- HTTP Request投げる → authコード取得
- でAPI叩けるよ
- 必要な権限だけ付与しないと、怪しいfb連携アプリみたいになっちゃうよ
- バッチ処理の権限
- 最近企業にウケるもの。Bot,AI,IoT。
- Cognitive service,WebJob使って楽に面白く
- APIでオリジナルサービスに進化させる
- Exceed1の事例
- 英単語勉強アプリ
- Bossから来る英文メールの頻出単語をリストアップし、勉強できる
- API利用のコツ
- Q1. outlook.とgraph.のAPIが混在している
- Q2. SfBのドキュメントなくない?
- LUIS超楽
- 関連：CogBot_CognitiveBotOverview_20161020 - Docs.com
16:30-17:20 AzureADでクラウドの認証基盤を統合したいけど、IDの安全性はどうする?(SEC008)
- あんまりメモってない
- 後でスライド期待
17:45-18:35 Cloud First、Mobile FirstにおけるID管理とは?-人(Identity)から始まるアクセス制御-(SEC004)
- IDを分散させるとセキュリティが低下する
- AzureADP使えばIP制限可能。アプリ毎にアクセス制御も可能
- Intuneは進化中でiOSのIMEI登録して許可したデバイスからしかアクセスできないように出来る
- すんませんあんまメモってない
- ID系のセッションは後でまとめよう
Day2
9:00-9:30 PowerShellの新しい相棒 Visual Studio Code(APP017)
- 'code .'でvscode起動
- 拡張紹介
- vscode-pandoc
- markdownをpdfとかHTMLにする
- PlantUML
- UMP図を書く
- vscode-pandoc
- デバッグにはlanuch.jsonというのが必要だが、自動で作成されるので意識しなくてもよい
- PSISE開発チームメンバーとVScodeの開発チームメンバーが同じ
- 日次でアップデートしてるよ
- 日本からのフィードバック待ってるよ
- SJIS開けないのどうにかしてほしい
9:55-10:25 お客様とパートナー様のOffice365導入・定着化を支援するFirstTrack Center(PRD013)
- EOPとかATPにも対応している。Notesからの移行についても対応している(IMAPとは別で)
- その他は知ってる事でした
10:50-11:40 Office365におけるID統合とアクセス制御のベストプラクティス(PRD004)
- オンプレ組織とO365ディレクトリ同期のデザインパターンについて
- 知ってる事だったけど、空ですらすら話せない(考えないと話せない)のでもうちょい浸透させよう
- 利用リージョンが分かれるとき、最も近いデータセンターに接続される
- 例えばO365日本テナントを米国で利用する場合、米国のCDNを引いて米国のO365フロントエンドにアクセスしバックエンドのMSネットワーク経由でデータを取り出す
- よってインターネット帯域の消費はしない
- ただし、O365ポータルとExOLのみ。SfB,SPOは近くのサイトに接続。
- Onedriveはどうなんだろう…?
- SRに(★Todo4)
- Office365への他テナントへのアクセス制御もうすぐ来るぽい
12:00-12:45 [ランチ付き] Azure IaaS 応用編～実務で使えるVMとPaaSの組み合わせ～(SNR001)
- ごめーん知ってる事ばっかりだった
13:10-14:00 プロトコルマニアックス～ OAuth 2.0/OpenID Connect/FIDO 2.0/SAML 2.0 違いと用途(SEC010)
- SAML 2.0
- RP Initiated
- IdP Initiated
- RP Initiatedがよく使われる。最初にAppにログイン試行する方法。
- OAhth 2.0
- SAMLとOAuthの違い
- 情報を出すのがIdPか本人か
- OAuthは認可をするプロトコルなので、アプリケーションは不安
- OIDC
- 2014年に登場
- OAuthにユーザーの認証機能を組み込んだもの
- OAuth2.0 + ID Token
- 企業の話
- 企業だからといって勝手にSAML2.0で個人情報出していいのか?OIDCで個人に確認を取って出すべきではないのか。
- FIDO 2.0
- 生体認証とかでサービスを使いたい
- 「パスワード以外の選択肢」スライドが素晴らしい。
- "パスワードはすぐ盗まれる"と言葉で言っても、こういうスライド1枚の破壊力
- パスワードとPINの違い
- まとめ
14:25-15:15 クラウドで守る! Exchange Online の最新セキュリティ対策(PRD005)
- EOP/ATPの話
- だいたい知ってた
- EOP新機能：Anti-spoofing protection
- EOPを通ると自然に有効になる。去年くらいから実装。
- 怪しげなメールにはプレビュー画面でNoticeする。
- 詳しくはこちら→How antispoofing protection works in Office 365 – Terry Zink: Security Talk
- EOP新機能：Zero-hour Auto Purge: ZAP
- EOPがスパムと認定した後でも、過去にユーザーが受信したメールをさかのぼって迷惑メールフォルダに移動する or 削除する
- ただし未読のメールのみ
- ATP
- URL Trace機能
- 現時点ではリストベースの判断。
- マジかよ知らんかった
- 今後は、実際に開いてページの中身を確認する(Sandbox)。動的であるので安全だが、ちょっと遅いかも?Linked Content Detonationというらしい
- 現時点ではリストベースの判断。
- Dynamic Delivery
- 今までだとATP通るのに5分～10分かかってしまう。これからは本文だけは送って添付ファイルは後から送る機能
- これ欲しかった
- 今までだとATP通るのに5分～10分かかってしまう。これからは本文だけは送って添付ファイルは後から送る機能
- URL Trace機能
- ATPの拡張
- ExOL以外にも広がってくよ～
- 値段変わらないのかな?
- ExOL以外にも広がってくよ～
- DKIM署名対応
- Q1. ATPって送信元によってATPする、しないを選べないの?
- A1. 送信者が組織内のメールだとATPされない。それ以外だと問答無用でされる。
15:40-16:30 詳説 - Rights Management Services / Azure Information Protection(SEC016)
- RMSの話
- それ以外は知ってる事でした
15:40-16:30 Xamarin と Azure で、超効率的にクラウドと繋がるモバイルアプリを作ろう！(APP005)
16:55-17:45 OMS Log Analytics によるビッグデータログの分析方法の解説と実演(DEP002)
- 最近インフラやってないけどSCCMとOMSでこういう事出来たなら速攻導入したかった
- Sandbox環境もあるので是非
- URL忘れた
18:10-19:00 条件付きアクセスを徹底理解 - Azure Active Directory で実現する場所とデバイスの“条件付きアクセス制御”-(SEC007)
- 他のID系のセッション出たので知ってる事ばかりだった
18:10-19:00 エバンジェリストが注目のこの人と語る IT キャリアの多様性と未来(SPL005)
- コント…?
- 面白かったです
参加したセッションまとめ
- ID系
- アクセス制御
- Day1：16:30-17:20 AzureADでクラウドの認証基盤を統合したいけど、IDの安全性はどうする?(SEC008)
- Day1：17:45-18:35 Cloud First、Mobile FirstにおけるID管理とは?-人(Identity)から始まるアクセス制御-(SEC004)
- Day2：10:50-11:40 Office365におけるID統合とアクセス制御のベストプラクティス(PRD004)
- Day2：18:10-19:00 条件付きアクセスを徹底理解 - Azure Active Directory で実現する場所とデバイスの“条件付きアクセス制御”-(SEC007)
- デリバリ
- Day1：14:00-14:45 アイデンティティのMVPが語るAzureADとアプリ連携の勘所(SEC020)
- 仕様
- アクセス制御
- O365系
- App
- Day1：11:30-12:20 Office 365 で実現する一歩先の情報漏えい対策(SEC002)
- Day2：14:25-15:15 クラウドで守る! Exchange Online の最新セキュリティ対策(PRD005)
- Day2：15:40-16:30 詳説 - Rights Management Services / Azure Information Protection(SEC016)
- Dev
- Day1：15:15-16:05 他と同じOffice365で満足ですか?Office365のAPIでオリジナルサービスに進化させる(APP009)
- Day2：9:00-9:30 PowerShellの新しい相棒 Visual Studio Code(APP017)
- Ope
- Day2：9:55-10:25 お客様とパートナー様のOffice365導入・定着化を支援するFirstTrack Center(PRD013)
- App
- Azure系
- Day1：12:45-13:35 Azure ネットワーク設計と運用のツボ(DEP005)
- Day2：12:00-12:45 [ランチ付き] Azure IaaS 応用編～実務で使えるVMとPaaSの組み合わせ～(SNR001)
- その他
まとめ
- はらへった
- 近くにコンビニほしかった
- 2日で6万円の元取るためにレッドブルとモンスター飲みまくった
- 5本飲んだので1000円分
- OneNoteっていうかSurfaceのペンをもっと使おうと思った
- ID系出過ぎた
- 全然関係ないセッションにもっと出ればよかった
- 内容濃かったから腹落ちさせて整理展開しないとな～
関連
Visual Studio CodeでPlane Text(.txt)で自分独自記法のハイライト表示
Sublime Text - Plain Text(.txt)で自分独自記法のハイライト表示 - Qiita
と同じく、僕もメモ帳ベースで自分独自記法のTodoリストを使ってます。
サクラエディタだとこんな感じ。
VSCodeでの独自シンタックスハイライト方法を調べてみました。
マニュアルなど
に載っています。簡単にまとめると
- tmLanguageファイルの用意
- VSCode用にコンバート
- VSCodeにインポート
となります。では1.から行きます。
1. tmLanguageファイルの用意
多分これが一番めんどくさいのですが、自分独自記法のtmLanguageファイルを用意します。サクラエディタだと簡単に書けるのに…。
tmLanguageの作り方の詳細は別でまとめるとして、今回は
に投稿されているソースを元にコンバートします。
※ メモ：tmLanguageファイルの書式
TextMate Manual » Language Grammars
2. VSCode用にコンバート
用意したtmLanguageファイルを使用してコンバートをします。手法は最初のVisual Studio Code Colorizersに載っています。作業の前に"Yeoman and the VS Code Extension generator"というものをインストールしなければいけないです。
The Yo Code Visual Studio Code Extension Generator
さらに、"Yeoman and the VS Code Extension generator"をインストールするために、npmというNode.jsのパッケージ管理システムをインストールしなければいけないようです。
How to Install Node.js® and NPM on Windows - Treehouse Blog
これらの準備が整った後、
yo code
でコンバートを開始します。参考までに画面ショットを載せておきます。
ここでの設定なのですが、tmLanguageファイル中のfileTypesに準拠しないと、コンバートは成功するもののVSCode起動時に正常にパッケージを読み込んでくれずシンタックスハイライトが効かない状態となります。
<key>fileTypes</key> <array> <string>log</string> </array>
おそらく、生成されるpackage.jsonとsyntaxes配下のファイル紐づけの問題かと思いますが、詳しいことは分かりませんでした。
3. VSCodeにインポート
実行したフォルダ直下に以下のような言語パッケージが生成されるので、
それを
%USERPROFILE%\.vscode\extensions
に配置してVSCodeを再起動します。
結果
ひとまず、シンタックスハイライトが効いていることを確認できました。この状態になれば
%USERPROFILE%\.vscode\extensions
配下のtmLanguageファイルを直接いじって色を変える・ワードを追加するのもOKかと思います。おかしくなったら言語パックをアンインストールして本手順を1から実施します。
サクラエディタ使いがVisual Studio Codeを使い始めた
理由はいろいろありますが使い始めました。
モダンなエディタを触りたい
2000年代前半のテキストエディア全盛時代よりサクラエディタでメモ書き～スクリプト開発してきました。2000年代後半にIDEが流行り始めた時も、開発者ではない・インストールに手間がかかる・重いなどの理由でテキストエディタを使い続けてきました。
そして2016年。Windowsに標準でIDE(Powershell ISE)が装備され、次世代テキストエディタ(sublime text,Atom)が登場し、軽くて無料のIDEが流行り始めた今、さすがにテキストエディタ一択ではいかんでしょということで時代についていく道を選択しました。
選んだもの
Visual Studioが無料ではありましたが、そこまでがっつり開発しない & 全機能を使い倒せる自信がなかったため、テキストエディタベースのものを選択。MSに親和性のある仕事をしているってことで、Visual Studio Codeを使うことにしました。
VSCodeのいい所
軽い
文字を打つのにストレスではない。これが一番大きい。少なくとも触った感触はサクラエディタと同等以上ではないといけなかったので、これは必須条件でした。
マルチプラットフォーム
Windows,Linux,MacOSで同じ操作性。サクラエディタを使ってて一番困ったのは、他のOSで全然動作しない、ということでした。MacOSを使っている時期に、Windowsエミュレーター上でがんばって動かしてたことはあったけど…。無理やり。
モダン
インテリセンス対応、シンタックスハイライト対応、gitへのアップロード対応など。つまりVisual Studio Codeについていけば、自然と最新を追っていける…?
将来性
MSが見てるので、いきなりぽしゃったり明後日の方向に行くことはないかな、と。dropboxやEvernoteなどの事例もあり、当初良くても数年後に斜陽になっている製品に乗るのが怖い今日この頃です。
今のところ実施した設定など
コマンドパレットをcmd.exeではなくpowershellで開きたい
Plane Text(.txt)で自分独自記法のハイライト表示
公式の方は基本的な文字列操作から書いてあるので覚えるまではここを参照。
powerpointのテンプレート名称が削除できない
マジどうでもいいバグなのですが。
powerpointファイルのプロパティに"テンプレート"という属性があります。ここにお客様名などを使用している資料を別のお客様に展開する場合、情報漏えい防止の観点でお客様名を消したいです。しかし結論としては消すことが出来ません。
削除方法
エクスプローラーからファイルを右クリックしてプロパティの削除から削除できるはずなのですが。
ファイルのプロパティ情報を削除する | 初心者のためのOffice講座
Windows10ではバグで削除できないそうです。
detail.chiebukuro.yahoo.co.jp www.makotoiwasaki.com
※ COM Surrogateの実体はdllhost.exeのようですが、殺してもすぐ復活します。
なお、mp3や動画ファイルなど非MS製のフリーソフトが存在するファイルは、そいつを使って無理やり属性を削除できるみたいです。ただpowerpointのフリーソフトなんて聞いたこと無い(LiberOfficeならいけるのか?)
悔しいので
Windows7(PowerPointインストール済み)でやったら削除できました。しかしながら、スライドマスター名だけは残ってしまいました。
結論
powerpointファイルを新規作成し、そこに内容を貼り付けたほうが早い気がしました。
MCP70-533を取得したのでメモ
こちらです。
Exam 70-533: Implementing Microsoft Azure Infrastructure Solutions
受かりましたので合格方法をメモします。
公式の動画とテキスト、問題を解く。
(MCP 70-533 対応) Microsoft Azure インフラストラクチャ ソリューションの実装 http://www.microsoftvirtualacademy.com/training-courses/mcp-70-533-microsoft-azure
(MCP 70-533 対応) Microsoft Azure インフラの実装 ～ Part 1 仮想マシン編 http://www.microsoftvirtualacademy.com/training-courses/mcp-70-533-microsoft-azure01
(MCP 70-533 対応) Microsoft Azure インフラの実装 ～ Part 2 Azure Active Directory の実装編 http://www.microsoftvirtualacademy.com/training-courses/mcp-70-533-microsoft-azure-part-2-azure-active-directory
上記動画の理解と、NextStepと称されるpdfの問題集に取り組みました。まーこれだけでいいんじゃないかな?
ぁゃιぃ問題集をやる
某所で入手した、問題の日本語訳と回答が怪しい問題集もやりました。
結論
結果的にはぁゃιぃ問題集あって楽できました。公式の動画と問題集で内容は網羅されているのでこれらを勉強し尽くせばよいのですが、問題集で4択の問題が本番では1つずつ順番を指定する方式に変わっていたりして、問題集の4択を覚えてしまっていると迷ってしまったりしたので。
公式動画は今から1年以上前のものであり、アフィニティグループやWebApp、ストレージのプランなど、今となっては古い内容も含まれた内容ですが、本番の試験ではそういった内容は出なかったように思えます。
僕は教科書読むより問題集で間違いだったものの理解を深めるやり方のほうが好きなので、動画を1回見た後は問題集を繰り返しやりました。正解を覚えるんじゃなく、なぜ正解の選択肢になるのか、なぜ間違いの選択肢は選べないのか、を1問ずつ自分の言葉で説明できるように取り組みました。結果、ぁゃιぃ問題集は「これ間違いやろ～」というのがいくつもあって、それは参考までに答えを覚えて本番で出たらその時考えよう作戦。
勉強時間は15時間ほどですが、仕事である程度下地があってのものなので、人によってはもうちょいかかるかも。ストレージからネットワーク、IaaS、SaaSまで幅広い知識が求めらたので、専門外の分野を全然知らない、だと辛そうです。個人的にはオンプレで一通りやった上に自分でWeb系の勉強していたので、問題集の内容に腹落ちする事が多く面白かったです。
Microsoftアカウントと組織アカウントの違いについて
MSのアカウント管理はややこしいなーと思うのでメモです。
AzureやらOffice365やらを使う時に「あなたのアカウントはMicrosoftアカウントですか?それとも組織アカウントですか?」と聞かれる。
Microsoftアカウントとは?
一般市民がGmailやYahoo!メールで登録できる、普通のアカウント。私的なアカウントというか。Googleで言うと、そのまんま"アカウント"となる。
組織アカウントとは?
Microsoftのクラウドサービスを利用している会社が発行するメールアドレスで、登録したアカウント。
例えば、株式会社TESTがOffice365を使用するとして、xxx@test.comというドメインでOffice365を利用したとする。この時、当然Microsoftは@test.comのドメインで登録されたメールアドレスはMicrosoftのサービスを利用しているということを知っている。なので、@test.comを持つメールアドレスは、組織アカウントとして登録する権利を持つ。
一方、@gmail.comや@yahoo.comというドメインのメールアドレスは、Microsoftの辞書にない。あるいは、Unixベースのメールシステムを使用している@oracle.comというドメインも(有名ではあるが)Microsoftの辞書にないため、組織アカウントとして登録することが出来ない(※1)
Microsoftが"組織アカウント"と"Microsoftアカウント"に分けている理由、もうちょい言えば"組織アカウント"なる定義を作っている理由だが、例えばMicrosoftのゴールドバートナーの会社に特典を付与する場合、その会社の組織アカウントでMSのサイトにアクセスする必要がある、などMicrosoftの管理上の問題といえる。つまりMSの都合。
使う側にとっては、必ずしも組織アカウントで登録する方がいい、とはいえず、Microsoftアカウントでしか出来ないようなアクションもある。とはいえ、MSのゴールドパートナークラスの会社なら、同じAzureを使うにしても組織アカウントで使っといたほうが何かといい(この会社の従業員はMSにお布施してくれてるな、というのが分かる)ような気がする。
ちなみに
- とある会社はMicrosoftのサービスを使っていない
- 従業員がその会社のメールアドレスをMicrosoftアカウントとして使用
- とある会社がMicrosoftのサービスを使用開始し、メールアドレスが組織アカウントして登録可能になる
このケースの場合、2で会社のメールアドレスをMicrosoftアカウントとして登録してしまった人はどうなるかというと、そのアカウントは一生Microsoftアカウントとなり、組織アカウントには登録できなくなる。それが私なのだが、救済策として、表示上はMicrosoftアカウントだが、特典などは組織アカウントと同等に受けられるようになる。
ややこしいのは、ドメイン自体は組織アカウントなので、「あなたのアカウントはMicrosoftアカウントですか?それとも組織アカウントですか?」と聞かれて組織アカウントを選択した場合、そもそもアカウント自体が存在しない扱いのため一生ログインできないというハメに合う。そのハメに合ったため、この記事を書いている。
自分用メモ
- イニシャル@xxx.com 組織アカウント。O365にログインして各種サービスを使えるのはこれ。
- イニシャル@xxx.co.jp Microsoftアカウントだが実質組織アカウントでいろんな権限が付与されている。パスワードは大文字7桁+1(どうやら同盟の組織アカウントも存在していることになるらしい?)
- 名.姓@xxx.com 1のエイリアスであるが、Azure利用上は1と違うアカウントになるぽくてよく分からない。Microsoftアカウントぽい。
- xxx@gmail.com クリーンなMicrosoftアカウント
※1 正確に言うと、AzureADにドメインを登録していれば、Microsoftに課金していなくても組織アカウントとして認められそうだが、ここらへんは試していないのでよくわかりません。
