最近、自宅の検証環境に Windows Update Services (WSUS) を導入しました。

新しい検証サーバーをデプロイして、Windows Update の参照先として構築した WSUS を設定したのですが更新プログラムの適用をすることができませんでした。

どうしてだろうと思って、WSUS の管理コンソールを開いてみたところこのようの画面になっていました…。

エラーの内容を見てみたところこのような内容が。

WSUS 管理コンソールは、リモート API 経由で WSUS サーバーに接続できませんでした。 Update Services サービス、 IIS および SQL がサーバー上で実行されていることを確認してください。問題が解決しない場合は、IIS、SQL、および Update Services サービスを再起動してみてください。 System.Net.WebException — HTTP ステータス 401: Unauthorized で要求が失敗しました。 Source System.Web.Services Stack Trace:    場所 System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)    場所 System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)    場所 Microsoft.UpdateServices.Internal.ApiRemoting.ExecuteSPGetUpdateServerStatus(Int32 updateSources, Boolean includeDownstreamComputers, String updateScopeXml, String computerTargetScopeXml, String preferredCulture, Int32 publicationState, Int32 propertiesToGet)    場所 Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccessProxy.ExecuteSPGetUpdateServerStatus(UpdateSources updateSources, Boolean includeDownstreamComputers, String updateScopeXml, String computerTargetScopeXml, String preferredCulture, ExtendedPublicationState publicationState, UpdateServerStatusPropertiesToGet propertiesToGet)    場所 Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetStatus(UpdateSources updateSources, Boolean includeDownstreamComputers, UpdateScope updatesToInclude, ComputerTargetScope computersToInclude, UpdateServerStatusPropertiesToGet propertiesToGet)    場所 Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetReplicaStatus(UpdateSources updateSources)    場所 Microsoft.UpdateServices.UI.SnapIn.Common.CachedUpdateServerStatus.GetFreshObjectForCache()    場所 Microsoft.UpdateServices.UI.AdminApiAccess.CachedObject.GetFromCache()    場所 Microsoft.UpdateServices.UI.SnapIn.Pages.ServerSummaryPage.backgroundWorker_DoWork(Object sender, DoWorkEventArgs e)

IIS / SQL Server / Update Service も正常に起動はしているのですよね…。

管理コンソールで再接続をしようとしてもこのようなエラーが。

‘2008R2-WSUS-01’ に接続できません。 サーバーが別のポートを使用しているか、別の SSL (Secure Sockets Layer) 設定を使用している可能性があります。

 

WSUS の Web サービスを開こうとしてもエラーとなっていました。

‘/ApiRemoting30’ アプリケーションでサーバー エラーが発生しました。 ——————————————————————————– 要求形式が認識されません。 説明: 現在の Web 要求を実行中に、ハンドルされていない例外が発生しました。エラーに関する詳細および例外の発生場所については、スタック トレースを参照してください。 例外の詳細: System.InvalidOperationException: 要求形式が認識されません。 ソース エラー: 現在の Web 要求の実行中にハンドルされていない例外が生成されました。障害の原因および発生場所に関する情報については、下の例外スタック トレースを使って確認できます。  スタック トレース: [InvalidOperationException: 要求形式が認識されません。]    System.Web.Services.Protocols.WebServiceHandlerFactory.CoreGetHandler(Type type, HttpContext context, HttpRequest request, HttpResponse response) +401178    System.Web.Services.Protocols.WebServiceHandlerFactory.GetHandler(HttpContext context, String verb, String url, String filePath) +281    System.Web.MaterializeHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +425    System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +263   ——————————————————————————– バージョン情報: Microsoft .NET Framework バージョン:2.0.50727.4952; ASP.NET バージョン:2.0.50727.4955

WSUS のログは [C:Program FilesUpdate ServicesLogFilesSoftwareDistribution.log] に出力がされているのですが、このログには以下のように出力がされていました。

