DevAdmin Blog

Eliminazione di directory di grandi dimensioni

Ermanno Goletto — Wed, 12 Jun 2013 14:00:08 GMT

A volte succede di dover eliminare directory di grandi dimensioni e con un gran numero di sotto directory. Si pensi ad esempio al caso in cui occorre eliminare parzialmente dei backup eseguiti su RDX perché si è eseguito una ristrutturazione di directory, o comunque a tutti quei casi in cui non è possibile semplicemente formattare il volume in cui di trovano i file.

In questi casi è possibile cercare di abbreviare i tempi eseguendo un paio di comandi dos:

DEL /F /S /Q PathFolder > nul
RMDIR /S /Q PathFolder

Il primo comando elimina i file dalla cartella e da tutte le sue sottocartelle evitando di fornire l’output video per maggior velocità

Il secondo comando elimina la cartella e tutte le sottocartelle.

L’eliminazione prima dei file nelle cartelle è poi della struttura delle cartelle velocizza il processo di eliminazione rispetto ad eseguire subito l’eliminazione della struttura delle cartelle eseguendo solo il comando RMDIR.

Ovviamente il vantaggio dipende molto dalla grandezza della cartella, dal numero di file e dalla struttura delle sottocartelle.

Qui due test che ho trovato su forum in Internet (per Method 1 si intende l’esecuzione del solo comando RMDIR, mentre per Method 2 l’esecuzione dei due comandi):

Here's the results of a quick time test of a small 5.85 MB of 960 files in 303 folders:

Method 1: 17.5s, 14.9s, 13.9s, 14.8s, 13.8s: average 14.98 seconds
Method 2: 14.3s, 12.1s, 11.7s, 14.2s, 11.8s: average 12.82 seconds

Here's results of another test using 404 MB of 19,521 files in 3,243 folders:

Method 1: 2 minutes 20 seconds
Method 2: 2 minutes 33 seconds

I've retested with much more data, this is a typical case for me: 28.3 GB of 1,159,211 files in 146,918 folders:

Method 1: 2h 15m, 2h 34m: average: 2 hours 25 minutes
Method 2: 49m, 57m: average: 53 minutes

Durata del Tombstone Lifetime

Ermanno Goletto — Wed, 29 May 2013 15:01:33 GMT

Il Tombstone Lifetime viene utilizzato in Active Directory nei seguenti situazioni:

Determinare quando un oggetto può essere eliminato fisicamente. A riguardo si veda How to search for deleted objects in Active Directory.
Determinare il tempo di validità di un backup del system state di un Domain Controller. A riguardo si veda Useful shelf life of a system-state backup of Active Directory.
Determinare il tempo oltre la Replica con un DC che contatta più gli altri DC viene interrotta definitivamente. A riguardo si veda Replication error 8614 The Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime

La durata del Tombstone Lifetime (TSL) dipende dalla versione del sistema operativo del primo DC che è stato installato nella foresta Active Directory:

OS primo DC nella foresta	Default tombstone lifetime
Windows 2000	60 giorni
Windows Server 2003	60 giorni
Windows Server 2003 SP1	180 giorni
Windows Server 2003 SP2	180 giorni
Windows Server 2003 R2	60 giorni
Windows Server 2003 R2 SP2	180 giorni
Windows Server 2008 e successivi	180 giorni

E’ possibile trovare i riferimenti ai valori di default del TSL nei seguenti:

Come detto precedentemente la durata del TSL è determinata dal dalla versione del sistema operativo del primo DC che è stato installato nella foresta Active Directory, questo significa che anche aggiornando tale DC ad una versione successiva il TSL non viene modificato come specificato in Useful shelf life of a system-state backup of Active Directory:

“Windows Server 2003 Service Pack 1 (SP1) increases the attribute value from 60 to 180 days in the following scenarios:

You use Windows Server 2003 SP1 slipstreamed media to upgrade a Microsoft Windows NT 4.0 domain to a Windows Server 2003 domain. When you perform the upgrade, you create a new forest.

You promote a computer that is running Windows Server 2003 SP1 to a domain controller. When you promote the domain controller, you create a new forest.

