IT号着地号いろいろ号

netsh traceはPowerShellへ流れている

下記のコマンドですが、PowerShellの方を推奨していたりすることはありませんか。

netsh trace start capture=yes traceFile=C:\NetTrace.etl maxSize=1024 fileMode=circular overwrite=yes

netsh trace stop

結論から申し上げますと、
ご指摘の通り現在は **PowerShell（特に `NetEventPacketCapture` モジュール）の使用が推奨されています。**

`netsh trace` は長年使われてきた非常に強力なツールですが、
Microsoftはネットワーク管理において、よりオブジェクト指向で
扱いやすい PowerShell コマンドレットへの移行を進めています。

---

### なぜ PowerShell が推奨されるのか？

`netsh` は「文字列」として結果を返しますが、
PowerShell は「オブジェクト」としてデータを扱います。これにより、フィルタリングや自動化が圧倒的に楽になります。

また、`netsh trace` で生成される `.etl` ファイルは解析に
「Message Analyzer（開発終了）」や「Network Monitor」が必要でしたが、
PowerShell 経由であればより現代的な解析ワークフローに乗りやすいというメリットもあります。

---

### PowerShell での代替コマンド

ご提示いただいた `netsh` コマンド（1GBの循環バッファでキャプチャ）を PowerShell で再現すると以下のようになります。

**1. セッションの作成と設定**

```powershell
New-NetEventSession -Name "MyTrace" -LocalFilePath "C:\NetTrace.etl" -MaxFileSize 1024 -FileMode Circular

```

**2. プロバイダー（キャプチャ対象）の追加**
※ `netsh trace` の `capture=yes` に相当する、標準的なネットワークトレースを追加します。

```powershell
Add-NetEventPacketCaptureProvider -SessionName "MyTrace"

```

**3. キャプチャ開始**

```powershell
Start-NetEventSession -Name "MyTrace"

```

**4. キャプチャ停止**

```powershell
Stop-NetEventSession -Name "MyTrace"
Remove-NetEventSession -Name "MyTrace"

```

---

### 比較まとめ

| 機能 | netsh trace (従来) | PowerShell (推奨) |
| --- | --- | --- |
| **構文の分かりやすさ** | 独特な引数が多い | 他のPSコマンドと共通の形式 |
| **自動化・スクリプト** | 文字列操作が必要で困難 | オブジェクトで制御可能 |
| **柔軟性** | プリセット（Scenario）が強い | フィルタリングの自由度が高い |
| **今後のサポート** | メンテナンスモード | 積極的な機能追加対象 |

### 注意点：使い分けのヒント

* **現場での手軽さ:** 1行でサクッと終わらせたい、あるいは古い Windows Server (2012以前など) を触る必要がある場合は、依然として `netsh trace` が現役で使われることも多いです。
* **今後の標準:** Windows 10/11 や Windows Server 2016 以降の環境であれば、PowerShell の作法に慣れておくのが「正解」と言えます。

ネットワークトラブルの初期切り分け

ネットワークトラブルの初期切り分け

### 1. Ping request could not find host
* **詳細原因:** DNSサーバーに問い合わせたが、そのホスト名に対応するIPアドレスが見つからない状態です。
* **補足:** * 単なるタイポ（打ち間違い）の可能性も高いです。
* `nslookup [ホスト名]` を実行して、DNSサーバー自体が生きているか確認するのが定石です。

### 2. Destination host unreachable（宛先ホストに到達不能）
* **原因:** 「宛先へのルート（道筋）がわからない」状態。
* 自分のPCにデフォルトゲートウェイが設定されていない。
* 途中のルーターが、その先のネットワークへの経路を知らない。
* 同一セグメントなら、ご指摘の通り「ARP解決できない（IPはあるがMACアドレスが不明）」状態。

* **対応:** * `tracert -d [宛先IP]` を実行。どこで「到達不能」が返ってくるか特定する。
* 自身のIP設定（サブネットマスク等）が正しいか再確認。

### 3. General failure（一般エラー）

* **詳細原因:** Windows内部のネットワークスタック（OSの送信準備段階）で問題が起きています。
* NIC（LANカード）が無効、またはケーブル断線。
* サードパーティ製セキュリティソフトによる強力な遮断。