2010-11-20 13:27:35.395 UTC    Error    WsusService.8    HmtWebServices.CheckDssAuthWebService    DssAuth WebService SoapException:System.Web.Services.Protocols.SoapException: System.W eb.Services.Protocols.SoapException: サーバーは要求を処理できませんでした。 —> System.InvalidOperationException: 一時クラスを生成できません (result=1)。 error CS2001: ソース ファイル ‘C:WindowsTEMPy4sk819r.0.cs’ が見つかりませんでした。 error CS2008: 入力が指定されていません。    場所 System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)    場所 System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies)    場所 System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence)    場所 System.Xml.Serialization.XmlSerializer.FromMappings(XmlMapping[] mappings, Evidence evidence)    場所 System.Web.Services.Protocols.SoapServerType..ctor(Type type, WebServiceProtocols protocolsSupported)    場所 System.Web.Services.Protocols.SoapServerProtocol.Initialize()    場所 System.Web.Services.Protocols.ServerProtocol.SetContext(Type type, HttpContext context, HttpRequest request, HttpResponse response)    場所 System.Web.Services.Protocols.ServerProtocolFactory.Create(Type type, HttpContext context, HttpRequest request, HttpResponse response, Boolean& abortProcessing)    — 内部例外スタック トレースの終わり —    場所 System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)    場所 System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)    場所 Microsoft.UpdateServices.Internal.DssAuthWebService.DssAuthWebService.Ping(Int32 pingLevel)    場所 Microsoft.UpdateServices.Internal.HealthMonitoring.HmtWebServices.CheckDssAuthWebService(EventLoggingType type, HealthEventLogger logger)    場所 Microsoft.UpdateServices.Internal.HealthMonitoring.HmtWebServices.CheckDssAuthWebService(EventLoggingType type, HealthEventLogger logger)    場所 Microsoft.UpdateServices.Internal.HealthMonitoring.HealthMonitoringTasks.ExecuteSubtask(HealthMonitoringSubtask subtask, EventLoggingType type, HealthEventLogger logger)    場所 Microsoft.UpdateServices.Internal.HealthMonitoring.HealthMonitoringTasks.Execute(EventLoggingType type)    場所 Microsoft.UpdateServices.Internal.HealthMonitoring.HealthMonitoringThreadManager.Execute(Boolean waitIfNecessary, EventLoggingType loggingType)    場所 Microsoft.UpdateServices.Internal.HealthMonitoring.HealthMonitoringThreadManager.PeriodicTask()    場所 Microsoft.UpdateServices.Internal.HealthMonitoring.PeriodicTaskExecuter.ThreadStart()    場所 System.Threading.ExecutionContext.runTryCode(Object userData)    場所 System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)    場所 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)    場所 System.Threading.ThreadHelper.ThreadStart()

情報を探してみたところ、以下のようなものがありました。
ASP.NET 2.0 をユーザー アカウントで実行されるように構成するとエラー メッセージ "一時クラスを生成できません" が表示される
Issues with the WSUS 3.0 Administration Console
WSUS に関連した Web サービスが、Windows Server 2003 ベースのコンピューターを Windows Server 2008 にアップグレードするときの動作を停止します。
WSUS Install Fails; There is a problem with this Windows Installer package.
そこが知りたい Windows Server Update Services（第3回）

今回の現象ですが、最後の [そこが知りたい Windows Server Update Services（第3回）] に記載されている現象が原因のようでした。

[C:Windowstemp]  から [Network Service] の権限が外れてしまっていたため Web サービスを実行した際の一時クラスが生成できずエラーになってしまったみたいですね。

[フォルダーの一覧/データの読み取り] の権限を付与したところエラーを回避することができました。

どうして突然外れてしまったのかはわからないのですが今後、同様の現象が発生した際の対応策のメモとして残しておきたいと思います。

Denali の HADR の構築はできましたので、今回はフェールオーバーについてまとめてみたいと思います。

■HADR 用のクラスターグループについて

HADR は WSFC が必須の構成となります。
HADR を構築するとクラスターグループとして Availability Group として設定したグループ名が作成されます。

このクラスターグループにはリソースが一つ含まれています。

このリソースですが、[SQL Server Availability Group] というリソースで作成されています。

リソースの所有者が [Primary] として設定されているサーバーになるようですね。

このグループですが、WSFC の管理コンソールからはグループを移動させることはできないようになっているようです。

 

■SSMS で Primary サーバーを切り替え

WSFC のグループは WSFC の管理コンソールからは切り替えることができません。
Primary サーバーを切り替える (フェールオーバーさせる) 場合は、SSMS から操作をする必要があります。

Primary サーバーの切り替えですが、現在 [Primary] サーバーとなっているサーバーの接続からは変更することができません。

• DENALI-01 : Primary
• DENALI-02 : Secondary