The original release version of Windows Server 2003 SP1 does not modify the value of the tombstone lifetime attribute when the following conditions are true:

You upgrade a Windows 2000 domain to a Windows Server 2003 domain by using Windows Server 2003 SP1 slipstreamed media.

You install Windows Server 2003 SP1 on domain controllers that are running the original release version of Windows Server 2003.”

Questo significa che se la foresta Active Directory era stata creata con DC che aveva un versione di OS in cui il TLS per default era a 60 giorni se non si interviene manualmente continuerà ad essere tale anche se si aggiornano tutti i DC nella foresta ad una versione di OS che prevede una durata del TSL di 180 giorni.

Il TSL è determinato dall’attributo tombstoneLifetime che se non impostato ha il valore di default di 60 giorni. Per la precisione il tombstoneLifetime è un attributo dell’ogetto Directory Service nella partizione di configurazione che è comune a tutti i domini della foresta.

Per determinare la durata del TSL è possibile utilizzare ADSI Edit oppure dsquery come indicato nel seguente Determine the tombstone lifetime for the forest oppure usare PowerShell:

(get-adobject "cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=sysadmin,DC=local" –properties "tombstonelifetime").tombstonelifetime

Per modificare il TSL è possibile usare ADSI Edit oppure PowerShell a rigurado si veda Modifying the Tombstone Lifetime for a Domain

Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Fabrikam,DC=COM" -Partition "CN=Configuration,DC=sysadmin,DC=local" -Replace @{tombstoneLifetime='210'}

Per ulteriori approfondimenti si vedano anche:

Windows Server 2012: Forzare un aggiornamento remoto di Criteri di gruppo

Ermanno Goletto — Sun, 26 May 2013 22:11:39 GMT

A partire da Windows 2003 e XP tramite GPUpdate.exe è possibile forzare l’applicazione delle Group Policy Computer e Utente sia sul computer locale che su di un computer remoto. Per i dettagli si veda Refresh Group Policy settings with GPUpdate.exe (in Windows 2000 era disponibile il comamando secedit con l’opzione refreshpolicy):

Gpupdate [/target:{computer|user}] [/force] [/wait:value] [/logoff] [/boot]

Applicazioni delle GPO sul computer locale:
gpupdate

Applicazione forzata delle GPO (ignora i processi di ottimizzazione e riapplica tutte le GPO) attendendo 100 secondi per il processamento delle GPO:
gpupdate /force /wait:100

Applicazioni delle GPO su un computer remoto:
gpupdate /target:computer

Applicazioni delle GPO sul computer locale e riavvio del sistema al termine del processamento delle GPO:
gpupdate /boot

Di seguito alcune precisazioni sui parametri di GPUpdate:

/Wait:{valore}

Questa opzione consente di impostare l'intervallo di attesa in secondi prima che l'elaborazione dei criteri venga completata. Il valore predefinito è 600 secondi. Il valore zero (0) significa che non occorre attendere il completamento dell'elaborazione. Il valore -1 significa che occorre attendere a tempo indeterminato. Quando viene superato il limite impostato, ritorna attivo il prompt dei comandi, ma l'elaborazione dei criteri continua.

/Boot

Questa opzione può causare il riavvio del computer dopo l'aggiornamento delle impostazioni dei Criteri di gruppo. Si tratta di una funzionalità necessaria per quelle estensioni dei Criteri di gruppo per i client che non elaborano i criteri con cicli di aggiornamento in background, ma eseguono questa operazione all'avvio. Un esempio di questo comportamento può essere osservato con la funzionalità rivolta al computer Installazione software. Questa opzione non ha effetto se non sono state richiamate estensioni che richiedono il riavvio del computer.

/Force

Questa opzione consente di applicare di nuovo tutte le impostazioni dei criteri. Per impostazione predefinita, vengono applicate solo le impostazioni dei criteri che sono state modificate.

(Fonte KB 298444 A Description of the Group Policy Update Utility)

La novità introdotta con Windows Server 2012 è la possibilità di aggiornare in remoto le impostazioni di Criteri di gruppo per tutti i computer di un'unità organizzativa tramite la Group Policy Management Console (gpmc.msc). In alternativa è possibile utilizzare il cmdlet PowerShell Invoke-GPUpdate mediante cui è possibile gestire un elenco di computer non limitato ad una unità organizzativa.

