Windows Defender è diventato in Windows 10 l’antivirus ufficiale per così dire tanto è vero che System Center Endpoint Protection non sarà più necessario su sistemi Windows 10 come riportato in Microsoft System Center Endpoint Protection Technical Preview:

“With Windows 10, System Center Configuration Manager Technical Preview will manage Windows Defender on Windows 10 computers without installing a separate Endpoint Protection agent. This means that all malware management and reporting will now come from Defender. The Endpoint Protection agent is still required for Windows 8.1 and earlier Windows operating systems.”

La medesima indicazione viene anche data per System Center 2012 R2 Endpoint Protection in How to Configure Endpoint Protection in Configuration Manager:

“If you manage endpoint protection for Windows 10 computers, then you must configure System Center 2012 Configuration Manager to update and distribute malware definitions for Windows Defender. Because Windows Defender is included in Windows 10, an endpoint protection agent does not need to be deployed to client computers.”

Per configurare Windows Defender sono disponibili vari approcci oltre a quello consigliato a livello Enterprise di utilizzare System Center Configuration Manager per i sistemi Windows 10.

Un secondo approccio consigliato nelle infrastrutture di senza System Center è quello di utilizzare le Group Policy Computer Configuration/Administrative Templates/Windows Components/Windows Defender:

Di seguito un esempio delle configurazioni tipo che possono essere applicate:

In Windows Vista le Group Policy a disposizione per la gestione di Windows Defender erano solo 8, mentre in Windows 8 e Windows Server 2012 sono state introdotte ben 91 Group Policy. In Windows 10 e Windows Server 2016 è sono state aggiunte la Group Policy Turn off Auto Exclusions:

“Allows an administrator to specify if Automatic Exclusions feature for Server SKUs should be turned off.”

Per un elenco delle Group Policy disponibili si veda Group Policy Settings Reference for Windows and Windows Server, mentre per una descrizione delle Group Policy principali si veda la KB927367 Description of the Windows Defender Group Policy administrative template settings.