となっている場合、DELALI-01 の接続では、サーバーの切り替えをするためのメニューは表示されません。

DENALI-02 に接続し、Secondary で右クリックをするとメニューが少し変わります。

SSMS で Secondary のサーバーに接続をして、Secondary のサーバーを右クリックすると [Force Failover] が表示されます。
[Force Failover] を使用することで Primary と Secondary を切り替えることができます。

CTP1 の Release Notes には以下の記載があります。

The SQL Server Code-Named “Denali” CTP1 release of "HADR" is a preview and does not support the following features:

• Synchronous data movement (synchronous-commit availability mode).

• Manual failover and automatic failover.

  The only supported form is forced failover, which allows data loss and suspends the secondary databases.

• Log compression.

• Automatic page repair.

• The ALTER AVAILABILITY GROUP Transact-SQL statement does not support changing the configuration of the availability group such as changing read-only access to an availability replica, adding or removing an availability database, and adding or removing a secondary availability replica. For information about what this Transact-SQL statement supports, see ALTER AVAILABILITY GROUP (Transact-SQL) in Books Online.

 

現状は マニュアル / 自動フェールオーバーは実装されていないようです。
そのため、Primary / Secondary を切り替えるためには強制フェールオーバーをする必要があります。
# Primary のサービスを停止しても Secondary には切り替わりません。

それでは、[Force Failover] を実行して Primary と Secondary を切り替えてみたいと思います。
DEHALI-02 に接続し、[HADR Group] → [Availability Replicas] を展開して、[DENALI-02] を右クリックし、[Force Failover] をクリックします。
# Secondary の接続でないと [Force Failover] が表示されません。

[OK] をクリックして、フェールオーバーを実施します。

H
ADR の強制フェールオーバーは以上で完了です。

強制フェールオーバー前は以下の状態となっていました。

[DENALI-01]

[DENALI-02]

 

強制フェールオーバーを実施すると以下の状態となります。

強制フェールオーバー前は [Primary] であった、[DENALI-01] が [Secondary] になっているのが確認できます。
強制フェールオーバーを実施した影響だと思うのですが、[Synchronization State] が [Synchronized] から [Not Synchronizing] に変わっています。

データベースの状態も [Online] から [Suspended] に変わっています。

[DENALI-01]

[DENALI-02]

強制フェールオーバーを実施した場合は、自動で [Online] にはならないため手動で HADR による同期を再開する必要があります。

 

同期を再開するためには、[Secondary] に接続をして [Resume Data Movement] を実行する必要があります。

[OK] をクリックして、HADR によるデータ同期を再開します。

Resume をすることでデータ同期が再開されます。

 

自動フェールオーバーや自動ページ修復が実装されるとミラーリングと変わらない利用が出来そうなので期待大ですね。

次の CTP で検証できるようになっているとうれしいですね～。

NEC Express5800/GT110b で iSCSI Boot を実行する方法についてまとめてみたいと思います。

GT110b のオンボード NIC には、Intel の [82574L] というチップセットの NIC が使用されています。
このチップセットですが iSCSI Boot に対応しているのですが、GT110b のオンボード NIC ではiSCSI Boot 用のファームに書き換えることができないため、iSCSI Boot をすることができません。

メーカーのホームページにも iSCSI Boot 不可という記載がされています。
Express5800/GT110b

実際にオンボード NIC のファームを更新しようとすると、以下のように表示がされて更新することができませんでした。

そこで、今回は Intel の [EXPI9301CT] という NIC を購入してこの NIC で iSCSI Boot を設定してみました。
この NIC もオンボードと同じ [82574L]  のチップセットを使用しているのですが iSCSI Boot 用のファームのアップデートを行うことが可能です。
また、オンボードの NIC と同じ Intel の チップセットなのでチーミングを組むことも可能です。
# iSCSI Boot 用のファームにした場合はチーミングを組むことができませんが。
お値段も 3,000 円台と手ごろな価格で入手が可能です。

この NIC を使用して iSCSI Boot を設定していきたいと思います。

ファームのアップデートですが 2 種類の方法があります。

1. 一度ローカルディスク上に OS をインストールしてそこからデバイスマネージャーで iSCSI 用のファームにアップデート
2. USB メモリに起動可能な DOS のイメージを格納して、そこから iSCSI Boot 用のユーティリティを実行

