異ドメインの壁を越える：VBScriptによる堅牢なネットワークドライブ自動割り当ての極意
業務自動化の現場において、「ネットワークドライブの割り当て」は、一見すると`WScript.Network`を呼ぶだけの簡単なタスクに見える。しかし、異ドメイン環境や非ドメイン参加PCが混在する複雑なネットワークトポロジーにおいて、この作業はしばしば「不安定なスクリプト」の代名詞となる。
今日は、場当たり的なコードではなく、エンタープライズ環境でも通用する「落とさない・止まらない」ネットワークドライブ割り当ての設計思想を伝授する。
—
1. なぜ「単純なMapNetworkDrive」では失敗するのか
多くの技術者が陥る罠は、認証情報をハードコードし、エラーハンドリングを怠ることだ。特に異ドメイン環境では、以下の事象が頻発する。
- セッションの競合: 既に同じドライブレターが割り当てられている場合、スクリプトは容赦なく例外を投げる。
- 認証情報のキャッシュ: Windowsの資格情報マネージャーが干渉し、期待しないユーザー権限でマウントされる。
- 名前解決の遅延: DNSが追いつかず、UNCパスに到達する前にタイムアウトする。
これらの課題を克服するには、「クリーンアップ・再試行・検証」の3層構造が必須となる。
—
2. 堅牢な実装コード：プロダクションレベルのテンプレート
以下のコードは、単にドライブを繋ぐだけでなく、既存のセッションを安全に破棄し、エラーを握りつぶさずに適切にログへ出力する設計である。
‘ — 設定エリア —
Const REMOTE_PATH = “\\192.168.x.x\ShareFolder”
Const DRIVE_LETTER = “Z:”
Const USER_NAME = “DOMAIN\UserName”
Const PASSWORD = “YourPassword”
‘ — メイン実行ロジック —
Call MapNetworkDriveRobust(DRIVE_LETTER, REMOTE_PATH, USER_NAME, PASSWORD)
Sub MapNetworkDriveRobust(strDrive, strPath, strUser, strPass)
Dim objNetwork, objFSO, objDrives
Set objNetwork = WScript.CreateObject(“WScript.Network”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objDrives = objNetwork.EnumNetworkDrives
‘ 1. 既存のドライブレターをクリーンアップ
Dim i
For i = 0 To objDrives.Count – 1 Step 2
If UCase(objDrives.Item(i)) = UCase(strDrive) Then
On Error Resume Next
objNetwork.RemoveNetworkDrive strDrive, True, True
On Error GoTo 0
Exit For
End If
Next
‘ 2. マッピング実行 (認証情報付き)
‘ 第4引数: User, 第5引数: Password, 第6引数: Profile(Trueで永続化)
On Error Resume Next
objNetwork.MapNetworkDrive strDrive, strPath, False, strUser, strPass
If Err.Number <> 0 Then
WScript.Echo “Error: ドライブの割り当てに失敗しました – ” & Err.Description
WScript.Quit 1
End If
On Error GoTo 0
‘ 3. 接続確認（FSOによる実存チェック）
If objFSO.FolderExists(strDrive & “\”) Then
WScript.Echo “成功: ” & strDrive & ” に接続しました。”
Else
WScript.Echo “警告: 割り当ては成功しましたが、パスにアクセスできません。”
End If
End Sub
—
3. アーキテクトからの助言：設計の急所
A. なぜ `Profile` 引数を `False` にするのか
`MapNetworkDrive` の第6引数（bUpdateProfile）を `True` にすると、ログオン時にドライブが永続化される。しかし、異ドメイン接続の場合、PCがそのドメイン環境にない時に「ログインが遅延する」あるいは「ログイン時に資格情報の入力を求めるダイアログが毎回出る」というUXの悪化を招く。自動化ツールであれば、`False` に設定し、スクリプト実行時のみマウントするのが鉄則だ。
B. エラーハンドリングの哲学
`On Error Resume Next` は諸刃の剣である。必ず最小範囲で使用し、`Err.Number` をチェックした直後に `On Error GoTo 0` で戻すこと。エラーを握りつぶして黙り込むスクリプトは、デバッグ時に我々を地獄へ引きずり込む。
C. データベースや外部設定ファイルとの連携
もしパスワードを直書きしたくない場合は、暗号化した設定ファイル（XMLやJSON）を読み込むか、Windowsの「資格情報マネージャー（`cmdkey`コマンド）」と組み合わせるのがベストプラクティスだ。
`cmdkey /add:server /user:user /pass:pass` をVBScriptの `WshShell.Run` で事前実行してからマウントすれば、認証情報をスクリプト内に保持する必要がなくなる。
—
最後に：VBScriptは「死なない」
現代の視点から見れば、VBScriptはレガシーかもしれない。しかし、OSの深層に直接触れ、依存関係なしに即座に動作するその軽快さは、今なお業務自動化の最前線で武器となる。
重要なのは言語の古さではない。「いかに予期せぬエラーを潰し、運用者の手を煩わせない仕組みを作るか」というアーキテクトの矜持だ。このコードをベースに、君たちの現場の複雑なネットワーク環境をねじ伏せてほしい。
健闘を祈る。