* **対応:** * `ipconfig` でNICが有効か、IPが `169.254.x.x` (APIPA) になっていないか確認。
* 一度NICを無効→有効にするだけで直ることも多いです。

### 4. Request timed out（要求がタイムアウトしました）
* **詳細原因:** 「道はつながっているが、返事がない」状態。
* 宛先PCが起動していない。
* 宛先PCや途中のFWでICMP（Ping）がブロックされている。
* **戻りの経路**がない（行きは届いたが、帰りの道を知らない）。

* **対応:** * 「Pingが通らない」という結果自体は出ているので、
次に**「別の機器（隣のPCなど）からは通るか？」**を確認し、
問題が「経路」か「宛先単体」かを切り分けます。

---
## 切り分けクイックリファレンス表
| エラーメッセージ | 疑うべき場所 | 最初のアクション |
| **Could not find host** | DNS / 名前解決 | `nslookup` または IPで直接叩く |
| **Destination unreachable** | ルーティング / 自設定 | `tracert` で止まる場所を確認 |
| **General failure** | 自PCの物理・OS設定 | NICの状態確認・再起動 |
| **Request timed out** | 宛先PC / FW / 戻り経路 | 宛先のFW設定確認・別端末からの試行 |
---

Wireless/NPS

Wireless/NPS（Network Policy Server）は、Microsoft Windows Serverの役割の一つで、無線LAN（802.1X）やVPN接続において、ユーザーの認証、認可、アカウンティング（AAA）を一元管理するRADIUSサーバー機能

BranchCache

BranchCacheは、Windows ServerとWindowsクライアントで構成されるネットワーク環境において、遠隔地（ブランチオフィス）から本社サーバー上のファイルやデータにアクセスする際、そのキャッシュをローカルエリアネットワーク（LAN）上に一時保存することで、WAN帯域の節約とアクセス高速化を実現する機能

GPO（グループポリシーオブジェクト）の基本

GPO（グループポリシーオブジェクト）の基本

GPOの適用対象
１．ドメイン
２．OU
３．サイト
※ユーザやPC個別は出来ない

GPO適用タイミング
コンピュータポリシー
１．PCの起動時
２．ドメインメンバー：９０〜１２０分の間でランダム
　　ドメインコントローラ：５分間隔

ユーザポリシー
１．ユーザのログオン時
２．９０〜１２０分の間でランダム

強制適用のコマンド
gpupdate /force

ループバック
特定のコンピュータにログオンしたときにだけ適用させたいユーザポリシーがある場合に使用。

▼補足
## 1. 適用対象と優先順位（LSDOU）
GPOには適用される順番があり、後に適用されたものが
優先（上書き）されます。このルールをLSDOUと呼びます。

1. Local（ローカル）：PC本体の設定
2. Site（サイト）：物理的な拠点ごと
3. Domain（ドメイン）：ドメイン全体
4. OU（組織単位）：部署やチームごと（これが最も優先度が高い）

補足：ご認識の通り、ユーザー個別の設定項目はありませんが、
「特定のユーザーだけに適用したい」場合は、OUを分けるか
「セキュリティフィルタリング」という機能を使って制限をかけるのが一般的です。

## 2. 適用の例外ルール
基本の順番（LSDOU）を無視して制御したい時に使う、2つの重要機能があります。

継承のブロック：上位（ドメインなど）で設定されたポリシーを、特定のOUにだけは適用させたくない場合に使用します。
強制（Enforced）：下位のOUで「継承のブロック」がされていても、それを無視して強制的に適用させます。

## 3. 適用タイミングの補足
「90〜120分のランダム」という点についてですが、正確には
「90分＋ 0〜30分のオフセット（遊び）」という計算です。
なぜランダムかというと、全クライアントPCがいっせいに
ドメインコントローラに通信しに行くと、ネットワークがパンクしてしまうのを防ぐためです。

## 4. ループバック処理の活用シーン
ループバックは少し理解が難しい部分ですが、以下のようなケースでよく使われます。

会議室の共有PC：「誰がログオンしても、このPCではコントロールパネルを禁止にしたい」といった、
「場所（PC）」に紐づいた制限をユーザー設定にかけたい時に必須となります。

## 5. デバッグに役立つコマンド

