kkamegawa's weblog

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

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管理サイトを削除してください。

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のフェイルオーバーも設定しようかな。

Windows Server 2016 Insider 16257のWindows Subsystem for Linuxを試す

待っていた、Windows Subsystem for Linux(WSL)をサポートしたWindows Server 2016 Insider 16275が公開されました(サポートそのものは16237かららしい)。

blogs.windows.com

Announcing Windows Server Insider Preview Build 16257 - Windows Experience Blog

実機に入れてみたので、簡単に試してみましょう。

WSLを追加

f:id:kkamegawa:20170810171747p:plain

PowerShellのコマンドレット、Enable-WindowsOptionalFeatureを使って有効にします。その前にGet-WindowsOptionalFeatureで入っているかどうか確認してみます。StateプロパティがDisabledなので、入っていませんね。

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

再起動するとインストール完了です。

Ubuntuを追加

f:id:kkamegawa:20170810171550p:plain

Windows 10 Insider 16257ではストアからダウンロードしますが、現在のWindows Server InsderではWebからとってきます。Ubuntuを入れていますが、OpenSUSEとSLESにも対応しています。PowerShellのInvoke-WebRequestコマンドレットでとってきます。

Invoke-WebRequest -Uri https://aka.ms/wsl-ubuntu-1604 -OutFile ~/Ubuntu.zip -UseBasicParsing

OpenSUSEの場合

Invoke-WebRequest -Uri https://aka.ms/wsl-opensuse-42 -OutFile ~/opensuse.zip -UseBasicParsing

SLESの場合

Invoke-WebRequest -Uri https://aka.ms/wsl-sles-12 -OutFile ~/sles.zip -UseBasicParsing

ここからはUbuntuで説明します。

f:id:kkamegawa:20170810171555p:plain

Expand-Archiveコマンドレットでzipを展開します。%USERPROFILE%直下に展開していますが、好きなところで構わないはずです。Windows 10の場合、%LocalAppData%\LxSSでした。

zipファイルを展開すると、こんな感じです。ubuntu.exeを実行すると、インストールが始まります。

f:id:kkamegawa:20170810171800p:plain

最初にUbuntu用のユーザーを作ります。これはWindows 10と同様に、Windowsのユーザーとは別管理です。

f:id:kkamegawa:20170810185210p:plain

インストール後、aptコマンドで更新しておきましょう。これでインストール終わりです。プログレスバーが乱れているのはリモート接続だからか、Insiderだからか…まぁいいでしょう。

f:id:kkamegawa:20170810171755p:plain

Ubuntuが入っています。

使ってみる

f:id:kkamegawa:20170810173524p:plain

Windows 10と同様に、Windows側のパスもWSLのパスとして登録されていますね。Windows 10と同様に、dirコマンドの結果をパイプでWSL側のgrepに渡せます。もちろん、そのままgrepと実行しても起動できないので、注意してください。

f:id:kkamegawa:20170810185142p:plain

ちなみに、bash.exeを実行した場合、ubuntu.exeを経由せず実行できます。複数のLinux環境入れた場合、どれが優先されるんでしょうね?

消した場合

f:id:kkamegawa:20170810171751p:plain

Enable-WindowsOptionalFeatureで追加できますが、Disable-WindowsOptionalFeatureでWSLを消すこともできます。Linuxモジュールは別管理のようで、Disable-WindowsOptionalFeatureで消した後、ubuntu.exeを実行すると、こんなエラーになります。

もちろん、再度Enable-WindowsOptinalFeatureでWSLを追加すると、ユーザー環境などはそのまま引き続き使用できます。確認してないですが、lxssコマンドもありました。

今後

とりあえずdocker入れたので、WSL側のdockerからWindowsのDockerコンテナ動くかとか、VSTS/TFSのビルドエージェント経由でWSLがどうやって動かせばいいのかとか、試してみたいと思います!

