ESXi上で、Windows 10 バージョン1703にFall Creators Updateを当てて1709にしたテンプレートから、新規仮想マシンへのデプロイではまった(その2)

その1

ESXi上で、Windows 10 バージョン1703にFall Creators Updateを当てて1709にしたテンプレートから、新規仮想マシンへのデプロイではまった(その1) - 苦労する日々

で、MiracastView アプリは消せたので、再度テンプレートにし新規仮想マシンへのデプロイを行ったが、C:\Windows\System32\Sysprep\Panther\setuperr.log にまたエラーが。

2017-11-DD HH:MM:SS, Error SYSPRP setupdigetclassdevs failed with error 0
2017-11-DD HH:MM:SS, Error SYSPRP Failed to remove staged package Microsoft.BingWeather_4.18.56.0_x64__8wekyb3d8bbwe: 0x80070002.
[gle=0x00000002]
2017-11-DD HH:MM:SS, Error SYSPRP Failed to remove apps for the current user: 0x80070002.

2017-11-DD HH:MM:SS, Error SYSPRP Exit code of RemoveAllApps thread was 0x2.
[gle=0x0000012a]
2017-11-DD HH:MM:SS, Error SYSPRP Failed to remove all apps: 0x80070002.
[gle=0x0000012a]

今度は、staged package になっている BingWeather アプリが原因らしい

再度テンプレートを仮想マシンに変換し、PowerShell(管理者) で Get-AppxPackage -alluser *BingWeather* で確認

Name : Microsoft.BingWeather
Publisher : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture : X64
ResourceId :
Version : 4.18.56.0
PackageFullName : Microsoft.BingWeather_4.18.56.0_x64__8wekyb3d8bbwe
InstallLocation :
IsFramework : False
PackageFamilyName : Microsoft.BingWeather_8wekyb3d8bbwe
PublisherId : 8wekyb3d8bbwe
PackageUserInformation : {S-1-5-18 [S-1-5-18]: Staged}
IsResourcePackage : False
IsBundle : False
IsDevelopmentMode : False
IsPartiallyStaged : False
SignatureKind : Store
Status : Ok

Name : Microsoft.BingWeather
Publisher : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture : X64
ResourceId :
Version : 4.21.2492.0
PackageFullName : Microsoft.BingWeather_4.21.2492.0_x64__8wekyb3d8bbwe
InstallLocation : C:\Program Files\WindowsApps\Microsoft.BingWeather_4.21.2492.0_x64__8wekyb3d8bbwe
IsFramework : False
PackageFamilyName : Microsoft.BingWeather_8wekyb3d8bbwe
PublisherId : 8wekyb3d8bbwe
PackageUserInformation : {S-1-5-18 [S-1-5-18]: Staged}
IsResourcePackage : False
IsBundle : False
IsDevelopmentMode : False
IsPartiallyStaged : False
SignatureKind : Store
Status : Ok

バージョン違いで2つ表示される。片方は、InstallLocation がない。

Get-AppxPackage -alluser *BingWeather* | Remove-AppxPackage

をやったところ、一つになった。

 

Get-AppxPackage -alluser | Sort-Object Name | Select Name,InstallLocation

をやったところ、他にもいくつか InstallLocation がなく、Name が重複しているものが。

Get-AppxPackage -alluser (重複アプリ) | Remove-AppxPackage

を行い、テンプレートに変換し、デプロイを行ったところ、無事マシン名も変更され、デプロイ完了した。

 

 

ESXi上で、Windows 10 バージョン1703にFall Creators Updateを当てて1709にしたテンプレートから、新規仮想マシンへのデプロイではまった(その1)

 ESXi 上の Windows 10 (1703)のテンプレートに Fall Creators Update を当てて Windows 10 1709のテンプレートにしたところ、Windows 10 1703 にした時と同じく、新規仮想マシンへのデプロイではまった。

 

状況は、1703へアップデートしたときの下記と同じ状況

ESXi上で、Windows 10 バージョン1703 ビルド15063 のテンプレートから、新規仮想マシンへのデプロイではまった - 苦労する日々

 

デプロイ後の C:\Windows\System32\Sysprep\Panther\setuperr.log のログを見たところ、

2017-11-DD HH:MM:SS, Error SYSPRP Package Windows.MiracastView_6.3.0.0_neutral_neutral_cw5n1h2txyewy was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.

2017-11-DD HH:MM:SS, Error SYSPRP Failed to remove apps for the current user: 0x80073cf2.

2017-11-DD HH:MM:SS, Error SYSPRP Exit code of RemoveAllApps thread was 0x3cf2.

と、MiracastView アプリが原因らしい。

しかし、デプロイ元のテンプレートの Windows 10 のメニューなどに MiracastView は見つからない。

PowerShell (管理者)で Get-AppxPackage -alluser *Mira* とすると存在はするので、

Get-AppxPackage -alluser *Mira* | Remove-AppxPackage しても消えない。

 

さまざま、調べたところ、C:\Windows\MiracastView がないのが原因らしい。

C:\Windows.old\Windows\MiracastView\ を C:\Windows\MiracastView にコピー

で、

PowerShell (管理者)で Get-AppxPackage *Mira* | Remove-AppxPackage したところ、

