Catalyst 3650でスマートコールホームのテストインベントリを送るには、Enableモードで、下記のコマンドを実施する。 事前に、スイッチに設定したcallhomeのプロファイル名を`show config`で調べておく。
call-home test profile [プロファイル名を指定]
これで、Cisco側に送信される。 プロファイル名が間違っているときは、送信を試みたあとに、エラーメッセージが表示されるので、ちゃんと読む。
Catalyst 3650でスマートコールホームのテストインベントリを送るには、Enableモードで、下記のコマンドを実施する。 事前に、スイッチに設定したcallhomeのプロファイル名を`show config`で調べておく。
call-home test profile [プロファイル名を指定]
これで、Cisco側に送信される。 プロファイル名が間違っているときは、送信を試みたあとに、エラーメッセージが表示されるので、ちゃんと読む。
2018年3月配信のWindows Updateで、32bit版のWindows7 SP1 において、物理アドレス拡張(PAE)モードを無効にしている場合に不具合が発生するとのこと。
◆参考URL
https://support.microsoft.com/ja-jp/help/4088875/windows-7-update-kb4088875
簡単に発生条件を書くと
・Windows 7 SP1の32ビットを使用し、
・メモリを4GBを超えて搭載しており、
・物理アドレス拡張(PAE)モードを無効
にしている場合、Windows Updateを行うと、ストップエラーが発生する。
なかなかのレアケース。通常、発注ミスがなければ、32bitのOSでメモリを4GBを超えるメモリは積まないだろうし、あえて8GBメモリとかにしているのであれば、物理アドレス拡張モードを使っているはずだ。
何故だ?と思っていたのだが、10万(100,000)を超えるファイルのあるフォルダをバックアップする場合、エージェントが”Itzam”フォルダーを作り、そこにファイルリストを作成し、バックアップするとのこと。この動作により、動作が遅くなる、そしてファイル数が増えれば増えるほど、一時的にとはいえ”Itzam”フォルダーの容量が増える。こういう仕組みなので、Acronisで大量のファイルをバックアップするときは時間もかかるし、ハングアップもしやすくなる。
Acronisは、ドライブ丸ごとの「イメージバックアップ」は得意なので、大量のファイルをバックアップするときは、フォルダやファイルでのバックアップではなくて、不経済かもしれなくてもドライブごとのイメージバックアップを取得した方が速いし、確実に行える。
Acronis Backup: “Itzam” フォルダー
https://kb.acronis.com/node/49682
Nexus 3524x のログを見ていたところ、`%DAEMON-3-SYSTEM_MSG: error:` が記録されていた。調べたところ、SSH接続が切られただけのようだ。LAN内部なら、多発していなければ放置でよさそうだ。
2018 Feb 4 11:55:34 hostname %DAEMON-3-SYSTEM_MSG: error: Received disconnect from 192.168.0.159: 2: disconnected by server request - dcos_sshd[7433]
第8世代のCore i5を搭載したVaioをゲットしたので、ちょっと遊んでみた。
CPUが第8世代なので、Core i5でもとても速い。「VAIO True Performance」が効いているのかどうかはわからないけれど、ベンチマークの結果もいいし、実際に使っても速い。グラフィック系の部分は、IntelのGraphicなので、よくはないけれど、ビジネス用途なら問題なし(ゲーム用途や3Dをバリバリ使わなければ大丈夫でしょう)。CPUをぶん回すと、熱い温風は結構でる。逆にとらえれば、冷却性能がいいのだろう。モバイル向けCore i5で4コアは良い。ハイパースレッディングもあるし。
いろいろと処理を動かしてみると、i5-5200Uと比べると2倍弱くらいの性能。i5-6200Uと比べると1.5倍くらいの性能。CPUのコア数が増えたのは、偉大だ。
RAID構成のシステムを導入するとき、より安全な構成を選ぼうとすると付いて回るのがコスト問題。とくにRAID5じゃダメなのかとか、RAID6だとコスト効率悪いとか、冗長性はあるにこしたことはないが、そのコストの説明が必要になる。そういうときに、説得力を出すのが、過去の障害事例だ。特に、有名どころの企業かつ被害が大きいものが有効だ(障害が発生した企業にはもうしわけないけど)。
そんな中で、三菱UFJニコスのシステムで発生した2017年末のシステム障害は、RAID6構成のシステムで、同時に3本のHDDが壊れて停止するという稀有な事例だ。
http://tech.nikkeibp.co.jp/it/atcl/news/17/020803126/
稀有な事例だけど、HDDのロットによっては、同じロットだと壊れやすいとか、よくある話。システムに絶対大丈夫なものはない。けれど、偉い人はどうしても、安全性とコストを天秤にかける(それが経営なんだから、それは仕方ない)。そういうときに、コストがかかっても安全なものを選択してもらうための説得材料が重要。割り切りとして、安価で済ます分、システム停止のリスクを容認するのか、それともコストをかけて、発生するかどうかわからないリスクに備えるのか。そのさじ加減はなんとも言えない。だけど、この事例は、コストを削りすぎるときのリスクを警鐘するには、ちょうどいいのではないかと思う。
ちょっと話はかわるが、こういう事例をみると、壊れた後の復旧策や手順は重要ということを再認識させてくれる。想定外に対応できるだけの運用体制は維持しておかないといけないね。
「Office 2019」が2018年後半にリリースへ、Windows 10のみ対応
https://cloud.watch.impress.co.jp/docs/news/1104562.html
実際に「発売されてみなければわからない」というのはあるが「Office 2019」はWindows 10のみのサポートになり、Windows7では使えないようだ。同じようにサーバOSにOfficeをインストールする場合も、最新のものしかサポートされなくなる。サーバに組み込んだシステムからOfficeを使うときは気をつけないといけない。買い切りのライセンスであれば、ダウングレード権をついているものを選択し、Office 2016を使うのがよさそうだ。その場合、2016のみにするのか、2016と2019の混在にするのかの方針を明確にしておかないと。
もう一つ重要なのが、2020年1月14日で「Office 365 ProPlus」のサポートから、Windows 7/8.1が外れるという内容。Windows 10でも、サポート外の半期チャネル(年に2回やってくる大型アップデートの最新の2バージョン以外はサポート対象外)の動作もサポートされなくなる。大型アップデートを促す役割があるのだろうが、ちゃんと検証と対応のサイクルを構築しなければ。あと、サーバOSにOfficeをインストールするときは、買い切りパッケージがよさそうだ。
この先のPCやOffice製品の導入計画を考えるときは、OSのライフサイクル、Officeのライフサイクル、物理的なPCのライフライフサイクルなど、いろいろと考えた上で決定したほうがよさそうだ。
Windows Server 2008 R2は、IE11が使用できるので、Windows Server 2012もIE11が使えると思ったが、IE10のみ。通常のIE10はMSのサポートが終了しているが、Windows Server 2012のIE10は、OSのサポートに従い2023年まで。なんとも、紛らわしい。
Microsoftから配信されている「Intelの脆弱性対策を無効化する緊急アップデート」を試してみた。
まず、通常のWindows Updateで適用できないので、一般ユーザに実施してもらうには、敷居が高い。実際にダウンロードして、Windows10に適用してみたが、あまり変わらず。Haswell以降ということで、CPUの型番も調べて対応していることも確認はしている。これ、不安定から、ちょっと不安定になる程度の緩和しかしていないのかもしれない。もしくは、ちゃんと適用できていないか。さて、どっちだろうか。
このSpectreとMeltdown問題、いつまで対応が続くのだろうか。ユーザの体感は下がっているし、第8世代のCoreシリーズに乗り換えを促すキャンペーンのような気がする。運用工数は増えるし、困ったものだ。