Mappa un'unità di rete che verrà utilizzata da un servizio

Supponiamo che alcuni servizi Windows utilizzino il codice che desidera unità di rete mappate e nessun percorso UNC. Come posso rendere la mappatura dell'unità disponibile per la sessione del servizio all'avvio del servizio? L'accesso come utente del servizio e la creazione di una mappatura persistente non stabiliranno la mappatura nel contesto del servizio effettivo.

Dovrai modificare il servizio o inserirlo in un processo di supporto: a parte i problemi di accesso alla sessione / all'unità, i mapping persistenti di unità vengono ripristinati solo su un accesso interattivo, che i servizi in genere non eseguono.

L'approccio del processo di supporto può essere piuttosto semplice: basta creare un nuovo servizio che mappa l'unità e avvia il servizio "reale". Le uniche cose che non sono del tutto banali al riguardo sono:

• Il servizio di supporto dovrà passare tutti i comandi SCM appropriati (avvio / arresto, ecc.) Al servizio reale. Se il servizio reale accetta comandi SCM personalizzati, ricordati di passare anche quelli (non mi aspetto un servizio che consideri i percorsi UNC esotici per usare tali comandi, però ...)

• Le cose potrebbero diventare un po 'complicate dal punto di vista credenziale. Se il servizio reale viene eseguito con un normale account utente, è possibile eseguire anche il servizio di supporto con tale account e tutto dovrebbe essere OK purché l'account abbia accesso appropriato alla condivisione di rete. Se il vero servizio funzionerà solo se eseguito come LOCALSYSTEM o someuch, le cose diventeranno più interessanti, in quanto non saranno in grado di "vedere" l'unità di rete o richiederanno un po 'di giocoleria credenziale per far funzionare le cose.