消えた!!!

 

しかし・・(その2へ続く)

 

ESXi上のVMで、Windows 8.1からWindows 10へのアップグレード途中固まる

ESXi上のVMで、Windows 8.1からWindows 10へのアップグレードを行った。
しかし、下記のところで、PCがフリーズ。

・ダウンロード等
・ライセンス規約に同意
・インストールに必要な作業を確認・・・
・PCに十分な容量があるか確認・・・
・引き継ぐものを設定
 (個人用ファイルとアプリを引き継ぐ」
・「インストール」
Windows 10 をインストールしていますの画面
・再起動
<= ここで固まる

VM なので、ESXi 上の該当VMのパフォーマンスを見ると
CPU使用率が50%張り付き(2CPUを割り当てているので、1CPUを100%使用)

夕方から翌日までほっておいたが、状況変化なし。

再起動すると、Windows 8 が立ち上がり、以下のメッセージが表示された。

---
0xC1900101 - 0x20017
BOOT 操作中にエラーが発生したため、インストールはSAFE_OS フェーズで失敗しました。
---

上記エラーコードなどで、いろいろ調べたが、状況変化なし。


下記URLと同じような状況。
http://mikado.at.webry.info/201508/article_1.html

そこで、ふと気づいたのが、自分の下記記事。
http://shaggyman.hatenablog.jp/entry/2017/04/13/141923

確認したところ「仮想マシンのバージョン:9」「ゲストOSの設定:Windows 8」・・・

仮想マシンのバージョン:11」「ゲストOSの設定:Windows 10」にしたところ、無事再起動で、インストールが続行され、無事Windows 10 になりましたとさ。

ESXi上で、Windows 10 バージョン1703 ビルド15063 のテンプレートから、新規仮想マシンへのデプロイではまった

私の管理している環境では、ESXi上で、テンプレートから新規仮想マシンへデプロイを多用している。

 

今回、Windows 10 の Creators Update で、新しく、Windows 10 バージョン1703 ビルド15063 のテンプレートを作ったところ、

この新しいテンプレートから、新規仮想マシンへのデプロイではまった。

 

デプロイ時の「新規仮想マシンのゲストOSのカスタマイズ」で、コンピュータ名を指定しているのだが、なぜかいつまで経っても、指定したコンピュータ名に変更されない。(vCenterServerにも 「カスタマイズの開始イベント」はあるが、「カスタマイズ成功イベント」は来ない)

 

状況をいろいろ調査したところ、

VMware Tools が古いとNG => 更新済み

・vCenter Server Appliance が古い => 6.0U3b に更新したが、現象変わらず

 

最終的にゲストOS内で、Sysprep で失敗していることがわかった。

で、デプロイ後のゲストOS内の下記のパスのエラーログを参照した。

C:\Windows\System32\Sysprep\Panther\setuperr.log

 

すると、Facebook・LINE・BingNews・Netflixなどのアプリがあることでエラーとなっているようだった。

テンプレートから該当アプリを削除すると、無事成功した。

 

17:45 追記

下記の注意事項に該当してた・・・

blogs.technet.microsoft.com

ESXi上のVMのWindows 10のCreators Updateの再起動で止まる

タイトル通り、ESXi上のVMのWindows10Proで、Creators Updateを手動で行ったところ、再起動で固まり、それ以降すすまない。

VMを電源オフし、起動するとWindows10は起動するが、バージョン1607のまま。

 

ネットワークドライブを外すなどいろいろ試した。

 

結果、仮想マシンのゲストOSの設定が「Windows 8」になっていたので、

仮想マシンのバージョンを 9から11へ変更し「Windows 10」に変えたところ、

再起動から先に進むようになった。

 

.htaccess Redirect で知らなかったこと

.htaccess Redirect で2点知らなかったことがあった

 

●1 日本語を含む場合は、転送元は日本語で .htaccess に記述する必要がある(.htaccessUTF-8 BOMなし)

例:

http://www.example.jp/転送元  -> http://www.example.jp/転送先

Redirect permanent /転送元 http://www.example.jp/%E8%BB%A2%E9%80%81%E5%85%88

 

●2 301リダイレクトは、ブラウザでキャッシュされる

1点目の確認をする最中に、気づいた

 

上記2点を知らなかったために、設定作成に時間がかかってしまった・・・

NETGEAR ReadyNAS 102 故障

昨年使い始めたNETGEAR ReadyNAS 102が故障。

 

NETGEAR ReadyNAS 102(ファームウェア 6.3.5と記憶) と iscsi でつないでいた サーバが停止

同様に、ReadyNAS 102 と iscsi でつないでいたESXiの一つのドライブも参照できなくなっていた。

 

いろいろ調べたがReadyNAS 102のハード故障らしい。

なので、たまたまあった別の ReadyNAS 102 にHDDを移動。

 

しかし、iscsi 用のLUN3つのうち、1つが完全に消えていた・・・(はぁ)

他の二つは正常に参照できた。

 

ReadyNAS 102の設定のバックアップがないし、復旧方法もわからず、このLUNの中のデータはあきらめ。(2日前のフルバックアップがあるVMと、削除予定VMだけだった。)

 

現在このハード自体は捨てられてしまっていたので、原因等は結局わからず。