Distribuyo una utilidad para desarrolladores que está diseñada para residir en un servidor compartido y se ejecuta desde el servidor en la PC local o en la sesión de Terminal Services/Citrix. No requiere ningún privilegio de administrador. No existe ningún proceso de instalación más que arrastrarlo y soltarlo en un servidor compartido. Está firmado digitalmente.
Me han dicho que a algunos departamentos de TI no les gusta que sus ex en el servidor compartan de esta manera. ¿Qué puedo hacer para ayudar a explicar a los departamentos de TI que mi utilidad es benigna?
Agregado
Soy el desarrollador de la herramienta,Actualizador automático de FEy está diseñado deliberadamente para no requerir privilegios de administrador. Es un archivo ejecutable independiente sin dependencias de instalación más que unos pocos archivos de configuración (INI) creados por el desarrollador que utiliza la herramienta.
Los usuarios ejecutan esta herramienta durante breves momentos mientras verifica si hay actualizaciones en la base de datos del front-end de Access y los archivos asociados en el servidor. El desarrollador que utiliza la herramienta puede ejecutarla durante dos o cinco minutos mientras actualiza la configuración.
Respuesta1
Aquí hay algunas razones por las queno me gustaDetesto que los ejecutables se lancen a través de la red:
- Los bloqueos del cliente impiden que la herramienta se actualice hasta que llega un momento en el que nadie ejecuta el archivo. Esto elimina el concepto de actualización bajo demanda desde la perspectiva del usuario.
- Los reinicios del servidor son necesarios en algunos casos cuando se producen bloqueos pendientes debido a que un cliente se cae de la red o un proceso muere.
- Sobrecarga de ancho de banda adicional para la red
- Tiempo de carga adicional para el cliente, lo que a menudo se traduce en una percepción de red lenta.
EDITAR:
¡Tu información agregada lo hace aún peor! Ahora hay otras dependencias externas que añaden un mayor riesgo de fracaso.
EDITAR 2
Independientemente de lo que esté sucediendo en los procesos, lo mejor es iniciarlos desde un disco local. En más de 15 años de TI, no he visto ningún tipo de proceso en el que el beneficio de lanzarlo a través de una red compartida supere los riesgos que he enumerado. (Lo calificaré diciendo en un entorno estándar de estación de trabajo/servidor de archivos de Windows; no tengo la experiencia *nix para hacer esa afirmación allí).
En cuanto a sus llamadas a las API estándar de Windows, está muy bien. Sí, son bastante estables en sí mismos. Poner Access en la mezcla abre más. Pero el proceso aún se está iniciando en toda la red y los riesgos que yo y otros ya hemos mencionado aún se aplican. Un proceso pequeño sigue siendo un proceso y aún es vulnerable a la inestabilidad. Simplemente no vale la pena cerrar un servidor completo cuando un proceso de cliente se descontrola si se puede evitar moviendo los binarios locales al cliente.
Sí, los procesos más pequeños que tienen una vida útil más corta tienen menos riesgo de fallar y, por lo tanto, menos riesgo de causar los problemas que hemos descrito. Sin embargo, soy bastante conservador en mis creencias sobre la administración, por lo que no me gustaría verlo en mi entorno. Y tal vez esté bien en tu entorno, no lo sé.
Respuesta2
Existen numerosas razones por las que un administrador preferiría no tener archivos ejecutables en la red, como otros han enumerado.
What can I do to help explain to IT departments that my utility is benign
Nada. Su política está establecida y usted, como externo, no tiene control sobre ella a menos que alguien lo suficientemente importante dentro de la empresa.necesidades(oen realidadquiere) su software en la red.
Respuesta3
A pesar de lo que siento por mi extos, No quiero verla ejecutada y soy administrador.
Dicho esto, no nos has dado muchos antecedentes, por lo que tendré que hacer algunas suposiciones.
No puedo decirle específicamente por qué a algunos administradores no les gustan los archivos .exe en sus recursos compartidos. Puede haber problemas de instalación al iniciar archivos ejecutables desde recursos compartidos del servidor, por ejemplo. También haces una suposición bastante grande de que tu ejecutable no requiere ningún permiso de administrador para ejecutarse. ¿Cómo sabrías?
Le diré que si se dedica a vender programas, al menos en un entorno Windows, es mucho más fácil para el administrador distribuir sus programas en formato msi. No puedo imaginar que tengan reparos en tener msi en sus servidores compartidos.
Actualizado para agregar:
Tony, a medida que pasa el tiempo descubrirás, si aún no lo has hecho, que cada vez más entornos sienten la necesidad de estar bloqueados. Ya sea legalmente o no, hoy en día tiene sentido hacerlo. Si bien el tiempo invertido en hacer que su programa sea lo más adaptable posible a ese escenario puede ser excelente, creo que generará ENORMES beneficios a largo plazo (aunque tratar de mantener al administrador del sistema FUERA del circuito no lo hará).
Los administradores de sistemas no se dedican a impedir que la gente haga su trabajo. Todo lo contrario. Si hay alguien que desea tener como amigo al otro lado de una llamada de soporte técnico, es el administrador del sistema que intenta hacer que su software funcione. Hacer que su software sea más fácil de implementar y actualizar para él/ella es donde usted quiere estar.
Respuesta4
Personalmente, no permito archivos ejecutables "remotos" porque si lo permitiera, el usuario podría descargar cualquier cosa que no requiera un instalador y ejecutarlo en la red. No es genial desde una perspectiva de seguridad: solo permito que las aplicaciones se ejecuten desde "C" y el usuario tiene derechos de lectura y ejecución en "C".