Quando si seleziona un'unità organizzativa (OU) per aggiornare in remoto le GPO sui i computer di tale OU saranno eseguite le seguenti operazioni:

Una query di Active Directory per ottenere i computer appartenenti all'OU.
Su ogni computer appartenente all'OU vie eseguita una chiamata WMI per recuperare l'elenco degli utenti connessi.
Viene creata un'attività pianificata remota per eseguire Gpupdate.exe /force per ogni utente connesso e una volta per l'aggiornamento delle GPO computer. L'esecuzione dell'attività viene pianificata con un ritardo casuale di un massimo di 10 minuti per ridurre il carico sul traffico di rete. Non è possibile configurare il tale ritardo casuale mediante la Group Policy Management Console (GPMC), ma solo creando l’attività pianificata con il cmdlet Invoke-GPUpdate oppure modificando direttamente l’attività pianificata.

Di seguito i prerequisiti per forzare le GPO remotamente impostando un’attività pianifica:

La configurazione può essere utilizzando solo tramite la GPMC in Windows Server 2012 o Windows 8 con Strumenti di amministrazione remota del server (RSAT)
È possibile pianificare un aggiornamento remoto delle GPO sui computer con i seguenti sistemi operativi:

Windows Server 2012, Windows Server 2008 R2, Windows Server 2008
Windows 8, Windows 7, Windows Vista

E’ necessario che sui client siano configurate le seguenti regole in entrata del firewall:

Gestione remota attività pianificate (RPC) (porte dinamiche RPC TCP per il servizio Utilità di pianificazione)
Gestione remota attività pianificate (RPC-EPMAP) (porta TCP 135 per servizio Remote Procedure Call RPCSS)
Strumentazione gestione Windows (WMI-in) (tutte le porte TCP per il servizio Strumentazione gestione Windows Winmgmt)

Per semplificare la configurazione delle regole del firewall sui client in WS2012 è stata introdotta la Starter GPO Group Policy Remote Update Firewall Ports (Porte firewall aggiornamento remoto Criteri di gruppo). Come best practices viene consigliato di creare una nuova GPO mediante questa Starter GPO e collegare la GPO al dominio, con precedenza maggiore rispetto alla Default Domain GPO in modo da impostare tutti i computer del dominio per consentire il traffico di rete necessario alla configurazione dell’aggiornamento remoto di Criteri di gruppo.

E’ possibile creare creare una GPO a partire da una Starter GPO anche mediante i cmdlets New-GPO e New-GPLink.

Come detto precedentemente se è necessaria una flessibilità maggiore per la configurazione dell’aggiornamento remoto di Criteri di gruppo è possibile utilizzare il cmdlet Invoke-GPUpdate che permette eseguire la configurazione non solo su una specifica OU e la modifica del ritardo casuale, di seguito alcuni esempi:

Configurazione dell’aggiornamento remoto di Criteri di gruppo su tutti computer del dominio:
Get-ADComputer –filter * -Searchbase "cn=computers, dc=Contoso,dc=com" | foreach{ Invoke-GPUpdate -computer $_.name -force}

Configurazione dell’aggiornamento remoto di Criteri di gruppo su tutti computer di un OU con ritardo casuale di 5 minuti:
Get-ADComputer –filter * -Searchbase "ou=Accounting, dc=Contoso,dc=com" | foreach{ Invoke-GPUpdate -computer $_.name -force -RandomDelayInMinutes 5}

Per ulteriori informazioni si vedano:

XP SP3: Security Essentials non rilevato dal Centro di sicurezza PC

Ermanno Goletto — Fri, 24 May 2013 15:17:57 GMT

Questo sembra essere un problema che capita spesso leggendo i vari forum su Internet, ed è successo anche a me di vederlo di tanto in tanto. In questo post cercherò di riportare i motivi e le possibili soluzioni a questo issue.

Risorse hardware insufficienti

Microsoft Security Essentials (MSE) ha requisiti decisamente bassi come si può vedere dal segunete Downloading and Installing Microsoft Security Essentials:

