Supporto Tecnico Enterprise : Windows Vista

Printer Server – Installare stampante locale senza interazione dell’utente

itentblg — Sun, 25 Oct 2009 23:00:00 GMT

In questo post vediamo come installare i driver delle stampanti locali tramite script in maniera automatizzata e sui vari client senza la necessità dell’interazione con l’utente.

Le stampanti “Plug & Play” collegate localmente richiedono le credenziali di amministratore per poter essere installate come indicato nel seguente articolo:

KB 326473
You Are Prompted for Administrator Credentials When You Try to Install a Plug and Play Printer
http://support.microsoft.com/default.aspx?scid=kb;en-us;326473

Quindi, nel momento in cui si collega la stampante al computer, è visualizzato il wizard d’installazione che richiede l’inserimento delle credenziali di amministratore.

Il wizard è avviato automaticamente dal Sistema Operativo in quanto il driver richiede “Client-side Installations” come indicato nel seguente articolo MSDN:

Device Installation Types
http://msdn.microsoft.com/en-us/library/ms791105.aspx

Devcon tool permette di interagire direttamente con il Device Manager e quindi evitare che l’utente riceva la schermata di installazione dei driver.
Maggiori informazioni sono disponibili sul TechNet:

Devcon Overview
http://technet.microsoft.com/en-us/library/cc737393(WS.10).aspx

Per quanto riguarda le stampanti, è possibile creare uno script di logon che esegua il rescan delle periferiche collegate al computer:

devcon.exe /rescan

A questo punto, la nuova stampante collegata localmente al PC sarà aggiunta dal Plug & Play nel Device Manager e tramite il seguente comando si eseguirà l’aggiornamento del driver:

devcon update %InfFile% %HardwareID%

Se il driver della stampante che vogliamo installare è inbox, ovvero presente nel CD di installazione del Sistema Operativo, è possibile far puntare %InfFile% a C:\WINDOWS\inf\ntprint.inf che contiene tutta la lista delle stampanti riconosciute da Windows.

Un altro comando utile per identificare tutte le stampanti installate nel computer è il seguente:

devcon.exe listclass printers

Inoltre, è anche possibile rimuovere la periferica tramite questo comando:

devcon.exe /remove %HardwareID%

Se non si conosce a priori l’Hardware ID della periferica installata nel computer, ma si conosce la lista delle stampanti presenti in azienda, è possibile creare l’installazione di tutti i driver conosciuti, in quanto devcon fallisce in caso non sia presente la periferica corrispondente all’Hardware ID specificato.
Questo semplifica la scrittura dello script d’installazione perché non richiede a priori la ricerca del tipo di periferica, anche se è possibile gestire i return code come indicato in questa sezione:

Devcon Remarks
http://technet.microsoft.com/en-us/library/cc779075(WS.10).aspx

Il download dell’applicazione è disponibile a questo indirizzo:

KB 311272
The DevCon command-line utility functions as an alternative to Device Manager
http://support.microsoft.com/kb/311272

Infine, una guida utile per controllare tramite Group Policy quali periferiche possono essere installate in Windows Vista e Windows Server 2008:

Device Management and Installation Step-by-Step Guide: Controlling Device Driver Installation and Usage with Group Policy
http://technet.microsoft.com/en-us/library/cc731387(WS.10).aspx

Daniele Maso
Senior Support Engineer
Microsoft Enterprise Platform Support

Windows Update - Panoramica dei log d’installazione degli aggiornamenti

itentblg — Mon, 31 Aug 2009 02:00:00 GMT

Come abbiamo visto nell’articolo precedente, nei nuovi sistemi operativi il processo di aggiornamento di una macchina è basato su di una tecnica transazionale, che garantisce la corretta installazione di tutti gli aggiornamenti scaricati.

Come accennato, gli eventi di sistema sono la prima fonte di informazione nel caso ci siano problemi durante l’installazione degli aggiornamenti. Le informazioni contenute nella descrizione degli eventi sono però ad alto livello, ovvero a livello di pacchetto.

