Unattended printing

Salve a tutti!

Oggi volevo parlarvi un pò di architettura delle applicazioni.

C’è un problema che assilla molti, e che fino ad oggi non ha molte soluzioni: la stampa batch di documenti.

Molti hanno la necessità di stampare documenti Word (ma anche Pdf, Xps e così via) da servizi che girano su application server. Questi server molte volte sono dislocati in posti impensabili e su quelli, di solito non ci sono utenti collegati fisicamente.

Le applicazioni di Office hanno diverse limitazioni in questi casi, in quanto non sono pensate per funzionare in questo tipo di environment. A partire da Vista poi si è aggiunta anche la Session 0 isolation, e il fatto che in quella sessione i driver video non sono nemmeno caricati. Quindi, ufficialmente, le applicazioni di Office non sono supportate se usate da applicazioni Server o da servizi:

257757  Considerations for server-side Automation of Office
http://support.microsoft.com/default.aspx?scid=kb;EN-US;257757

Come risolvere il problema quindi?

Abbiamo sicuramente bisogno di una sessione utente. In questa, quando un utente esegue il logon fisico alla macchina, avremo a disposizione le informazioni sulle stampanti installate sul sistema, e avremo accesso all’Ole Automation per comandare WinWord.

Possiamo avere due casi principali:

1 Un utente si collega generalmente al server.

2 Nessun utente si collega.

Nel caso 1, dovremo solo aspettare che un utente si colleghi e dal nostro servizio, creare un processo nella sessione utente come quell’utente. Questo processo provvederà a salvare i file da stampare in una carella temporanea e poi automatizzerà winword per eseguire la stampa.

I file e le informazioni sulla stampa, tipo quante copie, su quale stampante, in che formato ecc.., potranno essere lette da un DB o dal file system o da un coda di MSMQ. Qui abbiamo la più grande libertà di implementazione, nel senso che può essere il servizio a provvedere alla lettura delle informazioni e fare il dequeue dei documenti sul file system o può essere l’applicazione stessa.

Nel caso 2 invece, dobbiamo fare in modo di avere una sessione utente sul server. Possiamo utilizzare per questo la feature di Autologon del sistema operativo, in modo che al boot del Server, questo automaticamente si colleghi come un utente, in modo che il nostro servizio possa trovare una sessione e lanciare in quella la nostra applicazione. In questo specifico caso, se è la nostra applicazione che fa tutto, cioè si preoccupa di ricevere i file da stampare e le opzioni per questi, possiamo anche non avere il servizio, nel senso che possiamo usare l’Autorun per impostare l’esecuzione automatica della nostra applicazione. Avere un servizio è sempre comodo qualora la nostra applicazione andasse in crash o fosse chiusa inaspettatamente da un utente. Senza una applicazione di controllo, dovremo attendere il prossimo riavvio del server per poter riattivare la procedura di stampa.

Se qualcuno è estremamente preoccupato della privacy e della security del server, si può creare un Logon script che provveda ad avviare una applicazione di una linea, che chiamerà LockWorkstation. In questo modo, quando il server viene riavviato, usando l’AutoLogon viene creata una sessione utente, e la prima cosa che avviene è che la workstation viene lockata, così nessuno può vedere l’interfaccia di quella sessione e accedere alle informazioni ivi contenute. Una VM poi è l’ideale per questo tipo di utilizzo.

Alla prossima!

Mario Raccagni
Senior Support Engineer
Platform Development Support Team