For Windows XP, a PC with a CPU clock speed of 500 MHz or higher, and 256 MB RAM or higher.

Per esperienza ho notato che il processo di MSE (MsMpEng.exe) all’avvio può occupare più memoria soprattutto se esegue il controllo della presenza di firme aggiornate da scaricare. Questo su sistemi con il minimo della memoria richiesta può causare uno swap che rallenta la comunicazione di MSE col Centro di sicurezza PC col risultato di vedere il messaggio che non è stato rilevato un antivirus.

Ovviamente poi occorre disinstallare eventuali altri software antivirus in quando oltre ad avere un degrado delle performance si corre anche il rischio che i software interferiscano tra loro col risultato di essere meno efficaci (a riguardo si veda Does Microsoft Security Essentials work with other antivirus software?).

Eliminazione della cartella %SystemRoot%\System32\wbem\Repository

L’eliminazione di questa cartella può essere un primo tentativo di risolvere il problema se si è corrotto il database delle meta-informazioni e delle definizioni delle classi WMI.

Per eseguire tale operazione conviene seguire la procedura illustrata nel post WMI: Rebuilding the WMI Repository dell’EPS Windows Server Performance Team che nel caso di Windows XP significa eseguire un un file batch contenete i seguenti comandi:

sc config winmgmt start= disabled
net stop winmgmt /y
%systemdrive%
cd %windir%\system32\wbem
for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s
wmiprvse /regserver
winmgmt /regserver
sc config winmgmt start= auto
net start winmgmt
for /f %%s in ('dir /s /b *.mof *.mfl') do mofcomp %%s

(come riportato nel post WMI: Rebuilding the WMI Repository nel caso di sistemi operativi diversi da Windows XP occorre eseguire ancora altre operazioni)

Terminata l’esecuzione del file batch riavviare il computer un paio di volte.

Riesecuzione della registrazione delle DLL di MSE

Un’altro tentativo può essere quello di eseguire nuovamente la registrazione delle dll di MSE nel caso qualcosa si sia verificato qualche problema durante l’installazione tramite i comandi:

REGSVR32 WUPS2.DLL /S
REGSVR32 WUPS.DLL /S

Impostazione avvio ritardato del Security Center

Su Windows Vista è stato introdotta la possibilità di avviare i servizi solo quando il sistema è avviato impostando l’avvio come Automatic (Delayed). Sui sistemi precedenti a Windows Vista è possibile utilizzare l’approccio descritto nella KB193888: How to delay loading of specific services.

Impostare il servizio relativo al Centro di sicurezza PC con l’avvio ritardato può in certi casi risolvere il problema soprattutto su macchine con scarse risorse hardware.

DHCP evoluzione e problemi noti

Ermanno Goletto — Wed, 22 May 2013 13:37:17 GMT

Evoluzione del servizio DHCP

Il servizio DHCP ha subito nel corso degli anni varie evoluzioni che hanno portato una serie di nuove funzionalità estremante utili per un servizio chiave dell’infrastruttura aziendale. Infatti è fondamentale strutturare la gestione del DHCP in ottica di fault tollerance e scalabiltà futura ragionando sulla base della criticità e dell’evoluzione futura della propria rete aziendale.

Di seguito i link su cui trovare le nuove features introdotte dalle varie versioni del sistema operativo server:

Sistema Operativo	Nuove funzionalità	Link
Windows Server 2000	Enhanced performance monitoring and server reporting capabilities Expanded support for multicast scopes and superscopes Support for user-specific and vendor-specific DHCP options Integration of DHCP with DNS Rogue DHCP server detection Dynamic support for BOOTP clients Read-only console access to DHCP Manager	New Features
Windows Server 2003	DHCP client alternate configuration DHCP database backup and restore	New features for DHCP
Windows Server 2008	Dynamic Host Configuration Protocol for IPv6 (DHCPv6) support Network Access Protection enforcement support	New Networking Features in Windows Server 2008 and Windows Vista
Windows Server 2008 R2	MAC addressing filtering for DHCP leases DHCP name protection Supports prevention of exhaustion of IP addresses at scope level DHCP logging enhancements Supports migration of DHCP Server role using Windows Server Migration Tool (WSMT) DHCP Server service is moved under Network Service account from Local Service account Generate link layer address filtering lists from current leases Create reservations from current leases Create new DHCP options that apply only to reservations Integration with NAP DHCP Split Scope Wizard Delayed DHCP Server Response Setting	New features in DHCP for Windows Server 2008 R2 / Windows 7 Windows Server 2008 R2 Improvements in DHCP (Part 1)
Windows Server 2012	DHCP failover Policy based assignment Windows PowerShell for DHCP Server	What's New in DHCP