Con questo articolo vi illustro dove reperire ulteriori informazioni riguardo un’installazione fallita.

I principali posti da cui recuperare le informazioni relative all’installazione dei componenti, oltre agli eventi di sistema, sono:

%windir%\WindowsUpdate.log
%Windir%\logs\CBS.log

Mentre nel caso di errori di installazione al reboot della macchina:

%WinDir%\WinSxS\pending.xml
%WinDir%\WinSxS\poqexec.log

Seguendo l’ordine sopra descritto, si può tracciare una completa attività del processo di aggiornamento, in ordine crescente di dettagli.

Nel log di WindowUpdate troviamo tutta l’interazione con il server di aggiornamento, sia esso WSUS oppure il sito web Microsoft, ed inoltre troviamo lo stato finale dell’installazione come riportato dal servizio CBS. Nel caso di errori specifici all’installazione la sola consultazione di questo file non è sufficiente.

Nel secondo log della lista - CBS.log - troviamo tutte le operazioni effettuate dai componenti CBS, quindi la creazione delle transazioni e la valutazione delle regole di applicabilità. Il log non è “user-friendly” però a volte uno sguardo sommario può dare qualche indicazione in più sull’errore occorso durante l’installazione e fare puntare il dito verso una determinata risorsa (file, registro, permesso, ect.)

Gli ultimi due file sono strettamente legati tra loro, e servono per individuare l’errore quando l’installazione subisce problemi in fase di riavvio della macchina.

Addentriamoci ulteriormente nell’architettura CBS.

Possiamo pensare ad un pacchetto di aggiornamento come una serie/lista di operazioni da effettuare sul sistema; questa lista di operazioni, da eseguire con un ordine ben definito da regole di precedenza e di dipendenza, viene suddivisa in due code differenti:

Coda delle operazioni primitive (Primitive Operations Queue)
Coda delle operazioni avanzate (Advanced Installer Queue)

La prima coda contiene tutte quelle operazioni considerate “facili”, come ad esempio le operazioni sui file o sul registro di sistema; mentre la seconda coda viene riempita con tutte le operazioni che non possono essere modellate come operazioni primitive: ad esempio una modifica alle regole del firewall, l’installazione di una licenza..etc..

Per lo scopo di questo articolo, per semplificare le cose, consideriamo solamente la coda delle operazioni primitive.

Una volta costruita la coda, essa viene passata ad un componente che si occupa di eseguire tutte le operazioni elencate all’interno di una transazione kernel. È frequente che tra tutte queste operazioni alcune non possano essere eseguite durante la sessione di installazione, per i più svariati motivi, primo fra tutti l’accesso a file/risorse attualmente in uso.

Tutte queste operazioni “bloccano” la transazione richiedendo la propria esecuzione in fase di avvio della macchina. Davanti ad una simile richiesta il sistema operativo genera un file XML con il contenuto della coda primitiva (POQ) da eseguire durante il prossimo reboot. Il file generato è pending.xml ed è situato dentro la cartella %windir%\winsxs.

Esempio di file pending.xml:

<PendingTransaction Version="1.0" Identifier="58d5f3e1ca77c80164000000280f4c15">
<POQ>

<BeginTransaction id="TI4.29915082:3359338114:4/Package_for_KB937287" />
<MoveFile source="\SystemRoot\WinSxS\Temp\PendingRenames\b3053de0ca77c80161000000280f4c15 " destination="\SystemRoot\WinSxS\FileMaps\$$_servicing_fc2045b9046cc796.cdf-ms" />
<CreateFile path="\SystemRoot\WinSxS\FileMaps\$$_servicing_version_6.0.6001.18000 " fileAttribute="0x00000000" />
<DeleteFile path="\??\C:\Windows\System32\test.exe" />

</POQ>

Se al prossimo riavvio dovesse capitare un problema, il file verrà rinominato in pending.xml.bad e verrà generato il file poqexec.log all’interno della stessa cartella. Quest’ultimo file è come se contenesse l’indice degli errori occorsi all’interno del file pending.xml.bad. Controllando questo file il più delle volte riusciamo a trovare la specifica operazione primitiva che ha causato la fallita installazione.

