Mapear una unidad de red para ser utilizada por un servicio

Supongamos que algún servicio de Windows usa código que quiere unidades de red mapeadas y no rutas UNC. ¿Cómo puedo hacer que la asignación de unidades esté disponible para la sesión del servicio cuando se inicia el servicio? Iniciar sesión como usuario del servicio y crear una asignación persistente no establecerá la asignación en el contexto del servicio real.

Deberá modificar el servicio o incluirlo dentro de un proceso auxiliar: además de los problemas de acceso a la sesión / unidad, las asignaciones de unidades persistentes solo se restauran en un inicio de sesión interactivo, que los servicios generalmente no realizan.

El enfoque del proceso auxiliar puede ser bastante simple: simplemente cree un nuevo servicio que mapee el disco e inicie el servicio 'real'. Las únicas cosas que no son del todo triviales sobre esto son:

• El servicio auxiliar deberá pasar todos los comandos SCM apropiados (inicio / parada, etc.) al servicio real. Si el servicio real acepta comandos SCM personalizados, recuerde pasarlos también (no espero que un servicio que considere que las rutas UNC sean exóticas para usar tales comandos ...)

• Las cosas pueden ponerse un poco complicadas en cuanto a credenciales. Si el servicio real se ejecuta bajo una cuenta de usuario normal, también puede ejecutar el servicio auxiliar bajo esa cuenta, y todo debería estar bien siempre que la cuenta tenga acceso apropiado al recurso compartido de red. Si el servicio real solo funciona cuando se ejecuta como LOCALSYSTEM o somesuch, las cosas se vuelven más interesantes, ya que no podrá "ver" la unidad de red o requerirá un malabarismo de credenciales para que las cosas funcionen.

Usa esto bajo tu propio riesgo. (Lo he probado en XP y Server 2008 x64 R2)

Para este hack necesitarás SysinternalsSuite de Mark Russinovich :

Paso uno: abra un indicador elevado de cmd.exe (Ejecutar como administrador)

Paso dos: Vuelva a elevarse a la raíz con PSExec.exe: navegue a la carpeta que contiene SysinternalsSuite y ejecute el siguiente comando psexec -i -s cmd.exe que ahora está dentro de un indicador que es nt authority\systemy puede probarlo escribiendo whoami. Se -inecesita porque las asignaciones de unidades deben interactuar con el usuario

Paso tres: cree la unidad asignada persistente como la cuenta SYSTEM con el siguiente comando net use z: \\servername\sharedfolder /persistent:yes

¡Es fácil!

ADVERTENCIA : Solo puede eliminar esta asignación de la misma manera que la creó, de la cuenta SYSTEM. Si necesita eliminarlo, siga los pasos 1 y 2, pero cambie el comando del paso 3 a net use z: /delete.

NOTA : La unidad asignada recién creada ahora aparecerá para TODOS los usuarios de este sistema, pero la verán mostrada como "Unidad de red desconectada (Z :)". No dejes que el nombre te engañe. Puede afirmar que está desconectado, pero funcionará para todos. Así es como se puede decir que este truco no es compatible con M $.

Encontré una solución que es similar a la de psexec, pero funciona sin herramientas adicionales y sobrevive al reiniciar .

Simplemente agregue una tarea programada, inserte "sistema" en el campo "ejecutar como" y apunte la tarea a un archivo por lotes con el comando simple

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

Luego seleccione "ejecutar al inicio del sistema" (o similar, no tengo una versión en inglés) y ya está.

Una mejor manera sería usar un enlace simbólico usando mklink.exe. Simplemente puede crear un enlace en el sistema de archivos que cualquier aplicación pueda usar. Ver http://en.wikipedia.org/wiki/NTFS_symbolic_link .

Aquí hay una buena respuesta: https://superuser.com/a/651015/299678

Es decir, puede usar un enlace simbólico, p. Ej.

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

Podrías usar el comando 'uso neto':

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

Si eso no funciona en un servicio, pruebe Winapi y PInvoke WNetAddConnection2

Editar: Obviamente te entendí mal, no puedes cambiar el código fuente del servicio, ¿verdad? En ese caso, seguiría la sugerencia de mdb , pero con un pequeño giro: cree su propio servicio (llamémoslo servicio de mapeo) que mapea el disco y agregue este servicio de mapeo a las dependencias para el primer servicio (el trabajo real). De esa manera, el servicio de trabajo no se iniciará antes de que el servicio de mapeo haya comenzado (y haya mapeado la unidad).

ForcePush,

NOTA : La unidad asignada recién creada ahora aparecerá para TODOS los usuarios de este sistema, pero la verán mostrada como "Unidad de red desconectada (Z :)". No dejes que el nombre te engañe. Puede afirmar que está desconectado, pero funcionará para todos. Así es como se puede decir que este truco no es compatible con M $ ...

Todo depende de los permisos compartidos. Si tiene todos los permisos para compartir, otros usuarios podrán acceder a esta unidad asignada. Pero si solo tiene un usuario en particular cuyas credenciales utilizó en su secuencia de comandos por lotes y esta secuencia de comandos por lotes se agregó a las secuencias de comandos de inicio, solo la cuenta del sistema tendrá acceso a ese recurso compartido, ni siquiera el administrador. Entonces, si usa, por ejemplo, un trabajo ntbackuo programado, la cuenta del sistema debe usarse en 'Ejecutar como'. Si su servicio 'Iniciar sesión como: cuenta del sistema local' debería funcionar.