どちらの場合も、以下の URL からダウンロードできるファームを適用します。
iSCSI boot BIOS firmware utility

ファームを書き換えるとチーミング / PXE ブートができなくなるのですが、元のファームに戻したい場合はこちらのファームを適用します。
Intel Boot Agent BIOS image utility ? IBABUILD

 

GT110b の iSCSI Boot の検証をしていて気づいたのですが、オンボードの Software RAID を使用すると iSCSI Boot がうまくできなかったので、この点は注意が必要になるかもしれません。
# Software RAID を有効にすると iSCSI Boot のファームが起動してこなかったのですよね。

 

■ OS インストール後にファームをアップデート

今回は OS として Windows Server 2008 R2 をインストールしています。
82574L のチップセットの NIC ですが、OS のインストールメディアに含まれるドライバで認識ができるのですが、標準ドライバでは細かな設定をすることができません。

Intel のサイトから最新のデバイスドライバをダウンロードしてインストールします。
Network Adapter Driver for Windows Server 2008 R2*
# [PROWinx64.exe] を使用します。

インストールに関してはデフォルトでインストールをすれば問題ありません。

デバイスドライバを最新にするとタブが増えます。

[起動オプション] タブに [フラッシュの更新] ボタンがありますのでこれをクリックして、ダウンロードした iSCSI Boot 用ファームウェアの [iscsi.flb] というファイルを選択し、ファームをアップデートします。

1. [フラッシュの更新] をクリックします。
   
2. [はい] をクリックします。
   
3. [いいえ] をクリックします。
   # PXE ブートのファームに関してはダウンロードできますので。
   
4. [はい] をクリックします。
   
5. [iscsi.flb] を選択して、[開く] をクリックします。
   
6. [はい] をクリックします。
   
   
7. [OK] をクリックします。
   

これでファームの変更は完了です。
ファームが iSCSI Boot バージョンに変更されています。

[アクティブ イメージ] を [iSCSI Boot] に変更すると iSCSI Boot 用の設定をすることが可能になります。

 

 

■DOS 起動可能な USB で起動してファームをアップデート

 

OS をインストールしないでも DOS 起動可能な USB メモリで起動をしてファームを更新することも可能です。
DOS 起動可能な USB メモリを作成する方法ですが、[Windows 98 System Files] と [HP USB Disk Storage Format Tool] を使うと作成することが可能です。

 

作成した USB メモリで起動をすると DOS が起動しますので、コマンドを実行してファームの更新を行います。
USB メモリの中には、iSCSI boot BIOS firmware utility でダウンロードしたファイルを解凍したものを入れておきます。

今回は USB メモリの直下に [iSCSI] というディレクトリを作成してその中に格納をしています。

DOS 起動でファームを iSCSI Boot 用のものにアップデートするときには、[ISCSIUTL.EXE] を使用します。

この EXE を起動すると現在のファームのバージョンを確認することができます。

CD C:ISCSIISCSIUTLDOS ISCSIUTL Intel(R) iSCSI Remote Boot Utility Copyright (C) 2003-2010 Intel Corporation Type iSCSIUTL ?? for help Port Network Address Series  WOL Flash Firmware       Version ==== =============== ======= === ==================== ======== 1   xxxxxxxxxxxxxxxx Gigabit YES PXE Enabled          1.3.53 2   xxxxxxxxxxxxxxxx Gigabit YES FLASH Not Present

 

[1] が今回追加した NIC で [2] がオンボードの NIC になります。
オンボードの NIC は [Flash Firmware] が [FLASH Not Present] となっており、ファームウェアの更新を行うことができません。
これが回避できればオンボード NIC で iSCSI Boot ができるのですけどね…。

ISCSIUTL には[-FLASHENABLE] というオプションがあるのでそれを試してみたのですが駄目でした…。

本題に戻って iSCSI 用のファームにアップデートしたいと思います。

ISCSIUTL でファームを更新する場合、2 種類のオプションのどちらかを使用することが可能です。

1. 全アダプターを対象にして更新可能なものを更新
2. 特定のアダプターを対象として更新

ただし、[2] の [-NIC] [-UPDATE] オプションを使用して更新する方法だと、うまく更新を行うことができませんでした。
そのため、今回は [1] の全アダプターを対象にして更新しています。

