Internet Explorerでは、現在アクセスしているページが
以下のように4種類に分類される。

* インターネット
* ローカルイントラネット
* 信頼済みサイト
* 制限付きサイト

「信頼済みサイト」は手動で任意のサイトを登録して初めて分類される。
例えば、ある程度権限が無いと上手く動作しないサイトでは
ユーザーに予め登録をお願いし、セキュリティを弱くすることでサイトが正常に動作するようにすることができる。
「制限付きサイト」はその逆と考えて差し支えない（業務上、今まで使たことは無いが）。

ただ、そんなセキュリティを弱くしないといけないほどのシステムなんて、大抵は社内イントラネットだ。
なので、普通ならは信頼済みサイトへの登録なんてせずとも、自動でローカルイントラネットに識別され、システムは問題なく動作する。
（デフォルトでは「ローカルイントラネット」の方が「信頼済みサイト」よりセキュリティが弱く設定されている）

・・・と思っていたが、色んな会社を回っていると、どうもそうとも限らないらしい。
社内システムの筈なのに、IE上は「インターネット」に分類されている場合がある。
そこで、この分類され方について調べてみた。

何とこれ、実際にイントラネットかは全く判定していなかった。
URLに.(ドット)が入っていない場合は「ローカルイントラネット」、入っている場合は「インターネット」を分類しているに過ぎなかった。
FQDN または IP アドレスを使用すると、イントラネット サイトがインターネット サイトとして判別される

だから、社内システムでもURLが「http://CompanySystem.com」みたいになっている場合は「インターネット」識別になっていたのだ。
極端な話、hostsファイルを弄って「http://google」で「http://google.com」にアクセスするように設定去れば、
Googleのページすら「ローカルイントラネット」判定される。

いくら何でも雑な分類すぎませんかね。。。
まぁ、もうIEも消えてゆくはずだし、いいか。

Windows Serverは基本的にGUIがついているが、
Windows Server(Core)や、Hyper-V Server等、CUIしかないものも存在する。

これらはサイズも軽く、負荷も少ない（多分）という面で便利なのだが、
エクスプローラもないため、ちょっとしたファイルコピー、フォルダ権限付けを行いたいときもイチイチコマンドで行わなくてはならない。
共有フォルダなら外部のエクスプローラからアクセスすればよいが、そうでないとやはりコマンドでの実行になってしまう。正直、ちょっとした作業なのに一々コマンドを打つのも面倒だ。

ややハック的だが、Coreサーバーでもエクスプローラ（的）なものを使う方法がある。

1. コマンドプロンプトでnotepadと入力し、Enterを押下する
2. メモ帳が起動するので、「ファイル」の「開く」をクリックする
3. このダイアログ上でエクスプローラとほぼ同等の操作ができる

ちょっとした操作ならこの方がミスも少ないと思う。
ネットワークの共有フォルダを見たい場合は「ファイル名」の部分に「\\<アドレス>」を入力すればアクセス可能だ。
ex)\\TEST_Server

僕はcopyコマンドでコピー元とコピー先と間違える阿呆なので、この方法をよく使う。

本当に更新を定期的に実行するのは難しい。
今日は多分、今まででも1,2を争うレベルのくだらないミス。

WindowsでWebサーバーを構築する場合、
一般的にはIIS（インターネットインフォメーションサービス）を利用すると思う。
そして、キャッシュの開放や、IISで実行するコンポーネントを変更した場合には、IISを再起動するケースは多々ある。

IISの再起動は大変容易で、コマンドプロンプト（管理者権限）で
IISRESET
と入力し、Enterを押下するだけでよい。

夜間、定期的にIIS再起動行うするために、IIS再起動batを作成した。

間違えるような要素もないので、まず問題ないだろうと思っていた。
しかし、このbat、実行すると思うような動作をしてくれない。
下記のようになってしまう。

何故上手く実行されないか悩んでいたが、原因は単純だった。
ファイル名を「IISRESET.bat」にしていることが問題だった。
IISRESETにより、「IIS再起動」ではなく「IISRESET.bat」が再帰され、無限ループになっていた。

なので、「IISRESET実行.bat」とか、適当な名前に変更し、問題は解消した。

気付きそうで気付かないことろでした。これで1時間ぐらい悩んでしまった。。。

Windows UpdateによりOfficeファイルがWebDAVで開けなくなる問題だが、
ようやくMicrosoftが修正アップデートをしたようだ。

https://support.microsoft.com/en-us/kb/3114399

一応、直ったという報告もある。
https://www.reddit.com/r/sysadmin/comments/3vzmia/kb3114399_fixes_sharepoint_office_web_integration/

自分の環境ではまだ試せてないので、試してから追記する。

検証した。
どうやら問題なくWebDAVでのファイルオープンや保存ができるようになった模様。
[解決] KB3055034 適用後、Office 2010 アプリケーションがクラッシュする問題について

追記(2015/12/14)