Riporto un esempio concreto del file poqexec.log:

1c91429dcbd5e25: 0, 0, 0, 0, StartTime ;
1c91429e0a9e5b1: 0, 0, 0, 0, EndTime ;
1c92edb3b79b5c1: 0, 0, 0, 0, StartTime ;
1c92edb43e8bf82: 0, 0, 0, 0, EndTime ;
1c935d353ff8079: 0, 0, 0, 0, StartTime ;
1c935d3554f2373: 0, 0, 0, 0, EndTime ;
1c948b2d25268d5: 0, 0, 0, 0, StartTime ;
1c948b2d25268d5: 65b, c0190036, 16, 0, DeleteFile ;\??\C:\Windows\System32\test.exe
1c948b2d2787f05: 0, 0, 0, 0, EndTime ;

In caso di errori persistenti, come suggerisce l’articolo KB 949358 è possibile eliminare il file pending.xml per evitare che al successivo riavvio la macchina tenti di eseguire le sempre stesse operazioni che portano al problema.

Ogni errore ha una sua soluzione specifica, ma controllando tutti questi file, possiamo avere maggiori dettagli sugli errori occorsi, ed a volte possiamo anche trovare un work-around per la risoluzione del problema.

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platforms Support

Windows Update - TrustedInstaller e l’installazione transazionale

itentblg — Mon, 24 Aug 2009 02:00:00 GMT

Da Windows Vista in avanti è stata rivista gran parte dell’architettura di aggiornamento del sistema operativo. Si è passati da un’installazione “stand-alone” dei singoli aggiornamenti ad un sistema transazionale. Questa tecnica transazionale è molto più robusta e sicura della precedente, in quanto garantisce che il sistema si trovi sempre in uno stato consistente.

In parole più semplici, gli aggiornamenti vengono raggruppati in transazioni, e viene fatto un commit delle operazioni solamente se tutti gli aggiornamenti in una transazione non presentano errori nella propria di installazione. Al contrario se anche un solo aggiornamento fallisce la sua installazione, allora tutta la transazione viene annullata e nessun componente viene aggiornato.

Questa nuova architettura prende il nome di Component-Based Servicing (CBS) , e si basa sul concetto di componente. Un component è un’unità di “cambiamento dello stato del sistema” (file, registry key, settings, risorsa, etc.). Esso possiede un identità ed è trattato come un oggetto atomico. I componenti sono organizzati in deployment che a loro volta sono contenuti all’interno di package, unità di distribuzione. Un componente, così come un deployment ed un pacchetto, può avere delle dipendenze da soddisfare prima della propria installazione.

I principali componenti di questo nuovo sistema sono i seguenti:

Windows Modules Installer (TrustedInstaller.exe, CBS): è il servizio principale che lavora a livello di pacchetto/update ed analizza l’applicabilità di un aggiornamento
Component Servicing Infrastructure (CSI): infrastuttura di base che lavora a livello di deployment e a livello di componente, gestisce l’accesso e l’interazione con lo store dei componenti
Component Store: è formato dalla cartella %WinDir%\WinSxS e da un ramo particolare del registro. Esso è il ripostiglio di tutti i componenti e del loro manifesto (file XML che ne descrive le proprietà e le dipendenze)

In linea generale un pacchetto di aggiornamento viene passato al servizio CBS, che ne valuta l’applicabilità e lo scompatta nei vari deployment. A questo punto ogni deployment viene passato al livello CSI che si occupa di verificare la presenza dei vari componenti, ne controlla le dipendenze ed il loro stato. Infine il componente viene installato sul sistema. Tutte queste operazioni vengono eseguite all’interno di una transazione kernel che ne garantisce la corretta esecuzione.

