|
Hace un tiempo, una de las empresas para las que trabajo pidió una serie de reportes desde una base de datos MS-SQL.
Como no era nada complicado, ni se necesitaba algun formato en especial, se decidió realizar un script en VBScript que arme la consulta, la ejecute, genere la salida en CSV y la envíe por email.
Porque CSV, .. simple.. funciona en cualquier planilla y además la empresa utiliza G-Suite. Cortita y al pie como debe devolverse cualquier pared.
La solución funcionó correctamente y nos olvidamos del tema.
Peerrroooo... no me lo podés mandar en Excel?.. pidió uno de los gerentes...
Si.. si si.. lo se.. los escucho desde aca.... es lo mismo abrir el CSV, lo trabajas lo guardas en XLSX... en fin... y sobre todo si usas G-Suite... lo se..
Hecha la solicitud... no lo veíamos complicado... y decimos agregar una función al script para que abra y convierta el archivo CSV usando Excel Application.. fácil.. lo liquidamos en un rato... ilusos...
Un poco del entorno...
Antes de continuar con el problema y la solución encontrada, describo un poco del entorno.
Normalmente se trabaja en ambientes de dominio (estoy hablando de Active Directory), con severs miembros, estructura de políticas, servers en lenguaje inglés, etc. etc.
Pero no es este caso... Aqui nos encontramos con un server en español, Windows Server 2016, instalado como servidor independiente.
Dado que las licencias que se tenían lo permitían, se instaló un Office 2010 STD 32 bits español, solo la aplicación Excel.
Sin políticas generales que adcuen la funcionalidad, sin customizaciones particulaes, etc.
Sirva hasta aqui la descripción del entorno...
Linea de comandos.. 10 Puntos... Schedule Task.. No way jose..
Procedimos con el código en VB donde tomamos el archivo de salida, invocamos a excel y lo guardamos en formato XLSX.
Simple... claro... preciso..
Procedimos a hacer la consabida prueba en la linea de comandos... y perfecto.. quedó .. quedó..
Todos contentos... agendá la tarea.. y listo...
Ni ahí.... Con la tarea agendada el XLSX no se genera... Que Pasó???
Permisos...
Lo primero que se nos ocurrió fue la verificación de permisos... algo en la creación del segundo archivo falla debido a los permisos de ejecución de la tarea agenda.. revisemos
En este caso, ejecutamos con privilegios elevados, usamos una cuenta con permisos locales de administrador (demasiado, lo se... pero habia que probar), revisamos las carpetas, revisamos la invocación... no viene por aqui la falla.
Análisis...
Obviamente, la tarea se ejecutaba, se generaba la salida CSV desde el MS-SQL, pero no se generaba el XLSX... Se ejecutaba el Excel?
Revisamos, generamos eventos en el visor de eventos... y si... se ejecutaba el excel, pero no podía abrir el archivo... raro.. por lo menos para nosotros...
...Que????? El esapcio en disco o la memoria son insuficientes..... claramente no es ese el problema, pero es síntoma otra vez de permisos... no way.. pusimos "EVERYONE FULLCONTROL" para probar...
Entonces???? porque no puede abrir y guardar....?????. Recordé que por más que se invoque desde un script, Excel, sigue siendo una aplicación con GUI, y puede que requiera ciertas configuraciones del perfil del usuario... entonces escarbando un poco en internet encuentro que puede requerir la carpeta Desktop
Aqui surje un tema... el sistema operativo es de 64bits, pero la aplicación es de 32bits... que carpeta necesitará?... bueno... cubramos las bases, y generemos ambas...
64bits: C:\Windows\SysWOW64\config\systemprofile\Desktop
32bits: C:\Windows\System32\config\systemprofile\Desktop
Bueno... con las carpetas generadas... volvimos a ejecutar la tarea... esperando que funcionara.... que ilusos... no way jose.. again...
Entonces... que estamos pasando por alto...
Obviamente, el uso de vbscript para conectar con SQL estaba funcionando... el archivo csv se generaba.. el excel iniciaba... pero no podía acceder correctamente a los archivos en el disco.. es más Excel pensaba que había falta de espacio en disco o memoria....
es un problema de DCOM ...
Básicamente, al invocar Excel via vbscript, estamos invocando un objeto DCOM, y ahi... aplican otros permisos... en versiones anteriores, por ej. Windows Server 2003, esto hubiera funcionado sin problemas, con las mejoras de seguridad introducidas en 2008 en adelante.. no..
Para solucionar esto, debemos modificar la forma en que Excel es invocado via DCOM... entonces, procedemos a ejecutar dcomcnfg para acceder a la configuración de los objetos y buscamos Microsoft Excel....
... eh???? no está Microsoft Excel.... mala mía.....
antes expliqué que habíamos instalado un Office 32 bits... y estoy buscando en objetos de 64 bits... no va a estar....
Para configurar un objeto DCOM de 32 bits en un sistema operativo de 64bits, se debe cargar la MMC correspondiente, para ello ejecutamos mmc comexp.msc /32 ... y ahi estamos mejor... pero aun no terminamos...
Entonces, nuestro diagnóstico es falta de permisos... tenemos el objeto DCOM ubicado, nos falta asignar.. para ello hacemos click con el boton derecho del mouse sobre "Microsoft Excel Application" y seleccionamos propiedades,
luego en la ventana, buscamos la solapa "Identidad", y alli debemos seleccionar la cuenta, que tenga los permisos suficientes para ejecutar la aplicación excel, acceder a los archivos y generar los reportes, normalmente será la misma
cuenta que se utiliza para la tarea agendada... de más está decir que debe tener siempre los permisos mínimos... por seguridad... en fin...
Asignada la cuenta de inicio de sesion, como lo muestra la imagen, y guardado el objeto DCOM, solo quedaba volverlo a probar...y como se dice por ahi... "cool... it works.."
Finalización y consideraciones...
El problema se solucionó, el archivo XLSX se genera y se envía via tareas agendadas y todos contentos... peeerrrooo...
En este caso la configuración del objeto DCOM generar una vulnerabilidad, cualquier otra tarea agendada que se ejecute en el server invocando Excel Application, va a utilizar como inicio de sesión la cuenta con los privilegios que nosotros asignamos.
Deberíamos acotar los permisos y privilegios al máximo para prevenir cualquier "accidente" que surja de la explotación de esta cuenta.. (debemos tener esto especialmente en cuenta... recuerden que al principio indique que no hay políticas de dominio sobre este server que hagan esta tarea por nosotors...)
Conclusiones
Como solución rápida, en ambientes chicos, para reportes pequeños, sin ningunada duda, fue un éxito. No pretende suplantar a report server ni ninguna otra herramienta similar.
Realizadas las excepciones de seguridad antes dicha, agendar reportes en CSV para luego transformarlos en XLSX o incluso PDF usando Excel es una alternativa viable... se pueden adornar más los reportes incluyendo logos, ajustando formatos, etc.
Porque no lo dejamos en CSV?... eso... eso es otra historia...
|