Tengo un ejecutable .NET (que creé) que usa MicrosoftInterfaces del servicio Active Directory(a través de System.DirectoryServices.AccountManagement) para realizar consultas LDAP. Internamente a ADSI,descarga el esquema de Active Directory y lo almacena localmente. Se supone que debe almacenar este esquema en una carpeta en %LOCALAPPDATA%\Microsoft\Windows\SchCache\.
Cuando programo este ejecutable enProgramador de tareasen Windows Server 2012 R2 y configúrelo para que se ejecute como "UsuarioA"incluso si ese usuario no ha iniciado sesión, el programa se ejecuta pero intenta escribir el archivo de caché anterior en uncarpeta literalmente nombrada%LOCALAPPDATA%\Microsoft\Windows\SchCache\dentro deempezar encarpeta de la tarea programada (que está configurada intencionalmente en la carpeta de mi ejecutable). En otras palabras, está escribiendo en algo como C:\MyApp\%LOCALAPPDATA%\Microsoft\Windows\SchCache\. Tuve que otorgarle permisos de escritura explícitos al UsuarioA en esta carpeta para permitir que el programa se ejecutara correctamente.
Observé el proceso de la tarea con Process Monitor e inmediatamente irá a esa carpeta. No es que primero haya intentado algo C:\Users\pero haya fallado.
Cuando inicio sesión en el servidor como mi propio usuario y ejecuto manualmente el ejecutable como UsuarioA usandoEjecutar como un usuario diferente, el ejecutable se ejecuta y escribe correctamente el archivo de caché en C:\Users\UserA\AppData\Local\Microsoft\Windows\SchCache\.
¿Por qué sucede esto con el Programador de tareas y qué puedo hacer para solucionarlo? Me imagino que puede tener que ver con que el Programador de tareas ejecute el programa en el contexto del UsuarioA pero no se inicialice %LOCALAPPDATA%como una variable de entorno. Por capricho intenté configurarEjecutar con los privilegios más altosen la tarea, pero eso no cambió el resultado.
Respuesta1
Este es un error en Windows Server 2012 R2 y 8.1; Microsoft lo ha documentado enKB 2968540.
El problema ha sido solucionado y revisado.KB 3133689está disponible. Esta revisión resuelve el problema.
Las tareas programadas que se ejecutan mediante UBPM no tienen suficientes variables de entorno como APPDATA, USERPROFILE o TEMP cuando se inicia el proceso correspondiente.
Respuesta2
Creo que hay un error en las tareas programadas de Windows 7/2012, por lo que no ven las variables de entorno correctas para el usuario que están ejecutando:
https://stackoverflow.com/questions/32589381/
Para confirmar que esto está ocurriendo, puede ejecutar SET>test.txtun archivo por lotes en una tarea programada, en el mismo contexto de usuario. Cuando intento esto, lo hace.nomostrar el conjunto completo y correcto de variables de entorno para el usuario especificado; es decir, no es el mismo conjunto que ve si ejecuta el mismo comando (o archivo por lotes) cuando realmente inicia sesión como ese usuario. (Lo que es aún más confuso, esto depende de si el usuario ha iniciado sesión o no cuando se ejecuta la tarea programada; si ha iniciado sesión, entonces la tareahacevea las variables correctas.)
Creo que este comportamiento no está documentado ni es intencionado, y es un error en la forma en que se manejan las tareas programadas de Windows Server 2012 (¿tal vez solo R2?).
NÓTESE BIENEsto PATHtambién se aplica a la variable, por lo que las tareas programadas solo pueden ver los ejecutables que están en elpor defectoruta, o en el directorio actual, o con una ruta completamente especificada. Llamar a cualquier cosa que esté en la ruta del usuario especificada, pero no en la ruta predeterminada, generará un error difícil de depurar (¡ya que funciona en pruebas!).
Respuesta3
Esto es consecuencia de la forma en que Windows maneja las cuentas de usuario. Cuando una cuenta de usuario no ha iniciado sesión, su subárbol de registro de usuarios (la clave HKEY_USERSque normalmente se asigna como HKEY_CURRENT_USER) no está montada. Esa colmena (que se almacena en un archivo, en el perfil de cada usuario, llamado NTUSER.DAT) almacena casi todos los datos por usuario, incluidas las variables de entorno por usuario. Windows también tiene variables de entorno del sistema (algunas variables, como PATH, están presentes en ambas ubicaciones y se fusionan), por lo que aparecerán incluso si la sección del registro del usuario no está montada. Sin embargo, ninguno de los específicos del usuario lo hará.
No sé si el Programador de tareas manejó este escenario de manera diferente en otras versiones de Windows. ÉlpodríaSea lo suficientemente inteligente como para montar la colmena del usuario antes de ejecutar una tarea como ese usuario. En Win7/2012R2, aparentemente no es así.
Para solucionar este problema, debe asegurarse de que el subárbol de registro del usuario esté montado. La forma más sencilla de hacer esto es simplemente asegurarse de que el usuario haya iniciado sesión, ya que el subárbol de un usuario que ha iniciado sesión siempre está montado. A falta de eso, puedes intentar montar la colmena tú mismo (la API esRegLoadKeypero nunca he intentado invocarlo para esto).