Per ulteriori approfondimenti si vedano anche i seguenti:

Issues e problemi noti del servizio DHCP

Il servizio DCHP e il client DHCP dal momento che si interfacciano con vari aspetti dell’infrastruttura sono stati spesso oggetto di correzioni e KB, quindi risulta necessario assicurarsi che i server e client ricevano gli aggiornamenti critici e di sicurezza. Inoltre è possibile consultare le KB relative al servizio DHCP al seguente http://search.microsoft.com/en-us/supportresults.aspx?form=mssupport&q=DHCP.

Di seguito ho raccolto alcuni problemi noti che possono verificarsi con l’uso del DHCP raccolti sulla base di esperienze personali e delle domande più ricorrenti sui forum di Sysadmin.it.

Perdita delle impostazioni DNS sulle reservation in WS2008R2 o WS2012

La problematica è discussa nella KB2782558: DNS settings of a DHCP reservation revert to the settings at the scope level in Windows Server 2008 R2 and Windows Server 2012.

Per risolvere l’issue è disponibile un hotfix scaricabile dal link della KB.

Duplicazione dei lease durante la clonazione del Domain Controller virtuali in WS2012

La problematica è discussa nella KB2742836: Two DHCP leases are created for each domain controller when you use the VDC cloning feature.

Questo issue non è un problema, ma la consegueza del fatto che il DC viene installato e clonato in periodo di tempo inferiore alla durata del lease può accadere quanto segue:

Quando il DC viene installato ottiene un lease DHCP
Successivamente viene impostato un IP fisso per poter aggiungere il ruolo AD DS
Se il DC viene usato per generare un DC clonato nella fase di inizializzazione richiede un lease DHCP e gli viene fornito lo stesso del DC sorgente nel caso no sia ancora scaduto

Per risolvere il problema basta rimuovere manualmente i lease relativi ai Domain Controller.

Mancato rinnovo del lease dopo Sleep o Hybernate in W7 Sp1 o WS2008R2 SP1

La problematica è discussa nella KB2393659: A DHCP client computer that has multiple network adapters and that is running Windows 7 or Windows Server 2008 R2 cannot renew a DHCP lease when the computer wakes

La KB risolve un problema di mancato rinnovo del lease DHCP su computer con più schede di rete quando riprende la sua funzionalità dopo uno Sleep o un Hibernate

Rifiuto del lease DCHP in W7 SP1 o WS2008R2 SP1

La problematica è discussa nella KB 2824546: Incorrect DHCP packet is sent when DHCP client receives a DHCP offer on a Windows 7 SP1-based or Windows Server 2008 R2 SP1-based computer

Il problema causato dall'installazione della KB 2393659 che potrebbe non essere compatibile con software di terze parti di gestione della rete con la conseguenza che il DHCP Client usa lo stesso buffer per inviare e ricevere pacchetti, il risultato è che il client rifiuta il pacchetto perché lo vede provenire da un server DHCP con IP 0.0.0.0 che considera come non autorizzato

Perdita del lease al riavvio in Windows Vista, WS2008, W7 o WS 2008 R2

La problematica è discussa nella KB 958336: A computer loses its DHCP IP address if a DHCP server is not available in Windows 7 or Windows Vista.

La perdita del lease si verifica quando il computer si avvia il DHCP server non è disponibile il lease DHCP non viene mantenuto e viene assegnato IP sul range APIPA (Automatic Private IP Addressing), per risolvere il problema è possibile eseguire una modifica sul registro del sistema:

Su Windows 7 / Windows Server 2008 R2 è possibile impostare a 1 la chiave DWORD
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DontPingGateway
Su Windows Vista / Windows Server 2008 è possibile impostare a 1 la chiave DWORD
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<Adapter>\DontPingGateway

