結論から言うと、現時点においては、
WIndows Server 2016では、
iSCSIターゲットサーバーをインストールして、イニシエータと相互接続するのならば、
ファイアウォールの設定を手動で行う必要はないし、手動でいじくるべきではない。
いつのまにか自動的にファイアウォールの設定をしてくれる。
インターネット上の古い文献をみてみれば、手動でポートを開いてくれと記されているものもあるけれども、それは過去のWIndows Server のバージョンにおける構築手順の記述であって、Windows Server2016とはあまり関係がないのではないか。
というのが現時点での私の見解です。
海外のウェブサイトを見ていると、
iSCSIをインストールしただけでは、ポートが解放されていないので、
FireWallのせっていをいじくれと記されているページもある。
だけど、
実際は当方の環境においては、
ファイアウォールの設定を変更しなくても、
イニシエータとターゲットとの相互接続ができている。
むしろ、ファイアウォールで、3260ポートなどを開放している場合のほうが
サービスを利用できません。というエラーメッセージが表示される場合が多かったです。
ただ、原因がポート開放だとは断言できませんが。
私の環境の場合、3年以上使用しているSSDにwindows10homeなどをインストールしていますので、サーバーOSのisoファイルの一部のビット配列が狂っているから、動作が狂っているのかもしれませんし、そもそもVirtual Boxの仮想HDDを用いて、WindowsServer上で仮想HDDを作っているから、
「仮想の仮想」
が構成されているのが不具合の原因かもしれません。
iSCSIは、Hyper-Vとの相性問題もあるようです。
そうそう、やすやすと、どんな状況下でも柔軟に対応してくれるような優れモノでもないのかもしれません。
インストールが成功した事例をいくつかみてみると、
Firewallの設定をいじくっていない場合に、おおくみられる。
ファイアウォールはいじくらなくても、iSCSIの設定はうまくいっている。
今私が考えているのは、
A:ファイルサーバーがiSCSIターゲットサーバーをインストールして、クライアントマシンのイニシエータと接続しあう。それからファイルサーバーマシンとクライアントマシンがドメイン参加する場合と、
B:まず、ファイルサーバーマシンとクライアントマシンがドメイン参加する。
その後、ファイルサーバーがiSCSIターゲットサーバーをインストールして、クライアントマシンのイニシエータと接続しあう場合とでは、
動作にはどのような違いが表れるのかな。
という疑問です。
iSCSIターゲットサーバーインストール時に、うまくファイアーウォールの3260ポートを開いてくれるのだろうか。ドメイン参加後でも、うまく取り計らってくれるのだろうか。
うまく取り計らってくれないのなら、サーバー構築者がGPOにおいて、セキュリティが強化されたファイアウォールの設定を施すべきでしょう。
以下はこれまでに受け取ったエラーメッセージです。
・ファイアウォールの設定をいじくった場合
「サービスを使用できません。」というエラーメッセージが出力されたことがあった。
もともとファイアウォールをいじくらなくても、iSCSIの構築は失敗しやすいのに、
ファイアウォールをいじくることで、余計に状況は悪化する。
クライアント側＝イニシエータ側の管理ツール群のイベントビューアーでは、
以下のメッセージが表示されたことがあった。
エラーコード0x00002af9により、ターゲットポータル*fs32.yakamochi.local 0003260 ROOT\SCRIPT\0000_0に対するSendTargets経由のiSCSI探索に失敗しました。
イベントID：113
レベル：警告
ソース：MSiSCSI
ログの名前：システム
サーバー側＝ターゲット側では以下のメッセージが表示される。
Microsoft iSCSIターゲットサーバー サービスは、ネットワークアドレス 192.168.10.241ポート3260にバインドできませんでした。操作はエラーコード10049で失敗しました。他のアプリケーションがこのポートを（使用していないかどうかを）確認してください。
イベントID:10
レベル：エラー
ログの名前：Microsoft-Windows-iSCSITarget-Service/admin
ソース：iSCSITarget-Service
Microsoft iSCSIターゲットサーバーサービスは、ローカルマウントドライバを開くことができませんでした。