DC 兼ファイルサーバーの「旧サーバー」から新しいファイルサーバーへ共有データを移行した後、未更新のショートカットやドライブ割り当てで旧共有（例：\\FS1\users）にアクセスされるのを止めたい──ただし SYSVOL/NETLOGON を壊さず安全に。現場でそのまま使える判断基準・手順・ロールバックの残し方をまとめます。
なぜ「SMB を止める（NIC のファイルとプリンター共有を外す／Server サービス停止）」は危険なのか
旧サーバーがドメインコントローラー（DC）である場合、ファイル共有（SMB）は「ユーザー共有のため」だけではなく、ドメイン運用そのものに関わる共有として使われます。代表例が SYSVOL と NETLOGON です。
多くの Windows クライアントは、グループポリシー（GPO）の適用やログオンスクリプトの取得のために DC 上の共有へアクセスします。ここで SMB 全体を止めてしまうと、意図せず SYSVOL/NETLOGON 共有も止まり、ログオン処理や GPO 適用に影響が出るリスクが一気に高まります。
| やりたいこと | ついやりがちな手 | DC でのリスク | 推奨アプローチ |
|---|---|---|---|
| 旧ユーザー共有だけ止めたい | NIC の「ファイルとプリンター共有」を無効化 | SYSVOL/NETLOGON まで止まる可能性、GPO/ログオン影響 | ユーザー向け共有のみを削除・改名・アクセス制御 |
| 旧共有に入らせたくない | Server（LanmanServer）サービス停止 | SMB 全共有停止（運用影響が大きい） | 共有単位で「止める」「迷子にする」「案内に差し替える」 |
| ロールバックに備えて設定を残したい | 共有権限や NTFS 権限をぐちゃぐちゃに変更 | 復旧が複雑化、想定外の拒否/許可 | 共有定義のバックアップ→共有名変更 or 共有削除 |
まず押さえる：DC で「残すべき共有」と「止めたい共有」を分ける
旧サーバー上の共有には、Windows が自動で用意するもの（管理共有・ドメイン運用共有）と、業務用に作ったユーザー共有が混在します。ここを切り分けるのが第一歩です。
| 共有名（例） | 種類 | 用途 | 基本方針 |
|---|---|---|---|
| SYSVOL | ドメイン運用 | GPO（ポリシー/テンプレート/スクリプト）の配布 | 残す（止めない） |
| NETLOGON | ドメイン運用 | ログオンスクリプトなど | 残す（止めない） |
| ADMIN$ / C$ / IPC$ | 管理共有 | 運用・リモート管理で利用されることが多い | 原則そのまま（方針次第） |
| users / dept / data など | ユーザー共有 | 業務データ格納・ホームフォルダー等 | 止める対象 |
この「止める対象」は基本的に 共有の定義（共有名・共有権限）を触るだけで実現できます。フォルダーそのもの（NTFS 権限）まで触る必要がないケースがほとんどです。
結論：DC では SMB 自体を止めず「ユーザー向け共有だけ」を止める
やることはシンプルです。SYSVOL/NETLOGON を残したまま、ユーザー向け共有だけを無効化します。手段は主に次の 3 つで、要件（完全遮断・復旧容易性・案内の必要性）で選びます。
| 方法 | 旧パス（\\FS1\users）への効果 | 共有設定の保持 | ロールバック | おすすめ度 |
|---|---|---|---|---|
| 共有を削除（解除） | 即座にアクセス不可（パスなし） | 共有権限は消える（控えが必要） | 再作成が必要 | ◎（運用をきっぱり切る） |
| 共有名を変更（迷子にする） | 旧パスは失敗（共有名が変わる） | ほぼ保持（共有定義を残しやすい） | 戻すだけ | ◎（ロールバック前提なら最適） |
| 共有権限でアクセス拒否 | 旧パスは「アクセス拒否」 | 保持（ただし ACL 変更） | ACL を戻す必要 | ○（監査/案内と相性良い） |
手順：変更前に必ずやる「共有の棚卸し」と「共有定義のバックアップ」
いきなり共有を消す・改名する前に、現在の共有定義（共有名、パス、説明、共有レベルの権限）を控えておくと、ロールバックが圧倒的に楽になります。GUI でも可能ですが、PowerShell で一括取得しておくと抜け漏れが減ります。
PowerShell で共有一覧を確認する
旧サーバー（DC）で管理者として実行します。
Get-SmbShare | Sort-Object Name | Select-Object Name,Path,Descriptionこの出力で、SYSVOL / NETLOGON と、業務用の共有（users 等）を明確に分けてメモします。
共有アクセス権（共有レベル ACL）も一緒に控える
共有を削除すると「共有レベルの権限」は消えるため、復旧するなら控えが必須です。以下は “ユーザー向け共有だけ” を抽出してバックアップする例です（環境に合わせて除外リストは調整してください）。
$exclude = @('ADMIN$','C$','IPC$','NETLOGON','SYSVOL')
$shares = Get-SmbShare | Where-Object { $_.Name -notin $exclude }
$export = foreach ($s in $shares) {
[pscustomobject]@{
Name = $s.Name
Path = $s.Path
Description = $s.Description
Settings = $s | Select-Object ConcurrentUserLimit,EncryptData,CachingMode,FolderEnumerationMode
ShareAccess = Get-SmbShareAccess -Name $s.Name | Select-Object AccountName,AccessControlType,AccessRight
}
}
New-Item -Path C:\Temp -ItemType Directory -Force | Out-Null
$export | ConvertTo-Json -Depth 6 | Out-File C:\Temp\smbshare-backup.json -Encoding UTF8ポイントは次の通りです。
- NTFS 権限（フォルダーのセキュリティ）は共有を消しても残るため、まずは共有定義だけを安全に触れます。
- ロールバックまで想定するなら、共有レベル ACL の控えが一番効きます（復旧作業の短縮）。
- SYSVOL/NETLOGON は対象外にしておく（触らない）方が安全です。
方法1：共有を削除（解除）して旧共有を完全に止める
「旧サーバーへのアクセス自体を断ちたい」「いつまでも旧共有が残ると運用が終わらない」なら、最もストレートで効果が高い方法です。
GUI で共有を解除する
- 旧サーバーで対象フォルダーを右クリック → プロパティ
- 共有 タブ（または「詳細な共有」）を開く
- 「このフォルダーを共有する」をオフ、または共有を削除
- SYSVOL/NETLOGON は絶対に触らない
PowerShell で共有を削除する（運用向け）
Remove-SmbShare -Name "users" -Force複数共有を一括で止めるなら、削除対象を明示してループさせます（除外リストに SYSVOL/NETLOGON を入れるのが重要です）。
$exclude = @('ADMIN$','C$','IPC$','NETLOGON','SYSVOL')
Get-SmbShare |
Where-Object { $_.Name -notin $exclude } |
ForEach-Object { Remove-SmbShare -Name $_.Name -Force }この方法の注意点は「共有レベル ACL が消える」ことです。先ほどのバックアップ（JSON）を取っておけば、ロールバック時の復旧が現実的になります。
方法2：共有名を変更して「旧共有だけ」アクセス不能にする（ロールバック最優先）
「万が一の戻しを最速にしたい」「共有の定義や権限はできるだけ残したい」なら、共有名の変更が現場で一番使われます。旧パス（\\FS1\users）は共有名ありきなので、共有名が変わればショートカットやドライブ割り当ては失敗します。
おすすめの命名ルール（事故を防ぐ）
- 一目で “旧共有” と分かる（例：users_old）
- 作業日や移行先を入れる（例：users_old_202601）
- 必要なら末尾に $ を付けて隠し共有にする（例：users_old_202601$）
末尾の $ は「一覧に出にくくする」効果があり、知らない人が偶然見つける確率を下げられます（ただし “知っている人” はアクセスできる点は理解して使います）。
PowerShell で共有名を変更する
Set-SmbShare -Name "users" -NewName "users_old_202601$"この手の作業で重要なのは、共有名が変わることで影響を受ける“人以外のもの”がないかです。たとえば下記は要注意です。
- バックアップソフトのバックアップ元が旧共有名で固定されている
- サーバー上のタスクやサービスが旧 UNC を参照している
- 他サーバー（アプリサーバーなど）から旧共有を参照している
「人のショートカットは止めたいが、システム参照は残したい」という場合は、共有名変更は向きません。その場合は次の「共有権限で拒否」や「案内用 share」など、より設計した止め方を選びます。
方法3：共有権限でアクセス拒否にする（“パスは存在するが入れない” 状態）
共有を削除すると「パスが見つからない」になり、問い合わせが増えることがあります。一方、共有権限で落とすと “アクセス拒否” になり、止めた意図が伝わりやすいケースがあります。ただし ACL を触る以上、戻すときに戻し忘れが起きやすい点がデメリットです。
安全にやるコツ：いきなり Deny を多用しない
共有権限は Deny を乱用すると想定外の拒否が残ることがあります。基本は「一般ユーザー向け許可を外して、管理者だけ許可」に寄せる方が運用事故が起きにくいです。
# 例：まず現状を確認
Get-SmbShareAccess -Name "users"
# 例：一般的な許可を外す（環境により対象は調整）
Revoke-SmbShareAccess -Name "users" -AccountName "Everyone" -Force
Revoke-SmbShareAccess -Name "users" -AccountName "Authenticated Users" -Force
# 例：管理者だけ残す（例）
Grant-SmbShareAccess -Name "users" -AccountName "Domain Admins" -AccessRight Full -Forceこの方式を取るなら、作業前に Get-SmbShareAccess の結果を必ず控え、ロールバック手順もセットで用意しておくと安全です。
「案内」を優先したい場合：旧共有を“メッセージ置き場”に差し替える
完全に遮断すると問い合わせが増える現場では、旧共有にアクセスしたときに「移行先はここです」と分かる導線がある方がトラブルが減ります。この場合は、旧共有（例：users）を削除/改名するのではなく、中身を空の案内フォルダーへ切り替えるという運用もあります。
- 旧共有名（users）は維持する
- 共有のパスを、案内用のフォルダー（例：D:\ShareMovedNotice）に変更する
- 案内フォルダーには README（移行先 UNC）、新共有へのショートカット、FAQ を置く
ただしこれは「アクセスを防ぐ」というより「迷子を減らす」方法です。情報漏えい対策として “旧共有へ一切入れないこと” が主目的なら、方法1/2/3の方が適切です。
具体的な運用手順（失敗しにくい順番）
旧共有の停止は、実作業よりも「順番」が結果を左右します。以下は、問い合わせを抑えつつ SYSVOL/NETLOGON を守る現実的な流れです。
ステップ1：旧共有への接続がまだ残っているかを見える化する
「本当に誰も使っていない」と思って止めたら、実は特定部署やバッチが使っていた…が一番揉めます。まずは旧サーバーに対して誰が接続しているかを確認します。
| 確認したいこと | コマンド例 | 見るポイント |
|---|---|---|
| SMB セッション（接続中の端末/ユーザー） | Get-SmbSession | ClientComputerName / ClientUserName / NumOpens |
| 開かれているファイル | Get-SmbOpenFile | Path、どの共有由来か（環境により列が異なる） |
| 共有単位の切り分け | Get-SmbOpenFile | Select-Object ClientComputerName,ClientUserName,Path | users 配下のパスが出ているか |
ここで「まだ users を参照している端末がいる」なら、旧共有停止と同時に GPO 側のドライブ割り当て更新をセットで行うのが、現場負荷を下げる近道です。
ステップ2：GPO でドライブ割り当て・ショートカットを “強制的に新サーバーへ”
旧共有を止めるだけだと、ユーザーはエラーになります。問い合わせを減らすなら、旧共有停止より先に 参照先を新サーバーへ寄せる施策を入れておくのが定石です。
代表的には次の 2 つです。
- グループポリシーのユーザー構成 → 設定 → Windows 設定 → ドライブ マップ（GPP のドライブ割り当て）
- グループポリシーのユーザー構成 → 設定 → Windows 設定 → ショートカット（GPP のショートカット配布）
現場でよく効く運用のコツです。
- 既存の割り当てを置き換える必要があるなら、最初は 「置換（Replace）」 を使って強制的に新パスへ
- 行き渡ったら 「更新（Update）」 に変えて、以降の変更リスクを下げる
- 部署や端末条件がある場合は アイテム レベル ターゲットで安全に分岐する
旧共有停止の当日だけは、案内文（「新しい共有は \\FS2\users」）を社内周知しておくと、問い合わせが体感で半分以下になることが多いです。
ステップ3：旧共有を止める（おすすめは共有名変更→一定期間後に削除）
ロールバックを意識するなら、現場では次の二段階が扱いやすいです。
- まず共有名変更で即時ブロック（戻すのも即時）
- 運用が落ち着き、参照が消えたら 共有削除で整理
例：共有名変更（users → users_old_202601$）
Set-SmbShare -Name "users" -NewName "users_old_202601$"その後、一定期間モニタリングして参照がゼロになったことを確認できたら共有削除。
Remove-SmbShare -Name "users_old_202601$" -Forceこの流れは「いきなり消す怖さ」を減らしつつ、最終的には環境を健全に整理できます。
SYSVOL/NETLOGON を壊していないか、最小の動作確認
ユーザー向け共有を止めた後、必ず次の確認を行います。現場では “問題が出てから気付く” が一番辛いので、手短でも良いのでその場で確認します。
| 確認項目 | クライアント側での確認例 | 期待結果 |
|---|---|---|
| SYSVOL 参照 | \\旧DC名\SYSVOL | 参照できる |
| NETLOGON 参照 | \\旧DC名\NETLOGON | 参照できる |
| GPO 更新 | gpupdate /force | エラーなく完了（または致命的エラーが出ない） |
| 旧ユーザー共有 | \\旧DC名\users | アクセスできない（想定した拒否/不存在） |
ここで SYSVOL/NETLOGON に影響が出ている場合、やりがちな原因は「共有単位ではなく SMB 全体を止めてしまった」パターンです。DC の役割があるうちは、共有の止め方を必ず “共有単位” に寄せてください。
トラブルを減らすための「移行後に必ずやる」チェックリスト
旧共有停止の成否は、実は “止めた後の後始末” で決まります。最低限、次を押さえておくと再発しにくくなります。
| 項目 | 目的 | 実施の目安 |
|---|---|---|
| GPO のドライブ割り当てを新サーバーへ統一 | 旧 UNC の再発を防ぐ | 旧共有停止の前日〜当日 |
| ショートカット配布（GPP）で新 UNC を展開 | ユーザー操作の迷子を減らす | 旧共有停止とセット |
| 旧サーバーへの SMB セッション監視 | 残存参照（人・システム）を洗い出す | 停止後 1〜2 週間 |
| 共有定義のバックアップ保管（JSON 等） | ロールバックを短時間で可能にする | 停止作業の前 |
| 旧サーバーの役割分離（将来計画） | DC とファイルサーバー同居のリスク低減 | 落ち着いたら計画的に |
将来の移行をラクにする：共有パスを “サーバー名固定” から卒業する
今回の悩みの根本原因は「共有パスがサーバー名（\\FS1\users）に固定され、あちこちにばら撒かれている」ことです。これを減らすと、次回の移行は一気に楽になります。
おすすめ：DFS 名前空間で “論理パス” を作る
例として、ユーザーに提示するパスを次のように変えます。
- 変更前：\\FS1\users
- 変更後：\\ドメイン名\files\users（DFS）
DFS を使うと、実体のファイルサーバーが変わっても「ターゲット先」を差し替えるだけで、ユーザーの参照パスを固定できます。結果として、次回の移行で「旧共有へ入られるのを止めたい」という火消し作業が起きにくくなります。
DNS エイリアス（CNAME）で吸収する案は慎重に
「\\FS1\users というサーバー名自体を新サーバーへ向けたい」と考えることがありますが、SMB と認証（特に Kerberos/SPN）の絡みで設計・検証が必要です。安易に行うと “つながる人とつながらない人が出る” 事故につながることがあります。運用で吸収するなら DFS の方が扱いやすいケースが多いです。
よくある質問（現場で詰まりやすいポイント）
共有を削除したらフォルダー自体が消えますか？
消えません。共有を削除するのは「共有の公開設定」を外すだけで、フォルダーや NTFS 権限はそのまま残ります。データを残しておきたい（ロールバックしたい）場合でも、共有削除は成立します。
「共有名変更」と「共有削除」、どっちが安全ですか？
ロールバックを最優先するなら 共有名変更 が扱いやすいです。変更が一箇所で済み、戻すのも一瞬です。環境整理まで含めて “終わらせる” なら、一定期間のモニタリング後に 共有削除 まで進めるのがおすすめです。
旧共有を止めたのに、ユーザーが「まだ見える」と言います
よくある原因は次の通りです。
- エクスプローラーの履歴や最近使った項目が残っている（クリックするとエラーになる）
- ドライブ割り当てが “更新されていない端末” がある（GPO 適用遅延、VPN/持ち出し端末）
- ショートカットがローカルに残っている（個人作成分）
「旧共有を止める」だけではゼロになりません。GPO での強制置換や、周知、FAQ がセットで効いてきます。
まとめ：DC 兼ファイルサーバーの旧共有は “止め方” を間違えない
DC とファイルサーバーが同居している環境では、SMB はドメイン運用（SYSVOL/NETLOGON）にも使われるため、SMB 全体を止める発想は危険です。狙うべきはあくまで ユーザー向け共有だけ で、現場で確実に効く順番は次の通りです。
- 共有を棚卸しし、共有定義（共有レベル ACL）をバックアップする
- GPO でドライブ割り当て・ショートカットを新サーバーへ寄せる
- 旧共有は共有名変更または共有削除で止める（SYSVOL/NETLOGON は残す）
- モニタリングして参照が消えたら環境を整理し、将来的には役割分離を検討する
この手順で進めると、「旧共有だけ止めたい（SYSVOL/NETLOGON を壊さない）」という要件を満たしつつ、ロールバックと運用負荷のバランスも取りやすくなります。
コメント