Lo que hice , no asigné ninguna letra de unidad en mi script de inicio, solo usé net use \\\server\share ...y usé la ruta UNC en mis trabajos programados. Se agregó un script de inicio de sesión (o simplemente agregue un archivo por lotes a la carpeta de inicio) con la asignación al mismo recurso compartido con alguna letra de unidad: net use Z: \\\...con las mismas credenciales. Ahora el usuario registrado puede ver y acceder a esa unidad asignada. Hay 2 conexiones al mismo recurso compartido. En este caso, el usuario no ve esa molesta "Unidad de red desconectada ...". Pero si realmente necesita acceso a ese recurso compartido por la letra de unidad, no solo UNC, asigne ese recurso compartido con las diferentes letras de unidad, por ejemplo, Y para Sistema y Z para usuarios.

Se encontró una forma de otorgar acceso al Servicio de Windows a la Unidad de red.

Tome Windows Server 2012 con disco NFS por ejemplo:

Paso 1: escriba un archivo por lotes para montar.

Escriba un archivo por lotes, por ejemplo: 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

Paso 2: Monte el disco como NT AUTHORITY / SYSTEM.

Abra el "Programador de tareas", cree una nueva tarea:

1. Ejecutar como "SISTEMA", en "Inicio del sistema".
2. Crear acción: Ejecute "C: \ mount_nfs.bat".

Después de estos dos simples pasos, mi servicio Windows ActiveMQ se ejecuta bajo el privilegio "Sistema local", funciona perfectamente sin iniciar sesión.

La razón por la que puede acceder al disco cuando normalmente ejecuta el ejecutable desde el símbolo del sistema es que cuando lo está ejecutando como exe normal, está ejecutando esa aplicación en la cuenta de usuario desde la que ha iniciado sesión. Y ese usuario tiene los privilegios para acceder a la red. Pero, cuando instala el ejecutable como un servicio, de forma predeterminada, si ve en la gestión de tareas, se ejecuta en la cuenta 'SISTEMA'. Y es posible que sepa que el 'SISTEMA' no tiene derechos para acceder a los recursos de la red.

Puede haber dos soluciones a este problema.

1. Para mapear el disco tan persistente como ya se señaló anteriormente.

2. Hay un enfoque más que se puede seguir. Si abre el administrador de servicios escribiendo 'services.msc', puede ir a su servicio y en las propiedades de su servicio hay una pestaña de inicio de sesión donde puede especificar la cuenta como cualquier otra cuenta que no sea 'Sistema'. inicie el servicio desde su propia cuenta de usuario conectada o mediante 'Servicio de red'. Cuando hace esto ... el servicio puede acceder a cualquier componente de red y unidad, incluso si no son persistentes también. Para lograr esto mediante programación, puede buscar en la función 'CreateService' en http://msdn.microsoft.com/en-us/library/ms682450(v=vs.85).aspx y puede establecer el parámetro 'lpServiceStartName' en 'NT AUTORIDAD \ NetworkService '. Esto iniciará su servicio en 'Servicio de red'

3. También puede intentar hacer que el servicio sea interactivo especificando SERVICE_INTERACTIVE_PROCESS en el indicador de parámetro de tipo de servicio de su función CreateService (), pero esto se limitará solo hasta XP, ya que Vista y 7 no admiten esta función.

Espero que las soluciones te ayuden. Avísame si esto funcionó para ti.

No desea cambiar el usuario con el que se ejecuta el Servicio desde "Sistema" o encontrar una manera astuta de ejecutar su mapeo como Sistema.

Lo curioso es que esto es posible mediante el uso del comando "at" , simplemente programe su asignación de unidades un minuto en el futuro y se ejecutará en la cuenta del sistema, haciendo que la unidad sea visible para su servicio.

En lugar de confiar en una unidad persistente, puede configurar el script para asignar / desasignar la unidad cada vez que la use:

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

Esto funciona para mi.

Todavía no puedo comentar (trabajando en reputación), pero creé una cuenta solo para responder a @Tech Jerk @ spankmaster79 (bonito nombre jajaja) y a los problemas de @NMC que informaron en respuesta al "Encontré una solución similar a la que tenía psexec pero funciona sin herramientas adicionales y sobrevive al reiniciar ". la publicación que @Larry había hecho.

La solución a esto es simplemente navegar a esa carpeta desde la cuenta registrada, es decir:

    \\servername\share  

y deje que le solicite iniciar sesión e ingrese las mismas credenciales que utilizó para la UNC en psexec. Después de eso comienza a funcionar. En mi caso, creo que esto se debe a que el servidor con el servicio no es miembro del mismo dominio que el servidor al que estoy asignando. Estoy pensando si la UNC y la tarea programada se refieren a la IP en lugar del nombre de host

    \\123.456.789.012\share 

Puede evitar el problema por completo.

Si alguna vez obtengo suficientes puntos de representación aquí, agregaré esto como respuesta.