サービスによって使用されるネットワークドライブを割り当てます。
一部のWindowsサービスが、マップされたネットワークドライブを必要とし、UNCパスを必要としないコードを使用しているとします。サービスの開始時にドライブのマッピングをサービスのセッションで使用できるようにするにはどうすればよいですか。サービスユーザとしてログインし、永続的なマッピングを作成しても、実際のサービスのコンテキストでマッピングは確立されません。
サービスを変更するか、ヘルパープロセス内でラップする必要があります。セッション/ドライブアクセスの問題を除いて、固定ドライブマッピングは対話型ログオンでのみ復元されるため、通常はサービスは実行されません。
ヘルパープロセスのアプローチは非常に簡単です。ドライブをマッピングして「本物の」サービスを開始する新しいサービスを作成するだけです。これについて完全に自明ではない唯一のものは以下のとおりです。
ヘルパーサービスはすべての適切なSCMコマンド（開始/停止など）を実際のサービスに渡す必要があります。実際のサービスがカスタムSCMコマンドを受け付ける場合は、それらも渡すことを忘れないでください（ただし、そのようなコマンドを使用するのが厄介なUNCパスを考慮するサービスは期待できません...）
物事はちょっとトリッキーな信任状になるかもしれません。実際のサービスが通常のユーザーアカウントで実行されている場合は、そのアカウントでもヘルパーサービスを実行できます。アカウントがネットワーク共有に適切にアクセスできる限り、すべて問題ありません。実際のサービスがLOCALSYSTEMまたはそのようなものとして実行された場合にのみ機能する場合、ネットワークドライブをまったく「見る」ことができないか、または機能するために資格情報のジャグリングを必要としないため、状況はさらに興味深いものになります。
ご自身の責任でこれを使用してください。 （私はXPとServer 2008 x64 R2でそれをテストしました）
このハックのためにあなたが必要となるでしょう Mark RussinovichによるSysinternalsSuite ：
ステップ1：昇格したcmd.exeプロンプトを開く（管理者として実行）
ステップ2：PSExec.exeを使用して再度rootユーザーに昇格します。SysinternalsSuiteを含むフォルダーに移動し、次のコマンドを実行します。psexec -i -s cmd.exeプロンプトが表示されます。これはnt authority\systemであり、whoamiと入力することでこれを証明できます。ドライブマッピングはユーザーと対話する必要があるため、-iが必要です
ステップ3：以下のコマンドを使用して、固定割り当てドライブをSYSTEMアカウントとして作成しますNet Use z: \\servername\sharedfolder /persistent:yes
とても簡単です。
WARNING：このマッピングは、SYSTEMアカウントから作成したのと同じ方法でのみ削除できます。削除する必要がある場合は、手順1と2に従いますが、手順3のコマンドをNet Use z: /deleteに変更します。
NOTE：新しく作成されたマップドライブは、このシステムのすべてのユーザーに表示されますが、「切断されたネットワークドライブ（Z :)」と表示されます。 "）"＃：。その名前に惑わされないでください。それは切断されていると主張するかもしれませんが、それは皆のために働くでしょう。だからこそ、このハックはM $ではサポートされていないと言えるでしょう。
私はpsexecを使ったものと似ているがうまくいく解決策を見つけました追加のツールなしで再起動後も生き残ります。
スケジュールされたタスクを追加し、「実行」フィールドに「system」を挿入して、単純なコマンドでタスクをバッチファイルに指定します。
Net Use z: \servername\sharedfolder /persistent:yes
それから「システムの起動時に実行する」を選択してください（または同様の英語版はありません）。これで完了です。
もっと良い方法は、mklink.exeを使ってシンボリックリンクを使うことです。ファイルシステムにリンクを作成するだけで、どのアプリでも使用できます。 http://en.wikipedia.org/wiki/NTFS_symbolic_link を参照してください。
ここに良い答えがあります： https://superuser.com/a/651015/299678
すなわちシンボリックリンクを使うことができます。
mklink /D C:\myLink \\127.0.0.1\c$
あなたは私たちに 'Net Use'コマンドを使うことができます：
var p = System.Diagnostics.Process.Start("net.exe", "use K: \\\\Server\\path");
var isCompleted = p.WaitForExit(5000);
それがサービスで機能しない場合は、WinapiとPInvokeを試してください WNetAddConnection2
編集：明らかに私はあなたを誤解しました - あなたはサービスのソースコードを変更することはできませんね。その場合、私は mdb で提案に従いますが、ちょっとした工夫で：ドライブをマッピングし、このマッピングサービスを最初の依存関係に追加する独自のサービスを作成します。 （実際の作業）サービス。このようにして、マッピングサービスが開始される（そしてドライブをマッピングする）前に作業サービスは開始されません。
ForcePush、
NOTE：新しく作成されたマップドライブは、このシステムのすべてのユーザーに表示されますが、「Disconnected Network Drive（Z :)」と表示されます。その名前に惑わされないでください。それは切断されていると主張するかもしれませんが、それは皆のために働くでしょう。それで、あなたはこのハックがM $によってサポートされていないと言うことができます...
それはすべて共有アクセス許可に依存します。あなたが共有アクセス許可にEveryoneを持っている場合、この割り当てられたドライブは他のユーザーからアクセス可能になります。ただし、バッチスクリプトとこのバッチスクリプトで使用した資格情報がスタートアップスクリプトに追加された特定のユーザーだけがいる場合は、システムアカウントだけがその共有にアクセスでき、管理者もアクセスできません。たとえば、スケジュールされたntbackuoジョブを使用する場合は、[実行]でシステムアカウントを使用する必要があります。あなたのサービスが 'ローカルシステムアカウントとしてログオンする'であればうまくいくでしょう。
私がしたこと、私は自分の起動スクリプトにドライブ文字を割り当てず、スケジュールされたジョブでNet Use \\\server\share ...を使い、UNCパスを使いました。いくつかのドライブ文字を持つ同じ共有へのマッピングを使用してログオンスクリプトを追加します（または単にスタートアップフォルダにバッチファイルを追加します）。同じ資格情報を持つNet Use Z: \\\...。これで、ログに記録されたユーザーはその割り当てられたドライブを見てアクセスできるようになります。同じ共有への2つの接続があります。この場合、ユーザーはその厄介な "Disconnected network drive ..."を見ません。しかし、UNCだけではなくドライブレターでその共有にアクセスする必要がある場合は、その共有を別のドライブレターにマッピングしてください。システムの場合はY、ユーザーの場合はZ。
Windowsサービスにネットワークドライブへのアクセスを許可する方法を見つけました。
たとえば、Windows Server 2012とNFS Diskを組み合わせてください。
ステップ1：マウントするバッチファイルを書きます。
バッチファイルを作成します。例：C：\ mount_nfs.bat
echo %time% >> c:\mount_nfs_log.txt
Net Use Z: \\{your ip}\{netdisk folder}\ >> C:\mount_nfs_log.txt 2>&1
ステップ2：NT AUTHORITY/SYSTEMとしてディスクをマウントします。
「タスクスケジューラ」を開き、新しいタスクを作成します。
- 「システムの起動」で、「システム」として実行します。
- アクションを作成します。 "C：\ mount_nfs.bat"を実行します。
これら2つの簡単なステップの後、私のWindows ActiveMQサービスは "Local System"特権で実行され、ログインせずに完全に機能します。
あなたが通常コマンドプロンプトから実行可能ファイルを実行するときにドライブにアクセスすることができる理由はあなたが通常のexeとして実行しているときあなたがログオンしたユーザーアカウントでそのアプリケーションを実行しているからです。そしてそのユーザーはネットワークにアクセスする特権を持っています。しかし、あなたがサービスとして実行ファイルをインストールするとき、あなたがタスク管理で見ればデフォルトでそれは 'SYSTEM'アカウントの下で実行されます。そして、あなたは 'SYSTEM'がネットワークリソースにアクセスする権利を持っていないことを知っているかもしれません。
この問題には2つの解決策があります。
ドライブを既に上で指摘したように永続的としてマップする。
従うことができるもう1つのアプローチがあります。 「services.msc」と入力してサービスマネージャを開くと、サービスに移動でき、サービスのプロパティに「システム」以外のアカウントとしてアカウントを指定できる「ログオン」タブが表示されます。自分のログオンしたユーザーアカウントから、または「ネットワークサービス」からサービスを開始します。あなたがこれをすると..サービスはたとえそれらが永続的でなくてもどんなネットワークコンポーネントとドライブにもアクセスすることができます。これをプログラムで実現するには、 http://msdn.Microsoft.com/ja-jp/library/ms682450（v = vs.85）.aspx にある「CreateService」関数を調べて、 'NT AUTHORITY\NetworkService'のパラメータ 'lpServiceStartName'。これで 'Network Service'アカウントであなたのサービスが開始され、その後は完了です。
CreateService（）関数のservicetypeパラメータフラグにSERVICE_INTERACTIVE_PROCESSを指定してサービスをインタラクティブにすることでも試すことができますが、これはXPまでしか制限されず、Vistaではこの機能がサポートされません。
解決策があなたを助けることを望みます。これがあなたのために働いたかどうか私に知らせてください。
サービスを実行しているユーザーを "System"から変更したり、マッピングをSystemとして実行するための卑劣な方法を見つけたりしないでください。
おもしろいことに、これは "at" コマンドを使うことで可能になります。未来に向けてドライブマッピングを1分後にスケジュールするだけで、ドライブがサービスから見えるようにSystemアカウントで実行されます。
永続ドライブに頼る代わりに、ドライブを使用するたびにドライブをマップ/マップ解除するようにスクリプトを設定できます。
Net Use Q: \\share.domain.com\share
forfiles /p Q:\myfolder /s /m *.txt /d -0 /c "cmd /c del @path"
Net Use Q: /delete
これは私のために働きます。
私はまだコメントできない（評判に取り組んでいる）が@Tech Jerk @ spankmaster79（いい名前です）と@NMCの問題に答えるためのアカウントを作成しました。 psexecは追加のツールなしで動作し、再起動後も生き残ります。」 @Larryさんが投稿した.
これを解決するには、ログインアカウント内からそのフォルダを参照するだけです。
\\servername\share
そしてログインを促し、psexecでUNCに使用したものと同じ資格情報を入力します。その後それは働き始めます。私の場合、これはサービスを提供しているサーバーが、私がマッピングしているサーバーと同じドメインのメンバーではないためだと思います。 UNCとスケジュールされたタスクの両方が、ホスト名ではなくIPを参照しているかどうかを考えています
\\123.456.789.012\share
それは問題を完全に回避するかもしれません。
私がこれまでに十分な担当者ポイントを得た場合、私は代わりにこれを返信として追加します。