kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

Azure DevOpsの拡張機能で必要な権限が変わるとき

ちょうどいいネタができたので、Azure DevOpsアドベントカレンダー3日目の記事です。

qiita.com

今日、こんなメールが届きました。

f:id:kkamegawa:20191203212436p:plain

私はAzure DevOpsにDependency Trackerという拡張機能を入れているのですが、なにやらやらないといけないようです。Manage extensionをクリックすると、拡張機能管理画面に移動します。

f:id:kkamegawa:20191203212440p:plain

メッセージを読むと、バージョンアップに伴い、新しい権限が必要なようなので、Reviewボタンをクリックします。

f:id:kkamegawa:20191203212446p:plain

必要な権限が表示されます。おそらくAnalytics(read)が新規に必要になったのでしょう。Authorizeをクリックして承認します。

f:id:kkamegawa:20191203212431p:plain

承認すると、拡張機能が再度使えるようになったというメールが来ます。

なかなかこういうメールが来たことがなかったので、ちょっとびっくりしましたが、拡張機能の権限を確認の上、問題なければ承認すればいいだけなので、簡単です。

もちろん、理不尽な権限を要求するような拡張機能になったら削除してしまいましょう。

Azure DevOps 2019/11/4の更新

微妙にまとまった時間が取れず、ものすごく開いてしまいました。来週にはたぶんSprint 161がリリースされようというくらいですが、Sprint 160リリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

docs.microsoft.com

今回もPipelinesの機能が多いですね。YAMLベースの承認、ACRサポートの強化、cron形式で実行スケジュールを設定した場合、何時動くのかプレビューできるようになった(これマジ助かる)、サービス接続のセキュリティをプロジェクトレベルに限定、などなど。

Wikiのプレビューと編集画面の同時スクロールオンオフ切り替えもうれしいところ。

USはもう感謝祭→年末モードになってしまうので、もしかしたらSprint 161が出たら今年は終わりかもしれないですね。去年も12月に一度出しているので、今年はスケジュールの都合上Sprint 162まであるかもしれませんが。ではまた三週間後。

Translate to Japanese to Azure DevOps release note ...

わんくま大阪でAzure DevOpsとIDとセキュリティ管理についてお話してきました

以前Azure DevOpsとセキュリティという形でお話したのですが、今回はもうちょっとAzure ADに振った話にしてみました。これしゃべるためにAzure AD P2(正確にはEnterprise Mobility E5)買ってみました。やっぱりあると便利ですね。

実はこれ、もうちょっと先にあるイベントの練習というか、45分でどれだけしゃべれるかなということを知るためにこの分量にしてみたんですが、やっぱりちょっと多いですね。最後のオンプレミス版Azure DevOps Serverの内容は時間が足りなかったときのおまけとして用意していたんですが、入れていると時間が足りなかった。

話していて、いくつかアイディアは浮かんだので、構成は少し変えるのですが、中身はおおむねこんな感じでやる予定です。

Windows Server 2012 R2からWindows Server 2019へアップグレードした

そろそろサポートが終わるのはWindows Server 2008 R2ですが、手元のWindows Server 2012 R2も延長サポートということでWindows Server 2019にアップグレードしました。

最初に書いておきますが、サーバーOSでインプレースアップグレード(OSアップグレード)はやるもんじゃないです。毎回そう思うんですが、個人の環境だしいいかなということで。

世界的にもどっちがいいかいろいろ意見はあるようです。

実施前の注意点

アップグレードできる環境かどうか確認します。インストールしているソフトウェアがWindows Server 2019で使えるとは限りません。有名どころであれば互換チェックで弾かれますが、有名ではないものは引っかからないかもしれません。

私の場合はSQL Server 2012をアンインストールしました。

アップグレードのエディションも同じでないとインストール設定が引き継がれませんが、デスクトップエクスペリエンス入れていないServer Coreの2012 R2をアップグレードしようとしたら、引き継げなくてちょっと困りました(で、まだやってない)。

アップグレード前にHyper-VのVM動いていたら止めろと言われますが、個人的なおすすめはHyper-Vの役割を削除しておくことです。

いつもそうですが、OSアップグレード後、大抵仮想スイッチが変わってしまう(今回はプライベートに変わってました)ことが多く、一度削除しないといけないことが多いです。

スイッチ作り直したあと、VMのIP設定しなおしになります。今回はVMがDCだったのでちょっと大変でした。

アップグレード時間

Core i3-2100Tという少々古いCPUとHDDという環境でアップグレードしたところ、大体7時間くらいかかったようです。インストールしているものにもよりますが、こんなにかかるなら一からやってもいいですね。

今のWindows Serverインストールはわりと早いので、OSだけなら30分かそこらで終わります。

アップグレード後のトラブル

いくつかありました。今遭遇してるのはこのくらい。

  • リモートデスクトップ接続の設定は残っていたが、Firewallで3389が塞がれていた。
  • 設定でトラブルシューティングツールをクリックしても、動かない。
  • Hyper-Vの仮想ネットワーク作り直し(書いた通り)

設定アプリ内の機能が動かないのはちょっと困るので、ちゃんと調べようと思います。おそらくローカルセキュリティポリシーで適切に権限がついていないだけだと思うので、新規でインストールした環境と見比べてみます。

アップグレードできない環境

Windows Server 2012 R2全廃のためにServer Coreで動かしているDCもアップグレードしようとしたら、インプレースアップグレードできませんでした。

まぁDC/DHCP/DNSしか構成していないので、新しいVM作ってそちらで新規構築することにします。いい機会なので、DHCPのフェイルオーバーも設定しようかな。