Per approfondimenti su questo problema si veda il post Client Windows Vista e Windows 7 potrebbero rimanere senza indirizzo IP se il DHCP server è indisponibile.

Mancata impostazione del default gateway

La problematica è discussa in questo post Windows server 2003 e 2008 - DHCP client possono non ottenere correttamente settings del default gateway.

Il problema si verifica negli scope con State pari a 3 ovvero in modalità Switched, i possibili stati di uno scope sono:

0 - Deactivates the scope
1 - Activates the scope (default)
2 - Deactivates the scope and marks the scope as "Switched"
3 - Activates the scope and marks the scope as "Switched"

Va però tenuto presente che by design, Windows non assegna nessun default gateway alle reti di tipo “Switched”, in quanto a livello teorico per tali reti è impossibile definire un default gateway univoco. A riguardo di veda anche Netsh commands for DHCP.

Memory leak nel caso in cui il DNS dynamic protocol sia abilitato su un WS2003 con il servzio DHCP attivo

La problematica è discussa nella KB 939928: A memory leak occurs if the DNS dynamic update protocol is enabled on a DHCP server that is running Windows Server 2003.

La soluzione può essere quella di schedulare un riavvio del servizio DHCP, per approfondimenti si vedano:

Virtual Server 2005 R2 Sp1 errori 7022 e 7001 all’avvio

Ermanno Goletto — Fri, 17 May 2013 09:06:52 GMT

Se Virtual Server R2 2005 Sp1 non si avvia riportano i seguenti errori:

Tipo evento: Errore
Origine evento: Service Control Manager
Categoria evento: Nessuno
ID evento: 7022
Descrizione:
Servizio Servizio di assistenza macchina virtuale bloccato in partenza.

Tipo evento:    Errore
Origine evento:    Service Control Manager
Categoria evento:    Nessuno
ID evento:    7001
Descrizione:
Il servizio Virtual Server dipende dal servizio Servizio di assistenza macchina virtuale che non è stato avviato per il seguente errore:
Dopo l'avvio, il servizio si è sospeso in uno stato di attesa.

Il motivo può essere dovuto al cambio dell’indirizzo IP sulla scheda di rete che viene usata per Rete Esterna per risolvere è possibile eliminare e ricreare la Rete Esterna, operazione decisamente semplice tramite VMRCplus.

Per altre informazioni su errori che possono provare il mancato avvio o l’interruzione del servizio di Virtual Server 2005 R2 si veda anche la KB 941125: The Virtual Server service may stop responding when the service is starting if one or more of the virtual machines are configured to automatically start when the Virtual Server service starts.

Windows 2003 e Microsoft Update in loop

Ermanno Goletto — Wed, 15 May 2013 20:13:07 GMT

Oggi ho dovuto installare un Windows Server 2003, terminata l’installazione come da manuale ho provveduto a scaricare gli aggiornamenti e per farlo ho usato come sempre Microsoft Update ovvero la versione aggiornata del sito di update di Microsoft.

Windows Server 2003 per default utilizza invece ancora Windows Update, per passare a Microsoft Update occorre selezionare l’opzione relativa dopo aver avviato Windows Update e installare l’ActiveX relativo (MUWebControl Class in Wuweb.dll).

Il problema è che però dopo l’attivazione di Microsoft Update invece di proporre come di consueto la selezione tra l’esecuzione dell’update in modalità Rapido o Personalizzato la pagina web continuava a riproporre la fase “Ricerca dell’ultima versione del software di aggiornamento per Windows nel computer in uso…”

Tornando invece tramite l’opzione Cambia impostazioni ad utilizzare Windows Update gli aggiornamenti venivano invece rilevati, scaricati e installati correttamente.

Quindi senza dubbio era andato storto qualcosa durante l’installazione dell’ActiveX di Microsoft Update.

Per risolvere ho avviato Internet Explorer in modalità senza componenti aggiuntivi tramite Start –> Tutti i programmi –> Accessori –> Utilità di sistema –> Internet Explorer (nessun componente aggiuntivo) (in alternativa è possibile eseguire il comando iexplore.exe –extoff).

