2013年09月
2013年09月30日
Hyper-Vを利用しているのですが、あるときAdministratorでローカルのHyper-Vにアクセスしようとしたところ、
「サーバー"SERVER NAME" に接続中にエラーが発生しました。仮想マシン管理サービスが実行されており、サーバーに接続する権限が与えられているかどうかを確認してください。」
というエラーが出てしまいました。
どうやらアクセス件に問題があったようで、以下の方法で解決しました。
参考
(WindowsServer)Hyper-VマネージャをAdministrators以外で使う
【第2回】Windows VistaからHyper-Vを管理する
ドメイン環境であったため、上記参考サイトに挙げられているような CIMV2 / virtualization のアクセス件を確認すると、Hyper-V Administrators というグループにアクセス許可が付与されていました。
そしてこのグループを見ると、なんと Administrator がメンバーになっていませんでした。
ということで、グループのメンバにすることによって解決しました。
ちょっと前にADを色々いじっていたから、メンバーからはずれてしまったのかな???
「サーバー"SERVER NAME" に接続中にエラーが発生しました。仮想マシン管理サービスが実行されており、サーバーに接続する権限が与えられているかどうかを確認してください。」
というエラーが出てしまいました。
どうやらアクセス件に問題があったようで、以下の方法で解決しました。
参考
(WindowsServer)Hyper-VマネージャをAdministrators以外で使う
【第2回】Windows VistaからHyper-Vを管理する
ドメイン環境であったため、上記参考サイトに挙げられているような CIMV2 / virtualization のアクセス件を確認すると、Hyper-V Administrators というグループにアクセス許可が付与されていました。
そしてこのグループを見ると、なんと Administrator がメンバーになっていませんでした。
ということで、グループのメンバにすることによって解決しました。
ちょっと前にADを色々いじっていたから、メンバーからはずれてしまったのかな???
2013年09月29日
大変驚きました。
Word 2013 でマニュアルを作ったのです。もちろんキャプチャーした画像をWordに埋め込んで利用します。
PDFで保存を行い、提出をしようとしたところ、画像にマウスカーソルを載せると、吹き出しで画像の保存されているパスが表示されるのです。
どうやら昔のバージョンからそのようになっているようですね。
セキュリティ的にも情報漏洩的にも大変問題のある仕様だと思っています。
参考
PDF保存時にパス情報を削除する
Windows2007で出力したPDFファイルで画像にファイルパスがでる。
MS office2007と2010でpdfを作成すると画像のパスが表示される
参考サイトにあるように、
PDFで保存するときに、オプションの「アクセシビリティ用のドキュメント構造タグ」のチェックをはずす必要があります。そしてこれをデフォルトにはできないようでした。
十分に注意していきたいと思います。
Word 2013 でマニュアルを作ったのです。もちろんキャプチャーした画像をWordに埋め込んで利用します。
PDFで保存を行い、提出をしようとしたところ、画像にマウスカーソルを載せると、吹き出しで画像の保存されているパスが表示されるのです。
どうやら昔のバージョンからそのようになっているようですね。
セキュリティ的にも情報漏洩的にも大変問題のある仕様だと思っています。
参考
PDF保存時にパス情報を削除する
Windows2007で出力したPDFファイルで画像にファイルパスがでる。
MS office2007と2010でpdfを作成すると画像のパスが表示される
参考サイトにあるように、
PDFで保存するときに、オプションの「アクセシビリティ用のドキュメント構造タグ」のチェックをはずす必要があります。そしてこれをデフォルトにはできないようでした。
十分に注意していきたいと思います。
2013年09月28日
会社のサーバーですが、Windows 2008 のソフトRAIDを利用していました。
ファイルサーバーとして利用していることもあって、RAIDボードはファイル共有のためにとっておきます。そしてオンボードのRAIDは、万が一の時に心配なので、利用しないというポリシーでした。
(RAIDボードは結構壊れるので、オンボードだと、マザーボードを交換しなければ他の筐体で読み込めないことになってしまいます)
そして最近になってそのサーバーですが、HDDが故障してしまいデグレードモードにて動作していました。
基本的なことですが、このとき、以下の点に注意が必要です
・起動するドライブを正しく選択すること
HDDが2台あるウチのどっちが故障しているのか正しく理解する必要があります。そして起動ディスクも正しく選択する必要があります。
今回はDisk1が故障したので、Disk2 で起動する必要がありました。
システムのプロパティ - 起動と回復から、既定のオペレーティングシステムで、セカンダリプレックスを選択します。こうすることによって、HDD1を取り外しても問題無く起動することができます。
※以下の方法で成功しました
1. サーバーの電源をOFFにします
2. ディスクを交換します
3. Disk1(旧) と Disk2 のRAID情報があるため、既存のRAIDがエラーになっているはずです。このRAIDを解除します
4. 交換したDisk1 は未割り当てになっています。Disk2は起動ディスク(C)として単体で動作しているはずです。
5. Disk2 のパーティションをクリックし、ミラーの追加を選択します。→ 交換した Disk1 と今動作しているDisk2 のCドライブをRAID化します
これで再同期が始まり、あとは完了をまつだけです。
250G の容量で、2%/分という感じでした。 そのため、1時間もあれば完了しそうです。
ファイルサーバーとして利用していることもあって、RAIDボードはファイル共有のためにとっておきます。そしてオンボードのRAIDは、万が一の時に心配なので、利用しないというポリシーでした。
(RAIDボードは結構壊れるので、オンボードだと、マザーボードを交換しなければ他の筐体で読み込めないことになってしまいます)
そして最近になってそのサーバーですが、HDDが故障してしまいデグレードモードにて動作していました。
基本的なことですが、このとき、以下の点に注意が必要です
・起動するドライブを正しく選択すること
HDDが2台あるウチのどっちが故障しているのか正しく理解する必要があります。そして起動ディスクも正しく選択する必要があります。
今回はDisk1が故障したので、Disk2 で起動する必要がありました。
システムのプロパティ - 起動と回復から、既定のオペレーティングシステムで、セカンダリプレックスを選択します。こうすることによって、HDD1を取り外しても問題無く起動することができます。
※以下の方法で成功しました
1. サーバーの電源をOFFにします
2. ディスクを交換します
3. Disk1(旧) と Disk2 のRAID情報があるため、既存のRAIDがエラーになっているはずです。このRAIDを解除します
4. 交換したDisk1 は未割り当てになっています。Disk2は起動ディスク(C)として単体で動作しているはずです。
5. Disk2 のパーティションをクリックし、ミラーの追加を選択します。→ 交換した Disk1 と今動作しているDisk2 のCドライブをRAID化します
これで再同期が始まり、あとは完了をまつだけです。
250G の容量で、2%/分という感じでした。 そのため、1時間もあれば完了しそうです。
2013年09月27日
誕生日のしばらく前に、更新通知のハガキが来ていました。
ちょうど、台湾旅行の前後だったりとかで忙しくしている時期でした。そしてそのままお盆は混雑しているから避けて、、、、としていたら、9月末になってしまいました。もうちょっとで失効しちゃう!ということで更新に行ってきました。
今まで僕は、違反という区分で更新でした。だいたいは軽微な違反を警察に取り締まられることが多くて、なかなか次のところに行けなかったのです。
最後のスピード違反をしてから、最近は十分気をつけていました。
※そのときの記事は2009年07月30日:スピード違反。
そして前回の更新では、やっぱり違反の区分だったのです。
2010年09月06日:免許の更新をしてきました。
前回更新した2010年から、一度も違反をしていません。バイクに日々乗る僕ですが、全然違反をしていないのです。
くだらないスピード違反などはもちろんのこと、一時停止なども忠実に守っています。
歩行者妨害もね。
それらの努力のおかげもあって、無事に今回は一般での区分になりました。
今までは江東運転免許試験場で更新やら取得を行っていましたが、今回は鮫洲運転免許試験場に行ってきました。(ちなみに金曜日の午前中に行きました)
そして気がついたことは・・。とにかく空いているということです。
もちろん更新の諸々の手続きは、全員が一緒なので時間帯によって混雑しています。特に今回は視力検査に時間がかかっている人がいました。(とはいっても、長蛇の列と言うほどではありません。)
講習のところになると、今まで違反の区分だった頃は、教室がいっぱいでした。座席が埋まるほどだったのです。しかも広い教室が。(ちなみに以前は江東運転免許試験場だったので、その違いもあるかもしれません)
しかし今回は10名いないぐらいの人数でした。
10時15分ごろに試験場に入って、12時15分ごろに終わりました。試験場を出たのは12時半ぐらいでしょうか。
手続きが10時50分ごろまでに終わり、講習が11時15分から開始。講習は1時間。そういう感じの流れでした。
参考
2010年10月24日 (日):日曜午後の鮫洲運転免許試験場
鮫洲の運転免許試験場で免許更新:受付は8時ぐらいから開いてた
ちょうど、台湾旅行の前後だったりとかで忙しくしている時期でした。そしてそのままお盆は混雑しているから避けて、、、、としていたら、9月末になってしまいました。もうちょっとで失効しちゃう!ということで更新に行ってきました。
今まで僕は、違反という区分で更新でした。だいたいは軽微な違反を警察に取り締まられることが多くて、なかなか次のところに行けなかったのです。
最後のスピード違反をしてから、最近は十分気をつけていました。
※そのときの記事は2009年07月30日:スピード違反。
そして前回の更新では、やっぱり違反の区分だったのです。
2010年09月06日:免許の更新をしてきました。
前回更新した2010年から、一度も違反をしていません。バイクに日々乗る僕ですが、全然違反をしていないのです。
くだらないスピード違反などはもちろんのこと、一時停止なども忠実に守っています。
歩行者妨害もね。
それらの努力のおかげもあって、無事に今回は一般での区分になりました。
今までは江東運転免許試験場で更新やら取得を行っていましたが、今回は鮫洲運転免許試験場に行ってきました。(ちなみに金曜日の午前中に行きました)
そして気がついたことは・・。とにかく空いているということです。
もちろん更新の諸々の手続きは、全員が一緒なので時間帯によって混雑しています。特に今回は視力検査に時間がかかっている人がいました。(とはいっても、長蛇の列と言うほどではありません。)
講習のところになると、今まで違反の区分だった頃は、教室がいっぱいでした。座席が埋まるほどだったのです。しかも広い教室が。(ちなみに以前は江東運転免許試験場だったので、その違いもあるかもしれません)
しかし今回は10名いないぐらいの人数でした。
10時15分ごろに試験場に入って、12時15分ごろに終わりました。試験場を出たのは12時半ぐらいでしょうか。
手続きが10時50分ごろまでに終わり、講習が11時15分から開始。講習は1時間。そういう感じの流れでした。
参考
2010年10月24日 (日):日曜午後の鮫洲運転免許試験場
鮫洲の運転免許試験場で免許更新:受付は8時ぐらいから開いてた
2013年09月26日
以下のようなログが頻繁に出力されていました。
Catalog Database (1296) Catalog Database: データベースにページ データが含まれていないため、ファイル "C:\Windows\system32\CatRoot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\catdb" のオフセット 19345408 (0x0000000001273000) (データベース ページ 4722 (0x1272)) から 4096 (0x00001000) バイトのデータベース ページの読み取りを確認できませんでした。読み取り処理は、エラー -1019 (0xfffffc05) のため失敗します。この状態が続く場合は、以前のバックアップからデータベースを復元してください。これはハードウェアに問題がある可能性があります。問題の診断についての詳細はハードウェア製造元に問い合わせてください。
とりあえず以下の方法で、 catroot2 フォルダをリネームしてしまいました。
1. サービスを開き、Cryptographic Services を停止、
2. C:\Windows\System32\catroot2 を適当にリネーム
WindowsUpdateを再度行ったところ、 catroot2 が再作成されました。
とりあえず問題は起きていません。
イベントログのエラーも無くなりました。
Catalog Database (1296) Catalog Database: データベースにページ データが含まれていないため、ファイル "C:\Windows\system32\CatRoot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\catdb" のオフセット 19345408 (0x0000000001273000) (データベース ページ 4722 (0x1272)) から 4096 (0x00001000) バイトのデータベース ページの読み取りを確認できませんでした。読み取り処理は、エラー -1019 (0xfffffc05) のため失敗します。この状態が続く場合は、以前のバックアップからデータベースを復元してください。これはハードウェアに問題がある可能性があります。問題の診断についての詳細はハードウェア製造元に問い合わせてください。
とりあえず以下の方法で、 catroot2 フォルダをリネームしてしまいました。
1. サービスを開き、Cryptographic Services を停止、
2. C:\Windows\System32\catroot2 を適当にリネーム
WindowsUpdateを再度行ったところ、 catroot2 が再作成されました。
とりあえず問題は起きていません。
イベントログのエラーも無くなりました。
2013年09月25日
またアヤシイDMがTwitterに来ました。
twitterli.com というURLです。
検索してみると、色々被害が出ているようですね。
Have you seen this リンク ? i think its about youというDMに注意!アカウントが乗っ取られる被害横行中
しかしまあなぜ英語のフィッシングに引っかかってしまうのか・・・
twitterli.com というURLです。
検索してみると、色々被害が出ているようですね。
Have you seen this リンク ? i think its about youというDMに注意!アカウントが乗っ取られる被害横行中
しかしまあなぜ英語のフィッシングに引っかかってしまうのか・・・
2013年09月24日
※僕はプログラムを書かないですし、よくわからないのでアタリをつけたというメモになります。
まずプログラムの概要から。
GETでデータを受け取ります。
その後処理を行って違うPHPに移動します。このときは Location を利用しています。
そして帰ってくる結果が文字化けしているのです。
Windows サーバーで動作しているときは、文字化けなどせず、問題無く動作していました。しかし今回ReverseProxy環境にして、途中に Linux が絡むと文字化けしてしまうのです。
エンコードなどは、すべて shift-jis で行われており、プログラム上の不備は無いように思えます。
linux で tcpdump を取得したときは以下のようになっていました。
■最初のGET
GET /url-path/?postdata=[エンコード文字列]
■Location での移動
Content-Type: text/html; charset=UTF-8
Location: http://[url]/index.php?postdata=[エンコード文字列]
Server: Microsoft-IIS/8.0
X-Powered-By: PHP/5.2.5
Date: Mon, 23 Sep 2013 07:37:06 GMT
Connection: close
Content-Length: 834
ここで、最初のGETの時には、shift-jis でエンコードされているようです。実際にエンコード文字列をデコードするのも問題ありません。
しかし次の location の時は、charset=UTF-8 となっています。このため、エンコード文字列として渡されている値は shift-jis のため、整合性がとれず文字化けの原因になっているのでは無いかと思いました。。
※このcharset=UTF-8は無指定の場合のデフォルトのような気がします。(もちろんプログラムでの指定ミスかもしれません)
よく分からないのですが、このあたりが怪しいという感じでした。
まずプログラムの概要から。
GETでデータを受け取ります。
その後処理を行って違うPHPに移動します。このときは Location を利用しています。
そして帰ってくる結果が文字化けしているのです。
Windows サーバーで動作しているときは、文字化けなどせず、問題無く動作していました。しかし今回ReverseProxy環境にして、途中に Linux が絡むと文字化けしてしまうのです。
エンコードなどは、すべて shift-jis で行われており、プログラム上の不備は無いように思えます。
linux で tcpdump を取得したときは以下のようになっていました。
■最初のGET
GET /url-path/?postdata=[エンコード文字列]
■Location での移動
Content-Type: text/html; charset=UTF-8
Location: http://[url]/index.php?postdata=[エンコード文字列]
Server: Microsoft-IIS/8.0
X-Powered-By: PHP/5.2.5
Date: Mon, 23 Sep 2013 07:37:06 GMT
Connection: close
Content-Length: 834
ここで、最初のGETの時には、shift-jis でエンコードされているようです。実際にエンコード文字列をデコードするのも問題ありません。
しかし次の location の時は、charset=UTF-8 となっています。このため、エンコード文字列として渡されている値は shift-jis のため、整合性がとれず文字化けの原因になっているのでは無いかと思いました。。
※このcharset=UTF-8は無指定の場合のデフォルトのような気がします。(もちろんプログラムでの指定ミスかもしれません)
よく分からないのですが、このあたりが怪しいという感じでした。