Un terzo metodo è quello di intervenire sulle chiavi di registro, ma va detto che questa soluzione non è molto pratica se confrontata con la gestione tramite Group Policy, ma potrebbe essere utile in scenari con un numero ridotto di computer senza un’infrastruttura Active Directory. Si tenga presente che alcune chiavi di registro sono modificabili solo tramite l’account System quindi la cosa migliore è configurare tali chiavi di registro tramite uno script eseguito all’avvio del compter (a riguardo si veda Assign Computer Startup Scripts.

Di seguito ad esempio i comandi per gestire le esclusioni come da best practices suggerite nella KB 822158 Virus scanning recommendations for Enterprise computers that are running currently supported versions of Windows

Esclusioni per Windows Update:

REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths” /v %windir%\SoftwareDistribution\Datastore\Datastore.edb /t REG_DWORD /d 0 /f

REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths” /v %windir%\SoftwareDistribution\Datastore\Datastore.edb /t REG_DWORD /d 0 /f

REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths” /v %windir%\SoftwareDistribution\Datastore\Logs\Edb*.jrs /t REG_DWORD /d 0 /f

REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths” /v %windir%\SoftwareDistribution\Datastore\Logs\Edb.chk /t REG_DWORD /d 0 /f

REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths” /v %windir%\SoftwareDistribution\Datastore\Logs\Tmp.edb /t REG_DWORD /d 0 /f

Esclusioni per i Windows Security files:

REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths” /v %windir%\Security\Database\*.edb /t REG_DWORD /d 0 /f

REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths” /v %windir%\Security\Database\*.sdb /t REG_DWORD /d 0 /f

REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths” /v %windir%\Security\Database\*.log /t REG_DWORD /d 0 /f

REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths” /v %windir%\Security\Database\*.chk /t REG_DWORD /d 0 /f

REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths” /v %windir%\Security\Database\*.jrs /t REG_DWORD /d 0 /f

Esclusioni per i Group Policy related files:
REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths” /v %allusersprofile%\NTUser.pol /t REG_DWORD /d 0 /f

REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths” /v %SystemRoot%\System32\GroupPolicy\Machine\Registry.pol /t REG_DWORD /d 0 /f

REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths” /v %SystemRoot%\System32\GroupPolicy\User\Registry.pol /t REG_DWORD /d 0 /f

Di seguito invece alcune chiavi registro che possono essere utilizzate in Windows 8/8.1 per gestire la configurazione di Windows Defender:

Analisi Veloce giornaliera alle 13 (780 minuti):

REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Scan” /v ScheduleQuickScanTime /t REG_DWORD /d 780 /f

Verifica disponibilita’ definizioni prima di eseguire analisi pianificata:

REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Scan” /v CheckForSignaturesBeforeRunningScan /t REG_DWORD /d 1 /f

Intervallo verifica definizioni 1 ora:

REG ADD “HKLM\SOFTWARE\Microsoft\Windows Defender\Scan” /v SignatureUpdateInterval /t REG_DWORD /d 1 /f

In Windows 10 è anche possibile preconfigurare il sistema operativo  tramite il Windows Provisioning framework che consente anche la custominzation di Windows Defender a rigurado si vedano

Customize using the Windows Provisioning framework e la sezione WindowsDefender del

Windows Provisioning settings reference.

Volendo è anche possibile automatizzare l’esecuzione di alcuni task di Windows Defender tramite l’utility a riga di comando %ProgramFiles%\Windows Defender\MpCmdRun.exe, a riguardo si veda Run (and Automate) Windows Defender from the Command Line.

Di seguito alcuni esempi di comandi che possono essere avviati tramite un’operazione pianifica per automatizzarne l’esecuzione:

Avvio di una scansione veloce:
%ProgramFiles%\Windows Defender\MpCmdRun.exe -Scan -ScanType 1

Avvio di una scansione completa:
%ProgramFiles%\Windows Defender\MpCmdRun.exe -Scan -ScanType 2

Ricerca degli aggiornamenti delle definizioni:
%ProgramFiles%\Windows Defender\MpCmdRun.exe –SignatureUpdate

Per quanto riguarda i comandi di scansione è necessario eseguirli con privilegi elevati in modo da poter agire nel caso i malware si trovino in percorsi o file protetti, ad esempio nel caso vengano eseguiti tramite un’operazione pianifica converrà utilizzare l’account SYSTEM.

Il comando di aggiornamento delle definizioni dovrà invece essere eseguito nel contesto di un account amministrativo che abbia il diritto di accedere a Internet nel caso venga utilizzato un proxy.

Si noti che nel sistema sono già presenti una serie di operazioni pianificate relative a Windows Defender memorizzate all’interno della Libreria Utilità di pianificazione nel ramo Microsoft\Windows\Windows Defender.

Spesso agli eventi ricevo domande su alcuni problemi o issues che si verificano utilizzando i Remote Desktop Services.

Talvolta tali issues possono essere risolti tramite hotfix o workaroud a tal riguardo possono tornare utili le seguenti KB Microsoft in cui è possibile trovare l’elenco degli aggiornamenti rilasciati per i Remote Desktop Services nelle varie versioni del sistema operativo:

• KB2933664 Available Updates for Remote Desktop Services in Windows Server 2012 R2
• KB2821526 Available updates for Remote Desktop Services in Windows Server 2012
• KB2601888 Available Updates for Remote Desktop Services (Terminal Services) on Windows Server 2008 R2 SP1

Nel caso invece di problemi per la connessione tramite RDP verso VM in Azure si veda il seguente Troubleshoot Remote Desktop connections to a Windows-based Azure virtual machine.

Per problemi relativi al clinet RDP si vedano invece i seguenti:

• KB186645 Troubleshooting RDP Client connection problems 
• KB2477176 Troubleshoot “Remote desktop disconnected” errors in Windows Server 2008 R2

In Windows 10 i logs di Windows Update non  sono più memorizzati nel notepad %windir%\WindowsUpdate.log. Il file esiste ancora ma riporta la dicitura che ora i logs di Windows Update sono generati utilizzato Event Tracing for Windows (ETW). per maggiori informazioni sull’ETW si veda ETW (Event Tracing For Windows) – what it is and useful tools.

Aprendo il link suggerito (http://go.microsoft.com/fwlink/?LinkId=518345) si viene redirezionati alla KB3036646 How to read Windows Update logs in Windows 10 che spiega il motivo della scelta ovvero un aumento delle performance e un minore consumo di spazio su disco per la gestione dei logs a fronte di un accesso meno immediato, ma va precisato che tali logs sono di solito letti solo in caso di diagnostica.

Per leggere i logs estraendoli dall’EWT è possibile utilizzate il cmdlet PowerShell Get-WindowsUpdateLog che esegue il merge dei file etl files in un singolo file di log, di eseguito un esempio di utilizzo:

Get-WindowsUpdateLog -LogPath C:\Logs\WindowsUpdate.log

Alla prima esecuzione del cmdlet vengono scaricati i degugging symbols dal Microsoft symbol server e poi l’elaborazione procede con i seguenti fasi:

1. Lettura delle informazioni dai file .etl
2. Conversione in un formato intermedio CSV o XML, per default viene utilizzato il formato CSV, ma è possibile specificare di utilizzare l’XML tramite il parametro ProcessingType
3. Conversione del file nel formato intermedio in testo accodamento al file di log specificato dal parametro LogPath (se il parametro LogPath non viene specificato per default viene creato un file WindowsUpdate.log nella Desktop folder dell’utente che ha eseguito Cmdlet)

Per aprire il file di log tramite PowerShell è possibile utilizzare il comando:

Invoke-Item -Path C:\Logs\WindowsUpdate.log

Per aprire PowerShell in Windows 10 è possibile eseguire il comando PowerShell dalla dialog Esegui (WIN+R) o da un prompt dei comandi o usando la combinazione di tasti.

Per eventuali problemi si tengano presenti le note riportate nella KB3036646:

– If you’re having problems decoding the Windows Update log (for example, if you have multiple “GUID” entries that are displayed in the final text log), you may have to delete and then update your symbol cache. You can do this by deleting everything under the %temp%\windowsupdatelog folder.

– The first time that you run the Get-WindowsUpdateLog cmdlet, you may see the Microsoft Internet Symbol Store dialog box. To use the Get-WindowsUpdateLog cmdlet, you must accept the presented license terms to enable access to the public symbols that are used by the cmdlet.

– If you previously downloaded a symbol cache, you can use the -SymbolServer switch to use those symbols instead of connecting to the Microsoft symbol server. In order to do this, you must be able to provide a UNC path for that symbol cache.

– If you’re using Windows 10 Insider Preview, you may not always be able to decode the Windows Update log. Public symbols are published only for certain prerelease builds. Therefore, if public symbols are not available, you may be unable to successfully decode the log.

Come avevo riportato nel post Rilascio di Windows 10 fino al 29 luglio 2016 sarà possibile eseguire gratuitamente l’upgrade a Windows 10 dei sistemi Windows 7 Sp1 e Windows 8.1 con l’esclusione delle versioni Windows 7 Enterprise, Windows 8/8.1 Enterprise e Windows RT/RT 8.1.

Per quanto riguarda le versioni Enterprise il fatto di non poter eseguire l’upgrade è di fatto ininfluente dal momento che per poter eseguire tale versione di sistema operativo occorre avere la Software Assurance (SA) che garantisce la possibilità di poter aggiornare il sistema operativo alle versioni successive.

Per quanto riguarda ad esempio Windows 8.1 Pro con licenze a volume, ma non coperti da SA sarà quindi possibile eseguire l’upgrade nei seguenti modi.

Upgrade In-Place:

Installare Windows 10 avviando l’installazione da un sistema avviato e regolarmente attivato. Questo metodo permette di poter mantenere informazioni dell’utente e le applicazioni installate con tutti i pregi e i difetti tipici degli aggiornamenti In-Place anche se bisogna dare atto che in Windows 10 questo processo è stato molto perfezionato, infatti dopo l’aggiornamento In-Place il vecchio sistema operativo risiederà nella directory Windows.old e potrà essere eventualmente ripristinato entro 30 giorni.

Installazione pulita – Metodo 1:

Nel caso si abbia a disposizione una chiave VL per Windows 10 sarà possibile installare da zero il sistema operativo e usare tale chiave per attivare i sistemi reinstallati su cui si aveva di diritto eseguire l’aggiornamento. Ovviamente questo metodo prevede di dover acquistare almeno una copia VL di Windows 10.

Installazione pulita – Metodo 2:

Installare Windows 10 avviando l’installazione da un sistema avviato e regolarmente attivato e terminato l’aggiornamento eseguire il reset del sistema indicando di non voler mantenere file personale e applicazioni. In questo modo di avrà un sistema Windows 10 come se si fosse eseguita un’installazione pulita, attivato senza la necessità di dover acquistare una  una copia VL di Windows 10 come nel metodo che ho illustrato precedentemente. Ovviamente in questo caso i tempi di aggiornamento saranno maggiori.

Windows 10 introduce una serie di novità interessanti nell’ambito della sicurezza e una di questa è senza dubbio la tecnologia Virtual Secure Mode (VSM) che permette di implementare un ambiente sicuro in cui eseguire processi critici come il Local Security Authority (LSA) e il code integrity service.

VSM è una delle funzionalità di Device Guard, la collezione di feature di sicurezza disponibili nella versione Enterprise di Windows 10.

Scendendo nel dettaglio del funzionamento di VSM il Kernel Code Integrity service viene eseguito in un hypervisor-hosted service aumentando così la protezione del sistema operativo root e impedendo al malware di compromettere il kernel layer sfruttando il disaccoppiamento offerto dalla virtualizzazione. In pratica viene utilizzato un OS eseguito in in Hyper-V separtato dal sistema a cui Windows non ha accesso nè tramite GUI, nè tramite rete quindi anche nel caso in cui il kernel del sistema venisse compromesso i processi e i dati all’interno del VSM container rimarrebbero integri.

Come riportato in Device Guard overview per poter utilizzare VSM è necessario avere driver compatibili e le funzionalità di virtualizzazione attivate:

“Device Guard devices that run Kernel Code Integrity with virtualization-based security must have compatible drivers – legacy drivers can be updated – and have all virtualization capabilities turned on. This includes virtualization extensions and input/output memory management unit (IOMMU) support.”

Per quanto riguarda l’abilitazione di VSM è possibile fare riferimento all’articolo di Johan Arwidmark

Enabling Virtual Secure Mode (VSM) in Windows 10 Enterprise Build 10130, di seguito i passi principali:

• Abilitare Secure Boot and UEFI nel BIOS e il Trusted Platform Module (TMP), dalle prove eseguite da Johan entrambe le versioni 1.2 e 2.0 (PTT) consentono l’utilizzo del VSM
• Aggiungere in Windows 10 la feature Hyper-V
• Abilitare l’opzione Enable Credential Guard nella policy relativa al Virtual Secure Mode (VSM): Computer Configuration / System / Device Guard / Turn on Virtualization Based Security
• Configurare BCD per avviare VSM tramite il comando: bcdedit /set vsmlaunchtype auto

Per verificare se VSM è attivo è possibile che vengano registrati gli eventi di Sistema relativi alla protezione dei processi come LSA:

Oppure che sia in esecuzione il processo “Secure System”:

Di seguito la prova eseguita da Johan delle esecuzione del tool mimikatz realizzato dal ricercatore francese Benjamin Delpy in grado di elaborare i cosiddetti file dump che riflettono il contenuto della memoria ed estrarre tutte le password conservate dal momento che le credenziali dell’account utente vengono conservate nella memoria del sistema.

Di seguito l’output che si ottiene eseguendo su una macchina non prottetta da VSM il comando
mimikatz.exe privilege::debug sekurlsa::logonpasswords exit
In cui si può notare come il tool riesca a ricavare l’NTLM hash che potrebbe poi essere utilizzato per un  tentare un attacco di tipo Pass the hash.

Di seguito invece l’output che si ottiene eseguendo su una macchina prottetta da VSE il comando
mimikatz.exe privilege::debug sekurlsa::logonpasswords exit

Con Windows 10 è stata introdotta una novità per quanto riguarda la gestione degli aggiornamenti ovvero la funzionalità Ottimizzazione recapito di Windows Update (WUDO Windows Update Delivery Optimization) che permette di scaricare gli  aggiornamenti e le app non solo da Microsoft, ma anche di ricevere gli aggiornamenti e le app da altri PC in cui sono già disponibili.

Di seguito i passaggi per accedere alla configurazione della modalità di recapito degli aggiornamenti:

Quando la funzionalità Ottimizzazione recapito di Windows Update è attivata sono disponibili due opzioni:

PC della tua rete locale: In questo caso quanto Windows scarica un aggiornamento o un’app, cerca altri PC nella rete locale che hanno già scaricato l’aggiornamento o l’app con Ottimizzazione recapito. Windows scarica quindi parte dei file da tali PC e parte da Microsoft. Windows non scarica l’intero file da un’unica posizione. Il download viene invece suddiviso in parti più piccole. Windows usa l’origine di download più veloce e affidabile per ogni parte del file.

PC della rete locale e PC su Internet: In questo caso Windows usa lo stesso processo per ottenere aggiornamenti e app dai PC della rete locale e cerca anche PC su Internet da usare come origine per il download di parti di aggiornamenti e app.

Attivando Ottimizzazione recapito il PC invia parte delle app o degli aggiornamenti scaricati ad altri PC della rete locale o su Internet, a seconda delle impostazioni. Mediante Ottimizzazione recapito vengono scaricati gli stessi aggiornamenti e app disponibili in Windows Update e Windows Store e viene creata una cache locale in cui archiviare i file scaricati per un breve periodo di tempo. A seconda delle impostazioni, Windows invia quindi parte di questi file ad altri PC della rete locale o connessi a Internet che stanno scaricando gli stessi file. In ogni caso per sicurezza Ottimizzazione recapito non può essere usato per scaricare o inviare contenuto personale.

La funzionalità di Ottimizzazione recapito è attivata per impostazione predefinita in tutte le edizioni Windows 10, ma è configurata in modo diverso:

• In Windows 10 Enterprise e Windows 10 Education è impostata l’opzione PC nella rete locale.
• In tutte le altre edizioni di Windows 10 è impostata l’opzione PC nella rete locale e su Internet.

Come in Windows 8.1 anche Windows 10 non scarica automaticamente gli aggiornamenti o le app se rileva che il PC usa una connessione a consumo e analogamente Ottimizzazione recapito non scarica o invia automaticamente parti di aggiornamenti o app ad altri PC su Internet se rileva che usi una connessione a consumo. Per impostare una connessione WiFi a consumo eseguire la seguente configurazione:

• Start > Impostazioni > Rete e Internet > Wi‑Fi > Opzioni avanzate
• Selezionare il pulsante di opzione in Imposta come connessione a consumo

La configurazione della WUDO è gestibile anche tramite Group Policies mediante i template file DeliveryOptimization.admx e DeliveryOptimization.adml, a riguardo di veda la KB3088114 How to use Group Policy to configure Windows Update Delivery Optimization in Windows 10.

Anche in Windows 10 per installare .NET Framework 3.5 è possibile aggiungere la funzionalità come in Windows 8 (a riguardo si veda Installing the .NET Framework 3.5 on Windows 8, Windows 8.1 and Windows 10)

I file di installazione vengono ricercati solo su Windows Update e non in locale, come accade ad esempio in Windows Server 2012 a riguardo si veda Windows 8 and .Net Framework 3.5 e il mio post Windows Server 2012: errore durante l’installazione del .NET Framework 3.5.

Nel caso in cui non sia possibile connettersi ad Internet è possibile installare il .NET Framework 3.5 tramite il comando DISM come riportato nei seguenti:

• .NET Framework 4.5 is default and .NET Framework 3.5 is optional
• Deploy .NET Framework 3.5 by using Deployment Image Servicing and Management (DISM)

Per quanto riguarda i file d’installazione è possibile reperirli sul media d’installazione nella cartella sources\sxs\ 

Di seguito il comando da eseguire in un prompt dei comandi avviato con diritti amministrativi per l’installazione del :NET Framework 3.5 nell’ipotesi di avere nel drive D il media d’installazione (ovviamente è anche possibile copiare i file .cab in locale):

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:D:\sources\sxs

In Windows 8 è stata anche introdotta la policy Computer Configuration\Administrative Templates\System\Specify settings for optional component installation and component repair per la configurazione centralizzata del path per i componenti opzionali tra cui il .NET Framework 3.5.

Per ulteriori informazioni su eventuali errori che possono verificarsi si veda anche la KB2734782: .NET Framework 3.5 installation error: 0x800F0906, 0x800F081F, 0x800F0907.

Lo UniDrv (Universal Printer Driver or Unidriver) è un Microsoft Windows universal driver per stampanti on-PostScript basato su GDI noto anche con la denominazione v3 print driver.

Il principale vantaggio del driver universale è quello di poter essere utilizzato con vari modelli di stampanti anche di produttori diversi senza più la necessità di scaricare i singoli driver specifici per ogni stampante.

Per i dettagli implementativi si veda la sezione MSDN Introduction to the Universal Printer, di seguito le schema di funzionamento dell’Unidrv:

Talvolta può anche accedere che i driver specifici della stampante potrebbero non funzionare come nel caso che ho avuto modo di analizzare relativo ad una stampante HP LaserJet Pro M402dn i cui driver relativi a Windows 2008 R2 non inviavano la stampa alla stampante.

Il problema relativo alla stampante HP LaserJet Pro M402dn era dovuto sicuramente alla versione del driver per WS2008R2 in quanto utilizzando i driver Generico Solo Testo la stampa avveniva con successo e da un computer con Windows 8.1 64 bit installando il driver per W8.1 a 64 bit non si verificavano problemi. Utilizzando il tool HP Print and Scan Doctor scaricabile dal link http://www.hp.com/go/tools la stampante risultava non installata sul sistema a conferma che il problema risultava il driver.

Utilizzando l’HP Universal Print Driver per PCL6 invece la stampante HP LaserJet Pro M402dn funzionava senza problemi anche su Windows Server 2008 R2.

L’evoluzione dell’Unidrv è il V4 Printer Driver che va appunto a risolvere le problematiche che erano presenti nel modello del V3 print driver o Unidrv. Il v4 print driver model continua a supportare molte tecnologie ormai comni come XPSDrv, GPD, PPD, Autoconfiguration e Bidi, ma è ottimizzato per scenari Windows 8, Printer sharing e semplicità di sviluppo driver.

Di seguito lo schema di funzionamento del V4 Printer Driver in cui sono stati evidenziati in verde le nuove funzionalità e in blu le funzionalità già presenti nel V3 Printer Driver

Per quanto riguarda l’HP Universal Print Driver si faccia riferimento alle Specifiche Tecniche per gli scenari supportati, inoltre si veda anche la Documentazione e le White Papers. In particolare nella White Papers USING THE HP UNIVERSAL PRINT DRIVER WITH WINDOWS 8 AND WINDOWS SERVER 2012 viene chiarito che in W8 e successivi l’Universal Driver installato sarà appunto un V4 Printer Driver con una serie di vantaggi:

“V4 drivers have a greatly simplified configuration layer. Unlike V3 print drivers where the user
interface is strongly coupled to the configuration, V4 print drivers focus on providing PrintTicket,
PrintCapabilities, and constraint functionality.
A common configuration module, PrintConfig.dll, encapsulates the functionality that was previously
available in the UnidrvUI and Pscript5UI core drivers. V4 drivers do not currently employ
configuration plug-ins.
Most of the device configuration is expressed in Generic Printer Description (GPD) and PostScript
Printer Description (PPD) files. They may provide a JavaScript file that supports advanced
constraint handling as well as PrintTicket and PrintCapabilities support.
Generic Printer Description (GPD) and PostScript Printer Description (PPD) file formats have not
changed and existing GPD and PPD files are compatible. The main difference is that all V4 print
drivers must additionally specify required directives in their GPD or PPD files. These directives
prevent the expression of features that are not natively supported by XPSDrv.
Inbox (in the operating system) V4 drivers are available, developed and supported by Microsoft”

“When using Windows 8, V4 drivers install directly from the driver store on the local machine. This
increases the speed of driver installation and eliminates the danger of driver filename conflicts
where one V3 print driver can overwrite files in another V3 print driver.
IT Administrators no longer need to install cross platform drivers on their print servers. Windows will
either locate the correct driver from WU or WSUS, or it will use a fallback mechanism to enable
cross-platform printing.”

Per ulteriori informazioni si veda anche la White Paper HP UPD – Microsoft Driver Isolation Mode FAQs.

Se inavvertitamente vengono spostate delle mail della root della cassetta postale non sarà più possibile vederle nè nella Folder List e nè nel pane Outlook Today. Per tentare il recupero è possibile utilizzare uno dei due metodi suggeriti nella KB 2979451 Items placed in root folder seem to be lost in Outlook (il metodo 2 non è applicabile a Outlook 2013). Per ulteriori informazioni si veda anche il post Finding lost mail in your top level Outlook/Exchange root.

Esiste comunque un terzo metodo ter tentare il recupero ovvero aprire la mailbox tramite OWA (https://HostnameMailServer.domain.ext/owa/MailboxName@domain.ext) spostarsi sulla root della mail box e le mail dovrebbero essere visibili, quindi spostarle nella cartella corretta.

Inoltre quando si esegue lo spostamento nella root le mail verranno anche elencate tra gli elementi eliminati recuperabili.

Nel mio caso le prove sono state effettuate su un Exchange 2010 utilizzando un Outlook 2013.

Per la creazione di un VHD di Nano Server è possibile utilizzare due approcci come illustrato in Getting Started with Nano Server:

1. Utilizzare la funzione New-NanoServerImage contenuta in New-NanoServerImage.ps1 che a sua volta fa uso di Convert-WindowsImage.ps1. Questo approccio permette l’impostazione del nome computer e l’aggiunta di driver, ruoli e fnzionalità
2. Utilizzare la funzione Convert-WindowsImage contenuta in Convert-WindowsImage.ps1 Questo approccio prevede che la configurazione venga poi eseguita in una fase successiva alla creazione del VHD tramite DISM.

Di seguito elenco i passi da seguire per la creazione del VHD di Nano Server utilizzando il secondo metodo che può non essere così immediato da utilizzare:

Passo 1. Procurarsi la iso di Windows Server 2016 TP3 e avviare i comandi da un sistema con installato Windows 8 / Windows Server 2012 o successivo (io ho eseguito le prove sia su un computer con Windows 8.1 Professional 64 Bit installato in Italiano che su una macchina virtuale con Windows 10 Professional 64 Bit installata in Italiano)

Passo 2. Estrarre la cartella NanoServer dalla iso di Windows Server 2016 TP3, di seguito si ipotizzerà che tale cartella è stata copiata in C:\NanoServer

Passo 3. Aprire la console di PowerShell con privilegi amministrativi

Passo 4. Impostare a Unrestricted l’execution policy col comando:

Set-ExecutionPolicy Unrestricted

Passo 5. Impostare la directory corrente col comando:

Set-Location C:\NanoServer

Passo 6. Importare il modulo Convert-WindowsImage.ps1 tramite il comando:

Import-Module .\convert-windowsimage.ps1

Passo 7. Creare un VHD con Nano Server per una VM Gen 1 con formato VHD, tipo dinamico, dimensioni 40 GB (default) e partizionato con MBR tramite il comando:

Convert-WindowsImage -Sourcepath .\NanoServer.wim –VHDPath .\NanoServer.vhd –VHDformat VHD –VHDPartitionStyle MBR -Edition CORESYSTEMSERVER_INSTALL

In Windows 10, come già in Windows 8.1, è possibile gestire la ricerca web (abilitata per default) tramite la funzionalità Cerca tramite group policies.

Per la disabilitazione della ricerca web è possibile abilitare le seguenti GPO:

Computer Configuration \ Administrative Templates \ Windows Components \ Search \ Do not allow web search

Computer Configuration \ Administrative Templates \ Windows Components \ Search \ Don’t search the web or display web results in Search

Una volta applicate le GPO la ricerca restituirà solo più risultati locali e anche la grafica nella taskverrà modificata.

Per la disabilitazione di Cortana è possibile utilizzare la GPO:

Configuration \ Administrative Templates \ Windows Components \ Search \ Allow Cortana

“This policy setting specifies whether Cortana is allowed on the device. If you enable or don’t configure this setting Cortana will be allowed on the device. If you disable this setting Cortana will be turned off. When Cortana is off users will still be able to use search to find things on the device and on the Internet.”

Per edizioni Home di Windows 10 che non hanno il Group Policy Editor (gpedit.msc) è possibilie utilizzare la chiave di registroDWORD HKLM\SOFTWARE\Policies\Microsoft\Windows\Windows Search\AllowCortana impostandola al valore 0 per Disabilitare Cortana o 1 per abilitarla.

Al momento sui device membri di Azure AD l’utilizzo di Cortanaal momento non è disponibile che indicato nella KB3086254 – How to troubleshoot issues when you use Cortana with Office 365:

Issue: “Cortana is disabled by company policy” message when you try to enable Cortana from a device that’s joined to Azure Active Directory (Azure AD)

Currently, you can’t enable Cortana from a device that’s joined to Azure AD. This feature will be available in a future release.

Nel post Abilitare il KMS su WS2088R2 per gestire WS2012R2 e Office 2013 avevo descritto la procedura per gestire l’attivazione di Windows Server 2012 R2 e Office 2013 tramite il servizio KMS installato su un Windows Server 2008 R2.

Per quanto riguarda la gestione di Windows 10 la procedura è simile infatti come per Windows Server 2012 R2 e Office 2013 occorre prima installare un aggiornamento affinché il servizio KMS accetti le product key di Windows 10 come descritto nel post Activating Windows 10 on Windows Server 2008 R2, Windows Server 2012 and 2012 R2 KMS hosts.

In particolare per W7 e WS208R2 occorre installare la KB3079821 Update that enables Windows 7 and Windows Server 2008 R2 KMS hosts to activate Windows 10.

Per sistemi WS2012 R2 occorre installare la KB3086418 Error 0xC004F015 while activating Windows 10 Enterprise using Windows Server 2012 R2 KMS Host, mentre per sistemi W8/8.1 occorre installare la KB3058168 Update that enables Windows 8.1 and Windows 8 KMS hosts to activate a later version of Windows.

In ogni caso si tenga presente che l’attivazione non è supportata su  KMS installati sui seguenti sistemi:

• Windows Server 2008
• Windows Vista
• Windows Server 2003

Installato l’hotfix per KMS è possibile aggiungere la key per Windows 10 eseguendo i seguenti comandi in un prompt dei comandi con privilegi amministrativi:

• Rimuovere la chiave di licenza esistente tramite il comando:
  slmgr.vbs /upk
• Rimuovere la chiave di licenza esistente dal registry tramite il comando:
  slmgr /cpky
• Installare la chiave di licenza tramite il comando:
  slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
• Attivare la chiave di licenza tramite il comando:
  slmgr.vbs /ato
• Visualizzare la situazione delle chiavi di licenza tramite il comando:
  cscript %windir%\system32\slmgr.vbs /dlv

In caso di problemi è possibile provare a riavviare il servizio Protezione Software che si occupa di erogare le chiavi KMS tramite il comando (a riguardo si veda Deploying KMS Activation):
net stop sppsvc && net start sppsvc

Nel caso durante l’installazione venga visualizzato un errore 0xC004F015 è probabile che la key di Windows 10 non è compatibile con la versione di OS su cui è installato il KMS

Il problema può essere legato al fatto che occorre installare la corretta chiave di licenza come descritto nel post Windows 10 Volume Activation Tips, in particolare se il servizio KMS è in esecuzione su un OS Server come nel caso di Windows 2008 R2 occore utilizzare la key denominata Windows Srv 2012 R2 DataCtr/Std KMS for Windows 10 che sarà in grado di attivare sia OS client che server:

Obtain Your Windows Server 2012 R2 for Windows 10 CSVLK

Today there are 2 Customer Support Volume License Keys (CSVLK) for Windows 10 available.

• Windows 10 CSVLK: Can only be installed on a Windows 7 (with update 3079821 installed), Windows 8 (with update 3079821 installed), Windows 8.1 (with update 3079821 installed), or Windows 10 KMS host and only activates client operating systems.
• Windows Server 2012 R2 for Windows 10 CSVLK: Can only be installed on a Windows Server 2008 R2 KMS host (with update 3079821 installed), Windows 2012 or 2012 R2 (with update 3079821 installed) and activates both client and server operating systems

Generally most KMS hosts are setup on Server operating systems so you need to get the Windows Server 2012 R2 for Windows 10 CSVLK. To find it do the following:

1. Log on to the Volume Licensing Service Center (VLSC).
2. Click License.
3. Click Relationship Summary.
4. Click License ID of their current Active License.
5. After the page loads, click Product Keys.
6. In the list of keys, locate “Windows Srv 2012 R2 DataCtr/Std KMS for Windows 10.”

Per ulteriori informazioni su eventuali errori che possono verificarsi lato client e in particolare l’errore C004F074 si veda il post Getting error 0xC004F074 when activating against KMS server.

Per il corretto funzionamento del KMS occorre che il firewall del sistema su cui è installato il servizio consenta il traffico sulla porta TCP 1688, a riguardo si veda How to troubleshoot the Key Management Service (KMS).

Per quanto riguarda la gestione di Office 2016 tramite KMS occorre tenere presente delle indicazioni fornite dalla KB3104410 KMS error 0xC004F074 when you try to activate Office 2016 volume-licensed client in particolare se il servizio KMS è in esecuzione su Windows 7 o Windows Server 2008 R2 ed è già configurato per gestire l’attivazione d Office 2013:

After you set up a KMS host for Microsoft Office 2016, and then you try to activate the Office 2016 volume-licensed client, you receive the following error message:

The Software Licensing Service determined that the specified Key Management Service (KMS) cannot be used.

Error Code 0xC004F074

The issue occurs when you cohost the Office 2013 KMS host and the Office 2016 KMS host on the same system, and that system is running either Windows 7 or Windows Server 2008 R2.

While Microsoft works toward a permanent solution to this issue, use one of the following workarounds:

• Use Windows 8.1, Windows 10, or Windows Server 2012 R2 to host both the Office 2013 and Office 2016 KMS hosts.
• Install the Office 2016 KMS host on a system by itself, without any other Office KMS hosts on the same system.

Quindi in scenari dove il servizio KMS è in esecuzione su Windows 7 o Windows Server 2008 R2 ed è necessario gestire l’attivazione anche di Office 2013 occorre o dedicare un host kms alla sola attivazione di Office2016 o spostare il servizio KMS su un sistema con Windows 8.1, Windows 10 o Windows Server 2012 R2. Inoltre sui sistemi su Windows 7 o Windows Server 2008 R2 è necessario installare la KB2757817 Update adds support for Windows 8 and Windows Server 2012 to Windows Server 2008, Windows 7, and Windows Server 2008 R2 KMS hosts.

Per l’aggiunta della key di office 2016 nel KMS occorre utilizzare il Microsoft Office 2016 Volume License Pack. Occorre utilizzare il Volume License Pack anche se l’attivazione viene gestita tramite Active Directory che richiede Servizi di dominio Active Directory con schema di Windows Server 2012.

Per il corretto funzionamento del KMS occorre che il firewall del sistema su cui è installato il servizio consenta il traffico sulla porta TCP 1688, a riguardo si veda How to troubleshoot the Key Management Service (KMS).

In questi giorni ho aggiornato un PC con la Motherboard Asus P5Q PRO e dal momento che come alcuni altri ho incontrato qualche difficoltà  (si veda ad esempio la discussione

Can’t install Windows 10 TP on Asus P5Q motherbord with ICH10R) posto la mia soluzione a futura memoria e nel caso torni utile ad altri.

Dal momento che l’istallazione tramite DVD non andava a buon fine interrompendosi con messaggi di errore relativi a file non corretti e BOSD ho iniziato a sospettare che il problema fosse legato allo storage.

Quindi per prima cosa ho disconnesso l’hard disk secondario il lettore DVD tentando un’installazione da chiavetta USB (con l’ASUS P5Q PRO è necessario impostare da BIOS la chiavetta come primo disco e impostare quindi la priorità di boot per far sì che l’avvio avvenga da disco), ma anche in questo caso l’installazione si è interrotta.

Per riuscire a completare l’installazione ho dovuto impostare da BIOS lo storage nella modalità IDE – Compatible, terminata l’installazione ho ripristinato l’hard disk come primo disco per avviare il computer tramite il disco di sistema anziché tramite la chiavetta USB.

La modalità IDE è però meno performante rispetto a quella AHCI, infatti la modalità Advanced Host Controller Interface (AHCI) consente di utilizzare le funzioni avanzate delle unità SATA, come ad esempio l’hot-swapping e la Native Command Queuing (NCQ), inoltre consente all’hard disk di funzionare a velocità maggiori rispetto alla modalità IDE (a riguardo si veda PC desktop HP e Compaq – Informazioni sulle modalità controller e unità disco rigido SATA).

In Windows 10 è possibile modificare semplicemente l’impostazione da IDE a AHCI anche dopo l’installazione nel seguente modo:

1. Eseguire il seguente comando da un prompt dei comandi con privilegi amministrativi per avviare il sistema in modalità provvisoria:
   bcdedit /set {current} safeboot minimal
2. Riavviare il computer e  modificare da BIOS l’impostazione dello storage in AHCI.
3. Avviare il sistema in modalità provvisoria quindi eseguire il seguente comando da un prompt dei comandi con privilegi amministrativi per disabilitare l’avvio del sistema in modalità provvisoria:
   bcdedit /deletevalue {current} safeboot
4. Riavviare il sistema

Per altri metodi che è possibile utilizzare per modificare la modalità dello storage da IDE a AHCI dopo l’installazione si veda anche How to Enable AHCI in Windows 8 and Windows 10 after Installation.

Per maggiori informazioni su questa problematica si veda anche la sezione Boot issues nella pagina wikipedia dedicata all’Advanced Host Controller Interface.

Per eseguire dei test sulle performace della modalità IDE rispetto alla modalità AHCI è possibvile utilizzare il tool http://www.hdtune.com/ di cui ne esiste una versione free.

Nel corso degli anni DELL ha rilasciato vari strumenti per l’installazione, l’aggiornamento e la gestione dei propri server.
In questo post cercherò di elencare i principali strumenti a disposizione per capire quali può aver senso utilizzare nel contesto della propria infrastruttura.

Dell Server Update Utility (SUU)

Il Dell Server Update Utility ora denominato OpenManage Server Update Utility – SUU è un’immagine iso scaricabile che permette l’aggiornamento del BIOS e dei Firmware  del sistema. L’ultima versione del SUU è scaricabile al seguente Server Update Utility (al momento è disponibile la versione 15.1.2.00)

Dell Repository Manager

Il Dell Repository Manager ora denominato Dell OpenManage Repository Manager consente di creare immagini iso per gruppi di sistemi o specifici sistemi contenenti BIOS, Firmware, Driver e Software. L’ultima versione è scaricabile al seguente Dell Repository Manager (al momento è disponibile la versione 2.1)

Dell Systems Management Tools and Documentation

Il Dell Systems Management Tools and Documentation è un’immagine iso scaricabile che contiene vari tool per gestione del sistema al momento è disponibile la versione 8.2 che contiene i seguenti: Dell Systems Build and Update Utility,  OpenManage Server Administrator agent, Systems Service, Diagnostics Tools e Systems Documentation.

Per l’installazione di un singolo server è possibile utilizzare il seguente procedimento per aggiornare il sistema:

1. Installare il sistema operativo tramite l’iDRAC e il Lifecycle Controller, a riguardo si veda Lifecycle Controller Operating System Deployment in Dell PowerEdge Servers

2. Utilizzare Dell Repository Manager per creare un’iso contenente BIOS, Firmware e Driver per aggiornare il sistema

2. Utilizzare il Dell Server Update Utility (SUU) per installare eventuali ulteriori aggiornamenti BIOS e Firmware (mi è successo infatti che l’iso generata dal Dell Repository Manager non contenesse l’ultima versione del BIOS)

3. Utilizzare il Dell Systems Management Tools and Documentation per installare l’iDRAC Service Module che consente all’iDRAC di ottenere informazioni sul sistema operativo.

Per ulterirori informazioni su questi strumenti e tool e su altri si veda OpenManage Downloads page on Dell TechCenter.

L’UEFI (Unified Extensible Firmware Interface) è un’interfaccia firmware standard per PC creata da oltre 140 aziende aderenti al consorzio UEFI, tra cui Microsoft, per migliorare l’interoperabilità del software e risolvere le limitazioni del BIOS (Basic Input/Output System).

Di seguito i principali vantaggi del firmware UEFI:

• Miglioramento della sicurezza grazie alla protezione del processo pre-startup o pre-boot da attacchi di tipo bootkit.
• Maggiore velocità dei tempi di avvio e di ripresa dallo stato di ibernazione.
• Supporto agli hard disk di dimensioni maggiori di 2,2 terabyte (TB).
• Supporto di driver di dispositivi firmware a 64 bit che il sistema può utilizzare per indirizzare più di 17,2 miliardi di gigabyte (GB) di memoria durante l’avvio.
• Possibilità di utilizzare il BIOS con hardware UEFI.
• Supporto per il multicast deployment

Per maggiori informazioni si vedano:

• What is UEFI?
• UEFI Firmware
• Intel EFI and UEFI Overview and Specifications.

E’ possibile controllare se Windows è installato su un computer che utilizza UEFI oppure BIOS tramite il tool MSINFO32 ( a riguardo si veda How to check in Windows if you are using UEFI):

In alternativa è possibile utilizzare il cmdlet Confirm-SecureBootUEFI disponibile in WS2012/W8 e successivi per controllare se il computer utilizza UEFI e supporta il Secure Boot (a riguardo si veda il mio precedente post Secure Boot):

• If the computer supports Secure Boot and Secure Boot is enabled, then this cmdlet returns True.
• If the computer supports Secure Boot and Secure Boot is disabled, then this cmdlet returns False.
• If the computer does not support Secure Boot or is a BIOS (non-UEFI) computer, then this cmdlet returns an error displaying the following: Cmdlet not supported on this platform.

If Windows PowerShell® is not run in administrator mode, then this cmdlet returns an error displaying the following: Unable to set proper privileges. Access was denied.

This cmdlet requires that Windows PowerShell be run in administrator mode.

Per ulteriori approcci per controllare se se il computer utilizza UEFI si veda lo script PowerShell pubblicato al seguente Determine UEFI or Legacy BIOS from PowerShell (Three methods).

Quando Windows viene installato in computer che utilizzano UEFI anche la struttura delle partizioni di sistema di default cambiano come indicato nel seguente Configure UEFI/GPT-Based Hard Drive Partitions, di seguito la struttura di default:

Dove la partizione Windows RE tools è quella dedicata ai Windows Recovery Environment (Windows RE) Tools.

La configurazione raccomandata include anche una partizione per il recovery dell’immagine di sistema che conterà la Windows recovery image (install.wim) ed è raccomandabile che sia di almeno 3 GB:

Si noti che come indicato Configure UEFI/GPT-Based Hard Drive Partitions è importante che la partizione Recovery image sia posizionata al fondo del disco:

“Add the Windows RE Tools partition and system partition before you add the Windows partition. Add the partition that contains the recovery image at the end. This partition order helps keep the system and the Windows RE Tools partition safe during actions such as removing the recovery image partition or changing the size of the Windows partition.”

Per maggiori informazioni si vedano anche:

• Deployment Options for UEFI based Computers
• Installing Windows 7 on UEFI based computer
• KB2938884 Windows Deployment Services (WDS) support for UEFI

Talvolta può capitare di avere la necessità di creare una copia di una cartella con le relative impostazioni di sicurezza a causa di una risistemazione di un file server per esempio.

Per eseguire tale attività è possibile utilizzare vari approcci uno dei quali è utilizzare Robocopy (Robust File Copy) il tool a riga di comando presente già in Windows NT 4.0 all’interno del Windows Resource Kit e inserito poi come comando nativo in Windows Vista/Windows Server 2008 e successivi.

Per eseguire ad esempio la copia della cartella PrivateDocs in un percorso diver locale o remoto è possibile utilizzare il seguente comando:

robocopy “SourcePath\PrivateDoc” “DestinationPath\PrivateDoc” /MIR /SEC /SECFIX /R:1 /W:1 /V /TEE /LOG:Copy-PrivateDocs.log

Dove i parametri hanno il seguente significato:

/MIR

Mirrors a directory tree (equivalent to /e plus /purge)

The /mir option is equivalent to the /e plus /purge options with one small difference in behavior:

• With the /e plus /purge options, if the destination directory exists, the destination directory security settings are not overwritten.
• With the /mir option, if the destination directory exists, the destination directory security settings are overwritten.

/SEC

Copies files with security (equivalent to /copy:DAT)

/SECFIX

Fixes file security on all files, even skipped ones

/R

Specifies the number of retries on failed copies. The default value of N is 1,000,000 (one million retries)

/W

Specifies the wait time between retries, in seconds. The default value of N is 30 (wait time 30 seconds)

/V

Produces verbose output, and shows all skipped files

/TEE

Writes the status output to the console window, as well as to the log file

/LOG

Writes the status output to the log file (appends the output to the existing log file).

Il comando può essere anche eseguito più volte consentendo così di eseguire test o di gestire modifiche alla struttura di un file server con downtime minimi in quanto è possibile eseguire la copia dei file non modificati a ridosso dello spostamento preventivamente.

Per quanto riguarda la gestione dei permessi NTFS con RoboCopy si veda il seguente post

Robocopy /MIR switch – mirroring file permissions

> ROBOCOPY <source> <target> /MIR /SEC /SECFIX

/MIR will replicate data and security (as /SEC is specified) for changed files, and /SECFIX will update just the security for unchanged files. Add /V to the command line if you want to see which files are having their security “fixed” without having their data copied.

Robocopy è ottimo tool per la copia di directory in percorsi diversi estremamente duttile con buone performance e quindi utile in vari scenari, a riguardo si vedano ad esempio:

• Use Robocopy to Preseed Files for DFS Replication
• 20 Helpful Steps Migrating Windows Server 2003 to 2012 R2

Se però si ha la necessità di implementare una replica per sincronizzare dei file risulta decisamente più performante la funzionalità Storage Replica che sarà introdotta in Windows Server 2016, a riguardo si vedano le comparazioni riportare nel post Storage Replica versus Robocopy: Fight!.

Se invece la necessità è quella di migrare un file server è possibile ricorrere ai Windows Server Migration Tools a riguardo si vedano i seguenti:

• Migrate File and Storage Services to Windows Server 2012 R2
• Step-By-Step: Migrating a Windows Server 2003 file server, NTFS and Share Rights to Windows Server 2012 R2
• Migrate File Server Using The File Server Migration Toolkit Within Server 2012 R2
• KB2873617 You cannot use the Smigdeploy.exe tool in Windows Storage Server 2012 or Windows Storage Server 2008 R2

Volendo per la migrazione di un file server WS2003/WS2008 è anche possibile utilizzare il

Microsoft File Server Migration Toolkit 1.2, a riguardo si veda Step-By-Step: Migrating a 2003 file server with Microsoft File Server Migration Toolkit.

Talvolta capita di dover eliminare il driver di una stampante per reinstallarla a causa di problemi. Ultimamente mi sono successi alcuni issue con stampati di rete Toshiba che utilizzano il driver Toshiba Universal Printer 2 sia su Windows 7 64 bit che su Windows 8 64 bit.

Per rimuovere il driver della stampante eseguire le seguenti operazioni:

• Eliminare la stampante
• Eliminare il driver tramite la voce di menu Proprietà server di stampa dell’applet Dispositivi e stampanti o tramite l’apposita dialogo avviabile tramite il comando printui /s /t2 da eseguire in un prompt dei comandi con privilegi amministrativi.

Talvolta tentando la rimozione del driver della stampante l’operazione fallisce riportando un errore relativo ad un file in uso (di solito un file .inf)

E’ possibile rimuovere forzatamente il driver tramite la seguente procedura:

Passo 1: Arrestare il servizio di spooler

E’ possibile utilizzare l’applet services.msc o tramite il comando net stop spooler eseguito in un prompt dei comandi con privilegi amministrativi.

Passo 2: Rinominare le chiavi di registro dei Print Processor

Avviare Regedit con privilegi amministrativi e posizionarsi sulla chiave di registro:
HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Print Processors\

Rinominare tutte le chiavi relative ai Print Processor (ad esempio winprint in  winprint.ren, Hpcpp107 in Hpcpp107.ren etc…)

Passo 3: Avviare il servizio di spooler

E’ possibile utilizzare l’applet services.msc o tramite il comando net start spooler eseguito in un prompt dei comandi con privilegi amministrativi.

Passo 4: Rimuovere il driver

E’ possibile utilizzare la voce di menu Proprietà server di stampa dell’applet Dispositivi e stampanti o o tramite l’apposita dialogo avviabile tramite il comando printui /s /t2 da eseguire in un prompt dei comandi con privilegi amministrativi.

Passo 5: Ripristinare il nome delle chiavi di registro dei Print Processor

Avviare Regedit con privilegi amministrativi e posizionarsi sulla chiave di registro:
HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Print Processors\

Ripristinare il nome originale delle chiavi relative ai Print Processor (ad esempio winprint.ren in winprint, Hpcpp107.ren in Hpcpp107 etc…)

Passo 6: Riavviare il servizio di spooler

E’ possibile utilizzare l’applet services.msc o tramite il comando net stop spooler & net start spooler eseguito in un prompt dei comandi con privilegi amministrativi.

Dopo la rimozione del driver della stampante è possibile provare a reinstallare la stampante per verificare se gli issue sono scomparsi. Si tenga presente che molto spesso eventuali issue che si presentato dopo aggiornamenti Windows si risolvono con l’installazione di driver aggiornati.

Per alcune info su quali possono essere le cause che generano issue con le stampanti si vedano i seguenti:

• KB 2864755 Printing fails when you use a shared printer in Windows 7
• KB 2896881 Long logon time when you use the AddPrinterConnection VBScript command to map printers for users during logon process in Windows

Capita a volte di dover installare server fisici o virtuali che a causa dei servi che devono erogare necessitano di più connessioni di rete verso reti diverse e quindi la cosa più lineare in questi casi è quella di avere interfacce di rete separate.

Un classico esempio può essere un server di video sorveglianza che deve comunicare con la rete delle telecamere e con la rete interna.

In questi scenari dal momento che le schede di rete hanno tutte la stessa velocità conviene impostare sulla scheda di rete che dovrà essere usata per prima per gestire il traffico di routing una metrica manuale più bassa delle altre schede come indicato nella KB299540 An explanation of the Automatic Metric feature for Internet Protocol routes:

“The Automatic Metric feature is configured independently for each network interface in the network. This feature is useful in situations where you have more than one network interface of the same speed, for example, when each network interface has been assigned a default gateway. In this situation, you may want to manually configure the metric on one network interface, and enable the Automatic Metric feature to configure the metric of the other network interface. This setup can enable you to control the network interface that is used first in the routing of IP traffic.”

Per vedere quale è la metrica assegnata ad ogni scheda di rete è possibile utilizzare il segunete comando PowerShell:

 Get-NetIPInterface | Format-Table

Inoltre sulle schede di rete su cui non è specificatamente necessario è consigliabile disabilitare il traffico NetBIOS tramite il Tab WINS delle proprietà del protocollo TCP/IPv4:

Come indicato in Windows Internet Name Service (WINS) Overview se non è necessario implementare WINS o se non vi sono applicazioni che fanno uso di NetBIOS sulla connessione di rete attestata sulla scheda di rete è possibile disabilitarlo.

Altra configurazione necessaria quando si hanno più schede di rete è quella di impostare correttamente l’ordine delle schede e di Binding come riportato in Modify the protocol bindings and network provider order impostando per prima la scheda di rete più utilizzata e il protocollo più utilizzato.

“Network performance can be seriously degraded if you rearrange the bindings or provider order in an inappropriate way for your network. Set the connections and the protocols that you use to reach your resources listed first, with less frequently used connections and protocols listed second. For example, if you are on a LAN using primarily IPv4, then it is recommended that the LAN adapter be the first connection listed, and that IPv4 be the first protocol listed for that connection.”

“This can provide improved performance when you have multiple protocols installed and your network primarily uses one. If you set a protocol at the top of the list, it will be tried first. If another protocol is tried first for every packet, many will fail, and the other protocols will not be tried until that failure occurs.”

A riguardo si veda anche la KB 2526067 How to change the network connection priority in Windows 7 e il post Adjusting the Network Protocol Bindings in Windows 10 in cui sono contenute alcune indicazioni circa il fatto che in Windows 10 la modifica dell’ordine di binding diventa meno importante:

“There are no longer any components that utilize the binding order. The only known component that used the binding order was DNS ordering. By default, Windows uses the Route Metric + Interface Metric to determine which route has the highest priority by choosing the route with the lowest value.”

Per vedere l’elenco delle interfacce di rete e il loro ordine di priorità è possibile utilizzare il comando (minore è il valore della metrica e maggiore è la priorità della scheda di rete):

netstat –rn

Per modificare se necessario la metrica dell’interfaccia è possibile utilizzare il seguente comando PowerShell Set-NetIPInterface:

Set-NetIPInterface –InterfaceIndex “xx”–InterfaceMetric “yyy”

Nel caso in cui si abbiamo poi più schede di rete connesse alla stessa rete allo stesso switch è possibile avere dei comportamenti inaspettati come indicato nella KB175767 How multiple adapters on the same network are expected to behave, va però precisato questo tipo do configurazione non è consigliabile:

Consider the following scenario:

• You have a working computer that has Windows installed. 
• Two network adapters are connected to the same physical network or hub.
• TCP/IP is installed as the network protocol.
• The adapter addresses on the same subnet are 192.168.0.1 and 192.168.0.2.
• A client on the network uses the address 192.168.0.119.

In this scenario, you may expect the two adapters on the same physical network and protocol subnet to perform load balancing. However, by definition, only one adapter may communicate on the network at a time in the Ethernet network topology. Therefore, both adapters cannot be transmitting at the same time and must wait if another device on the network is transmitting. Additionally, broadcast messages must be handled by each adapter because both are listening on the same network. This configuration requires significant overhead, excluding any protocol-related issues. This configuration does not offer a good method for providing a redundant network adapter for the same network.

Windows Server 2012 includes a new feature call SMB Multichannel. SMB Multichannel is part of the SMB 3.0 protocol and lets servers use multiple network connections at the same time.

Windows Server 2012 servers cannot use multiple network connections at the same time if the network is configured by using CSMA/CD.

Another thing to consider is that some network applications bind to specific adapters in the system. If a network application were to bind to the second adapter specifically, application-related traffic that was received from clients on the first adapter might be ignored by the application. This might be caused by NetBIOS name registration on the network. Additionally, if the adapter to which the application is bound fails, the application may fail if it does not use the other adapter.

Usually, unless applications specifically demand it, this kind of configuration is not helpful. Some manufacturers make fault-tolerant network adapters to guard against a single point of failure. These adapters enable two adapters to be included on the same server but enable only one adapter to be used at a time. If the primary adapter fails, the driver deactivates the first card and enables the second by using the same address configuration. The result is a fairly seamless transition to the alternative adapter. This is the preferred method to guard against a single network adapter as a single point of failure.

Per ulteriori informazioni si veda anche il mio post Doppio gateway e impostazione di una scheda di rete come primaria.

WSUS supporta già nativamente la gestione della sincronizzazione e della distribuzione degli aggiornamenti di Windows 10, ma  non il deploy delle feature upgrades (circa le opzioni di aggiornamento di Windows 10 di veda il mio post Windows 10 Enterprise LTSB).

Per WSUS 4.0, la versione di WSUS in Windows Server 2012 e Windows Server 2012 R2 è stata rilasciata la KB3095113 Update to enable WSUS support for Windows 10 feature upgrades che risolve anche l’issue che mostra in WSUS i computer con Windows 10 come Windows Vista, ma vanno tenti presenti le seguenti avvertenze prima di procedere all’installazione dell’hotfix:

“This hotfix enables Windows Server Update Services (WSUS) on a Windows Server 2012-based or a Windows Server 2012 R2-based server to sync and distribute feature upgrades for Windows 10. This hotfix is not required to enable WSUS to sync and distribute servicing updates for Windows 10.

Important This update must be installed before you sync the upgrades classification. If the update is not installed when the upgrades classification is enabled, WSUS will see the Windows 10 build 1511 feature upgrade even if it can’t properly download and deploy the associated packages. If you try to sync any upgrades without having first installed KB 3095113, you will populate the SUSDB with unusable data that must be cleared before upgrades can be properly distributed.  This situation is recoverable but the process is nontrivial and can be avoided altogether if you make sure to install the update before enabling sync of upgrades.  If you have encountered this issue, refer to the following article: How to delete upgrades in WSUS.

For more information about Windows 10 servicing and how feature upgrades and servicing updates differ, see the following TechNet topic:
Introduction to Windows 10 servicing.

This hotfix also fixes an issue in which Windows 10-based computers are displayed as “Windows Vista” on Windows Server 2012 R2 or Windows Server 2012.

Important If you install a language pack after you install this hotfix, you must reinstall this hotfix. Therefore, we recommend that you install any language packs that you need before you install this hotfix.

Prerequisites: To apply this hotfix in Windows Server 2012 R2, you must have April 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 (2919355).

Va però precisato che dal momento che anche senza questa hotfix WSUS può gestire gli aggiornamenti di sicurezza dei computer con Windows 10 se non vi è la specifica esigenza di distribuire delle  feature upgrades è possibile attendere il rilascio dell’update, a riguardo si veda il post Important update for WSUS 4.0 (KB 3095113) del team di WSUS in cui si prevede il rilascio dell’update per il primo trimestre del 2016.

“Some folks are cautious about updates like KB 3095113 being released with boilerplate text that include verbiage such as “do not install unless you are experiencing this issue.”  Hotfix is our most expedient release vehicle, and we wanted to provide as much time to deploy this ahead of the Windows 10 1511 feature upgrade release to WSUS as possible.  We have tested it the same as we would any Windows Update release, so there is no reason to wait to install the update on your WSUS 4.0 servers.  For your convenience, we’ll be releasing the update more broadly to DLC and Catalog, as well as to WSUS itself, in the first quarter of 2016.  If you prefer to wait for those releases, then please review the caution described next.”

“WSUS may be able to see the Windows 10 1511 feature upgrade even if it can’t properly download and deploy the associated packages.  The feature upgrades will become visible as soon as the “Upgrades” classification is checked in the WSUS options for Products and Classifications.  If you attempt to sync any Upgrades without having first installed the recent patch, then you will populate the SUSDB with unusable data that must be cleared before Upgrades can be properly distributed.  This situation is recoverable, but the process is nontrivial and can be avoided altogether if you make sure to install the update before enabling sync of Upgrades.  If you have encountered this issue, then please stay tuned for an upcoming KB article that details the recovery steps.”

“If you are content to wipe and load images for Windows 10 in order to stay on a current build, then simply do not enable sync of Upgrades in your WSUS, and do what you usually do to upgrade your Windows builds.  However, if you ever intend to deploy Windows 10 and fully enable Windows as a service for your enterprise, then you’ll want to deploy the recent patch.  Furthermore, the safest route is to enable sync of Upgrades in your WSUS only after you have installed this patch on all WSUS 4.0 servers that service Windows 10 machines in your environment.”

Per altri dettagli si veda il post Important update for WSUS 4.0 (KB 3095113).