Windows Server 2016 の Server Core（GUIなし）に AWVS（Acunetix）をインストールしたのに、起動すると「You’ll need a new app to open this awvs（この awvs を開くには新しいアプリが必要です）」と出て実行できない――。この症状は AWVS 本体の故障というより、Server Core 特有の「起動方式」「関連付け」「権限」「ブラウザー不在」が絡んで発生しがちです。現場で使える切り分けと対処をまとめます。
起きている症状を整理する
表示される「You’ll need a new app to open this awvs」は、Windows が“awvs というプロトコル（リンク）や拡張子を開く担当アプリを見つけられない”ときに出やすいメッセージです。つまり、あなたが意図している「AWVS の実行ファイル（.exe）を起動する」ではなく、Windows 側が別の“開く処理”として解釈している可能性が高い、というのが第一のポイントです。
Server Core 環境では特に、次のような事情でこの手のエラーが表面化しやすくなります。
- GUI がないため、ソフトが内部で「ブラウザーを起動」「GUI を開く」「設定アプリを開く」などを要求すると失敗しやすい
- スタートメニューのショートカット等がURL プロトコル（例：awvs://）で実装されていると、関連付けが崩れた瞬間に起動できない
- UAC/権限、サービス起動、ファイアウォールなどの“周辺要因”が原因でも、結果として起動に失敗して見える
まずは切り分け：何を「起動」しようとしているか確認する
同じエラーメッセージでも、実際に実行しているものがexeなのか、ショートカット（.lnk）なのか、プロトコル（awvs:）なのかで、対処が変わります。最初にここをはっきりさせると、遠回りを防げます。
| やっている操作 | 例 | 起きがちなこと | 優先して試す対処 |
|---|---|---|---|
| コマンドで awvs を叩いている | awvs / start awvs | awvs.exe が存在しない／Shell がプロトコル扱いにしている | 実行ファイルをフルパスで起動、where で実体確認 |
| ショートカットやリンク相当を実行している | 何らかの .lnk / 登録された起動コマンド | 内部が awvs:// のようなプロトコル呼び出しで、関連付けがないと失敗 | ショートカットを使わず exe を直接起動 |
| exe を直接実行している | C:\...\xxx.exe | 権限不足、依存コンポーネント不足、GUI前提で落ちる | 管理者で実行、サービス/ログ確認、再インストール |
Server Core で実体を確認するコマンド例
まず「awvs という名前で呼び出しているものの正体」を確認します。
where awvs
where /R "C:\Program Files" *awvs*.exe
where /R "C:\Program Files" *acunetix*.exe
REM インストール先が分からない場合の雑な探索
dir "C:\Program Files" /b
dir "C:\Program Files (x86)" /bwhere awvs で何も出ないのに「新しいアプリが必要」と出るなら、あなたが起動しているのは exe ではなく、プロトコル/関連付けの可能性が濃厚です。以降の対処を順に当てていきます。
対処：管理者として明示的に実行する（runas で起動）
Server Core は GUI がないぶん、権限不足のときに「それっぽい別のエラー」に見えることがあります。特に、インストール直後やサービス登録直後は管理者権限での初回起動が効くケースがあります。
CMD を開き、runas で管理者ユーザーを指定して exe を起動します（ユーザー名・パス・引用符の扱いが重要です）。
runas /user:<ドメイン名またはコンピューター名>\<管理者ユーザー名> "<プログラムのフルパス>"
例（ローカル管理者で実行）
runas /user:.\Administrator "C:\path\xxx.exe"
例（ドメイン管理者で実行）
runas /user:CONTOSO\AdminUser "C:\path\xxx.exe"exe に引数が必要な場合は、cmd /c を噛ませると事故りにくいです。
runas /user:.\Administrator "cmd /c ""C:\path\xxx.exe"" --help"よくある落とし穴
- パスに空白があるのに引用符が足りない（
C:\Program Files\...など） - 実行しているのが exe ではなく、ショートカット/プロトコルだった（この場合 runas でも改善しないことが多い）
- そもそも“管理者の CMD”で開けていない（Server Core でも、権限が分かれます）
「管理者で開けているか」を確認するだけでも切り分けになります。
whoami
whoami /groups対処：AWVS は「Server Core 上でブラウザーを開く」前提を捨てて運用する
AWVS（Acunetix）は、ローカルで GUI を起動して操作するというより、Web 管理画面で操作する流れが中心の構成になっていることが多いです。Server Core ではブラウザーや GUI が使えないため、起動時に「ローカルブラウザーを開こうとして失敗」→「awvs を開くアプリが必要」といった形でつまずくことがあります。
実務では、次の運用に寄せるのが安定します。
- Server Core 側：AWVS をサービスとして動かす（スキャンエンジン/管理UIのバックエンド）
- 別 PC（Windows クライアントや Desktop Experience サーバー）側：ブラウザーで Web 管理画面へアクセス
サービスが動いているか確認する
まずは AWVS/Acunetix らしきサービスが存在し、起動しているかを確認します（サービス名はバージョンで変わることがあります）。
sc query type= service | findstr /i acunetix
sc query type= service | findstr /i awvs
REM 状態が STOPPED なら起動（表示されたサービス名を指定）
sc start "<サービス名>"ポートが待ち受けているか確認する（Web UI が立っているか）
Web 管理画面が動いていれば、どこかの TCP ポートで待ち受けます。既定のポートは環境差があるため、最も確実なのは netstat で確認する方法です。
netstat -ano | findstr LISTENING
REM よく使われがちなポート帯を当てる例（確定ではないので要確認）
netstat -ano | findstr ":3443"
netstat -ano | findstr ":443"
netstat -ano | findstr ":80"待ち受けポートが分かったら、別 PC のブラウザーから次のようにアクセスします。
https://<サーバー名またはIP>:<待ち受けポート>/
運用上の注意（重要）
- 管理画面は社内の管理用ネットワークからのみアクセスできるようにする（不要な公開はしない）
- Windows ファイアウォールで許可する送信元を限定する（同一サブネット/踏み台サーバーのみ等）
- 初期パスワード運用は避け、強固な管理者パスワードと二要素認証など製品側の機能があれば活用する
Windows ファイアウォールでアクセスを通す例
検証目的で一時的に開ける場合でも、最終的には許可範囲を絞るのが安全です。まずは必要最低限で疎通させます（ポートは netstat で判明した値に置き換えてください）。
REM 例：TCP 3443 を許可（必要に応じてポート番号を変更）
netsh advfirewall firewall add rule name="AWVS Web UI" dir=in action=allow protocol=TCP localport=3443より安全にするなら、送信元 IP を限定します。
REM 例：管理端末のIP（192.0.2.10）だけ許可
netsh advfirewall firewall add rule name="AWVS Web UI (Admin PC only)" dir=in action=allow protocol=TCP localport=3443 remoteip=192.0.2.10対処：ショートカットや「awvs:」プロトコル起動を避け、exe を直接叩く
今回のエラー文言からすると、OS が「awvs を“開く”」処理として扱っている可能性が高いです。つまり、起動の入口が exe ではない（プロトコル呼び出しや関連付け）ことが多い、ということです。
この場合、正攻法は単純で、AWVS の実行ファイルをフルパスで直接起動します。
REM 例：インストール先を探してから実行（パスは環境に合わせて）
dir "C:\Program Files" /s /b | findstr /i acunetix
dir "C:\Program Files" /s /b | findstr /i awvs
REM 見つかった exe をそのまま実行
"C:\path\to\found.exe"もし「インストール時に作られた起動コマンド（ショートカット相当）」を確認したい場合、PowerShell が使える環境なら、.lnk の Target を参照できます（Server Core でも PowerShell は利用可能な構成が多いです）。
$lnkPath = "C:\path\to\shortcut.lnk"
$wsh = New-Object -ComObject WScript.Shell
$sc = $wsh.CreateShortcut($lnkPath)
$sc.TargetPath
$sc.ArgumentsTarget/Arguments が awvs:// のような URL プロトコル呼び出しになっている場合は、Server Core ではそのままでは詰まりやすいので、Target を exe に置き換えた起動手段（バッチ、タスク、サービス起動＋リモートアクセス）に寄せるのが現実的です。
対処：アンインストール → 再インストールで関連付け・登録の崩れを戻す
「関連付けやプロトコル登録が途中で壊れている」「サービス登録が不完全」「依存ランタイムの導入順が悪かった」など、インストールの“状態不整合”で起動できないケースもあります。Server Core は GUI がないぶん、失敗したときの復旧手順も分かりづらいため、入れ直しが一番早いことが少なくありません。
ただし Server Core では「プログラムの追加と削除」が使えないため、アンインストール方法を押さえておくと安全です。
| 方法 | コマンド例 | メリット | 注意点 |
|---|---|---|---|
| インストールフォルダ内のアンインストーラ | C:\path\uninstall.exe | 製品側の想定手順で外せる | 場所が分からないと探す必要がある |
| レジストリの UninstallString を参照して実行 | reg query ... /s /f "Acunetix" | GUI不要で確実に手がかりが取れる | 表示されたコマンドの引用符/引数に注意 |
| MSI なら msiexec でアンインストール | msiexec /x {GUID} | 手順が標準化できる | 製品が MSI 提供である必要がある |
UninstallString を探す（Server Core でもやりやすい）
REM 64bit アプリ候補
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" /s /f "Acunetix"
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" /s /f "AWVS"
REM 32bit 側（WOW6432Node）候補
reg query "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall" /s /f "Acunetix"
reg query "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall" /s /f "AWVS"表示された UninstallString（アンインストールコマンド）をコピーして実行し、完了後に再起動→再インストールを行います。再インストールは管理者のコンソールから行い、インストール直後に起動するタイプのセットアップなら、いきなり起動でつまずかないように「サービスが起動しているか」「Web UI へ外部からアクセスできるか」を先に確認すると安定します。
対処：ログとイベントで「どこで失敗しているか」を掴む
Server Core だとイベントビューアー GUI がないため、ログ確認が後回しになりがちです。ですが、「アプリの起動」問題はログを見るだけで一気に原因が絞れることが多いです。
Windows イベントログを wevtutil で確認する
REM Application ログの最新 30 件をテキスト表示
wevtutil qe Application /c:30 /f:text
REM System ログも併せて確認
wevtutil qe System /c:30 /f:textAWVS/Acunetix 由来のエラー、.NET ランタイム、サービス起動失敗、ポート競合（既に他プロセスが使用）などが出ていないかを見ます。
製品ログの場所を探す
製品ログは、インストールディレクトリ配下や C:\ProgramData 配下にあることが多いです。場所が分からない場合は、ログっぽいファイルを検索します。
REM ProgramData 配下で "acunetix" 文字列を含むファイル名を探す例
dir "C:\ProgramData" /s /b | findstr /i acunetix
REM PowerShell の場合（重いので範囲は絞る）
Get-ChildItem -Path "C:\ProgramData" -Recurse -ErrorAction SilentlyContinue |
Where-Object { $_.Name -match "log|acunetix|awvs" } |
Select-Object FullNameログに「ブラウザー起動に失敗」「UI 起動に失敗」「プロトコル関連付けがない」等の記載があれば、Server Core ではローカル UI 起動を諦めて Web UI 運用へ寄せる判断がしやすくなります。
それでも解決しない場合：ベンダー（Acunetix）へ問い合わせる前に揃える情報
3rd パーティ製品固有の挙動は Microsoft 側だけでは追いづらく、サポートへ問い合わせるのが最短になることがあります。その際、情報が揃っていると往復が減って復旧が早まります。
| 項目 | 例 | 取得方法 |
|---|---|---|
| OS 情報 | Windows Server 2016 / Server Core / ビルド | systeminfo / ver |
| AWVS（Acunetix）のバージョン | 製品名、ビルド番号 | インストール先のバージョン表記、ログ、レジストリ等 |
| 何を実行したか | exe 直叩き / awvs:// / ショートカット | 実行コマンド、.lnk の Target/Arguments |
| サービス状態 | RUNNING / STOPPED | sc query |
| 待ち受けポート | LISTENING のポート番号 | netstat -ano |
| イベントログ抜粋 | Application/System の該当エラー | wevtutil qe |
特に「Server Core での利用がサポート対象か」はベンダー回答が最重要です。サポート外なら、いくら OS 側をいじっても安定しません。
実務判断：Server Core を維持するか、Desktop Experience へ切り替えるか
Server Core は攻撃面積を減らしやすい一方で、GUI 前提のソフトは相性問題が出ます。AWVS のように管理 UI が絡む製品は、運用のしやすさも含めて判断が必要です。
| 観点 | Server Core 継続 | Desktop Experience へ切替 |
|---|---|---|
| 互換性 | GUI 前提の起動がつまずきやすい | 起動方式の相性問題が減る |
| 運用 | Web UI を別端末で操作する形に寄せると安定 | サーバー単体で完結しやすい |
| セキュリティ/保守 | 機能が少なく管理対象が減るメリット | GUI 分の更新・管理も増える |
| おすすめパターン | スキャンエンジンは Server Core、操作は別 PC から | AWVS をそのサーバーで完結運用したい場合 |
「Server Core に置く理由」が強い（役割分離、最小構成、既存標準）なら、UI 起動を捨てて Web 管理画面運用に寄せるのが現場では最も事故が少ない選択になりがちです。一方、検証環境や単体運用が目的なら、最初から Desktop Experience へ寄せたほうが時間を溶かしません。
まとめ：このエラーで最優先すべきこと
- 「awvs を開くには新しいアプリが必要」は、exe 起動ではなく関連付け/プロトコル起動になっているサインであることが多い
- runas で管理者として exe をフルパス起動し、入口の問題（権限/関連付け）を潰す
- Server Core ではローカルで GUI やブラウザーを開く運用は避け、サービス起動＋別端末ブラウザーから Web UI へアクセスするのが堅い
- 再現が続く場合は、アンインストール→再インストールで登録崩れを戻す
- 最終的にサポート範囲がボトルネックになるため、情報を揃えてベンダーに確認する
Server Core は“サーバー役割を最小構成で動かす”ことに強い一方、脆弱性診断ツールのように UI と連動する製品は、起動経路が少し崩れただけで今回のようなメッセージに繋がります。起動の入口を exe に寄せ、サービス稼働と Web 管理画面への到達性（ポート・FW）を押さえるだけで、運用は一気に安定します。
コメント