Negli eventi di sistema vengono loggate tutte le operazioni effettuate, quindi un sguardo agli eventi è sempre il passo base per qualsiasi problema nell’installazione dei componenti. Questi eventi sono autoesplicativi, quindi ometto la loro descrizione. Il provider di tali eventi è Microsoft-Windows-Servicing.

Dopo questa panoramica, che è necessaria per capire la nuova architettura, nel prossimo articolo vi illustrerò dove recuperare maggiori informazioni in caso di errori durante l’installazione di un componente.

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platforms Support

Editing dei file del registro direttamente dal file WIM

itentblg — Mon, 16 Feb 2009 03:00:00 GMT

WIM Files

Le recenti versioni dei sistemi operativi Microsoft (Vista e Windows Server 2008) vengono fornite su media che contengono un nuovo formato di immagine di disco chiamato WIM.

I WIM File sono dei file compressi che contengono immagini di disco che a differenza delle normali immagini sector based sono file based. Questo significa che il WIM File è un contenitore di file che in aggiunta fornisce dei descrittori di come gli oggetti contenuti in esso devono essere copiati e configurati su disco. Grazie a questa strutturazione è possibile avere all’interno delle immagini nel WIM un unico file che se necessario può essere “istanziato” più volte invece che copiato. E’ chiaro che questo meccanismo, in aggiunta alla compressione delle immagini porta a ridurre considerevolmente la dimensione del file WIM che potrà quindi contenere più immagini di disco.

Intestazione WIM : definisce il contenuto del file con estensione wim, inclusi la posizione di memoria delle risorse principali (metadati, tabella di ricerca, dati XML) e vari attributi del file (versione, dimensioni, tipo di compressione).

Risorsa file : una serie di pacchetti contenenti i dati acquisiti, ad esempio i file di origine.

Risorsa metadati: contiene informazioni sui file acquisiti, inclusi la struttura di directory e gli attributi del file. In un file con estensione wim esiste una risorsa metadati per ogni immagine.

Tabella di ricerca: contiene la posizione di memoria dei file di risorse nel file con estensione wim.

Dati XML: contiene ulteriori informazioni sull'immagine.

Tabella di integrità: contiene informazioni sull'hash di protezione utilizzato per verificare l'integrità di un'immagine nel corso di un'operazione di applicazione.

File default HIVE in XP e variazione con vista Vista/Windows Server 2008

Nella versione precedente di Windows XP la configurazione di default del registry era importata utilizzando i file HIVE*.inf contenuti nella cartella del media di installazione. La modifica di questi file consentiva di fatto di generare una configurazione personalizzata del registry prima ancora del setup.

Nei file .WIM è contenuta un’immagine completa di un’installazione del sistema e di conseguenza non esistono più tali file.

Contenuto del media d’installazione

Sfogliando il media di installazione di Vista o Windows Server 2008 si possono individuare due file .WIM.

Boot.wim: contiene Windows PE; un sistema operativo minimale basato su kernel Vista. Consente di eseguire il setup, eseguire operazioni di risoluzione di problemi ed infine eseguire il ripristino automatico in caso di software OEM.
Install.wim: contiene le immagini di installazione del sistema operativo.

IMAGEX e modifica del REGISTRY

Con il formato .WIM viene introdotto il tool Imagex, necessario per lavorare con le immagini file based. Questo tool consente in particolare di scompattare in una cartella su disco le immagini contenute nel file .WIM consentendo così di lavorare OFFLINE sulla futura installazione del sistema. Per quanto riguarda in particolare la modifica del registry, la procedura consisterà nello scompattare l’immagine, caricare nel registry della propria macchina il file del registry che si vuole modificare contenuto nell’immagine, apportare le modifiche e salvare l’immagine includendo il nuovo file modificato. Vediamo nel dettaglio la procedura.

Prima di tutto eseguiamo il mount del file install.wim in read/write nella cartella c:\mount\ dopo aver copiato il file install.wim su disco, con il seguente comando:

imagex /mountrw install.wim 1 c:\mount

