Monday, May 14, 2012
A partire da Microsoft Hyper-V Server 2008 R2 per gli OEM (Original Equipment manufacturer) viene supportato il deploy su un'unità flash USB.
Questo approccio può essere una soluzione interessante per i server dedicati alla virtualizzazione senza HD locali che velocizza e semplifica il loro deploy e aggiornamento, garantendo al tempo stesso la possibilità di tornare rapidamente alla configurazione precedente.
L'unità flash USB dovrà essere formattata e preparata con un'immagine Hyper-V Server generalizzata, inoltre è necessario copiarvi i file di avvio necessari.
In estrema sintesi i criteri OEM per la distribuzione di Microsoft Hyper-V Server 2008 R2 su unità flash USB sono:
- Gli OEM possono distribuire Microsoft Hyper-V Server 2008 R2 in un'unità flash USB data da un componente interno del computer, ad esempio un disco rigido interno, che sarà identificata come non rimovibile dalla struttura di archiviazione STORAGE_DEVICE_DESCRIPTOR.
- Gli OEM non possono distribuire Microsoft Hyper-V Server 2008 R2 in un'unità flash USB non data da un componente interno del computer, ad esempio un'unità flash USB esterna portabile.
Requisiti per l’unità flash USB:
- Compatibile con USB 2.0
Ovvero dispositivo di archiviazione di massa standard (Classe 08h) compatibile con Universal Serial Bus (USB) 2.0. - Non rimovibile
L'unità flash USB deve essere un componente interno non rimovibile incorporato nel sistema del server. Il bit del supporto rimovibile (RMB, removable-media bit) nella struttura di archiviazione STORAGE_DEVICE_DESCRIPTOR corrispondente al dispositivo deve essere impostato su zero (0) per indicare che si tratta di un supporto non rimovibile. - 16 gigabyte di capacità (8 gigabyte minimo)
Occorrono almeno 8 gigabyte (GB) per distribuire Hyper-V in un'unità flash USB, ma 16 GB rappresentano le dimensioni minime consigliate dell'unità flash USB. Infatti anche se le dimensioni dell'immagine del disco rigido virtuale sono inferiori a 16 GB è consigliabile riservare spazio aggiuntivo per aggiornamenti, service pack e agenti di gestione di terze parti futuri. Inoltre lo spazio aggiuntivo serve anche a limitare l'usura del sistema nel corso del tempo. - Hardware appropriato per il carico di lavoro previsto
E’ consigliabile utilizzare unità flash che possano funzionare correttamente per un periodo previsto di 7 - 10 anni di utilizzo continuo in condizioni tipiche degli OEM.
Per la guida step by step per la preparazione manuale di una unità USB per l’avvio di Hyper-V si faccia riferimento al seguente Deploying Microsoft Hyper-V Server 2008 R2 on USB Flash Drive.
Sono anche disponibili due tool per la creazione:
Wednesday, May 09, 2012
Nel post Windows Server 8 Beta: Remote Desktop Services avevo cercato di tirare le somme sulle novità relative agli RDS in Windows server 8 Beta che verrà rilasciato col nome di Windows Server 2012.
In WS8 i ruoli associati all’infrastruttura VDI:
- Remote Desktop Virtualization Host
- Remote Desktop Web Access
- Remote Desktop Connection Broker
- Remote Desktop Gateway
- Remote Desktop Licensing
- Remote Desktop Management Service
In WS8 la tecnologia RemoteFX, introdotta col Service Pack 1 di WS2008 R2, per consentire il supporto a coded avanzati, virtualizzazione di GPU, applicazione grafiche di vario tipo incluse quelle 3D e l’utilizzo di periferiche USB è stata ulteriormente migliorata con i seguenti obbiettivi:
- Capacità di utilizzare hardware dedicato alla grafica e una vasta gamma di periferiche anche all’interno dei desktop virtuali offerti dalle macchine virtuali.
- Riduzione dei requisiti hardware sugli endpoint device che utilizzano i virtual desktop al fine di poter utilizzare client di basso costo, ma garantendo una User Experience elevata.
L’utilizzo delle funzionalità di RemoteFX richiedono una GPU con supporto a RemoteFX (si veda il Windows Server Catalog per l’elenco) e CPU con supporto alla Second Level Address Translation (SLAT) (per le CPU Intel la SLAT è identificata col nome Extended Page Tables (EPT) mentre per le CPU AMD la SLAT è identificata col nome Nested Page Tables (NPT)).
Per motivi di sicurezza e performance viene raccomando di non far coesistere nello stesso server il ruolo Remote Desktop Virtualization Host, i service role RemoteFX e il ruolo Active Directory Domain Services (il tentativi di installare i ruoli sullo stesso server genererà un warning).
Analogamente ai servizi RDS anche per quanto riguarda l’infrastruttura VDI è disponibile Remote Desktop Management Service (RDMS) che permette la gestione centralizzata dell’installazione e della configurazione dei vari ruoli (per alcuni dettagli su RDMS si veda il post Windows Server 8 Beta: Remote Desktop Services). Inoltre tramite RDMS le VM potranno essere duplicate a partire da master VM image rendendo semplice la creazione delle VM in ambiente VDI e la feature VM Streaming consentirà di eseguire il deploy della VM anche su share SMB oltre che su SAN.
Altra feature interessante è la Pooled VM Patching ovvero la possibilità di eseguire aggiornamenti di sistema sulle VM non utilizzate in pool con possibilità di definire una deadline oltre cui tutte le VM devono essere aggiornate, in questo all’utente sarà notificato di salvare il proprio lavoro e di eseguire il logoff dalla VM per consentirne l’aggiornamento.
Per quanto rigurada il patching delle macchine Personal può essere gestito come per le macchine fisiche tramite Windows Update mentre la VM è attiva, mentre se è necessario eseguire l’aggiornamento mentre la VM è spenta o in saved state sarà possibile avviarla tramite l’host agent installare le patch e mettere poi la VM nelle stato inziale notificando che la VM è stata aggiornata.
Un’altra novità saranno i User Profile Disks, ovvero VHD dedicati a profili utente che possono risiedere su share SMB di cui avevo già discusso nel post Windows Server 8 Beta: Remote Desktop Services.
Ovviamente per le infrastrutture VDI una grande importanza la rivestirà la tecnologia RemoteFX introdotta col Service Pack1 di WS2008 R2 e ulteriormente migliorata con nuove funzionalità:
- RemoteFX Integration la tecnologia RemoteFX ora è integrata nella feature Remote Desktop senza più richiedere l’istallazione di un ruolo separato
- RemoteFX for WAN che permette l’utilizzo dia dei protocolli TCP che UDP per adattarsi automaticamente alle condizioni di traffico della connessione di rete
- RemoteFX Adaptive Graphics che adatta la trasmissione dei dati dinamicamente e ottimizza l’encoding in base al contenuti da inviare
- RemoteFX Media Remoting che permette la fruizione dei contenuti multimediali tramite RDP adattando la trasmissione dati alla rete
- RemoteFX Multi Touch che permette di utilizzare il Multi Touch in sessione remota consentendo quindi l’utilizzo dell’interfaccia grafica Metro introdotta con Windows 8
- GPU Management che permette di scegliere quale GPU utilizzare per offrire una GPU virtualizzata ad un VM e di ottenere indo sulle GPU e il loro utilizzo in Hyper-V
- Managing a RemoteFX VM che permette di connettersi ad una VM con una RemoteFX 3D Video Adapter tramite VMConnect (in WS2008R2 SP1 era possibile connettersi alla VM solo tramite RDP)
- Multimonitor Support che supera i limiti di WS2008 R2 per cui si potevano utilizzare fino a 4 monitor, ma con risoluzione minore
- RemoteFX Codec Improvements in WS2012 il RemoteFX Codec ha circa raddoppiato il rapporto di compressione rispetto a WS2008R2 SP1, ciò permetterà di ridurre il consumo di banda
Per ulteriori informazioni si vedano:
Le ISO e i file VHD della versione Beta a 64 Bit in 5 lingue (Inglese, Cinese semplificato, Francese, Tedesco e Giapponese) di Windows Server 8 sono disponibili al seguente Download Windows Server "8" Beta.
Thursday, May 03, 2012
A volte può accadere che al login dell’utente lo script di logon non venga eseguito, mi è capitato di vedere personalmente questo scenario oltre che di leggere esperienze in tal senso sui Forum di Sysadmin.it.
Il motivi che possono generare un tale malfunzionamento possono essere svariati ed escludendo quello più banale ovvero un errore nello script le causa più comune è quella in cui lo script non viene avviato piuttosto che un errore nell’esecuzione dello stesso.
Il mancato avvio dello script di avvio/logon è di solito legato a problematiche di rete come ad esempio:
- Rete lenta a causa di problemi su apparati, cavi o infrastruttura di rete con collegamenti che passano attraverso più apparati, tratte a diversa velocità o loop che causano l’intervento dello Spannig Tree.
- Servizi di rete sul computer avviati in ritardo rispetto alla procedura di avvio/logon che viene eseguita in background e non può quindi accedere alla share SYSVOL del domain controller per l’avvio degli script. I motivi per cui ciò può succedere sono svariati e spesso saltuari e possono essere causati da:
- Esecuzione di una procedura di inizializzazione a seguito dell’installazione di un aggiornamento di sistema tramite Windows Update o WSUS
- Una scansione all’avvio eseguita dall’antivirus che può durare più del dovuto a causa di file temporanei corposi causati dalla sessione di lavoro precedente
- Un rallentamento all’avvio dovuto ai programmi/servizi ad avvio automatico o alla frammentazione del partizione di avvio del sistema
Se la causa è la mancanza della rete nel momento in cui la procedura di avvio/logon prevede l’esecuzione dello script è possibile provare ad ovviare a tale problematica abilitando la GPO Computer Always wait for the network at computer startup and logon in Administrative Templates\System\Logon.
Tale GPO impone l’attesa della rete durante l'avvio del computer e l'accesso dell'utente infatti per default il sistema non attende l'inizializzazione completa della rete all'avvio e all'accesso utente, gli utenti esistenti si connettono utilizzano le credenziali memorizzate nella cache, con tempi di accesso più brevi e i criteri di gruppo vengono applicati in background quando la rete diventa disponibile.
Tale GPO è stata introdotta in Windows XP (nei sistemi precedenti quali Windows 2000 veniva sempre attesa la completa inizializzazione della rete prima dell’accesso) inoltre nella descrizione della GPO viene riportato quanto segue:
“A causa dell'aggiornamento in background, le estensioni quali Installazione software e Reindirizzamento cartelle richiedono due accessi per applicare le modifiche. Per operare in modo sicuro, tali estensioni richiedono che nessun utente sia connesso. Pertanto, è necessario elaborarle in primo piano prima che gli utenti utilizzino attivamente il computer. Inoltre, è possibile che il rilevamento delle modifiche apportate all'oggetto utente, ad esempio l'aggiunta del percorso di un profilo comune, di una home directory o di uno script di accesso oggetto utente, richiedano due accessi.
Se un utente con un profilo comune, una home directory o uno script di accesso oggetto utente si connette a un computer, Windows XP attende sempre l'inizializzazione della rete prima di consentire l'accesso dell'utente (*).
Se un utente si connette al computer per la prima volta, Windows XP attende sempre l'inizializzazione della rete.
Se si attiva questa impostazione, gli accessi vengono eseguiti allo stesso modo dei client Windows 2000, in quanto Windows XP attende l'inizializzazione completa della rete prima di consentire l'accesso degli utenti. I criteri di gruppo vengono applicati in primo piano, in modo sincrono.
Se si disattiva o non si configura questa impostazione, Windows non attende l'inizializzazione completa della rete e gli utenti si connettono con le credenziali memorizzate nella cache. I criteri di gruppo vengono applicati in modo asincrono in background.
Nota: se si desidera garantire che l'applicazione di Reindirizzamento cartelle, Installazione software o delle impostazioni del profilo utente comune avvenga con un solo accesso, attivare questa impostazione in modo che Windows attenda che la rete sia disponibile prima di applicare i criteri.
Nota: per i server, l'elaborazione dell'avvio e dell'accesso presuppone sempre l'attivazione dell'impostazione del criterio.
(*) Nella descrizione si parla di script di accesso oggetto utente sembrerebbero quindi esclusi gli script impostati direttamente sull’utente ed è proprio in questo scenario che mi è capitato di verificare la mancata esecuzione saltuaria degli script.
Si ricordi che impostando la policy Always wait for the network at computer startup and logon questa sarà attiva al secondo accesso infatti al primo questa verrà scaricata e applicata e al secondo il sistema attenderà quindi la disponibilità della rete prima di eseguire l’accesso.
Per ulteriori informazioni si vedano:
Un’altra possibile causa potrebbe essere legata alle funzionalità TCP Chimney e RSS, spesso infatti i driver di rete non implementato correttamente tali nuove funzionalità di rete per risolvere il problema è possibile verificare se esistono driver aggiornati per i computer client che manifestano il problema oppure è possibile disabilitare tali funzionalità nel caso non di particolare interesse sui client interessati a riguardo si veda Error message when an application connects to SQL Server on a server that is running Windows Server 2003: "General Network error," "Communication link failure," or "A transport-level error".
Inoltre va tenuto presente che alcuni servizi possono non essere compatibili con la funzionalità TCP Chimney e causare quindi malfunzionamenti, a riguardo si veda la seguente KB per Windows Server 2008 Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008.
A riguardo segnalo anche una hotfix che è stata rilasciata per Windows 7 e Windows Server 2008 R2 che va a risolvere problematiche legate al TCP Chimney Offload in presenza di elevati carichi di rete che potrebbero verificarsi non tanto sul client, ma sul Domain Controller The TCP Chimney Offload feature fails on all network adapters in Windows Server 2008 R2 or in Windows 7 if you disable or change the properties of a network adapter.
Un’altra possibile causa potrebbe essere l’elevato numero di connessioni verso il Domain Controller, in questi scenari la problematica dovrebbe presentarsi più frequentemente nei giorni che seguono una pausa lavorativa degli uffici come ad esempio il Lunedì mattina. Per provare ad ovviare a questo problema è possibile aumentare il valore MaxUserPort, a rigurado si vedano:
Un’ulteriore causa del mancato avvio degli script di avvio/logon potrebbe essere dovuta al fatto che la connessione di rete viene rilavata come lenta.
In presenza di connessioni lente i meccanismi di avvio possono subire modifiche comportamentali per ovviare è possibile utilizzare due GPO computer.
La prima GPO computer è Group Policy slow link detection in Administrative Templates\System\Group Policy che è possibile attivare e impostare a 0 per considerare tutte le connessioni di rete come veloci. Per maggiori informazioni si veda la descrizione della GPO:
Specifica se una connessione è lenta per l'applicazione e l'aggiornamento dei Criteri di gruppo.
Se la velocità di trasferimento dati dal controller di dominio primario che fornisce l'aggiornamento di un criterio ai computer del gruppo è inferiore a quella specificata dal criterio, la connessione sarà considerata lenta.
La risposta del sistema a una connessione lenta varia a seconda dei criteri specificati. Il programma che applica il criterio determina la risposta a un collegamento lento. Inoltre il criterio che elabora i criteri della cartella consente di sostituire le risposte ai collegamenti lenti specificate dal programma.
Per utilizzare questo criterio, digitare nella casella "Velocità di connessione" un numero decimale compreso tra 0 e 4.294.967.200 (0xFFFFFFA0), che indica la velocità di trasferimento in kilobit al secondo. Le connessioni al di sotto del limite specificato verranno considerate lente. Se il valore immesso è 0, tutte le connessioni verranno considerate veloci.
Se si disattiva questo criterio o non lo si configura, verrà utilizzato il valore predefinito di 500 kilobit al secondo.
Questo criterio appare nelle cartelle Configurazione computer e Configurazione utente. Il criterio di Configurazione computer definisce i collegamenti lenti per i criteri della cartella Configurazione computer, mentre il criterio di Configurazione utente definisce i collegamenti lenti per i criteri della cartella Configurazione utente. Consultare anche il criterio "Non rilevare connessioni di rete lente" e i criteri relativi in Computer Configuration\Administrative Templates\System\User Profile. Nota: se il server dei profili ha connettività IP, sarà utilizzato il criterio velocità di connessione. Se non ha connettività IP, sarà utilizzata la temporizzazione SMB.
Al seguente Specifying Group Policy for Slow Link Detection è possibile verificare quali funzionalità per default non sono attive in presenza di connessioni lente ovvero Software Installation, Scripts e Folder Redirection. Si noti che in questo caso però si intendono gli script impostato tramite GPO e non quelli assegnati direttamente sull’utente (Default Behavior for Group Policy Extensions with Slow Link).
E possibile anche forzare l’esecuzione degli script impostati via GPO tramite la GPO Computer Scripts policy processing in Administrative Templates\System\Group Policy, attivado tale GPO sarà possibile forzare l’esecuzione delle policy di script anche in presenza di connessioni lente coem indicato nella descrizione
Determina il momento in cui i criteri che assegnano gli script condivisi vengono aggiornati.
Questa impostazione si applica a tutti i criteri che utilizzano il componente script dei Criteri di gruppo, quali ad esempio quelli in Impostazioni di Windows\Script.
Questa impostazione sostituisce le impostazioni personalizzate definite al momento dell'installazione dal programma che implementa il criterio degli script.
Se si abilita questa impostazione, sarà possibile modificare le opzioni nelle apposite caselle di controllo. Se si disabilita questa impostazione o non la si configura, essa non avrà alcun effetto sul sistema.
L'opzione "Consenti elaborazione attraverso una connessione di rete lenta" aggiorna i criteri anche quando gli aggiornamenti vengono trasmessi tramite una connessione di rete lenta, quale una linea telefonica. Il trasferimento degli aggiornamenti tramite connessioni lente può provocare ritardi notevoli.
L'opzione "Non applicare durante l'elaborazione periodica in background" impedisce l'aggiornamento di tali criteri in background mentre il computer è in uso. Gli aggiornamenti in background possono creare problemi agli utenti, causare l'interruzione o il funzionamento anomalo del programma e, in rari casi, danneggiare i dati.
L'opzione "Elabora anche se gli oggetti Criteri di gruppo non sono stati modificati" aggiorna e riapplica i criteri anche in assenza di modifiche. Molte implementazioni dei criteri specificano che gli aggiornamenti verranno effettuati solo in presenza di modifiche. È tuttavia possibile aggiornare i criteri che non hanno subito modifiche, riapplicando ad esempio una impostazione modificata da un utente.
Per ulteriori informazioni si veda anche How a slow link is detected for processing user profiles and Group Policy.
Come ultimo consiglio verificate anche la presenza di errori o avvisi nell’Event Viewer del computer client o del Domain controller per capire se è possibile ricavare più informazioni sul malfunzionamento o capire se si verifica in corrispondenza di determinate situazioni.
Monday, April 30, 2012
Da qualche anno Microsoft ha dedicato parte dei sui sforzi alla sicurezza acquisendo prodotti e sviluppandoli. Il risultato di questo investimento sul fronte della sicurezza sono oltre alla linea di prodotti Forefront anche tuta una serie di applicativi e tools gratuiti.
Microsoft Security Essentials
![Microsoft-Security-Essentials-300x300[1]](http://blogs.sysadmin.it/images/blogs_sysadmin_it/ermannog/Windows-Live-Writer/Microsoft-security-tools_12527/Microsoft-Security-Essentials-300x300%5B1%5D_dc8efdbc-86eb-4f92-b9e2-6c005e718895.png "Microsoft-Security-Essentials-300x300[1]")
Microsoft Security Essentials , di cui è stata rilasciata la versione 4.0 il 24 Aprile 2012, è l’antivirus gratuito utilizzabile su Windows XP SP3, Windows Vista SP1/SP2 e Windows 7. MSE utilizza lo stesso motore di scansione utilizzato dai prodotti a pagamento Windows Intune e Forefront Endpoint Protection.
Il prodotto è utilizzabile a livello Domestico (gli utenti domestici possono installare e utilizzare un numero qualsiasi di copie di MSE sui dispositivi personali affinché possano essere utilizzati dal nucleo familiare) e in Imprese di Piccole Dimensioni (Il licenziatario potrà installare e utilizzare il software su un numero massimo di dieci dispositivi qualora operi in un'impresa di piccole dimensioni). Viceversa MSE non può essere utilizzato in dispositivi di proprietà di enti governativi o istituti didattici e, com’è logico per un software gratuito, non è prevista la fornitura di servizi di supporto tecnico da parte di Microsoft (per ulteriori informazioni sulla licenza d’uso si veda CONDIZIONI DI LICENZA PER IL SOFTWARE MICROSOFT).
Le caratteristiche di MSE fornisce protezione in tempo reale ed è utilizzabile anche in piccole imprese con un massimo di 10 PC e tra le sue caratteristiche vi sono:
- Protezione in tempo reale
- Analisi del sistema pianificata o su richiesta con tre opzioni Rapida, Completa o Personalizzata
- Pulizia del sistema consentendo le seguenti azioni: Rimozione, Quarantena e Consenti (ovvero aggiunta dell’elemento dall'elenco Elementi consentiti per evitare future analisi dell’elemento)
- Integrazione con Windows Firewall (in fase di installazione MSE determina se è presente un firewall attivo)
- Protezione da rootkit (MSE monitora il kernal del sistema operativo per verificare la presenza di attacchi o modifiche dannose ed esegue l'analisi diretta del file system)
- Supporto a Windows XP Mode di Windows 7
- Può essere eseguito solo su sistemi che eseguono una copia di Windows originale
Per ulteriori informazioni sul prodotto e per il download si veda Informazioni su Microsoft Security Essentials.
Tra le novità della versione 4.0 di MSE che era in beta dal Dicembre 2011 oltre alla correzione di alcuni bug minori vi sono:
- Miglioramenti alla capacità di rilevare malware e alle performance durante la scansione
- Automatic Remediation che mette in quarantena le minacce ad alto rischio senza visualizzare una richiesta all’utente
- Possibilità di utilizzare la Microsoft Active Protection Service (il nuovo nome per SpyNet) per inviare a Microsoft le informazioni sul malware eventualmente rilevato al fine di consentire la generazione di nuove firme in modo rapido e incisivo per le nuove minacce (ovviamente è possibile disabilitare tale funzione se si preferisce che MSE non invii tali comunicazioni che comunque riguardano solo lo stretto necessario per consentire di analizzare il malware rilevato senza inviare informazioni personali)
Sulle versioni di Windows 8 che sono state rese pubbliche nel sistema è presente Windows Defender che fornisce una protezione da malware come indicato in Antimalware apps for Windows 8 Consumer Preview, ma al momento W8 non è compatibile con MSE come indicato in Application Compatibility release for Windows 8 Consumer Preview:
“This update introduces a hard block on Microsoft Security Essentials. A hard block prevents an application that is incompatible with Windows 8 Consumer Preview from running on the computer. This hard block is being introduced because Microsoft Security Essentials is incompatible with Windows 8 Consumer Preview.”
MSE di base non ha strumenti che ne consentono la centralizzazione, ma in realtà qualcosa su questo fronte si può fare. Innanzitutto per quanto riguarda le firme va detto che è possibile gestirle anche tramite WSUS come avevo indicato nei post WSUS: Security Essentials e Microsoft Security Essential: Gestione degli aggiornamenti. Inoltre è possibile gestire MSE tramite il deploy di configurazioni basate su chiavi di registro tramite GPO custom o GPO Preferences e quindi centralizzando la gestione d MSE, avevo trattato questi argomenti nel post Microsoft Security Essential in azienda.
Per altre informazioni si vedano:
Security tools gratuiti
Oltre a MSE Microsoft ha reso disponibili anche i seguenti tools che possono tornare utili per controllare un sistema o rimuovere eventuali malware:
- Microsoft Safety Scanner che offre funzionalità di analisi su richiesta e consente di rimuovere virus, spyware e altro malware, funziona con il software antivirus esistente e può quindi essere utilizzato come ulteriore verifica. MSS scade scade 10 giorni dopo il download ed occorre scaricarlo nuovamente per utilizzare le ultime definizioni antimalware. Non fornisce protezione in tempo reale e quindi non sostituisce l'utilizzo di un programma software antivirus.
- Windows Defender Offline che permette la scansione offline del sistema in quanto è uno strumento di scansione che può essere eseguito da chiavetta USB, DVD o CD. Richiede 250 MB di spazio e un sistema XP SP3 o successivo da cui creare il supporto ad avvio automatico contente WDO che è disponibile sia 32 bit che a 64 bit (occorre rispettare l’architettura del sistema che si desidera analizzare). Per utilizzare WDO occorre disabilitare BitLocker se attivo (per ulteriori informazioni si veda Requisiti di sistema di Windows Defender Offline). Grazie alla scansione offline è possibile rimuovere più semplicemente malware particolarmente aggressivo come i rootkits o operare su sistemi che non riescono più ad avviarsi o funzionano in modo limitato a causa di un’infezione.
- Sysinternals Security Utilities tra cui in particolare RootkitRevealer per la scansione del sistema al fine di individuare potenziali rootkits
Links e portali
Per avere informazioni e sulla sicurezza, sulle nuove minacce e sulle best practies è possibile utilizzare i seguenti:
Friday, April 13, 2012
SQL Server è progettato per acquisire e liberare la memoria in modo dinamico in base alle necessità. Il suo obiettivo principale consiste nel ridurre al minimo l'I/O su disco poiché le letture e le scritture su disco impegnano la maggiore quantità di risorse se confrontate con le altre operazioni (a riguardo si veda Memory Architecture).
Per conservare le pagine lette dal database, SQL Server crea in memoria un pool di buffer e cerca di raggiungere un equilibrio tra i due obiettivi seguenti:
- Evitare che le dimensioni del pool di buffer aumentino fino a limitare la memoria dell'intero sistema
- Ridurre al minimo l'I/O fisico sui file di database aumentando la dimensione del pool di buffer fino a raggiungere il valore massimo possibile
Quando SQL Server utilizza la memoria in modo dinamico, esegue query periodiche sul sistema per determinare la memoria libera disponibile in modo da evitare il paging del sistema operativo rilasciando memoria al sistema operativo se necessario. Nel caso invece sia disponibile una quantità maggiore di memoria libera e il carico di lavoro lo richiede SQL Server alloca più memoria.
Quindi riassumendo per quanto concerne la gestione della memoria in SQL Server possiamo dire che:
- SQL Server non utilizza il PageFile
- SQL Server alloca la memoria solo quando il carico di lavoro lo richiede e il sistema ha memoria libera disponibile
- SQL Server non rilascia la memoria allocata a meno che la memoria libera del sistema non scenda a valori tali da richiedere il paging.
È possibile impostare manualmente le opzioni per la memoria e limitare la quantità di memoria massima a cui può accedere SQL Server (come pure garantire una memoria minima per maggiori informazioni si vedano Effects of min and max server memory e How to adjust memory usage by using configuration options in SQL Server).
Se si decide di impostare manualmente la memoria massima assegnabile a SQL Server occorre determinare la memoria necessaria al sistema operativo, ad eventuali altre istanze in esecuzione e ad altri utilizzi (per esempio funzionalità di SQL Server oltre al DBMS, come ad esempio SQL Server Agent, Full Text, Reporting Services etc). La differenza tra Memoria fisica e Memoria non destinata a SQL Server rappresenta la quantità di memoria massima assegnabile a SQL Server (Max Server Memory).
Nel post Suggested Max Memory Settings for SQL Server 2005/2008 di Glenn Berry (SQL Server MVP 2007, 2008 e 2009) vengono ad esempio suggeriti dei valori di Memoria Massima per SQL Server in base alla Memoria fisica disponibile.
Si noti che il valore Max Server Memory si riferisce in realtà alla dimensione del pool di buffer e non alla memoria occupata da SQL Server.
L’impostazione della memora massima previene situazioni di memori pressure che possono verificarsi nel lasso di tempo che intercorre tra due query per la memoria libera disponibile. Inoltre come indicato nel seguente Importance of setting Max Server Memory in SQL Server and How to Set it su sistemi a 64 Bit è buona pratica impostare il limite massimo di memoria assegnabile a SQL Server (a riguardo si veda anche How to reduce paging of buffer pool memory in the 64-bit version of SQL Server).
Inoltre per evitare la paginazione dei dati di SQL Server è consigliabile abilitare la funzionalità Lock Pages in Memory, in SQL Server 2012 è sufficiente che l’utente che esegue SQL Server (per default l’utente virtuale NT Service\MSSQLSERVER) abbia il privilegio Locked Pages in Memory impostato tramite la policy locale Computer Windows Settings\Security Settings\User Rights Assignment\Lock pages in memory.
Per ulteriori informazioni si veda Server Memory Server Configuration Options e Enable the Lock Pages in Memory Option (Windows).
Ipotizzando quindi uno scenario in cui SQL Server 2012 sia installato su Windows 2008 R2 su sistema con 10 GB di RAM dedicato esclusivamente al servizio di database io di solito eseguo le seguenti configurazioni:
- Imposto la Max Server Memory per SQL Server a RAM-1GB quindi nell’esempio a 10GB-1GB=9 GB. La scelta di sottrarre 1 GB deriva dal fatto che il requisito minimo di sistema per WS2008R2 è 512 MB a cui aggiungo altri 512 MB per eventuali altri processi che possano avere la necessità di essere eseguiti anche anche il sistema è dedicato esclusivamente a SQL Server (script di backup, Reporting Services etc..)
- Abilito la funzionalità Lock Pages in Memory
- Imposto il PageFile a 1024 MB
La scelta di impostare il PageFile a 1024 MB nasce dalle seguenti considerazioni:
- SQL Server se configurato correttamente (Max Server Memory impostato e Lock Pages in Memory abilitata) non utilizza il PageFile.
- Per default WS2008R2 è configurato per generare in caso di fault un Kernel Dump il quale richiede 800 MB per sistemi con RAM >= 8GB come indicato in Understanding Crash Dump Files. Si tenga conto che il supporto Microsoft nel caso venga aperta una chiamata potrebbe richiedere il Kernel Dump.
- Per default WS2008R2 imposta il page file ad una dimensione pari alla RAM e considerando che la memoria del sistema oggetto di possibile paginazione è RAM-Max Server Memory che nell’esempio precedente risulta uguale a 1GB.
Per ulteriori informazioni si vedano:
Nella guida in linea di SQL Server nella sezione Opzioni di configurazione del server Server Memory tra le varie note viene riportata anche la seguente relativa all’ottimizzazione dei dati per le applicazioni di rete.
Per ottimizzare l'utilizzo della memoria di sistema per SQL Server, è necessario limitare la quantità di memoria utilizzata dal sistema per la memorizzazione dei file nella cache. Per limitare la cache del file system, assicurarsi che l'opzione Massimizza la velocità di trasmissione dati per condivisione file non sia selezionata. Per specificare la quantità minima di cache del file system, è possibile selezionare Minimizza la quantità di memoria utilizzata o Bilanciamento.
Si noti però che questa impostazione è applicabile solo a sistemi Windows Server 2003 e Windows Server 2003 R2 in quanto in Windows Server 2008\Vista e successivi non più possibile configurare questa impostazione tramite interfaccia grafica inoltre la chiave di registry che imosta tale configurazione (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache) è mantenuta solo per compatibilità verso applicazioni che ne controllarne il valore (ma in queste versioni di OS tale pratica è deprecata).
Quindi in Windows Server 2008\Vista e superiori non è necessario occuparsi di questa configurazione e non occorre impostare il valore della chiave LargeSystemCache come indicato nel post Maximize data throughput for network applications in Vista and higher?.
Inotre per quanto riguarda SQL Server 2012 dal momento che come si può verificare nella sezione della BOL Hardware and Software Requirements for Installing SQL Server 2012 è supportato su Windows Server 2008\Vista volendo fare i precisini si potrebbe anche dire che il riferimento all’all’ottimizzazione dei dati per le applicazioni di rete per questa versione di SQL Server non ha più significato e potrebbe essere eliminata dalla BOL.
Thursday, April 12, 2012
Su sistemi Windows Vista SP1, Windows Server 2008, Windows 7 SP1 o Windows Server 2008 R2 SP1 nel registro Applicazione dell’Event Viewer viene registrato l’errore:
Source: Microsoft-Windows-WMI
Event ID: 10
Task Category: None
Level: Error
Keywords: Classic
Description: Event filter with query "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA "Win32_Processor" AND TargetInstance.LoadPercentage > 99" could not be reactivated in namespace "//./root/CIMV2" because of error 0x80041003. Events cannot be delivered through this filter until the problem is corrected.
L’errore può essere ignorato in quanto non è il sintomo di un problema del sistema operativo.
Nei seguenti articoli della KB è possibile trovate una spiegazione dettagliata dell’errore e un workaround basato su un script vbs.
Event ID 10 is logged in the Application log after you install Windows Vista Service Pack 1 or Windows Server 2008
This problem occurs if the WMI filter is accessed without sufficient permission.
This particular Event ID 10 error message listed above can be safely ignored, this is not indicative of a problem with the Service Pack or with the operating system.
Event ID 10 is logged in the Application log after you install Service Pack 1 for Windows 7 or Windows Server 2008 R2
This originated in the Windows 7 SP1 DVD/ISO creation process. There was an issue in the creation process that caused a WMI registration to remain in the DVD/ISO. Since the registration is designed to work only during the DVD/ISO creation process, it fails to run on a live system and causes these events. These events are not indicative of any issue in the system and can be safely ignored.
Monday, April 09, 2012
Il Disk Partion Alignement (ovvero l’allineamento della della geometrie del disco e della partizione) è una best practies che può portare ad un significativo aumento delle performance in determinati contesti anche se spesso rischia di essere poco considerata.
Innanzitutto va detto che l’”allineamento” consiste nel far sì che le operazioni di IO sui dischi da parete di SQL Server avvengano in maniera ottimizzata, dal momento che la file allocation unit size (cluster size) raccomandata per SQL Server è di 64 KB (che coincide con un singolo SQL Server extent) il concetto è quello di allineare i dati ai vari livelli (stripe, partizione e volume) per fare in modo che i dati siano gestiti a blocchi o multipli di 64 KB in modo da ridurre il numero di I/O richiesti.
Come già detto precedentemente l’allineamento si ottiene lavorando a tutti i livelli:
- Stripe (ovvero il RAID)
- Partizione
- Volume (ovvero file allocation)
La dimensione del settore, che rappresenta la più piccola unità fisica di archiviazione sul disco, è invece fissata dal costruttore del disco. Storicamente la dimensione era fissata a 512 byte, ma ora i nuovi drive ha dimensioni del settore che posso variare da 1KB, 2KB o 4KB.
Impostazione dello Stripe size
Lo strip size è l’unità di dati che scritta e letta quando i dischi sono in RAID. L’indicazione che viene data per SQL Server è quella di impostare lo strip size tra 64 KB e 256 KB e in particolare se occorre operare su tabelle con dimensioni superiori a 100 MB uno stripe size di 256 KB risulterà più efficiente.
A riguardo di veda Physical Database Storage Design:
“A smaller stripe size allows data to be distributed to more disks and increase I/O parallelism. Note that the stripe size of a single SQL Server extent (64 KB) is the lower limit. For the same data, a larger stripe size means the data can be stored on fewer disks and decrease the I/O distribution and the degree of parallelism. We recommend a 64 KB or 256 KB stripe size for most workloads. When the workload includes table and index range scans on tables that are larger than 100 MB, a stripe size of 256 KB allows for more efficient read-ahead.”
Allineamento a livello di Partizione (o Partition Alignment)
L’allineamento a livello di partizione consiste nell’impostare il Partition Offset in quanto il disk array riserva 63 o 32 settori nascosti e Windows di conseguenza riserva questi settori all’inizio della prima partizione di un disco in cui fa risiedere il Master Boot Record (MBR). Questi 32 o 63 settori iniziali sono la causa del disallineamento tra la partizione lo stripe in quanto l’accesso al singolo cluster di dati avverrà accedendo a attraverso più stripe unit del RAID.
Per essere precisi in WS2003\XP e precedenti l’allineamento di default per la partizione è di 32.256 bytes ovvero 31.5 KB, mentre in WS2008\Vista e successivi il Partition Offset è per default di 1.048.576 byte ovvero 1024 KB per dischi di dimensione superiore a 4 GB (il valore è configurabile tramite la chiave di registro HKLM\SYSTEM\CurrentCpntrolSet\Services\VDS\Alignment).
Quindi in WS2008\Vista il Partition Alignment non è necessario, mentre lo è sul sistemi WS2003\XP e precedenti.
Per avere informazioni sulla partizione è possibile usare il comando wmic partition get BlockSize, StartingOffset, Name, Index
Per i dischi dinamici è possibile utilizzare il comando dmdiag –v.
Il drive di sistema su versioni di Windows precedenti a WS2008/Vista non possono essere allineati, ma si noti che le best practies sconsigliano di lasciare i file di dati e i logs sulla partizione di sistema per evitare problemi di performance dovuti alle operazioni di IO svolte dall’OS e dalla gestione del file di paginazione.
Nei sistemi in cui è necessario intervenire per impostare il Partition Offset è possibile utilizzare il comando diskpart.exe in WS2003 e successivi (con l’SP1 di WS2003 è stata introdotta l’opzione /align), per WS2000 è disponibile tramite il Windows 2000 Resource Kit il tool diskpar.exe.
Allineamento a livello di Volume (o File Allocation Unit Size)
L’allineamento a livello di volume consiste nell’impostare il File Allocation Unit Size, ovvero i bytes per cluster, ottimale per ottimizzare le operazioni di IO tenendo conto che, come detto precedentemente, il singolo SQL Server extent è di 64 KB.
Per visualizzare le informazioni sull’allineamento a livello di volume è possibile usare il comando fsutil fsinfo ntfsinfo drive:.
Il default cluster size per NTFS è di 4096 bytes ovvero 4 KB per dimensioni di volume fino a 16 TB come indicato nel seguente Default cluster size for NTFS, FAT, and exFAT, ma è modificabile quando si esegue la formattazione del volume è in base alle best practies di SQL Server va impostato a 64 KB.
Correlazioni tra Stripe Unit, Partition Offset e File Allocation Unit Size
Per avere performance ottimali sulle I/O del disco devono essere rispettate due correlazioni fondamentali:
- Il rapporto Partition Offset / Stripe Unit Size deve essere un numero intero (il risultato intero di questo rapporto garantisce l’allineamento tra Partizione e Stripe)
- Il rapporto Stripe Unit Size / File Allocation Unit Size deve essere un numero intero (il risultato intero di questo rapporto garantisce l’allineamento tra Volume e Stripe)
Esempio
Consideriamo ad esempio di volere gestire l’allineamento per la partizione dedicata al file dati e/o file log di SQL Server in ambiente WS2008 R2 utilizzando un controller Smart Array HP per un Database OLTP di tipo gestionale (quindi con possibilità di dover gestire tabelle di dimensione uguale o superiore ai 100 MB).
Gli Smart Array HP impostano 32 settori per traccia per drive logici con dimensione fino a 502 GB e 63 settori per traccia per drive logici con dimensioni superiori a 502 GB (è possibile forzare l’uso di 63 settori per traccia impostando l’opzione MaxBoot di drive logico). Lo Stripe Size può assumere i valori di 8 KB, 16 KB, 32 KB, 64 KB, 128 KB, 256 KB, 512 KB e 1024 KB e il valore di default dipende dall’impostazione del RAID level (per ulteriori informazioni si vedano i Manuali HP).
In base alle considerazioni fatte precedentemente occorre impostare lo Stripe Size a 256 KB.
Dal momento che si è ipotizzato un ambiente WS2008 R2 per impostazione predefinita il Partition Offset sarà di 1024 KB.
Quindi il primo rapporto Partition Offset / Stripe Unit Size sarà di 4 ovvero un valore intero garantendo quindi l’allineamento tra Stripe e Partizione.
In base alle best practies viste precedentemente occorre formattare il volume con Dimensione Unità di Allocazione (File Allocation Unit Size) di 64 KB.
Quindi il primo rapporto Stripe Unit Size / File Allocation Unit Size sarà di 4 ovvero un valore intero garantendo quindi l’allineamento tra Stripe e Volume.
Considerazioni per ambienti virtuali
Per quanto riguarda i drive virtuali questi devono essere allineati al drive dell’Host quindi occorre seguire le regole viste per i volumi, partizioni e stripe che conterranno i VHD inoltre la partizione all’interno del VHD dovrà essere allineata con il corretto Partition Offset e il volume formatto con una Dimensione Unità di Allocazione (File Allocation Unit Size) di 64 KB.
Per ulteriori informazioni e considerazioni si veda Hyper-V VM Partition Alignment.
Conclusioni
Per un’approfondimento sull’argomento si veda l’articolo Disk Partition Alignment Best Practices for SQL Server in cui viene analizzata in dettaglio la tematica e vengono anche proposti alcune rilevazioni in scenari reali per capire l’impatto sulle performance su sistemi allineati e non allineati. Ad esempio su un scenario OLTP con workload che coinvolgono table scans, update e selezioni le performance su un sistema “allineato” si aggira sul 30% in più rispetto ad un sistema in cui non è stato eseguito l’allineamento. Ovviamente le performance riportate dagli autori (JimmyMay e Denny Lee) vanno poi verificate nei propri scenari con l’hardware che si ha a disposizione e, tempo permettendo, occorrerebbe anche provare quale valore di Stripe Size conferisce nella propria realtà performance migliori (ovviamente nell’ambito dei valori che garantiscono l’allineamento).
I concetti che abbiamo visto si applicano in realtà anche a tutti questi servizi che hanno a che fare con trattamento intensivo di dati, ovviamente occorre gestire correttamente l’allineamento sulla base della File Allocation Unite Size suggerita.
Ad esempio per quanto riguarda i file di dati e log di Analisys Services è suggerita una File Allocation Unite Size di 32 KB, mentre per i file .edb e i logs file di Exchange una File Allocation Unite Size di 64 KB.
Per ulteriori informazioni si veda anche SQL Server Unplugged Follow Up.
Friday, April 06, 2012
Spesso possono accadere errori legati all’esecuzione di Windows Update su macchine che devono utilizzare proxy per accedere a Internet.
Nel mio caso il computer aveva le seguenti caratteristiche:
- OS WS2008R2Sp1 appena installato
- In workgroup
- Proxy configurato manualmente per utilizzare un server TMG 2010 su cui non vi sono regole di accesso anonimo agli URL di Windows Update, ma solo regole che ne consentono un accesso Autenticato.
Analizzando il file %Windir%\windowsupdate.log la causa dell’errore è appunto la mancata connessione al sito di Microsoft:
AU Triggering AU detection through DetectNow API
AU Triggering Online detection (interactive)
AU #############
AU ## START ## AU: Search for updates
AU #########
AU <<## SUBMITTED ## AU: Search for updates [CallId = {E8F5EF71-CD1C-487A-983A-89EA3F1D8332}]
Agent *************
Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates]
Agent *********
Agent * Online = Yes; Ignore download priority = No
Agent * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"
Agent * ServiceID = {9482F4B4-E343-43B6-B170-9A65BC822C77} Windows Update
Agent * Search Scope = {Machine}
Setup Checking for agent SelfUpdate
Setup Client version: Core: 7.5.7601.17514 Aux: 7.5.7601.17514
Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x801901f6
Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x801901f6
Misc WARNING: DownloadFileInternal failed for http://download.windowsupdate.com/v9/windowsupdate/redir/muv4wuredir.cab: error 0x801901f6
Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x801901f6
Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x801901f6
Misc WARNING: DownloadFileInternal failed for http://download.microsoft.com/v9/windowsupdate/redir/muv4wuredir.cab: error 0x801901f6
Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x801901f6
Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x801901f6
Misc WARNING: DownloadFileInternal failed for http://www.update.microsoft.com/v9/windowsupdate/redir/muv4wuredir.cab: error 0x801901f6
Setup WARNING: SelfUpdate check failed to download package information, error = 0x80244021
Setup FATAL: SelfUpdate check failed, err = 0x80244021
Agent * WARNING: Skipping scan, self-update check returned 0x80244021
Agent * WARNING: Exit code = 0x80244021
Agent *********
Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]
Agent *************
Agent WARNING: WU client failed Searching for update with error 0x80244021
AU >>## RESUMED ## AU: Search for updates [CallId = {E8F5EF71-CD1C-487A-983A-89EA3F1D8332}]
AU # WARNING: Search callback failed, result = 0x80244021
AU # WARNING: Failed to find updates with error code 80244021
AU #########
AU ## END ## AU: Search for updates [CallId = {E8F5EF71-CD1C-487A-983A-89EA3F1D8332}]
AU #############
AU Successfully wrote event for AU health state:0
AU Successfully wrote event for AU health state:0
Report REPORT EVENT: {B548FFE6-7B02-45AF-BA71-FEDEAF0940D8} 2012-04-06 08:06:35:906+0200 1 148 101 {D67661EB-2423-451D-BF5D-13199E37DF28} 1 80244021 SelfUpdate Failure Software Synchronization Windows Update Client failed to detect with error 0x80244021.
Report CWERReporter::HandleEvents - WER report upload completed with status 0x8
Report WER Report sent: 7.5.7601.17514 0x80244021 D67661EB-2423-451D-BF5D-13199E37DF28 Scan 101 Unmanaged
Report CWERReporter finishing event handling. (00000000)
Il motivo è legato al fatto che come detto precedentemente non viene eseguita l’autenticazione al proxy come indicato nella seguente You experience problems when you access the Windows Update Version 6 Web site through a server that is running ISA Server:
Scenario 2
When you visit the Windows Update V6 Web site, you are prompted to select Express Install or Custom Install. When you select either of these options, Windows Update may fail, and you may receive an error message that is similar to the following:
Windows Update has encountered an error and cannot display the requested page.
Additionally, you may see "[Error number: 0x80244021]" or "[Error number: 0x80244019]" or "[Error number: 0x80244018]" in the upper-right corner of the Web page.
To work around the problem that is described in Scenario 2, give anonymous access to the relevant Windows Update sites
Una curiosità se esiste una su ISA o TMG un’Access Rule per i siti di Windows Update per l’utente Administrator di dominio e sul computer non in dominio l’Administrator locale ha la stessa password dell’account Administrator di dominio quando di tenta di eseguire Windows Update verrà richiesta l’autenticazione e specificando le credenziali dell’Administrator di dominio la connessione verrà eseguita con successo.
La problematica si presenta anche su server a dominio eseguendo Windows Update tramite l’account Administrator locale con password diversa dalla password dell’account Administrator di dominio.
Per riuscire ad eseguire Windows Update negli scenari in cui l’autenticazione al proxy fallisce le soluzioni possibili sono due.
La prima soluzione è quella suggerita all’interno della KB ovvero consentire l’accesso anonimo agli URL necessari per utilizzare Windows Update. Con ISA o TMG questo significa però o consentire l’accesso anonimo a tutti gli host interni a Windows Update (soluzione a mio avviso da evitare) oppure gestire una rule di accesso che consenta di accedere a Windows Update solo ai server che necessitano dell’acceso anonimo. Anche quest’ultima configurazione non è però ottimale in quanto comporta la manutenzione della rule ogni volta che viene messo in produzione un server non in dominio, inoltre occorre impostare un IP fisso su tali computer e nel caso l’IP venga modificato occorre intervenire sulla rule di accesso.
La seconda soluzione, a mio avviso più duttile, è quella di creare un account di dominio (xes usrupdates) a cui viene consentito l’accesso agli URL di Windows Update e impostare una password di rete sul server specificando le credenziali di tale utente quando occorre accedere al proxy specificato nelle opzioni di connessioni di Internet Explorer.
In questo modo il computer non dovrà per forza un IP fisso e non sarà necessario eseguire alcuna manutenzione sull’Access Rule nel caso cambino le impostazioni di rete sul server o nel caso vengano messi in produzione altri server fuori dominio che necessitano di accedere a Windows Update.
Io di solito nell’Access Rule consento l’accesso oltre all’utente per gli aggiornamenti (usrupdates) anche all’amministratore di dominio perché in questo modo l’accesso a Windows Update da parte di computer in dominio sarà trasparente se vengono utilizzate le credenziali dell’amministratore di dominio. Ciò può tornare utile ad esempio su computer client quando occorre provare ad installare immediatamente un aggiornamento senza aspettare i tempi di deploy di WSUS oppure quando l’aggiornamento non viene distribuito dalle policy impostate su WSUS e occorre installarlo su pochi Computer.
Per ulteriori informazioni si vedano anche le seguenti KB:
Tuesday, April 03, 2012
In WS8 i ruoli associati agli RDS sono:
- Remote Desktop Session Host
- Remote Desktop Web Access
- Remote Desktop Connection Broker
- Remote Desktop Gateway
- Remote Desktop Licensing
- Remote Desktop Management Service
Come per le versioni precedenti Windows Server per motivi di sicurezza e performance viene raccomando di non far coesistere nello stesso server il ruolo Remote Desktop Session Host e il ruolo Active Directory Domain Services (il tentativi di installare i ruoli sullo stesso server genererà un warning di avviso).
Remote Desktop Management Service (RDMS) rappresenta una novità rispetto a WS2008R2 e si occupa di fornire un’interfaccia utente da cui monitorare e gestire tutti i server dell’infrastruttura RDS, raggruppando quindi in un’unica console il management dei vari ruoli RDS.
RDMS è un plugin del nuovo Server Manager di Windows Server 8 Beta che utilizza un processo di discovery per rilevare i ruoli installati su ogni macchina aggiunta al Server Manager pool. Dopo che è stata eseguita l’installazione di uno scenario RDS e i ruoli sono stati rilevati RDMS visualizza un diagramma della topologia del deployment degli RDS fornendo informazioni di ciascun server (stato di servizio, eventi rilevanti e i risultati del Best Practice Analyzers di ciascun ruolo RDS)
I tool RDS legacy ovvero Remote Desktop Services Manager, Remote Desktop Session Host Configuration e l’interfaccia Connection Manager per configurare il Connection Broker sono stati sostituiti dalla RDMS administration console, quindi tutte le funzioni amministrative che venivano eseguite tramite questi tools in WS8 saranno eseguite tramite il plugin RDMS plugin in Server Manager.
RDMS introduce il concetto di collection, ovvero di gruppo logico di VM o server con il ruolo Remote Desktop Session Host che potranno quindi essere gestiti come unica entità.
Novità relative alle RemoteApp
In Windows 7 sono state introdotte una serie di features sulla shell come il Grouping delle applicazioni, il Pinning, le Jump Lists, le Tabbed Windows, le Progress States e Overlay Icons, ma le RemoteApp in WS2008R2 non erano compatibili con queste features. WS8 aggiunge una maggiore compatibilità delle RemoteApp con le nuove features della Shell.
Pinning: gli utenti possono eseguire il pin delle applicazioni RemoteApp alla taskbar
RemoteApp and Workspace Icons: per permettere agli utenti di indentificare le RemoteApps è stata utilizzata un’icon overlay con il logo Remote Desktop.
Tabbed Windows: le istanze multiple di una RemoteApp sono visualizzate come tabs multipli nella RemoteApp thumbnail preview.
Novità per gestione Disco e Rete
In WS2008R2 era stata introdotta la CPU Fairshare ovvero la capacità di bilanciare il carico della CPU tra le varie sessioni evitando che una sessione con elevate richieste di CPU condizioni le performance delle altre.
In WS8 sono state aggiunte nuove features per il controllo della banda di rete e del disco che sono abilitare per default (come la CPU Fairshare), ma che possono essere disabilitate tramite GPO.
Disk Fairshare
Consente il bilanciamento dell’accesso al disco tra le diverse sessioni RD per evitare che una sessione con elevati accessi penalizzi le altre.
Network Fairshare
Consente il bilanciamento del’utilizzo della banda di rete tra le diverse sessioni RD regolando la larghezza di banda disponibile mediante round-robin.
Novità nella RemoteFx USB redirection
La RemoteFx USB redirection era stata introdotta in WS2008R2 come alternativa alla RDP High-Level Device Redirection, ma era dedicata esclusivamente a scenari VDI.
In WS8 sono state apportate alcune migliorie:
- Non è più richiesto il RemoteFX 3D Video Adapter per avere l’USB redirection
- L’USB redirection è disponibile per le seguenti SKUs:
Come in WS2008R2 se un dispositivo è rediretto tramite RemoteFx in una sessione non potrà essere utilizzato in locale o da sessioni diverse da quella in cui è rediretto (ma va precesato che questa è una limitazione dell’USB e non di RemoteFx USB redirection).
Per poter utizzare l’USB redirection occorre:
- Client con Windows 8 Consumer Preview o Windows 7 SP1 con RDC 8
- Server con Windows Server "8" Beta
User Profile Disks
Fino a WS2008R2 per preservare lo stato dell’utente tra le sessioni RD (o anche su una VM in scenario VDI) venivano utilizzati i roaming profiles e la folder redirection che però presentano alcuni svantaggi:
- Alcune applicazioni scrivono dati al di fuori del profilo utente
- I Roaming profiles e la folder redirection, soprattutto se utilizzati insieme, possono essere di difficile configurazione
- Per poter memorizzare i dati della sessioni in scenari VDI occorre utilizzare personal VM anzichè pooled VM
- I tempo di logon possono aumentare se il profilo utente è caricato tramite la rete
- Se il roaming profile è utilizzato anche al di fuori degli RDS per esempio su una macchina fisica è possibile che si possano verificare delle perdite di dati se il profilo si danneggia e diventa inutilizzabile
In WS8 è possibile configurare lo store dei dati dell’utente e dell’applicazione su un singolo file VHD memorizzato su una share di rete tramite gli User Profile Disks. Volendo è anche possibile utilizzare una soluzione basata sulla combinazione di roaming profiles, folder redirection e User Profile Disks per consentire un controllo granulare di ciò che l’applicazione memorizza in ciascuno dei tre repository
Novità nel Remote Desktop Client e del protocollo RDP
Con W8 verrà rilasciata una nuova versione dell’RDC che supporterà le nuove features del protocollo RDP. W8 contiene sia la versione metro dell’RDC che la versione classica (Win32) ed entrambe contengono le stesse features, la versione classica dell’RDC ha maggiori impostazioni avanzate ed è quindi rivolta ad utenti avanzati, mentre la versione metro dell’RDC è indirizzata agli utenti finali e consente l’utilizzo dei servizi di Remote Desktop tramite l’interfaccia touch.
Automatic Detection of Connection Quality
RDC 8 rileva la qualità della connessione verso un Windows Server "8" Beta server o un Windows 8 Consumer Preview client e imposta automaticamente le features utilizzabili.
Bandwidth Monitoring Display
Quando il client RDP opera in full-screen viene visualizzata la larghezza di banda rilevata sia tramite un’icona che tramite un popup.
Novità nel ruolo Remote Desktop Connection Broker
In WS2008R2 nel deploy degli scenari VDI viene utilizzata Active Directory per memorizzare l’assegnazione utente-macchina virtuale e un RD Connection Broker per gestire l’orchestrazione tra personal e pooled Virtual Desktop e processare le connessioni remote. Questo implica che può esserci un solo RD Connection Broker attivo.
Centralization of Publishing Data
In WS8 per migliorare la scalabilità e semplificare viene utilizzato un database centralizzato che consente a più un RD Connection Broker di essere attivi contemporaneamente questo significa una maggior scalabilità per il VDI.
Il database non sarà più basato su Jet come è stato fino dai tempi di WS2003, ma sarà basato sul componente Windows Internal Database e conterà i dati relativi ai seguenti ruoli:
- Virtual Desktop Infrastructure (VDI)
- Remote Desktop Session Host (RDSH)
- Application Publishing
- RD Gateway
- RD Licensing
Highly Available Connection Broker
Come il Session Directory in WS2003 anche il Remote Desktop Connection Broker in WS2008R2 supporta l’uso del failover clustering per implementare una soluzione ad alta affidabilità presentando però alcuni svantaggi:
- E’ possibile avere un solo brocker attivo contemporaneamente (active/passive configuration)
- L’installazione e la configurazione di Connection Broker in alta affidabilità è un processo complesso che prevede alcuni passaggi manuali a causa della dipendenza dal Failover Clustering (a riguardo si veda Deploying Remote Desktop Connection Broker with High Availability Step-by-Step Guide)
- Il DNS round robin non può conoscere lo stato del servizio Connection Brocker e quindi potrebbe indirizzare gli utenti verso un server non attivo.
In WS8 vi sono le seguenti migliorie:
- Supporto a più Connection Broker attivi contemporaneamente (active/active configuration)
- Semplificazione dell’installazione tramite l’automatizzazione di gran parte della configurazione, inoltre il Failover Clustering non viene più utilizzato
- La possibilità di avere più Connection Broker attivi garantisce che le richiesta dei client siano indirizzate versò Connection Broker funzionanti
Novità nel ruolo Remote Desktop Web Access
Il ruolo RD Web Access in WS8 è stato oggetto di numerose migliorie.
RDWeb Folders
In WS2008R2 le RemoteApp sono filtrate per utenti e gruppi per visualizzare solo quelle assegnate, in ogni caso se le RemoteApp sono molte verranno visualizzate tramite pagine multiple e occorrerà ricorrere allo scroll per trovare l’applicazione in quanto le RemoteApp sono raggruppate solo alfabeticamente.
In WS8 è stata introdotta la possibilità di raggruppare in folder le RemoteApp e di visualizzare sullo Start Screen se ci si connette al feed delle RemoteApp
RDWeb Feed
In WS2008R2 vi sono 4 metodi per pubblicare le RemoteApp verso gli utenti:
- Accedere al RDWeb sul server RD Web Access
- Utilizzare l’RDWeb feed per integrare nello Start Menu le RemoteApp tramite il RemoteApp and Desktop Connections (disponibile in W7 e successivi)
- Utilizzare file MSI per eseguire il deploy di file RDP
- Eseguire il deploy di file RDP tramite Email o SMB share, ma questo è un metodo indicato per piccole infrastrutture in quando non è automatizzabile
In WS8 il deploy tramite MSI non è più supportato inoltre è stato modificato il modo in l’RD Web Access costruisce la pagina web per accedere alle RemoteApp in modo che utilizzi lo stess feed XML che viene utilizzato da RemoteApp and Desktop Connections in questo moso sarà più semplice:
- Aggiungere nuove feature all’RDWeb
- Eseguire il Re-branding del default web site intervenendo solo più sullo style sheet
- Le estensioni di terze parti risultano più semplice e flessibili
Workspace Auto Discovery and Sign Up
In ambiente ES2008R2 con client W7 l’aggiunta di un computer ad un workspace non è un’operazione semplice per l’utente finale, infatti due sono i modi utilizzabili che però comportano entrambi operazioni manuali da parte dell’utente:
- Fornire all’utente un file di setup
- Fornire all’utente un URL che dovrà essere digitato manualmente per impostare la connessione
In WS8 viene introdotta la funzionalità Workspace Auto Discovery and Sign Up che permette all’utente di avere accesso in modo semplice al feed per configurare l’accesso al proprio workspace. Infatti l’utente dovrà conoscere semplicemente il proprio indirizzo mail all’interno dell’infrastruttura aziendale(default smtp proxy address) o in alternativa se il computer è membro dell’Active Directory aziendale sarà possibile configurarne il default workspace tramite Group Policy.
Workspace Single Sign On
SSO è una feature che permette all’utente di digitare le proprie credenziali una sola volta e utilizzarle per autenticarsi automaticamente alle connessioni RDP. In WS2008R2 esistono due forme di SSO:
- Single Sign On (Credentials Delegation richiede che il computer sia membro del dominio)
- Web Single Sign-On (implementato tramite le connessioni RDWeb che non richiede che il computer sia membro del dominio)
Dal punto di vista della User Experience allo stato è necessario digitare più volte le proprie credenziali durante il processo di connessione come ad esempio quando ci si connette all’RD Web Access, all’RD Gateway, all’Redirector (nel caso di VDI o Farm Redirection) o all’RD Session Host (sia RDSH che RDVH Guest).
In WS8 il SSO viene migliorato richiedendo di inserire utente e password una sola volta durante il processo di connessione ed assicurando la sicurezza delle credenziali evitando compromissioni, vengono inoltre evitare multipli popup, warnig, prompts e dialog informative per conntire l’utilizzo delle RemoteApp simile a quello delle applicazioni locali.
In WS2008R2 la configurazione della SSO prevede diversi passaggi e talvolta operazioni complesse in base allo scenario da gestire, in WS8 la configurazione del SSO è stata semplificata.
Novità nel ruolo Remote Desktop Gateway
Il ruolo RD Gateway permette di accedere tramite Internet sfruttando RDP over HTTPS a risorse interne all’infrastruttura quali RD Session Host, RemoteApp, Virtual Desktop.
UDP Protocol Support
In WS8 l’RD Gateway supporta traffico real time su reti ad alta latenza mediante il supporto alla connessioni su UDP, nel caso il client o l’endpoint non supporti l’UDP verrà utilizzato il protocollo HTTP.
Novità nella funzionalità RemoteFx
In WS8 tramite RDP8 si ha l’integrazione di RemoteFx nelle features Remote Desktop senza più richiedere l’installazione di un service role (RemoteFX Integration).
Inoltre mediante la possibilità di utilizzare sia il protocollo TCP che UDP che vengono scelti in modo automatico in base al rilevamento delle condizioni della rete è possibile offrire le funzionalità grafiche di RemoteFx anche su WAN o su WiFi (RemoteFX for WAN). A contribuire ad una migliore dinamicità in base alle condizioni della rete è anche la funzionalità RemoteFX Adaptive Graphics che oltre ad adattare la trasmissione dei dati dinamicamente ottimizza l’encoding sulla base del contenuto da inviare (questo significa ad esempio che in una pagina web l’encoding del testo, delle immagini e dei contenuti multimediale saranno eseguiti con codec specificatamente ottimizzati per ogni tipo di contenuto).
In W7 è stata introdotta un efficiente redirezione dei contenuti multimediali attraverso la fruizione tramite Windows Media Player in sessione remota. In questo scenario il contenuto viene intercettato nella sessione remota inviato in formato compresso tramite RDP al client che lo fruisce locamente tramite WMP. In WS8 grazie alla feature RemoteFX Media Remoting viene utilizzata RemoteFx per usufruire dei contenuti multimediali tramite RDP adattando la trasmissione dati alla rete.
In W8 e WS8 una delle novità è la gestione del MultiTouch che potrà essere utilizzato anche in sessione remota da client W8 (RemoteFX Multi Touch) con la stessa User Experience che si avrebbe in locale. In W7 e WS2008R2 il supporto al MultiTouch in sessione RDP sarà limitato.
Per ulteriori informazioni si vedano:
Le ISO e i file VHD della versione Beta a 64 Bit in 5 lingue (Inglese, Cinese semplificato, Francese, Tedesco e Giapponese) di Windows Server 8 sono disponibili al seguente Download Windows Server "8" Beta.
[Update 01]
I servizi RDS in W8 non hanno requisti software o hardware se non si intende usare RemoteFx, se invece si vuole eseguire il deploy di un RemoteFX server occorre:
- Un processore con supporto alla Second-Level Address Translation (SLAT)
- Una GPU in grado di supportare RemoteFx e DirectX 11