`gpupdate /force` 以外に、現場で必ず使うコマンドを紹介します。

| コマンド | 用途 |
| `gpresult /r` | 現在どのGPOが適用されているか、コマンドプロンプト上で確認できます。 |
| `gpresult /h report.html` | 詳細な適用結果をHTMLファイルとして出力します（非常に見やすいです）。 |
| `rsop.msc` | 視覚的にどの設定が有効になっているかを確認できるツールを起動します。 |

Kerberos認証

Kerberos認証の流れ
１．AS Request(SSO可能)
　KDC(AS)に対して、TGTの発行を要求

２．AS Response(SSO可能)
　要求者が本人であることを確認、TGTを発行

３．TGS Request
　リソースにアクセスするために、KDC(TGS)に対して、取得済みのTTをそえてSTを要求

４．TGS Response
　アクセスを要求されているリソースの情報を確認、STを発行

５．AP Request
　アクセスするリソースへSTを提示して、サービスの利用を要求

６．AP Response
　提示されたSTを確認、アクセスを許可。これでKerberos認証完了。

▼詳細
Kerberos（ケルベロス）認証をより直感的に理解するために、
「テーマパークの入園とアトラクション」に例えて解説します。
## わかりやすい例え：ディズニーランドの仕組み

Kerberosのやり取りは、まるで大きなテーマパークで遊ぶ時の流れと同じです。
KDC（チケット売り場）: パークの運営事務局
TGT（入園パスポート）: 園内ならどこでも持ち歩ける「本人確認済み」の証
ST（アトラクション利用券）: 「スプラッシュマウンテン専用」など、特定のリソースに入るための券
リソース（アトラクション）: 実際に使いたいサーバーやファイル

## 認証のステップ（ストーリー仕立て）
1 & 2：まずは「入園パスポート(TGT)」をもらう

AS Request / Response
何をしているか: あなたがチケット売り場（AS）に行って、身分証を見せます。
結果: 「よし、君は本人だね」と認められ、TGT（入園パスポート）をもらいます。
　　　　　　これで園内の「中」には入れますが、まだ個別の乗り物には乗れません。

3 & 4：乗りたい物の「利用券(ST)」に引き換える
TGS Request / Response
何をしているか: 園内の案内所（TGS）へ行き、TGT（パスポート）を見せて
「このファイルサーバー（アトラクション）を使いたい」と言います。
結果: 案内所はパスポートを確認し、そのサーバー専用のST（利用券）をくれます。

5 & 6：いよいよ「サービス」を利用する

AP Request / Response
何をしているか: 目的のサーバー（アトラクションの入り口）へ行き、ST（利用券）を見せます。
結果: サーバー側は「その券は本物だね、どうぞ！」と許可し、ついにデータにアクセスできます。

ワンポイント・アドバイス：
「TGT」は「入園パスポート」、「ST」は「各施設の入場チケット」と考えると、
AD（アクティブディレクトリ）の環境でなぜ2種類のチケットが必要なのかがよりスッキリ理解できるはずです。

ADDSについて

ADDS（Active Directory Domain Services）について

1. ドメインコントローラ（DC）の本質
DCは、ネットワーク内の「お役所」兼「警察署」のような存在です。

ntds.dit（住民基本台帳）：誰がどこに住んでいるか
（ユーザー名、パスワード、所属部署）を記録した巨大なデータベースです。
SYSVOL（校則・ルールブック）：「壁紙はこれにする」「パスワードは10桁以上」といった
グループポリシー（GPO）の実体ファイルが置かれる共有フォルダです。

2. FSMO（フィスモ）を「役割」で理解する
ADは基本的に、どのDCで情報を書き換えても全体に同期される
「マルチマスター方式」ですが、「同時にあちこちで変えると困る重要な仕事」
だけは、特定の1台が担当します。これがFSMOです。

5つの役割を、もう少し直感的に分類してみましょう。
A. フォレストに1台だけの「大きな決断」担当
スキーママスター
「名簿の項目」を決める人。住所や電話番号のほかに「血液型」という項目を増やす、といったデータベースの構造変更を管理します。
ドメイン名前付けマスター
「支店（ドメイン）」の増設担当。フォレスト内に新しいドメインを作る際、名前が重複しないように管理します。