自分の環境では再現できていないが、一部環境では「名前をつけて保存」時にまだ不具合がある模様。
HOME-BOX2
（「【HOME-BOX2】Office 2010 WebDAV接続不具合に関するご案内(12/10)」の項）

う～ん。これは困った。

追記(2016/02/24)

上記現象もKB3114750でようやく解消した模様。
https://support.microsoft.com/ja-jp/kb/3114750
よかったね。おめでとう。

仕事でHyper-V上で複数マシンを立ちあげて管理している。
一応、各ゲストマシンはそれぞれ無関係なので、ゲストマシン間の通信は行えないようにしたい。
ただ、現実問題として使える仮想ネットワークアダプタは限られているので、
どうしても同じネットワークアダプタを使わざるを得ない。

何とか良い通信制御方法は無いかと探していたら、Hyper-VでAcl（アクセス制御）ができることが分かった。
ホストマシンでコマンド実行するだけなので、一度わかればかなり楽に設定が可能である。
なお、Windows Server 2012からの機能なので、恐らくWindows Server 2008 R2とかその世代のものではできないと思う。

ホストマシンからPowerShellで以下のコマンドを実行すると設定等が実行できる。
なお、ここで「VM名」と言っているのはHyper-Vマネージャ上で表示されている仮想マシンの名称のことである。

• 設定を確認する
  
  PowerShell

  Get-VMNetworkAdapterAcl

  1	Get-VMNetworkAdapterAcl

• 設定を追加する
  
  PowerShell

  Add-VMNetworkAdapterAcl -Action <Action> -Direction <Direction> -VMName <VM名> -RemoteIPAddress <対象IPアドレス>

  1	Add-VMNetworkAdapterAcl -Action <Action> -Direction <Direction> -VMName <VM名> -RemoteIPAddress <対象IPアドレス>

  ・<Action>・・・接続拒否ならDeny、接続許可ならAllow、計測ならMeter。
  ・<Direction>・・・VMへの入力方向ならinbound、VMからの出力方向ならoutbound、VMの入出力両方ならBoth。
  ・<VM名>・・・対象のVM名を指定する。コンピュータ名でなくVM名なことに注意。
  ・<対象IPアドレス>・・・対象のIPアドレス。CIDR表記での設定も可能。
• 設定を削除する
  
  PowerShell

  Delete-VMNetworkAdapterAcl -Action <Action> -Direction <Direction> -VMName <VM名> -RemoteIPAddress <対象IPアドレス>

  1	Delete-VMNetworkAdapterAcl -Action <Action> -Direction <Direction> -VMName <VM名> -RemoteIPAddress <対象IPアドレス>

  要するに、addしたものと同じ設定を指定してDeleteする必要がある。何と面倒な。

例えば、192.168.0.1がルータで、192.168.0.xが別のゲストマシンの場合、
以下のようにすれば、「ルータ（=インターネット)にのみ接続し、他の同ネットワーク上マシンとは通信しない」という設定が可能である。

以下のページがより詳しいので参照すると良い。
僕はこのページが無くては詰んでいました。ありがとうございます。
参考: Windows Server 2012 Hyper-VでPort ACL・その1

いよいよ日本に帰任しそう。
引越し手続きとか全部やってくれないかね。
自分で手配するの面倒臭いし絶対何かミスしそう。

RDP(リモートデスクトップ)でキチンとセキュアな環境を整えるためには、
サーバー証明書を設定する必要がある。
設定する理由と、設定しない場合の弊害は下記記事を参照するとわかりやすい。
参考: リモート・デスクトップ接続のサーバに「正しい」証明書を割り当てる

さて、それでWindows Server 2008 R2であればGUIで簡単に割り当てられるのだが、
Windows Server 2012では同様の項目が見つからなかった。
調べた結果、どうもPowerShellを使うぐらいしか方法が見つからなかったので、その方法を記載する。

1. 新しい証明書をダブルクリックし、インポートする。
2. PowerShellを管理者として実行する。
3. 以下を実行し、新しい証明書のThumbprintを確認する。
   dir cert:\LocalMachine\My
4. 以下を実行する。これは単にパスを設定するだけである。
   $path = (Get-WmiObject -class “Win32_TSGeneralSetting” -Namespace root\cimv2\terminalservices -Filter “TerminalName=’RDP-tcp'”).__path
5. 以下を実行し、証明書の割当を変更する。
   Set-WmiInstance -Path $path -argument @{SSLCertificateSHA1Hash=”新しい証明書のThumbprint”}

以上の手順で証明書を設定できる。
実行後、特にエラーが起きないことを確認したら、RDPを切断し、再度RDPで接続できることを念の為に確認する。
RDPしたときのウィンドウ上の鍵マークをクリックすれば、設定した証明書が利用できているか確認できる。

他に方法はあるはずだと思うけど、上記手順で行えたので調査は打ち切りです。
こんな操作すること滅多にないしね。

こういう作業の何が嫌かって、万が一ミスってRDPできなくなったときだね。
データセンターのサーバーに対してやる場合、最悪データセンターに行かなくてはならなくなる・・・