CD C:ISCSIISCSIUTLDOS ISCSIUTL ?ALL ?UP Intel(R) iSCSI Remote Boot Utility Copyright (C) 2003-2010 Intel Corporation Press ‘q’ in a prompt to exit the command operation Programing flash on port 1 with flash firmware image Create restore image before proceeding?  (Y)es or (N)o:N Continue update without restore image?   (Y)es or (N)o:Y Updating iSCSI Remove PXE functionality Would you like to Continue?              (Y)es or (N)o:Y Flash update successful Unsupported feature on port 2 ERROR: Flash update was unsuccessful Port Network Address Series  WOL Flash Firmware       Version ==== =============== ======= === ==================== ======== 1   xxxxxxxxxxxxxxxx Gigabit YES iSCSI Enabled        2.5.12 2   xxxxxxxxxxxxxxxx Gigabit YES FLASH Not Present

現状のファームのバックアップを取得しないでファームをアップデートする場合はこのような形で実行を行います。
全アダプターを対象として実行していますので、オンボード NIC も更新しようとするのですがファームのアップデートには対応をしていないためエラーとなっています。

以上でファームのアップデートは完了です。

 

続いて iSCSI Boot 用の設定をしていきたいと思います。
iSCSI Boot 用の設定ですが、OS のデバイスマネージャーかファームのユーティリティを起動して設定をすることができます。

 

■OS から iSCSI Boot を設定

デバイスマネージャーから iSCSI Boot の設定をしてみたいと思います。
デバイスマネージャーからネットワークアダプターのプロパティを開いて設定を行います。

1. [起動オプション] タブをクリックします。
   
2. [アクティブ イメージ] を iSCSI Boot に設定します。
   アクティブイメージを変更することで iSCSI Boot 用の設定をすることが可能となります。
   
3. [起動の優先度] を選択して、[プロパティ] をクリックします。
   
4. [プライマリーの設定] をクリックして、[OK] をクリックします。
   
   
5. [OK] をクリックします。
   
6. [イニシエータ] を選択して、[プロパティ] をクリックします。
   
7. iSCSI イニシエーターの設定情報を入力して、[OK] をクリックします。
   DHCP がある場合は iSCSI  Boot をする NIC の IP アドレスを自動で取得することができますが、今回は固定 IP を割り当てています。
   
8. [ターゲット] を選択して、[プロパティ] をクリックします。
   
9. iSCSI Boot で使用する LUN を用意している iSCSI ターゲットの情報を入力して、[OK] をクリックします。
   私は iSCSI に QNAP の TS-439 を使用していますので、ターゲットの IQN はQNAP 用の設定になっています。
   iSCSI ターゲットの [起動 LUN] に関しては、最初の LUN が [0] になるようですね。
   今回は対象のターゲットにはブート用の LUN 一つのみを設定しています。
   
10. 認証設定をしている場合は、[認証] を選択し [プロパティ] をクリックします。
    
    

続いてファームのユーティリティから iSCSI Boot の設定を実施してみたいと思います。

 

■ファームのユーティリティから iSCSI Boot を設定

オンボードの Soft RAID を有効にしている場合は無効に設定します。

1. 起動時に iSCSI Remote Boot 用のファームが起動してきますので [Ctrl] + [D] をクリックしてファームのユーティリティを起動します。
   # Soft RAID を有効にしているとこの画面が表示されないのですよね…。
   
   

   Intel (R) iSCSI Remote Boot version 2.5.12 Copyright (c) 2003-2010 Intel Corporation. All rights reserved. Press ESX key to skip iSCSI boot initialization. Press <Ctrl-D> to run setup…

2. iSCSI Remote Boot が起動しますので、設定を行うポートを選択して [P] を押して PRIMARY に設定をします。
   設定をしたら [Enter] を押し、確定します。
   
   

   Intel(R) iSCSI Remote Boot v2.5.12 ================================================================================== iSCSI Port Selection MAX:xxxxxxxx Dev:i0D3 Loc:13:0:0 BOOT:PRIMARY   ================================================================================== Select iSCSI Boot priority: P=PRIMARY S=SECONDARY D=DISALED B=BLINK LED

3. [iSCSI Port Selection] を選択し、[Enter] を押します。
   
   

   Intel(R) iSCSI Remote Boot v2.5.12 ================================================================================== iSCSI Port Configuration iSCSI Port Selection iSCSI CHAP Configuration Discard change and Exit Save change and Exit   ================================================================================== Copyright (c) 2003-2010 Intel Corporation. All rights reserved.