Usalo a tuo rischio e pericolo. (L'ho provato su XP e Server 2008 x64 R2)

Per questo trucco avrai bisogno di SysinternalsSuite di Mark Russinovich :

Passaggio 1: aprire un prompt cmd.exe elevato (Esegui come amministratore)

Passaggio 2: elevare di nuovo alla radice utilizzando PSExec.exe: passare alla cartella contenente SysinternalsSuite ed eseguire il comando seguente psexec -i -s cmd.exe ora si trova all'interno di un prompt che è nt authority\systeme si può provare digitando whoami. Il -iè necessario perché mapping di unità hanno bisogno di interagire con l'utente

Passaggio 3: creare l'unità mappata persistente come account SYSTEM con il seguente comando net use z: \\servername\sharedfolder /persistent:yes

È così facile!

ATTENZIONE : È possibile rimuovere questa mappatura solo nello stesso modo in cui è stata creata, dall'account SYSTEM. Se è necessario rimuoverlo, seguire i passaggi 1 e 2 ma modificare il comando al passaggio 3 in net use z: /delete.

NOTA : l'unità mappata appena creata verrà ora visualizzata per TUTTI gli utenti di questo sistema, ma verrà visualizzata come "Disconnected Network Drive (Z :)". Non lasciarti ingannare dal nome. Potrebbe pretendere di essere disconnesso ma funzionerà per tutti. È così che puoi dire che questo hack non è supportato da M $.

Ho trovato una soluzione simile a quella con psexec ma funziona senza strumenti aggiuntivi e sopravvive al riavvio .

Basta aggiungere un'attività sheduled, inserire "system" nel campo "run as" e puntare l'attività su un file batch con il semplice comando

net use z: \servername\sharedfolder /persistent:yes

Quindi selezionare "Esegui all'avvio del sistema" (o simile, non ho una versione inglese) e il gioco è fatto.

Un modo migliore sarebbe usare un collegamento simbolico usando mklink.exe. Puoi semplicemente creare un collegamento nel file system che qualsiasi app può utilizzare. Vedi http://en.wikipedia.org/wiki/NTFS_symbolic_link .

C'è una buona risposta qui: https://superuser.com/a/651015/299678

Vale a dire È possibile utilizzare un collegamento simbolico, ad es

mklink /D C:\myLink \\127.0.0.1\c$

Potresti usare il comando 'net use':

var p = System.Diagnostics.Process.Start("net.exe", "use K: \\\\Server\\path");
var isCompleted = p.WaitForExit(5000);

Se ciò non funziona in un servizio, provare Winapi e PInvoke WNetAddConnection2

Modificare: ovviamente ti ho frainteso: non puoi cambiare il codice sorgente del servizio, giusto? In quel caso seguirò il suggerimento di mdb , ma con una leggera svolta: crea il tuo servizio (chiamiamolo servizio di mappatura) che mappa l'unità e aggiungi questo servizio di mappatura alle dipendenze per il primo servizio (funzionante). In questo modo il servizio di lavoro non si avvierà prima dell'avvio del servizio di mappatura (e della mappatura dell'unità).

ForcePush,

NOTA : l'unità mappata appena creata verrà ora visualizzata per TUTTI gli utenti di questo sistema, ma verrà visualizzata come "Disconnected Network Drive (Z :)". Non lasciarti ingannare dal nome. Potrebbe pretendere di essere disconnesso ma funzionerà per tutti. Ecco come puoi dire che questo hack non è supportato da M $ ...

Tutto dipende dalle autorizzazioni di condivisione. Se disponi di Tutti nelle autorizzazioni di condivisione, questa unità mappata sarà accessibile da altri utenti. Ma se hai solo un determinato utente le cui credenziali hai usato nello script batch e questo script batch è stato aggiunto agli script di avvio, solo l'account di sistema avrà accesso a quella condivisione, nemmeno l'amministratore. Pertanto, se si utilizza, ad esempio, un processo ntbackuo pianificato, l'account di sistema deve essere utilizzato in "Esegui come". Se il tuo servizio "Accedi come: Account di sistema locale" dovrebbe funzionare.

Quello che ho fatto , non ho mappato alcuna lettera di unità nel mio script di avvio, ho solo usato net use \\\server\share ...e usato il percorso UNC nei miei lavori programmati. Aggiunto uno script di accesso (o semplicemente aggiunto un file batch alla cartella di avvio) con il mapping alla stessa condivisione con una lettera di unità: net use Z: \\\...con le stesse credenziali. Ora l'utente registrato può vedere e accedere a quell'unità mappata. Vi sono 2 connessioni alla stessa condivisione. In questo caso l'utente non vede quel fastidioso "Disconnected network drive ...". Ma se hai davvero bisogno di accedere a quella condivisione tramite la lettera di unità non solo UNC, esegui il mapping di quella condivisione con le diverse lettere di unità, ad esempio Y per System e Z per gli utenti.

È stato trovato un modo per concedere l'accesso del servizio Windows a Network Drive.

Prendi Windows Server 2012 con NFS Disk per esempio:

Passaggio 1: scrivere un file batch da montare.

Scrivi un file batch, ad esempio: 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

Passaggio 2: montare il disco come NT AUTHORITY / SYSTEM.

Apri "Utilità di pianificazione", crea una nuova attività:

1. Esegui come "SISTEMA", in "Avvio del sistema".
2. Crea azione: esegui "C: \ mount_nfs.bat".

Dopo questi due semplici passaggi, il mio servizio ActiveMQ di Windows viene eseguito con il privilegio "Sistema locale", funziona perfettamente senza effettuare l'accesso.

Il motivo per cui è possibile accedere all'unità quando si esegue normalmente l'eseguibile dal prompt dei comandi è che quando lo si esegue come exe normale, si esegue quell'applicazione nell'account utente da cui si è effettuato l'accesso. E quell'utente ha i privilegi per accedere alla rete. Ma, quando si installa l'eseguibile come servizio, per impostazione predefinita, se si vede nell'attività gestire, viene eseguito con l'account "SISTEMA". E potresti sapere che il "SISTEMA" non ha diritti di accesso alle risorse di rete.

Ci possono essere due soluzioni a questo problema.

1. Per mappare l'unità come persistente come già indicato sopra.

2. C'è un altro approccio che può essere seguito. Se apri il gestore servizi digitando "services.msc" puoi andare al tuo servizio e nelle proprietà del tuo servizio c'è una scheda logOn dove puoi specificare l'account come qualsiasi altro account diverso da "Sistema", puoi avviare il servizio dal proprio account utente connesso o tramite "Servizio di rete". Quando lo fai .. il servizio può accedere a qualsiasi componente di rete e guidare anche se non sono persistenti. Per raggiungere questo obiettivo a livello di programmazione, è possibile consultare la funzione "Crea servizio" all'indirizzo http://msdn.microsoft.com/en-us/library/ms682450(v=vs.85).aspx e impostare il parametro "lpServiceStartName" su "NT AUTHORITY \ NetworkService'. Questo avvierà il tuo servizio in "Servizio di rete"

3. Puoi anche provare a rendere il servizio interattivo specificando SERVICE_INTERACTIVE_PROCESS nel flag del parametro servicetype della tua funzione CreateService (), ma questo sarà limitato solo fino a XP in quanto Vista e 7 non supportano questa funzione.

Spero che le soluzioni ti possano aiutare. Fammi sapere se questo ha funzionato per te.

Non dovrai cambiare l'utente con cui il Servizio esegue da "Sistema" o trovare un modo subdolo per eseguire la tua mappatura come Sistema.

La cosa divertente è che questo è possibile usando il comando "at" , basta programmare la mappatura dell'unità un minuto nel futuro e verrà eseguita con l'account di sistema che rende l'unità visibile al tuo servizio.

Invece di fare affidamento su un'unità persistente, è possibile impostare lo script per mappare / annullare la mappatura dell'unità ogni volta che lo si utilizza:

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

Questo funziona per me.

Non posso ancora commentare (lavorando sulla reputazione) ma ho creato un account solo per rispondere ai problemi di @Tech Jerk @ spankmaster79 (bel nome lol) e @NMC che hanno segnalato in risposta a "Ho trovato una soluzione simile a quella con psexec ma funziona senza strumenti aggiuntivi e sopravvive al riavvio ". post @Larry aveva fatto.

La soluzione a questo è semplicemente navigare in quella cartella dall'account di accesso, ovvero:

    \\servername\share  

e lascia che richieda il login e inserisci le stesse credenziali che hai usato per UNC in psexec. Dopodiché inizia a funzionare. Nel mio caso, penso che ciò sia dovuto al fatto che il server con il servizio non è un membro dello stesso dominio del server a cui sto mappando. Sto pensando se l'UNC e l'attività pianificata si riferiscono entrambi all'IP anziché al nome host

    \\123.456.789.012\share 

potrebbe evitare del tutto il problema.

Se avrò mai abbastanza punti di ripetizione qui, aggiungerò questo come risposta.