Enviando datos en crudo a una impresora

Hola chavales, en el curro me he topado con un problema con unas viejas impresoras matriciales.
Resulta que el programa que envía los datos a imprimir, los manda "en crudo" ("raw" para los colegas).

Explico, nosotros tenemos un driver que suplanta una impresora Postscript y crea un PDF. Pues bien, la impresión "en crudo" lo que hace básicamente el saltarse el driver a la torera y enviar los datos directamente al puerto.

Para hacer las pruebas pertinentes, utilizamos un programita de Micro$oft:
 https://support.microsoft.com/es-es/kb/138594?wa=wsignin1.0

Gracias a las pruebas con este programita detectamos que el driver no se ejecutaba, y que los datos iban del tirón al puerto en cuestión.

Así que ya sabéis que si una impresora matricial no funciona, quizá la culpa no sea del driver.

Salu2 a to2

Trabajo con impresoras desde la línea de comandos en Windows

Hola a todos, hoy se ma ha planteado la necesidad de ver cómo se puede cambiar el nombre de una impresora desde la línea de comandos de Windows.

Pues bien, resulta que Microsoft incorpora una serie de Scripts VBS para trabajar con las impresoras.

https://technet.microsoft.com/es-es/library/cc771846%28v=ws.10%29.aspx

Lo primero es localizar estos scripts en el ordenador. En el servidor donde estaba trabajando se encontraban en la ruta C:\Windows\System32\Printing_Admin_Scripts\es-ES\

A partir de ahí puedes utilizar estos scripts para hacer cosas como listar las impresoras del sistema:

   cscript prnmngr.vbs -l 

O cambiar el nombre de una impresora:

  cscript prncnfg.vbs -x -p "Microsoft XPS Document Writer" -z XPS

Salu2 a to2

Comparando antes y después con Windows

Hola a todos. En un servidor con Windows Server 2012 tenemos una aplicación que cuando un usuario con privilegios de administrador instalaba, dicha aplicación funcionaba correctamente.

Pero si se borraba el perfil local de la máquina (teniendo "roaming profiles" en el Active Directory), tras iniciar sesión en el servidor la aplicación ya no funcionaba.

Dicha aplicación se instala en el perfil del usuario, algo nada recomendable pero por lo que se ve los programadores de esta aplicación lo hicieron así. Así que cuando ese "perfil movil" se movía, había algo de la aplicación que no se estaba moviendo correctamente.

Después de muchos quebraderos de cabeza y muuuuuuuchas horas de trabajo, conseguimos averiguar qué era y solucionar el problema. Para ello usamos el software "Process Monitor".

  https://technet.microsoft.com/es-es/sysinternals/bb896645.aspx

Partiendo de un perfil limpio, instalamos la aplicación y luego lanzamos el process monitor.

Aplicamos todos los filtros necesarios para excluir de la captura de eventos los procesos típicos del sistema (como el "task manager", o el "svchost"), y lanzamos la apliación que lógicamente funcionó correctamente. Luego guardamos la captura como CSV.


Tras esto, cerramos sesión, borramos el perfil local y a tras traerse el perfil móvil hicimos otra captura de eventos con el Process Monitor, pero esta vez sabíamos que la aplicación fallaría.

Una vez que teníamos 2 ficheros CSV (una con los eventos cuando la aplicación funciona y otra cuando no funciona). Los abrimos con Excel y quitamos las columnas de fecha y hora, y del ID de proceso. De esta forma los dos ficheros CSV son similares hasta el punto donde falla la aplicación.

Finalmente, comparando ambos ficheros CSV con Winmerge (que para algo son ficheros de texto), pudimos ver que nos faltaban algunas entradas del registro e incluso una librería DLL.

RESUMIENDO: Si queréis comparar un "antes" y un "después" del comportamiento de una aplicación, el "Process Monitor" es un buen aliado.

Salu2 a to2