4. iSCSI イニシエーターとターゲットの設定をして、[OK] を押します。
   
   

   Intel(R) iSCSI Remote Boot v2.5.12 ================================================================================== iSCSI Boot Configuration [ ] Use dynamic IP Configuration (DHCP)                              Initiator Name:     iqn.2010-11.gt110b-03.local                 Initiator IP:       192.168.0.1                                 Subnet Mask:        255.0.0.0                                   Gateway:            192.168.0.254                               VLAN ID:                                                        [ ] Use DHCP for iSCSI Target information                              Target Name:    iqn.2004-04.com.qnap:ts-439.iscsi.iscsiboot.xxxxxx Target IP:      192.168.0.10                                       Target Port:    3260                                               Boot LUN:       0                                                  [OK]                [Cancel] ================================================================================== Copyright (c) 2003-2010 Intel Corporation. All rights reserved.

5. 認証設定がある場合は、トップのメニューで [iSCSI CHAP Configuration] を選択して設定を行います。
   
   

   Intel(R) iSCSI Remote Boot v2.5.12 ================================================================================== iSCSI CHAP Configuration Specify the same authentication information as configured on the target. [ ] Use CHAP                                                           User Name:                                                    Targert Secret:                                                 [ ] Use MutualCHAP                                                       Initiator Secret:                                                                             Minimum CHAP secret length is 12 and maximum 16. [OK]                [Cancel] ================================================================================== Copyright (c) 2003-2010 Intel Corporation. All rights reserved.

6. 設定が終わったら、トップメニューの [Save changes and Exit] を押して設定を保存します。
7. [ESC] を押してユーティリティを終了させます。

設定が終了して、ユーティリティを終了させると起動画面に戻るのですが設定が正しく行われていれば以下のように表示がされ iSCSI ターゲットの LUN に接続ができていることを確認できます。

Initializing adapter configuration ? MAC address (xxxxxxxxxxxxxxxxx). Using STATIC configuration for primary port, please wait. iSCSI Target Name       : iqn.2004-04.com.qnap:ts-439.iscsi.iscsiboot.xxxxxx  iSCSI Target IP Address : 192.168.0.10 LUN ID: 0                   Port: 3260 iSCSI Initiator IP      : 192.168.0.1 iSCSI Gateway IP        : 192.168.0.254 iSCSI Initiator Name    : iqn.2010-11.gt110b-03.local Attempting to connect to target disk using MAC address (xxxxxxxxxxxx) LUN: 0   DEVICE: QNAP iSCSI Storage  40.0 GB

ここまでで設定は完了です。

内蔵のディスクに OS をインストールしている場合は、BIOS のブート順で [PCI SCSI: Intel (R) iSCSI Remote Boot] を [IDE HDD] より上になるように設定をしておきます。
# Soft RAID を有効にしていると Remote Boot がブート対象として表示されないのですよね。

iSCSI Boot でインストールした環境がこちらになります。
40GB の領域が iSCSI の領域になります。

Soft RAID と併用する方法が分かっていないのですが、iSCSI Boot の検証したいときには利用ができそうです。
Soft RAID 構築後にジャンパピンを変更しても設定はそのまま残っていますので、iSCSI Boot に切り替えたいときも既存環境を壊さないで確認ができます。

 

iSCSI Boot から PXE Boot 用のファームに変更したいときは、Intel Boot Agent BIOS image utility ? IBABUILD からダウンロードしたファームを適用すれば戻すことができます。

作業内容は同じで、OS から変更する場合はデバイスマネージャーで NIC のプロパティを開いて、[フラッシュの更新] から

[BA1353L2.FLB] を選択して適用を行います。

iSCSI Boot で起動している状態で、iSCSI Boot に使用している NIC に対して変更できました。

DOS 起動可能な USB メモリから変更する場合は、以下のコマンドを実行します。
# USB メモリに [Boot] というディレクトリを作成してその中にダウンロードしたファイルを展開しています。

CD C:BOOT IBAUTIL.EXE ?ALL ?UP

設定も簡単に戻せるので気軽に検証ができそうですね。
EXPI9301CT は amazon でも購入できますので入手も難しくありませんので結構おすすめかもしれないですね。