Quindi ho selezionato l’opzione per controllare la disponibilità di aggiornamenti di Windows

A questo punto è stata riproposta l’opzione di scaricare nuovamente l’ActiveX di Microsoft Update

Terminata l’installazione dell’ActiveX Microsoft Update ha ripreso a funzionare correttamente.

Un metodo alternativo (che però non ho testato) potrebbe essere quello di scaricare l’ultimo Windows Update Agent dal seguente Information for network administrators about how to obtain the latest Windows Update Agent, l’ultima versione al momento disponibile dovrebbe essere la 7.4.7600.226 (a riguardo si veda How to get the latest version of the Windows Update Agent) e di reinstallarlo tramite il comando per sistemi operativi a 32 bit:

WindowsUpdateAgent30-x86.exe /wuforce

Oppure il seguente per sistemi operativi a 64 bit:

WindowsUpdateAgent30-x64.exe /wuforce

Per ulteriori informazioni si veda la seguente KB How do I reset Windows Update components? che illustra come resettare la funzionalità di aggiornamento di Windows e propone anche un tool per l’esecuzione automatica delle correzioni.

Inoltre per problemi legati agli aggiornamenti in generale si vedano anche i seguenti:

Skype: disabilitazione invio e ricezione file

Ermanno Goletto — Tue, 07 May 2013 12:55:32 GMT

In questi giorni si sta diffondendo tramite Skype un malware mediante lo scambio dei file o l’invio di file o di link che poi scaricano un malware.

Un malware che va per la maggiore è quello descritto nel post Virus Mal/DorkLnk-A di Mario Serra di seguito un altro paio di post a tema:

Se la fonte dell’infezione è un link la sicurezza viene demandata all’antivirus lato client e lato firewall, soprattutto quest’ultimo può intervenire bloccando il link perché appartenente a categoria vietate, perché proviene da un’origine segnalata come malevola o applicando l’analisi antimalware sul file richiesto.

Quello che si può fare lato skype se l’infezione viene propagata scambiando file è quello di bloccare il trasferimento file.

E’ possibile farlo usando le policies di Skype che non sono altro che impostazioni di registro nelle chiavi:

HKLM\Software\Policies\Skype\Phone per impostazioni a livello di computer
HKCU\Software\Policies\Skype\Phone per impostazioni a livello utente

Le policies sono descritte nella IT Administrators Guide in particolare per disabilitare il Trasferimento file a livello di computer è possibile impostare a 1 la chiave REG_DWORD

HKLM\Software\Policies\Skype\Phone\DisableFileTransferPolicy

Volendo è disponibile un file adm per gestire le impostazioni tramite GPO che può essere scaricato al seguente http://download.skype.com/share/security/Skype-v1.7.adm

Leggendo questi post pare non sia mai stato rilasciato un adm più recente dell’1.7:

In alternativa è possibile anche gestire l’impostazione tramite uno script di Avvio Computer sempre configurato tramite GPO che esegua il seguente comando:

REM Aggiunta registry Key per disabilitazione File Transfert con Skype
reg query "HKLM\Software\Policies\Skype\Phone" /v DisableFileTransfer
IF ERRORLEVEL 1 reg add "HKLM\Software\Policies\Skype\Phone" /v DisableFileTransfer /t REG_DWORD /d 1

Ho testato questa seconda soluzione su macchine XP SP3 32 bit e Windows 7 Sp1 a 64 Bit.

Volendo è anche possibile distribuire tale impostazione mediante le Group Policies Preferences.

Windows Server 2012: errore durante l’installazione del .NET Framework 3.5

Ermanno Goletto — Wed, 01 May 2013 22:40:21 GMT

Tra le funzionalità di Windows Server 2012 vi è la possibilità di installare il .NET Framework 3.5, ma va precisato che tale funzionalità non viene integrata nel sistema durante l’installazione (al contrario ad esempio del .NET Framework 4.5).

Infatti se tentiamo l’installazione e il computer non ha una connessione a Internet questa fallirà e nei registri relativi al Setup verrà registrato l’evento d’informazione:

Log Name:      Setup
Event ID:      11
Task Category: (1)
Level:         Information
Description:
Update NetFx3 of package Microsoft .NET Framework 3.0 failed to be turned on. Status: 0x800f0906.