Azure Active Directory Domain ServicesでTFSを使ってみる

Azure Active Directory Domain Servicesができたときからぜひ使ってみたいと思っていました。フルマネージドなので、AD特有の面倒なことが解消されそうです。

azure.microsoft.com

ただ、いろいろ問題もあります。

  • 高い。裏で4台くらいのサーバーを動かしているので、しょうがないのですが、もうちょっとお安くならないものかと…。
  • 全部の機能が使えない。例えば、Domain AdminやEnterprise Adminといった権限はないので、Kerberos認証に必要なsetspnが使えません。これは回避策があります(後述)。
  • 現在、クラッシックデプロイしかサポートされていないので、ARMベースのデプロイする仮想マシンとつなぐ場合VPNが必須。

田中さんもかかれているので、こちらもどうぞ。

tech.tanaka733.net

作ってみる

f:id:kkamegawa:20170727063925p:plain

Azureポータルから、Azure AD Domain Servicesを検索して作っていきます。

f:id:kkamegawa:20170727063921p:plain

ディレクトリは初期値では「既定のディレクトリ」しかないので、選択できません。カスタムドメイン(exsample.jpなど)を作りたい場合は、クラッシックポータルからドメインを作っておきましょう。既定のディレクトリは~.onmicrosoft.comが作られています。

このonmicrosoft.comの前のドメイン名はクラッシックポータルでは変更できるように見えるのですが、変更してもユーザー追加のところで追加できないので、変えないでおきましょう。そのまま。

リソースグループやら、場所を選択します。

f:id:kkamegawa:20170727063914p:plain

ネットワークに仮想ネットワークとアドレス空間、サブネットを指定します。DNSで二つとられるし、なに使うかわからないので、どーんととっておきます。ここでは/22を指定しています。クラッシックポータルで作るときは/22位がデフォルトだったはずですが、新ポータルでは/24がデフォルトです。

サブネットは/24を指定しています。

f:id:kkamegawa:20170727063911p:plain

これでOK押して確定。

f:id:kkamegawa:20170727064222p:plain

AAD DC Administratorsというグループがいわゆるドメイン管理者(正確にはもっとロックダウンされていますが)になります。とりあえずここでサブスクリプションの管理者を追加しておきます。

f:id:kkamegawa:20170727064218p:plain

で、これで全部できました。OKを押すとデプロイが始まります。Azure AD Domain ServicesはVPNと仮想マシンを結構いっぱいデプロイするので、実際に使用できるまでにかなり時間がかかります。30分くらいは見ておいたほうがいいです。

f:id:kkamegawa:20170727063932p:plain

その間、クラッシックポータルでユーザーを追加しておきます。TFSをActive Directoryで使う場合、AP層のユーザー、SQL Server Reporting(もうほとんどいらなくなりましたが)のユーザー、SQL Server用のユーザーあたりはあったほうがいいです。作っておきましょう。

ここで追加したユーザーはドメイン内の一般ユーザーになります。username@~.onmicrosoft.comでログオンできるユーザーですね。

VPNピアリング

f:id:kkamegawa:20170728054941p:plain

クラッシック仮想マシンなら必要はないのですが、もう今どきクラッシック使いたくないですよね。Azureの新機能の恩恵もうけれないし。ということでVPNピアリングを設定します。

注意点としてはIPアドレス空間が重ならないように、ということくらいです。

docs.microsoft.com

Kerberos の制約付き委任を構成する

docs.microsoft.com

setspnが使えないので、こちらの方法でKerberosの制約付き委任を構成します。

完成

これで一通りできました。あとは普通にWindows Serverを構成して、仮想ネットワークだけ明示的に既存のものを指定するだけです。

Windows Serverのドメイン参加はAAD DC Adminグループに追加した@~.onmicrosoft.comユーザーで実施します。ドメインに参加した後、Windows Serverのドメインログオンは username@~.onmicrosoft.comでできます。