B. 各ドメインに1台ずつの「日常業務」担当
PDCエミュレーター
「時間の番人」兼「最後の審判者」。
ドメイン内の時計を合わせるリーダーであり、パスワード変更の即時反映も行います。
FSMOの中で最も忙しく、止まると影響が大きい役割です。

RIDマスター
「IDの発行機」。
ユーザー作成時に必要な「背番号（SID）」の元ネタを、各DCに束で配ります。
これが枯渇すると新しいユーザーが作れなくなります。

インフラストラクチャマスター
「外部参照の整理係」。他のドメインのユーザーが自ドメインのグループに
入っている時、その名前変更などを追いかけて整合性を保ちます。

さらに理解を深めるポイント
なぜFSMOを分けるのか？
通常は1台のDCが5つの役割をすべて兼任していますが、
大規模環境では負荷分散や障害対策のために役割を分散させることがあります。

グローバルカタログ (GC)
まとめにはありませんが、ADを語る上で「GC」も重要です。
これはフォレスト全体の情報を検索しやすくするための
「索引（インデックス）」の役割を持ち、ログイン処理を高速化します。

パッチ適用テスト

パッチ適用テスト
物理PCを一台ずつ手作業で検証するよりも、
仮想環境でゴールデンイメージ（マスターイメージ）を
更新してテストする方が、はるかに効率的で安全です。

AVDと一般的なVDIの違い
ざっくり言うと、「全部自分で管理するプロ仕様のVDI」か、
「Microsoftにお任せできるクラウド版VDI」か、という違いです。

Azure Virtual Desktop = AVD

slmgr /ipk というコマンドを叩くことがよくあります。
この ipk も「Install Product Key」の略

Windowsの更新プログラム（アップデート）の種類

Windowsの更新プログラム（アップデート）の種類について

1. Bリリース (B-release)
一般的に「パッチチューズデー（火曜日のパッチ）」と呼ばれる、最も重要な更新プログラムです。

配信時期: 毎月第2火曜日（米国時間）。日本時間では第2水曜日の未明に配信されます。
内容: セキュリティの脆弱性修正（セキュリティ更新）と、過去に配信された修正をまとめた累積的な更新が含まれます。
特徴: 強制適用: セキュリティ維持のため、Windows Updateで自動的にインストールされる設定になっていることが多いです。
すべてのユーザーが受け取る「本番」の更新です。

2. Cリリース (C-release)
主に翌月のBリリースに向けた「プレビュー版」という位置づけの更新プログラムです。

配信時期: 毎月の第3または第4週。
内容: セキュリティ以外の修正（バグ修正や新機能の先行導入）が含まれます。
特徴: オプション提供: 自動ではインストールされず、
設定画面で「ダウンロードしてインストール」を手動でクリックしたユーザーにのみ適用されます。
IT管理者や「最新の状態をいち早く試したい」ユーザーが、翌月の本番配信前にテストするために利用されます。

3. OOB (Out-of-Band)
「帯域外」、つまり定例のスケジュールを外れて急遽配信される例外的な更新プログラムです。

配信時期: 不定期（緊急時）。
内容: 悪用が始まっている深刻な脆弱性の修正や、多くのユーザーに影響を与える致命的な不具合の解決など。
特徴: 次の「Bリリース」を待てないほど緊急性が高い場合にのみ発行されます。
非常に重要な内容であるため、速やかな適用が推奨されます。

更新リリースの比較まとめ
| 種類 | 通称 | 配信時期 | 重要度・目的 |
| Bリリース | 定例アップデート | 第2火曜日（米） | 高い（セキュリティ修正） |
| Cリリース | プレビュー更新 | 第3・4週 | 中（バグ修正の先行テスト） |
| OOB | 緊急パッチ | 随時 | 極めて高い（緊急の脆弱性対策） |

Windows Update for Business (WUfB)

Microsoft Intune の Windows Update for Business (WUfB) は、WSUS（Windows Server Update Services）等の不要なローカルサーバーを介さず、Intune経由でWindows 10/11の更新（品質/機能）をクラウドから直接、管理・展開・制御できる機能です。更新のタイミングや強制再起動のスケジュールを詳細に設定し、組織全体のセキュリティとパフォーマンスを最適化できます

IT号 着地号 いろいろ号