Linux and FreeBSD Virtual Machines on Hyper-V のリストが最近、更新されていました。前回更新からの変更差分はこちら...
2016/01/30
2016/01/28
System Center 2012 R2 UR9
3ヶ月?に一度、恒例の System Center 2012 R2 の Update Rollup (UR) 9 出ました。
Description of Update Rollup 9 for System Center 2012 R2
[URL] https://support.microsoft.com/en-us/kb/3129757
System Center 2012 R2 修正プログラム最新版 (Update Rollup 9) がリリースされました!! (Japan Sytem Center Support Team Blog)
[URL] http://blogs.technet.com/b/systemcenterjp/archive/2016/01/28/3659656.aspx
Data Protection Manager で気になってた (見て見ぬふりをしていた)、Hyper-V 仮想マシンの Offline または Online タグ が UR9 で削除され、すっきり。
仮想マシンに付く Offline と Online タグはもともと、オンライン バックアップ中に仮想マシンが停止状態になるか、無停止かを示すものでしたが、いろいろと仕様が変更になっていて Offline でも無停止でバックアップできるものがあり、実体を示していませんでした。
Description of Update Rollup 9 for System Center 2012 R2
[URL] https://support.microsoft.com/en-us/kb/3129757
System Center 2012 R2 修正プログラム最新版 (Update Rollup 9) がリリースされました!! (Japan Sytem Center Support Team Blog)
[URL] http://blogs.technet.com/b/systemcenterjp/archive/2016/01/28/3659656.aspx
Data Protection Manager で気になってた (見て見ぬふりをしていた)、Hyper-V 仮想マシンの Offline または Online タグ が UR9 で削除され、すっきり。
仮想マシンに付く Offline と Online タグはもともと、オンライン バックアップ中に仮想マシンが停止状態になるか、無停止かを示すものでしたが、いろいろと仕様が変更になっていて Offline でも無停止でバックアップできるものがあり、実体を示していませんでした。
Removing the Offline/Online tag from Hyper-V VM name in the DPM UI
DPM used to display an Offline/Online tag to the VM name for Hyper-V VMs. This was intended was to notify users about whether the VM was paused during backup or was always online. However, this behavior was confusing for the customers because the tag was static and it was determined during first inquiry and not updated later. Moreover, for Hyper-V 2012 R2, the VMs will never be interrupted during backups as per the Hyper-V changes mentioned here.
The Offline/Online tag has been removed, and we now display only the Hyper-V VM name. This behavior applies to all existing PGs as well as to new PGs.
Update Rollup 9 for System Center 2012 R2 Data Protection Manager (https://support.microsoft.com/en-us/kb/3112306)
メモ: Hyper-V の 1601 年問題について
Windows Server 2012 R2 Hyper-V、Microsoft Hyper-V Server 2012 R2、Windows 8.1 Hyper-
V の仮想マシンで作成日が 1601/01/01 9:00:00 (9:00 の部分はタイムゾーンによる) になるという問題。
Hyper-V 2012 R2 Virtual machine creation date resets to 01/01/1601 after host reboot
[URL] https://social.technet.microsoft.com/Forums/en-US/d2679da3-dd59-424c-b8b7-03ce6325c8b8/hyperv-2012-r2-virtual-machine-creation-date-resets-to-01011601-after-host-reboot?forum=winserverhyperv
この既知のバグ、ずっと放置されたままでしたが...
Windows Server 2012 R2 Hyper-V にて仮想マシン作成日が "1601/01/01 9:00:00" と表示される
[URL] http://blogs.technet.com/b/askcorejp/archive/2016/01/26/windows-server-2012-r2-hyper-v-quot-1601-01-01-9-00-00-quot.aspx
関連:
Windows Server Technical Preview の評価日記 (その13): Windows 10 Build 9926 の Hyper-V vNext (2015/01/27)
V の仮想マシンで作成日が 1601/01/01 9:00:00 (9:00 の部分はタイムゾーンによる) になるという問題。
Hyper-V 2012 R2 Virtual machine creation date resets to 01/01/1601 after host reboot
[URL] https://social.technet.microsoft.com/Forums/en-US/d2679da3-dd59-424c-b8b7-03ce6325c8b8/hyperv-2012-r2-virtual-machine-creation-date-resets-to-01011601-after-host-reboot?forum=winserverhyperv
Yes, there's a known bugWin32 FILESYSTEM 構造体 (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724284(v=vs.85).aspx) は、1601/01/01 UTC からの100 ns 値で日時を表現しているそうなので、仮想マシンの作成日が 0 または Null を返すバグなんでしょうね。UTC 1601/01/01 0:00:00 は、JST 1601/01/01 9:00:00 ですから。
この既知のバグ、ずっと放置されたままでしたが...
Windows Server 2012 R2 Hyper-V にて仮想マシン作成日が "1601/01/01 9:00:00" と表示される
[URL] http://blogs.technet.com/b/askcorejp/archive/2016/01/26/windows-server-2012-r2-hyper-v-quot-1601-01-01-9-00-00-quot.aspx
この事象は Windows Server 2012 R2 でのみ発生し、Windows Server 2012、Windows 10 では発生いたしません。本事象については弊社開発部門にて製品の不具合として認められておりますが、仮想マシンの業務サービスや Hyper-V の運用操作等に影響を与えないことから、現時点で修正の予定はありません。だそうです。結局、放置されるみたい。"Windows Server 2012 R2 のみ"となってますが、Windows 8.1 Hyper-V でも発生します。
関連:
Windows Server Technical Preview の評価日記 (その13): Windows 10 Build 9926 の Hyper-V vNext (2015/01/27)
2016/01/22
メモ: RDP 接続でカーソルを点滅させたい
いままで気にしてなかった(気付かなかった)んですが、リモート デスクトップ接続のセッションや RemoteApp プログラムでは、カーソルが点滅しません。
RDP の設定 (.rdp ファイル) には disable cursor setting:i:0 という設定があり、0 (点滅有効、既定) と 1 (点滅無効) で調整できるようなのですが、これが利かない。
追記) 以下の仕様変更とは関係なく、そもそも disable cursor setting:0|1 はカーソル点滅には影響しない設定かもです。
どうやら、RDP 接続のセッションで画面の更新を減らすために、Windows Server 2003 からサーバー側で無効化されているらしい。なつかしのハイパーターミナルに関する情報に、そう書いていました。
ハイパーターミナルのトラブルシューティング > リモート デスクトップ接続でハイパーターミナルを使用している場合に、カーソルが点滅しません。
[URL] https://msdn.microsoft.com/ja-jp/library/cc786584(v=ws.10).aspx#BKMK_11
“解決方法: ありません” となっていますが、解決方法はありました。
追記) 以下の仕様変更とは関係なく、そもそも disable cursor setting:0|1 はカーソル点滅には影響しない設定かもです。
どうやら、RDP 接続のセッションで画面の更新を減らすために、Windows Server 2003 からサーバー側で無効化されているらしい。なつかしのハイパーターミナルに関する情報に、そう書いていました。
ハイパーターミナルのトラブルシューティング > リモート デスクトップ接続でハイパーターミナルを使用している場合に、カーソルが点滅しません。
[URL] https://msdn.microsoft.com/ja-jp/library/cc786584(v=ws.10).aspx#BKMK_11
原因 : リモート デスクトップ接続でハイパーターミナルを使用している場合には、カーソル点滅オプションは使用できません。これは、リモート デスクトップ セッションでの画面の更新を減らすためです。
解決方法 : ありません。
“解決方法: ありません” となっていますが、解決方法はありました。
2016/01/15
メモ: Windows 7 のワーク フォルダーの同期設定を引き継ぐ更新
ワーク フォルダーを利用している企業には、なにげに重要な更新。
Update for Work Folders improvements in Windows 7 SP1
[URL] https://support.microsoft.com/en-us/kb/3081954
Update for Work Folders improvements in Windows 7 SP1
[URL] https://support.microsoft.com/en-us/kb/3081954
2016/01/14
1/13 以降、Visual C++ 2012 Update 4 の更新 KB3119142 が繰り返される問題 (解決)
我が家の Windows 7 x64 PC の 1 台で、「Microsoft Visual C++ 2012 Update 4 再配布可能パッケージの更新プログラム (KB3119142)」が、インストールしても繰り返し検出されるように。
更新履歴を見ると、すべて「成功」。でも、また Windows Update に出てくる。
更新履歴を見ると、すべて「成功」。でも、また Windows Update に出てくる。
2016/01/13
今日の Office 2016 Update
本日は、2016 年初の、恒例の Windows Update の日 (水曜だけど Patch Tuesday) ですが、クイック実行 (Click to Run: C2R) 版の Office 2016 にもアップデートがきてます。
Office 365 client update branch releases
[URL] https://technet.microsoft.com/en-us/office/mt465751 (英語)
[URL] https://technet.microsoft.com/ja-jp/office/mt465751 (日本語)
クイック実行 (C2R) 版の Office 2016 (2013 も) は、Windows Update では更新されず、Office 組み込みの自動更新機能で更新されるのでご注意ください。ファイル → アカウント → 更新オプション → 今すぐ更新 で手動更新を開始できます。
各更新ブランチの、本日時点の最新バージョンは以下のとおり。
Current Branch (CB)
→ January 12, 2016 Version: 16.0.6366.2056
Current Branch for Business (CBB)
→ なし (2016 年 2 月スタート)
First Release for Current Branch for Business (FR CBB、CBB の先行リリース)
→ January 12, 2016 Version: 16.0.6001.1054
Office 365 client update branch releases
[URL] https://technet.microsoft.com/en-us/office/mt465751 (英語)
[URL] https://technet.microsoft.com/ja-jp/office/mt465751 (日本語)
クイック実行 (C2R) 版の Office 2016 (2013 も) は、Windows Update では更新されず、Office 組み込みの自動更新機能で更新されるのでご注意ください。ファイル → アカウント → 更新オプション → 今すぐ更新 で手動更新を開始できます。
各更新ブランチの、本日時点の最新バージョンは以下のとおり。
Current Branch (CB)
→ January 12, 2016 Version: 16.0.6366.2056
Current Branch for Business (CBB)
→ なし (2016 年 2 月スタート)
First Release for Current Branch for Business (FR CBB、CBB の先行リリース)
→ January 12, 2016 Version: 16.0.6001.1054
2016/01/05
Windows 10 バージョン 1511 を Sysprep じゃあなく、Provisioning Package で
Windows 10 バージョン 1511 (ビルド 10586) から、Sysprep 後の Mini-Setup に異様に時間がかかるようになってしまったようです。Windows 8.1 と同様の Unattend.xml で自動セットアップできることは確認したのですが、1 時間以上かかるのでは待ってられない。たぶん、Windows 10 バージョン 1511 からの不具合だと思うのですが...
追記) Mini-Setup に異様に時間がかかる問題は、その後の更新で解消されたっぽいです。最近作成した Sysprep イメージでは再現しませんでした。発生するイメージと発生しないイメージあり。原因は不明。どうやら、Sysprep 実行時に/mode:vmオプションを付けるとこの問題に遭遇するみたいです。
というわけで、Windows 10 の新機能、プロビジョニング パッケージってのでイメージ展開してみました。
参照用 (リファレンス) PC に Windows 10 をインストール → Sysprep → イメージのキャプチャ → イメージ展開+ Unattend.xml で自動セットアップ!
ってところを
Windows 10 の Sources\Install.wim + プロビジョニング パッケージ (.ppkg) → 自動セットアップ!
とやってみるって話です。プロビジョニング パッケージを含むインストール用 USB メディアを作ってそれから PC を起動して、自動セットアップするという方法もあるみたいですが、今回はそれではないっす。
追記) Mini-Setup に異様に時間がかかる問題は、
というわけで、Windows 10 の新機能、プロビジョニング パッケージってのでイメージ展開してみました。
参照用 (リファレンス) PC に Windows 10 をインストール → Sysprep → イメージのキャプチャ → イメージ展開+ Unattend.xml で自動セットアップ!
ってところを
Windows 10 の Sources\Install.wim + プロビジョニング パッケージ (.ppkg) → 自動セットアップ!
とやってみるって話です。プロビジョニング パッケージを含むインストール用 USB メディアを作ってそれから PC を起動して、自動セットアップするという方法もあるみたいですが、今回はそれではないっす。
告知: Tohoku ComCamp 2016 powered by MVPs の開催
登録:
投稿 (Atom)