Ora nella cartella c:\mount\ vi è il contenuto del disco che si ha con una normale installazione di Windows (Vista Server 2008). Nella folder c:\mount\windows\system32\config\ sono contenuti i file del registry, tra cui ad esempio il file DEFAULT (setting di default a livello utente).

Il passo successivo consiste nel caricare l’hive DEFAULT nel registry della propria macchina ad esempio in HKLM\esempio ed editarlo con i setting necessari. Possiamo usare il seguente comando:

reg load HKLM\esempio c:\mount\windows\system32\config\DEFAULT

Terminata la modifica scarichiamo il file HIVE appena editato con il seguente comando:

reg unload HKLM\esempio
La procedura termina con l’unmount e il salvataggio dell’immagine tramite il seguente comando:

imagex /unmount /commit c:\mount

Marco Pulita
Microsoft Enterprise Platform Support

Estensione della partizione di sistema di Windows Server 2003

itentblg — Mon, 08 Dec 2008 03:00:00 GMT

Durante la fase di installazione di un nuova macchina, si devono fare scelte ben precise sul dimensionamento della partizione di sistema. Può capitare che a posteriori, per ragioni che non erano state prese in considerazione, si debbano rivalutare queste scelte.

Il caso più comune è quello in cui si vuole ripartizionare il disco fisso, aggiungendo o modificando le partizioni esistenti. Nei nuovi sistemi operativi, Windows Server 2008 a Vista sono presenti due comodi comandi nella console di gestione dei dischi:

Shrink
Extend

Il primo comando viene utilizzato per restringere una partizione esistente, liberando spazio che può essere riassegnato ad altre partizioni.

Il secondo comando, invece è utilizzato per ingrandire una partizione. Un requisito necessario per eseguire il comando di estensione è la disponibilità di spazio contiguo non allocato, in coda alla partizione. Per fare un esempio pratico:

Nei nuovi sistemi operativi questi comandi sono utilizzabili su tutte le partizioni esistenti, senza limitazioni di sorta. Gli stessi comandi sono disponibili dalla console tramite il comando diskpart.

Il comando di estensione è presente anche su Windows Server 2003 SP2, ma non può essere utilizzato sulla partizione di sistema. Per ovvi motivi questa partizione, in cui è installato il sistema operativo, non può essere soggetta a questo tipo di operazioni. Esiste però un work-around per aggirare questa limitazione.

Il meccanismo è semplice, basta procurasi il CD di installazione di Vista o Windows Server 2008, e procedere con una finta installazione. Il programma di installazione di questi nuovi sistemi operativi, contiene la nuova versione del tool di partizionamento, che incorpora il comando di estensione.

Durante questa fase d’installazione, il sistema operativo presente sul disco non è attivo, quindi la partizione di sistema è accessibile e modificabile.

Vediamo in dettaglio come procedere:

Boot della macchina con il CD di installazione
Premere un tasto per Iniziare l’installazione
Inserire il codice della licenza a scegliere l’installazione “custom”
Quando viene mostrata la schermata che permette di scegliere la partizione su cui installare il sistema operativo, scegliere le opzioni avanzate. A questo punto comparirà il pulsante che permetterà di effettuare l’operazione di estensione.

Una volta terminato il nuovo layout del disco potete abbandonare l’installazione.

Al successivo riavvio della macchina, il disco avrà il nuovo layout senza nessun tipo di danno alle componenti del sistema operativo.

L’operazione di shrink al contrario non è stata inserita nel programma di installazione.

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platforms Support

Windows Vista: Point & Print

itentblg — Mon, 29 Sep 2008 02:00:00 GMT

Di seguito vediamo le modifiche apportate alla funzionalità Point & Print di Windows Vista.

Point & Print è una funzionalità che permette agli utenti di collegarsi ad una stampante di rete senza avere la necessità di installare i driver manualmente.

Point & Print scarica automaticamente e installa i printer driver richiesti quando un utente si collega alla stampante condivisa.

Un’altra funzione interessante è l’aggiornamento nel client dei driver o della configurazione della stampante quando la configurazione è modificata nel printer server.

Differenze di “Point & Print” in Windows Vista?

Point & Print installa del software nel computer client e quindi è soggetto all’”Enhanced Security Model” di Windows Vista.

Per poterlo configurare, sono state aggiunte delle nuove group policy nella sezione Stampanti riguardo a “Restrizioni di selezione e stampa” (Point & Print Restrictions).

Best Practice per la sicurezza con Point & Print

Le group policy possono essere modificate utilizzando “gpedit.msc” e sono localizzate in “Configurazione Utente\Modelli amministrativi\Pannello di controllo\Stampanti”.

Di seguito vediamo varie configurazioni possibili in diversi scenari.

Scenario 1: Utilizzare stampanti definite tramite group policy

Con le “Deployed Printers”, solo le stampanti definite per utente o gruppi saranno installate nei client controllati tramite Group Policy.

Questo è considerato il modo più sicuro perché i client avranno installate solo le stampanti definite nelle Group Policy. La configurazione delle “Deployed Printers”, può essere eseguita tramite il “Print Management Console” (printmanagement.msc) pere creare le GPO e definire le stampanti da installare.

Configurazione: Impostare le GPO come indicato di seguito.

Dopo aver configurato le stampanti da installare, bisogna configurare la Group Policy di “Restrizioni di selezione e stampa” (Point and Print Restrictions) come segue:

“Restrizioni di selezione e stampa” (Point and Print Restrictions): Attivata.
Quando si installano i driver per una nuova connessione (When installing drivers for a new connection): “Non mostrare avvisi o richieste di elevazione” - Do not show warning or elevation prompt.
Quando si aggiornano i driver per una connessione esistente (When updating drivers for an existing connection): Mostra solo avvisi - Show warning only.

User Experience: Dopo aver configurato le “Deployed Printers” e la group policy di restrizioni del “Point & Print”, le stampanti saranno automaticamente installate nei client al successivo logon degli utenti. L’utente non vedrà nessun messaggio di avviso neanche nella prima installazione della stampante. Comunque, nel caso in cui la configurazione della stampante fosse aggiornata lato printer server, l’utente riceverà un avviso che lo informerà riguardo la necessità di modificare la configurazione o aggiornare i driver.

Scenario 2: Utilizzare le impostazioni di sicurezza predefinite

Le impostazioni di sicurezza predefinite in Windows Vista forniscono il livello più alto di sicurezza e avvisano l’utente prima di installare il software nel computer. Il valore di default inoltre inibisce l’installazione di software ai soli utenti con privilegi amministrativi.

Printer driver certificati, come quelli presenti nel DVD di installazione o nei pacchetti di installazione, non richiedono le credenziali di amministrazione per eseguire l’installazione.

Configurazione: Nessuna ulteriore configurazione è necessaria.

User Experience: Se un utente si collega da una stampante di rete e i driver necessari non sono presenti nel computer, o se il driver è stato aggiornato nel printer server, “Point & Print” inizia il processo di installazione. Per prima cosa, è visualizzato un messaggio di avvertimento all’utente come illustrato di seguito:

Dopo che un utente con i privilegi amministrativi clicca sul pulsante “Installa driver”, una finestra di dialogo è visualizzata richiedendo i permessi per continuare.

Se l’utente invece non ha i diritti amministrativi per installare i driver, sarà visualizzata la schermata del “Controllo Account Utente” (User Account Control) richiedendo la password di amministrazione.

Scenario 3: Utilizzare “Point & Print” su alcuni Printer Server

La group policy “Point & Print Restrictions” permette di limitare i server ai quali gli utenti possono collegarsi per installare le stampanti. Inoltre, è possibile limitare il tipo di driver disponibili sul server in modo da utilizzare solo driver certificati o che non richiedono il download, come quelli presenti nel DVD di installazione.

Configurazione: Primo, configura il printer server in modo da condividere solo stampanti con driver certificati o già presenti nel DVD di installazione del client. Questi driver possono essere:

in-box printer drivers
printer driver presenti in un pacchetto
printer driver testati e certificati
printer driver già installati nel client.

Poi configura le seguenti opzioni nelle Group Policy:

“Restrizioni di selezione e stampa” (Point and Print Restrictions): Attivata.
“Gli utenti possono selezionare e stampare soltanto su questi server” (Users can only point and print to these servers): Selezionata.
Immettere i nomi completi dei server (FQDN - Fully Qualified Server Name) separati dal punto e virgola
Quando si installano i driver per una nuova connessione (When installing drivers for a new connection): Non mostrare avvisi o richieste di elevazione.
Quando si aggiornano i driver per una connessione esistente (When updating drivers for an existing connection): Non mostrare avvisi o richieste di elevazione.

User Experience: Quando un utente si collega ad una stampante che è condivisa su un printer server presente nella lista della Group Policy, Point & Print installa i driver necessari e non richiede l’interazione dell’utente. Se un utente si collega ad un stampante di rete su un altro server, Point & Print non installerà i driver sul client. L’utente potrà utilizzare ugualmente la stampante ma solo se non sarà necessario scaricare i driver (installati precedentemente oppure inbox).

Scenario 4: Utilizzare stampanti solo con driver inclusi nel DVD di installazione

Le stampanti con i driver presenti nel DVD di installazione possono essere utilizzate senza la necessità di scaricare del software dal printer server. Se tutte le stampanti presenti nella rete utilizzano dei driver inbox, non sarà visualizzato nessun messaggio di avviso agli utenti quando si collegheranno alle stampanti.

Configurazione: Verificare che tutte le stampanti condivise abbiano disponibili dei driver inbox per tutte le versioni di Windows installate nei client aziendali.

User Experience: Quando un utente si collega alla stampante di rete che ha dei driver inbox, la stampante sarà installata utilizzando il software già presente nel computer client. Point & Print non scaricherà nessun driver e quindi l’utente non vedrà nessun messaggio di avviso.

Scenario 5: Utilizzare il livello di sicurezza di Windows XP

E’ possibile utilizzare la Group Policy delle restrizioni Point & Print per fornire ad un client con Windows Vista, lo stesso livello di sicurezza presente in Windows XP.

Configurazione: Configurare la group policy “Restrizioni di selezione e stampa” (Point and Print Restrictions) come segue:

“Restrizioni di selezione e stampa” (Point and Print Restrictions): Attivata.
Quando si installano i driver per una nuova connessione (When installing drivers for a new connection): “Non mostrare avvisi o richieste di elevazione” - Do not show warning or elevation prompt.
Quando si aggiornano i driver per una connessione esistente (When updating drivers for an existing connection): “Non mostrare avvisi o richieste di elevazione” - Do not show warning or elevation prompt.

User Experience: Gli utenti non vedranno nessun messaggio di avviso aggiuntivo quando si collegheranno ad una stampante di rete e Point & Print eseguirà l’installazione dei nuovi driver o eseguirà un aggiornamento della configurazione esistente nel client.

Scenario 6: Utilizzare stampanti con Pacchetti Driver (Printer Driver Packages)

Windows Vista introduce un nuovo modo di distribuire i driver per le stampanti. Un Pacchetto Driver è costituito da un gruppo di file firmato digitalmente che forma un printer driver. Questi pacchetti sono sicuri e possono essere installati dagli utenti senza richiedere permessi di tipo amministrativo.

Configurazione: Verificate che la stampante di rete presente nel print server abbia un Printer Driver Packages fornito dal costruttore. Da notare che solo Windows Vista e Windows Server 2008 possono utilizzare i Pacchetti Driver. Computer che hanno installato una versione precedente di Windows non possono utilizzare il Printer Driver Packages.

User Experience: Siccome i Pacchetti Driver sono firmati digitalmente e quindi sicuri, questi sono scaricati e installati senza visualizzare nessun tipo di avviso all’utente.

Maggiori informazioni e approfondimenti:

Daniele Maso
Senior Support Engineer
Microsoft Enterprise Platforms Support