In sostanza con Windows 8 e Windows 2012 è stato introdotto il concetto di Features on Demand per risparmiare spazio su disco, in sostanza alcune features tra cui il .NET Framework 3.5 richiedono di essere scaricate da Internet o di avere il media d’installazione per essere installate.

Dal seguente Configure Features on Demand in Windows Server:

Features on Demand is a new feature in Windows® 8 and Windows Server 2012 that allows you to remove role and feature files (sometimes called feature payload) from the operating system to conserve disk space, and install roles and features from remote locations or installation media instead of from local computers. You can remove feature files from running physical or virtual computers. You can also add feature files to or remove feature files from Windows image (WIM) files or offline virtual hard disks (VHDs) to create a reproducible copy of Windows 8 and Windows Server 2012 Features on Demand configurations.

In a Features on Demand configuration, when feature files are not available on a computer, if an installation requires those feature files, Windows Server 2012 can be directed to get the files from a side-by-side feature store (a shared folder that contains feature files, and is available to the computer on the network), from Windows Update, or from installation media. By default, when feature files are not available on the target server, Features on Demand searches for missing feature files by performing the following tasks, in the order shown.

Searching in a location that has been specified by users of the Add Roles and Features Wizard or DISM installation commands

Evaluating the configuration of the Group Policy setting, Computer Configuration\Administrative Templates\System\Specify settings for optional component installation and component repair

Searching Windows Update

In ogni caso come detto è possibile specificare una sorgente per i file d’installazione (come indicato nel tooltip giallo) selezionando la voce Specify an alternate source path.

Se si desidera utilizzare il media d’installazione è possibile specificare il path <DVD drive>:\sources\sxs

Per ulteriori informazioni si vedano:

Windows Server 2012: Hyper-V e Ibernazione

Ermanno Goletto — Wed, 01 May 2013 21:35:23 GMT

Con Windows 8 è stato introdotta la possibilità di usare Hyper-V anche su OS Client grazie alla funzionalità Client Hyper-V (a riguardo si veda il mio post Windows 8 e Client Hyper-V). Sebbene Client Hyper-V abbia qualche limitazione rispetto alla versione di Hyper-V contenuta in Windows Server 2012 ha però anche qualche feature in più come ad esempio la possibilità di usare le reti Wireless e l’integrazionei con le funzionlità di Standby e Ibernazione che possono tornare utili su un laptop.

Dal seguente Client Hyper-V:

“With Client Hyper-V, you can use Hyper-V virtualization with both wireless network adapters and sleep states on your desktop computer. For example, if you are running Client Hyper-V on a laptop and close the lid, the virtual machines that are running will be put into a saved state, and resumed when the machine wakes.”

Se però avete la necessità come me di avere Windows Server 2012 su un laptop potete ricorrere ad un workaroud che poteva già essere utilizzato con WS2008 per poter utilizzare Standby e Ibernazione e che è stato descritto in questo post Hibernate and Sleep with Hyper-V Role Enabled.

L’idea è quella di modificare l’avvio del servizio hvboot tramite la seguente procedura:

Aggiungere la chiave di registro HKLM\SYSTEM\CurrentControlSet\Services\hvboot

Quindi aggiungere il valore DWORD Start in HKLM\SYSTEM\CurrentControlSet\Services\hvboot e impostarlo al valore 3 (0=Boot, 1=System, 2=Auto, 3=Demand, 4=Disabled)

In alternativa è possibile eseguire il comando sc config hvboot start= demand

Riavviare il computer

Dopo aver impostato il servizio hvboot ad avviarsi su richiesta sarà possibile utilizzare Sleep e Ibernazione quando non sarà avviato, sarà poi possibile avviare se necessario il servizio per utilizzare Hyper-V tramite il comando net start hvboot. Ovviamente quando il servizio hvboot sarà in esecuzione Sleep e Ibernazione non saranno più disponibili.

Per abilitare l’ibernazione è possibile usare il comando powercfg.exe /hibernate on inoltre è possibile avviare l’ibernazione con il comando shutdown –h.

Per ulteriori informazioni si vedano: