kkamegawa's weblog

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

Devblogラジオ第三回 - CosmosDB編

devblog.connpass.com

毎回毎回トラブルが続いてすいません。今回はYouTubeの仕様変更に伴い、「既存のライブからコピーして作ると同じセッションキーを再利用されてしまって、本番のライブ配信が始まってしまうというね…直前でURL変わってしまってすいませんでした。反省。

そしてさらにライブでは私のマイクだけ電動コイルに巻いたような音声になっていたそうです。ちなみに私に聞こえるのもそうだったので、相手側の問題だと思っていました。考えられる原因としてはこの辺でしょうか。

  1. Surface Headphonesが配信用とメインPC両方ペアリングしていたから(もう配信用からは外した)
  2. 配信用PC(Teams)に入っていたアカウントのマイクミュートを忘れていた。途中で気づいたけど、これでミュートしてほかの人の音声が切れたらと思うと怖かったので、続行(Windowsのミキサーでのマイクミュートはしていた)。
  3. 配信用Teamsと画面共有用のPCをそれぞれ別アカウント使って入っていた。
  4. 帯域不足(でもそれなら画像のほうが先にアウトになりそうな)。画像切ってみても変わらず。

画面をほかの人に取ってもらうと少しましになった気がします。私の音声にエコーバック入っていたのはたぶん2が原因かなと。配信は難しいですね…。CosmosDBは個人的にはそんなに使えていないので、どうなるかと思ったんですが、松村さんや足利さんがいろいろ経験を騙ってくれて助かりました。複数人の雑談はこういうところがいいですね。

次回は大物ゲストを呼んだ四人で .NET 5とリリースされるだろうVisual Studio 2019 16.8についてフリートークをやる予定です。お楽しみに!


devblogラジオ vol.3

WSUSインストール後の構成に失敗する問題と対処

手元で運用しているオンプレミスのWindows Server 2016を2019へインプレースアップグレードしてみました。新規構築とどちらがいいのかは悩ましいところだと思います。個人的に言えばあんまりやるべきではないかと思います。

私が入れていたのはWSUS, SQL Server 2016(Azure DevOps用), Hyper-Vとファイル共有くらいなので、一から構築してもよかったのですが、性懲りもなく前回の2012R2から2016に移行したときと同じ二回目の轍を踏んでみました。事前作業としてはこのくらい。

  • Hyper-VのVMをシャットダウンしておく(DCが動いているので、起動もしないようにしておく)
  • DC一台でも使えるようにしておく(DNSとDHCPだけですが)

後は数時間お待ちするだけ。結局10時間以上待ってました。

終わった後はいろいろ再チェック。困ったのがWSUSの再構成。WSUSコンソールが使えなくなっていました。具体的にはコンソールから接続してもすぐ切れる。機能を削除、追加を繰り返してようやく原因判明。

Default Web Siteを作り直す

2020-11-03 15:15:48  Starting service W3SVC
2020-11-03 15:15:48  Configuring IIS...
2020-11-03 15:15:48  Start: ConfigureWebsite
2020-11-03 15:15:48  System.Runtime.InteropServices.COMException (0x80070003): 指定されたパスが見つかりません。

アップグレードで 既定のWebサイトが消えているので、作り直します。

  1. IIS 管理コンソール
  2. Default Web Siteという名前で作る
  3. DefaultAppPoolを選択する
  4. パスを適当に(デフォルトはc:\inetpub\wwwroot)設定する
  5. バインディングを設定する
    1. プロトコルhttp
    2. ポート80
    3. IPアドレス:すべて

これでIISを再起動するとこのエラーはなくなりますが、まだエラーは続きます。

同期に失敗する

Importing ClientServicingApiDetectoid.xml...
Importing default detectoids succeeded.
Synchronization in progress. Please cancel synchronization and rerun postinstall again. Exception: System.Net.WebException: HTTP ステータス 503: Service Unavailable で要求が失敗しました。
   場所 System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   場所 System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   場所 Microsoft.UpdateServices.Internal.ApiRemoting.GetServerVersion()
   場所 Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccessProxy.GetServerVersion()
   場所 Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.CreateUpdateServer(String serverName, Boolean useSecureConnection, Int32 portNumber)
   場所 Microsoft.UpdateServices.Internal.BaseApi.UpdateServer..ctor(Boolean bypassApiRemoting)
   場所 Microsoft.UpdateServices.Setup.StartServer.StartServer.FixSubscriptionCategories()
2020-11-03 16:24:06  StartServer encountered errors. Exception=Synchronization in progress. Please cancel synchronization and run postinstall again.
2020-11-03 16:24:06  Microsoft.UpdateServices.Administration.CommandException: WSUS サービスを開始および構成できませんでした
   場所 Microsoft.UpdateServices.Administration.PostInstall.Run()
   場所 Microsoft.UpdateServices.Administration.PostInstall.Execute(String[] arguments)

なやんだのですが、これはWSUSの同期ログがアップグレードに伴い、古い形式と互換性がなくなったためのようです。同様の理由か知りませんが、Azure Backupやイベントビューアのログもきれいになくなります。

USE SUSDB
GO
DELETE FROM tbEventInstance WHERE EventNamespaceID = '2' AND EVENTID IN ('381', '382', '384', '386', '387', '389')

SSMSで上記のSQLを実行してください。たぶんこれで大丈夫のはずです。

参考:
docs.microsoft.com

WSUS管理サイトを削除する(追記)

一つ忘れていました。WSUSの後処理でIISにあるWSUS管理というサイトを追加するのですが、これが残っていると後処理に失敗します。アップグレードの後、再構成するときは、必ずIISからWSUS管理サイトを削除してください。

Azure DevOps 2020/10/21の更新

遅くなりましたが、Azure DevOps Sprint 177のリリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

docs.microsoft.com

Azure Boardsの隠されたルールの一つがなくなったそうです。具体的にはAglieプロセスにおいて、Bugカテゴリーの作業項目をResolvedにすると、Assignedフィールドの値がCreated by(つまりBugを作った人)の値に巻き戻っていたそうです。おそらくこれはBugを登録した人がResolved状態になったら最後に責任をもって確認して、Closedに移行するべき、という考えに基づいていたのではないかなと思います。

最初のころはこれでよかったのですが、現代では開発プロセスが成熟して、もうそういうおせっかいをしなくてもよくなったのではないか、ということのようですね。これはこれで便利なルールなので、Aglieプロセスで引き続き使いたい人は継承して、同じ動きをするルールを登録してください、ということのようです。

Pull RequestのUIがこまごまと変更されています。地味だけど不便だった点なのでありがたいですね。

Azure PipelinesのUbuntu-latest20.04に移行するそうです(GitHub Actionsも同じ)。18.04に依存している環境はlatestから明示的に18.04書き直してください。

また、エージェントで実行されるタスクで使われるnode.jsのバージョンが6から14になる…はずでしたが、Red Hat Enterprise Linux 6はnode 14に非互換がある(というかまだサポートしていない?)そうなので、node 10に移行することになったそうです。おそらくこの辺の話ですかね。

access.redhat.com

ではまた三週間後。

Translate to Japanese to Azure DevOps release not…

Azure DevOpsの通知メールを振り分け可能にカスタマイズする

Azure DevOpsからの通知メールはカスタマイズできない(要望は出ているのですが)ので、通知メールの振り分けに困るという相談は度々出ていました。配布リストを一人のために作るのもあれだし、困るなぁと思っていました。gmailであればローカルパートに+で識別子をつけれるけど、gmail前提でもないしと思っていたら、Exchange Onlineがgmailと同じ仕様の + で連結するローカルパートをサポートしてくれることになりました。

techcommunity.microsoft.com

これを使えば一つのメールアドレスで振り分けルールが比較的自由に作れます。ちょっとやってみましょう。ExchangeのPowerShellモジュールを追加しておきます。次に、PowerShellでExchange Onlineに接続して、Set-OrganizationConfigで変更します。

Connect-ExchangeOnline -UserPrincipalName 管理者のID  
Set-OrganizationConfig  -AllowPlusAddressInRecipients $true

Get-OrganizationConfigで設定を確認します。

AllowPlusAddressInRecipients : True

こうなっていればOKです。Exchange Onlineから切断します。

Disconnect-ExchangeOnline

即時反映されているはずです(多分)。次にAzure DevOps側の設定を行います。

f:id:kkamegawa:20201029153438p:plain

User settings(https://dev.azure.com/{organization}/_usersSettings/notifications)を開いて、チームプロジェクト単位で通知を設定します。たとえば、SessionDemoというプロジェクトであれば、メールアドレスのローカルパートをkkamegawa+SessionDemoという形式にします。

f:id:kkamegawa:20201029153430p:plain

Outlookの振り分けルールで+付きのメールアドレスで指定フォルダーに振り分けます。もちろんラベルなどでもいいでしょう。

f:id:kkamegawa:20201029153434p:plain

今回はビルドの通知だけいじりましたが、ビルド完了通知が正しく振り分けられていますね!本来はTeamsとかSlackへのポストがいいんでしょうけど、使えないこともあると思います。

全部の設定を変更するの大変かもしれないですが、REST APIで登録できたはずなので、その辺りグローバルルールを全部無効にして、こういうルールを追加していけば振り分けも楽になるかもしれません。

docs.microsoft.com