Ivan Salvade’

Il mio punto di vista su Virtualizzazione, Sicurezza, Messaggistica, Network Management…

  • Ivan

    248418_467427256623661_1655875885_n.jpg
  • Abbonati

  •  

    novembre 2017
    L M M G V S D
    « gen    
     12345
    6789101112
    13141516171819
    20212223242526
    27282930  
  • Tag Cloud

Il Windows 7 USB/DVD Download Tool

Scritto da Ivan Salvade' il 18 marzo 2012

Vi segnalo oggi un comodo strumento gratuito di Microsoft, che esiste da parecchio tempo ma non è conosciuto più di tanto : il “Windows 7 USB/DVD Download Tool”.

Ci permette di trasformare un file .ISO contenente Windows 7 in un DVD o una chiavetta USB di installazione.

Ovviamente l’operazione è fattibile anche con software di terze parti, ma perchè non utilizzare ciò che abbiamo già in casa, e gratuitamente?

Vedo l’utilità dello strumento soprattutto al giorno d’oggi, quando moltissimi prodotti software ci vengono fatti scaricare proprio in formato ISO, ivi compresi i sistemi operativi Microsoft.  E spesso non vogliamo sprecare un DVD-R per masterizzare qualcosa che, magari, non vogliamo mantenere ma solo testare.  Infatti, secondo me,  l’utilità maggiore è proprio la possibiltà di poter creare un supporto USB autoavviante di installazione di un sistema operativo, che in qualunque momento possiamo poi cancellare quando non serve più.

Il “Windows 7 USB/DVD Download Tool” è scaricabile dal Microsoft Store al seguente link :

http://www.microsoftstore.com/store/msstore/html/pbPage.Help_Win7_usbdvd_dwnTool

E’ un piccolo eseguibile di 2,6 Mb.  Può essere installato su Windows XP SP2, Windows Vista, Windows 7 32 o 64 bit, e richiede la presenza del .NET Framework almeno 2.0 (e anche, per i possessori di XP, della “Microsoft Image Mastering API v2).

Se vogliamo trasformare l’ISO in USB, è necessaria una chiavetta USB con almeno 4 GB di spazio.  La chiavetta verrà formattata dallo strumento, quindi bisognerà salvare a parte eventuali dati contenuti in essa.

Il tool deve essere prima installato :

img0004180000.jpg

img0005220000.jpg

img0007430000.jpg

Ora si può lanciare il semplice wizard, dopo essersi dotato del file ISO di un Windows 7 :

img0008360000.jpg

Si può scegliere tra il trasferimento su USB o su DVD :

img0009310000.jpg

La chiavetta USB deve essere grande almeno 4 GB :

img0012470000.jpg

Si viene ampiamente avvisati dell’esecuzione della formattazione :

img0013050000.jpg

img0013230000.jpg

La chiavetta verrà formattata e resa autoavviante :

img0014100000.jpg

img0021140000.jpg

img0027090000.jpg

Ora, da BIOS, attivate il boot da USB sul vostro computer e procedete all’installazione di Windows 7.

Buon divertimento :-)

  • Share/Bookmark

Pubblicato in Windows 7 | Nessun commento »

La potenza dello Startup Repair di Windows 7

Scritto da Ivan Salvade' il 22 novembre 2011

Vi segnalo un particolare problema avuto su un’installazione Windows 7, risolto egregiamente e velocemente grazie allo Startup Repair di Windows 7.

La configurazione del computer era la seguente :

  • Windows 7 Ultimate 64 bit
  • Scheda madre ASUS P5E WS Professional
  • 2 dischi fisici da 1 Tb l’uno collegati a controller SATA
  • I due dischi erano settati nel BIOS in configurazione RAID
  • Tramite la ROM Utility della scheda madre “Intel Matrix Storage Manager”, erano stati creati sui due dischi i seguenti volumi :
    • RAID 1 (Mirror) da 275 Gb
    • RAID 0 (Stripe) da 1,3 Tb circa
  •  Sul volume RAID1, in Windows 7 erano state create le seguenti partizioni :
    • C:  (partizione di avvio di Windows 7)
    • D:  (partizione di avvio di Windows Server 2008 R2, in dual-boot)
    • E:  (partizione per dati importanti)
  •  Sul volume RAID 0, in Windows 7 era stata creata un’unica partizione F: (partizione per dati non importanti) che occupava l’intero volume

Per motivi imprecisati, durante un boot del computer il BIOS si era resettato ai suoi valori di default.  In particolare, la configurazione dei dischi si era impostata su IDE.

Al primo reboot dopo il reset, Windows 7 si è accorto della mancanza del settaggio “RAID” nel BIOS, ed ha caricato tutti i driver IDE per “vedere” la nuova configurazione dei dischi senza RAID.  A questo punto, in Gestione Disco, erano visualizzabili i due dischi fisici IDE (non più i due RAID precedenti), aventi la stessa “Signature”: in entrambi i dischi erano visibili le precedenti partizioni C: D: E: , perfettamente speculari, mentre era scomparsa la partizione F: precedentemente presente sul RAID 0.

Il tentativo di re-impostazione, nel BIOS, del settaggio “RAID” nella configurazione SATA dei dischi, provocava la completa mancata partenza di Windows 7, con errori del tipo :

BOOTMGR is missing

Disk Read Error

Ciò era dovuto al fatto che l’ambiente di boot di Windows 7 si era ormai configurato per eseguire l’avvio da dischi in modalità IDE piuttosto che dal volume di Mirror.  Fortunatamente, però, Windows 7 mantiene in questo caso anche la precedente configurazione di partenza, localizzabile alla seguente chiave di registro :

HKLM\System\CurrentControlSet\Enum\IDE

E’ sufficiente reimpostare l’ambiente di boot a riutilizzare il volume Mirror dichiarato in questa chiave di registro, per ottenere l’avvio corretto di Windows 7.  Senza lo Startup Repair di Windows, sarebbero necessari passaggi complessi.  Invece, in questo caso la procedura è semplice, e consiste nei seguenti passi :

  1. Se non è mai stato fatto un backup, rimettere “IDE” nella configurazione SATA dei dischi nel BIOS, riavviare Windows 7 ed eseguire un backup completo di tutta la macchina (almeno i vostri dati importanti e un’immagine del sistema). NON FIDATEVI A RIMANERE SENZA BACKUP!!  La procedura seguente, nel mio caso, ha funzionato, ma potrebbe non funzionare per voi, e potreste veramente rischiare di perdete dati e di dover riformattare tutto!!
  2. Dopo il backup, riavviare il pc, entrare nel BIOS e re-impostare “RAID” nell’opportuna sezione di configurazione SATA dei dishi
  3. Riavviare il pc utilizzando il DVD-ROM di Windows 7 (o un DVD di ripristino, se creato precedentemente)
  4. Dopo aver scelto lingua e tastiera opportune, scegliere l’opzione “Repair Your Computer”
  5. Nella successiva finestra “System Recovery Options”, dovrebbe già essere visibile l’installazione di Windows 7 (e nel mio caso anche quella di Windows Server 2008 R2) rilevate dall’ambiente di recupero sul volume RAID 1.  Selezionare l’installazione di Windows 7 e procedere con un “Next”
  6. Nella schermata successiva, scegliere “Startup Repair”
  7. …  et voilà!!!  Il wizard chiederà il riavvio, e dovreste essere in grado di far ripartire Windows 7 dal volume Mirror.  Addirittura, nel mio caso, ho potuto far ripartire anche Windows Server 2008 R2, ed è pure ricomparsa la partizione F: presente sul volume RAID 0.

In bocca al lupo!!!  :-)

  • Share/Bookmark

Pubblicato in Windows 7 | Nessun commento »

Attivare l’ibernazione su un desktop Windows 7 SP1

Scritto da Ivan Salvade' il 4 giugno 2011

L’ibernazione del computer è utile in particolar modo sui portatili, per preservare la batteria e soprattutto accenderli e spegnerli in modo molto veloce.

Quando Windows 7 è installato su un desktop, l’ibernazione è attiva per default, ma potrebbe comunque non comparire tra le voci di spegnimento, come si nota in questa figura.

img2332340000.jpg

Il motivo è che in Windows 7 esistono quattro modalità di spegnimento del computer :

  1. Spegnimento completo (”Arresta il Sistema”)
  2. Sospensione (”Sospendi”)
  3. Sospensione Ibrida (mai presente in menù Start)
  4. Ibernazione (nella figura, non presente in menù Start)

Fra “Sospensione Ibrida” e “Ibernazione”, solo una può essere utilizzata, e per default, su un desktop Windows 7, è attiva proprio la “Sospensione Ibrida” : per questo motivo “Ibernazione” non è visibile nel menù Start.

Ecco una rapida spiegazione delle tre modalità “particolari” di spegnimento :

  • Sospensione :  il computer viene messo in stato di “basso consumo di energia”, tutti i dati sono salvati in RAM, si può riprendere a lavorare nel giro di pochi secondi.  Se manca l’alimentazione durante la sospensione, il lavoro attivo viene perso.
  • Ibernazione :  il computer viene spento completamente e tutti i dati sono salvati su disco rigido (nel file c:\Hiberfil.sys).  Alla riaccensione del computer, in poco tempo i dati vengono ricaricati dal disco rigido, e si può riprendere a lavorare dal punto in cui si era arrivati.
  • Sospensione Ibrida :  è una combinazione delle due precedenti modalità; il salvataggio dei dati viene fatto sia in RAM che sul disco rigido, e il computer viene messo in stato di “bassissimo consumo di energia”.  Se manca l’alimentazione durante la sospensione ibrida, il lavoro attivo NON viene perso in quanto è salvato anche su disco.  Se si passa allo stato di “Sospensione” quando la “Sospensione Ibrida” è attiva (default sui desktop Windows 7), viene attivata proprio la “Sospensione Ibrida”.   Dalla “Sospensione Ibrida”, è possibile uscire tipicamente con un semplice tocco della tastiera o del mouse, e si può riprendere a lavorare dal punto in cui si era arrivati.

Se vogliamo effettivamente utilizzare l’Ibernazione anche su un desktop, bisogna disattivare la Sospensione Ibrida.

Si va nel Pannello di Controllo e nelle Opzioni di Risparmio Energia :

img2334170000.jpg

Si sceglie “Modifica impostazioni di sospensione del computer” in corrispondenza dell’opportuna combinazione di risparmio energetico preferita :

img2334570000.jpg

Si sceglie “Cambia impostazioni avanzate di risparmio energia” :

img2335200000.jpg

Nella sezione “Sospensione” si troverà che la Sospensione Ibrida è attiva :

img2335590000.jpg

Si disattiva la Sospensione Ibrida :

img2336580000.jpg

Ora nel menù Start dovrebbe comparire la voce “Ibernazione” :

img2342510000.jpg

Se ancora non dovesse comparire, potrebbe essere completamente disattivata l’Ibernazione. Si può procedere alla sua attivazione con il seguente comando :

img2357470000.jpg

Se ancora non dovesse comparire, verificare che nel BIOS del computer siano attivi i settaggi di sospensione/ibernazione.  Potrebbe anche esserci una incompatibilità della scheda video, il cui driver potrebbe non permettere l’ibernazione del computer.

N.B. : a seconda dell’hardware e del BIOS presenti sul vostro computer, potrebbe essere possibile riprendere dall’ibernazione anche con una semplice pressione di un tasto sulla tastiera, piuttosto che utilizzare il pulsante di accensione del pc.

  • Share/Bookmark

Pubblicato in Windows 7 | 6 Commenti »

L’accesso a C$ in Windows 7 e Windows Server 2008 R2 (parte 2)

Scritto da Ivan Salvade' il 10 marzo 2011

Nella prima parte di questo articolo (http://ivansalvade.it/2011/02/24/laccesso-a-c-in-windows-7-e-windows-server-2008-r2/), ho trattato delle due casistiche generali che regolano l’accesso alla condivisione amministrativa c$ in sistemi Windows Vista, Windows 7, Windows Server 2008 e Windows Server 2008 R2.

Ora vediamo più nel dettaglio diversi scenari reali che si possono presentare.

Ipotizziamo di avere due computer, Server1 con installato Windows Server 2008 R2, e Client1 con installato Windows 7 Enterprise, e un generico dominio Active Directory Contoso.com.

SCENARIO 1 : Server1 è in Workgroup, Client1 è nel dominio Contoso.com

Esistono le seguenti utenze e password :

  • Server1\Administrator          Pa$$w0rd
  • Server1\Admin                    Pa$$w0rd    (membro del gruppo Administrators locale)
  • Client1\Administrator           Pa$$w0rd
  • Client1\Admin                      Pa$$w0rd    (membro del gruppo Administrators locale)
  • CONTOSO\Administrator     Pa$$w0rd
  • CONTOSO\Jane                   Pa$$w0rd    (Utente Standard di dominio)

Eseguiamo ora diversi tentativi di accedere alla condivisione amministrativa c$ su Server1 (\\Server1\c$) dal client.  A seconda delle utenze utilizzate, possiamo avere i seguenti diversi risultati :

  1. Se su Client1 siamo loggati come CONTOSO\Administrator oppure Client1\Administrator, l’accesso è OK (perchè il collegamento remoto effettuato con l’utenza built-in Administrator, sia essa locale o di dominio, elude il controllo UAC;  inoltre su Server1 si trova l’utenza Server1\Administrator con la stessa password di CONTOSO\Administrator o Client1\Administrator)     clicca qui per vedere un esempio
  2. Se su Client1 siamo loggati come Client1\Admin, l’accesso è NEGATO (perchè il collegamento remoto effettuato con un utente membro dei gruppi Administrators locali viene bloccato da UAC, che nega l’elevazione dei privilegi a Full Administrator, anche se l’utente Server1\Admin ha la stessa password di Client1\Admin)    clicca qui per vedere un esempio
  3. Se eseguo lo stesso tentativo illustrato al punto 2, ma dopo aver posto, nel registro di sistema di Server1, a valore 1 la chiave LocalAccountTokenFilterPolicy posizionata in HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System, l’accesso è OK (perchè questa chiave di registro evita l’operazione di filtraggio eseguita da UAC sugli account membri dei gruppi Administrators locali)    vedi la chiave di registro

Cambiamo ora qualche carta in tavola, per esempio alcune password:

  • Server1\Administrator          altrapassword
  • Server1\Admin                    altrapassword    (membro del gruppo Administrators locale)
  • Client1\Administrator            Pa$$w0rd
  • Client1\Admin                      Pa$$w0rd    (membro del gruppo Administrators locale)
  • CONTOSO\Administrator     Pa$$w0rd
  • CONTOSO\Jane                   Pa$$w0rd    (Utente Standard di dominio)

Eseguiamo ora altri tentativi di accedere alla condivisione amministrativa c$ su Server1 (\\Server1\c$) dal client.  A seconda delle utenze utilizzate, ecco i nuovi risultati :

  1. Se su Client1 siamo loggati come CONTOSO\Administrator oppure come Client1\Administrator, viene richiesta l’autenticazione (perchè il collegamento remoto effettuato con l’utenza built-in Administrator, sia essa locale o di dominio, elude il controllo UAC;  ma su Server1 l’utenza Server1\Administrator ha una password diversa da quella degli account CONTOSO\Administrator o Client1\Administrator.  Una volta inserita la corretta password nella finestra di autenticazione, l’accesso è OK)    clicca qui per vedere un esempio
  2. Se su Client1 siamo loggati come Client1\Admin, l’accesso è NEGATO (perchè il collegamento remoto effettuato con un utente membro dei gruppi Administrators locali viene sempre bloccato da UAC, che nega l’elevazione dei privilegi a Full Administrator, anche se su Server1 l’utente Admin avesse la stessa password di Client1)   clicca qui per vedere un esempio
  3. Se eseguo lo stesso tentativo illustrato al punto 2, ma dopo aver posto, nel registro di sistema di Server1, a valore 1 la chiave LocalAccountTokenFilterPolicy posizionata in HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System, viene richiesta l’autenticazione (perchè questa chiave di registro evita l’operazione di filtraggio eseguita da UAC sugli account membri dei gruppi Administrators locali, ma la password di Client1\Admin è diversa da quella di Server1\Admin.  Inserendo la password corretta nella finestra di autenticazione, l’accesso è OK)   clicca qui per vedere un esempio    vedi la chiave di registro

SCENARIO 2 : Server1 e Client1 entrambi nel dominio Contoso.com

Esistono le seguenti utenze e password :

  • CONTOSO\Jane                     Pa$$w0rd    (Utente Standard di dominio, membro di Server1\Administrators)

Eseguiamo ora il tentativo di accedere alla condivisione amministrativa c$ su Server1 (\\Server1\c$) dal client.  Sul client siamo loggati come Contoso\Jane.   L’accesso è OK!  Motivazione : in ambiente di dominio, quando dal client un utente di dominio (membro del gruppo Administrators locale del server), tenta l’accesso a \\Server1\c$,  l’utente viene connesso come Full Administrator, e le restrizioni UAC non hanno effetto.   Il comportamento è by design.

SCENARIO 3 : Server1 e Client1 entrambi in workgroup

Esistono le seguenti utenze e password :

  • Server1\Administrator          Pa$$w0rd
  • Server1\Admin                    Pa$$w0rd    (membro del gruppo Administrators locale)
  • Client1\Administrator            Pa$$w0rd
  • Client1\Admin                      Pa$$w0rd    (membro del gruppo Administrators locale)

Eseguiamo ora diversi tentativi di accedere alla condivisione amministrativa c$ su Server1 (\\Server1\c$) dal client.  A seconda delle utenze utilizzate, possiamo avere i seguenti diversi risultati :

  1. Se su Client1 siamo loggati come Client1\Administrator, l’accesso è OK (perchè il collegamento remoto effettuato con l’utenza built-in Administrator, sia essa locale o di dominio, elude il controllo UAC;  inoltre su Server1 si trova l’utenza Server1\Administrator con la stessa password di Client1\Administrator)    clicca qui per vedere un esempio
  2. Se su Client1 siamo loggati come Client1\Admin, l’accesso è NEGATO (perchè il collegamento remoto effettuato con un utente membro dei gruppi Administrators locali viene bloccato da UAC, che nega l’elevazione dei privilegi a Full Administrator, anche se l’utente Server1\Admin ha la stessa password di Client1\Admin)    clicca qui per vedere un esempio
  3. Se eseguo lo stesso tentativo illustrato al punto 2, ma dopo aver posto, nel registro di sistema di Server1, a valore 1 la chiave LocalAccountTokenFilterPolicy posizionata in HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System, l’accesso è OK (perchè questa chiave di registro evita l’operazione di filtraggio eseguita da UAC sugli account membri dei gruppi Administrators locali)    vedi la chiave di registro

Cambiamo ora qualche carta in tavola, per esempio alcune password:

  • Server1\Administrator          altrapassword
  • Server1\Admin                    altrapassword    (membro del gruppo Administrators locale)
  • Client1\Administrator            Pa$$w0rd
  • Client1\Admin                      Pa$$w0rd    (membro del gruppo Administrators locale)

Eseguiamo ora altri tentativi di accedere alla condivisione amministrativa c$ su Server1 (\\Server1\c$) dal client.  A seconda delle utenze utilizzate, ecco i nuovi risultati :

  1. Se su Client1 siamo loggati come Client1\Administrator, viene richiesta l’autenticazione (perchè il collegamento remoto effettuato con l’utenza built-in Administrator, sia essa locale o di dominio, elude il controllo UAC;  ma su Server1 l’utenza Server1\Administrator ha una password diversa da quella di Client1\Administrator.  Una volta inserita la corretta password nella finestra di autenticazione, l’accesso è OK)    clicca qui per vedere un esempio
  2. Se su Client1 siamo loggati come Client1\Admin, l’accesso è NEGATO (perchè il collegamento remoto effettuato con un utente membro dei gruppi Administrators locali viene sempre bloccato da UAC, che nega l’elevazione dei privilegi a Full Administrator, anche se su Server1 l’utente Admin avesse la stessa password di Client1)    clicca qui per vedere un esempio
  3. Se eseguo lo stesso tentativo illustrato al punto 2, ma dopo aver posto, nel registro di sistema di Server1, a valore 1 la chiave LocalAccountTokenFilterPolicy posizionata in HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System, viene richiesta l’autenticazione (perchè questa chiave di registro evita l’operazione di filtraggio eseguita da UAC sugli account membri dei gruppi Administrators locali, ma la password di Client1\Admin è diversa da quella di Server1\Admin.  Inserendo la password corretta nella finestra di autenticazione, l’accesso è OK)    clicca qui per vedere un esempio    vedi la chiave di registro
  • Share/Bookmark

Pubblicato in Windows 7, Windows Server 2008 R2 | Nessun commento »

L’accesso a C$ in Windows 7 e Windows Server 2008 R2 (parte 1)

Scritto da Ivan Salvade' il 24 febbraio 2011

Il “Controllo Account Utente” (UAC) è un componente di sicurezza di Windows 7, Windows Vista e Windows Server 2008, che permette agli utenti di eseguire le loro normali operazioni quotidiane come “non-amministratori”, pur facendo parte, come spesso accade, del gruppo locale degli Amministratori.

In pratica, quando si logga un utente facente parte del gruppo Amministratori, questo viene dotato di un doppio token di accesso : uno con i completi diritti amministrativi, e l’altro con i diritti di Standard User.  E’ proprio quest’ultimo che rimane attivo per default, finchè l’utente esegue operazioni che non richiedono diritti amministrativi (es. consultare la posta, andare in Internet, ecc.).

Non appena l’utente deve eseguire un’operazione amministrativa (es. aprire “Gestione Computer”), viene attivato il suo token “amministrativo” (più o meno automaticamente, questo è configurabile), e l’utente può eseguire l’operazione con i massimi privilegi.

La tecnica UAC crea dei problemi quando si vuole accedere da remoto alle condivisioni amministrative (per esempio la tanto famosa e utile C$) presenti su Windows Vista, Windows 7 o Windows Server 2008.

Esistono due casistiche generali :

  1. Quando un utente (non di dominio), membro del gruppo Administrators locale di un computer remoto, tenta di stabilire una connessione remota amministrativa verso quel computer (per es. \\computer\c$), l’utente non viene connesso come Full Administrator, perchè UAC non eleva i privilegi per una connessione amministrativa proveniente da remoto, se fatta da un utente locale (SAM Account).  Quindi si riceve un accesso negato.
  2. Quando un utente (di dominio), che ha il suo account di dominio membro del gruppo Administrators locale di un computer remoto, stabilisce una connessione remota amministrativa verso quel computer, viene connesso come Full Administrator, e UAC non ha effetto.  Quindi la connessione avviene con successo.

Per disabilitare la restrizione del punto 1, è possibile regolare la seguente chiave di registro sul computer remoto :

Posizionarsi in :

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System

Se non esiste, creare la voce di tipo DWORD  “LocalAccountTokenFilterPolicy“, e porre il valore a 1.

Queste sono le casistiche generali.  In un successivo articolo (http://ivansalvade.it/2011/03/10/l%e2%80%99accesso-a-c-in-windows-7-e-windows-server-2008-r2-parte-2/), illustrerò in maniera dettagliata il funzionamento della suddetta tecnica in una moltitudine di scenari.

  • Share/Bookmark

Pubblicato in Windows 7, Windows Server 2008 R2 | 4 Commenti »

Installazione del SP1 di Windows 7 e Windows Server 2008 R2

Scritto da Ivan Salvade' il 23 febbraio 2011

L’installazione del Service Pack 1 di Windows 7 / Windows Server 2008 R2 è piuttosto semplice.

Potete scaricare i packages standalone dai siti per gli abbonati Technet o MSDN, oppure dal seguente link pubblico disponibile dal 22 febbraio (attenzione alla lingua e alla convalida della genuinità del vostro sistema operativo) :

http://www.microsoft.com/downloads/details.aspx?familyid=C3202CE6-4056-4059-8A1B-3A9B77CDFDDA&displaylang=it

Il sito pubblico vi dà la possibilità di scaricare l’immagine ISO del DVD contenente il SP1 valido per tutte le architetture, oppure il singolo package del SP1 a 32 bit (per Windows 7), oppure il singolo package del SP1 a 64 bit (per Windows 7 e/o Windows Server 2008 R2).

Se scaricate l’immagine ISO completa dai siti Technet o MSDN, il package dovrebbe presentarsi più o meno come nella seguente immagine :

snag-0000.jpg

La scompattazione del file ISO dà il seguente risultato :

snag-0001.jpg

Il Setup.exe è in grado autonomamente di rilevare il sistema operativo e l’architettura del vostro sistema :

snag-0002.jpg… rilevazione di Windows 7 (clicca per ingrandire)

snag-0003.jpg… rilevazione di Windows Server 2008 R2 (clicca per ingrandire)

Si accetta la licenza :

snag-0004.jpg

Si indica al wizard di riavviare il computer al termine dell’installazione (facoltativo) :

snag-0005.jpg

Il wizard installa automaticamente la patch 976902 : è un fixup che aggiorna alcune DLL del software di installazione che, in Windows 7 e Windows Server 2008 R2, gestisce installazione e rimozione di patch, language pack, service pack.  Il fixup è obbligatorio :

snag-0006.jpg

Viene poi inizializzato e installato il corretto cabinet del SP1.  L’articolo di KB che descrive il SP1 è il 976932 :

snag-0007.jpg

L’installazione ha una durata variabile tra i 35 e i 60 minuti, a seconda della potenza della macchina :

snag-0008.jpg

snag-0009.jpg

Una volta installato il SP1, questo è referenziato nelle proprietà di sistema :

snag-0010.jpg

Dal pannello di controllo, è sempre possibile eseguirne una disinstallazione :

snag-0011.jpg

Buona installazione!!

  • Share/Bookmark

Pubblicato in Generale, Gestione dei Sistemi, Windows 7, Windows Server 2008 R2 | Nessun commento »

SP1 di Windows 7 e Windows Server 2008 R2 è RTM

Scritto da Ivan Salvade' il 16 febbraio 2011

Da poche ore, per chi è abbonato Technet o MSDN, è disponibile il download del SP1 RTM di Windows 7 e Windows Server 2008 R2.

Il SP1 RTM era già stato distribuito settimana scorsa agli OEM e ai System Builder.

Entro il 22 febbraio, il SP1 verrò reso disponibile anche attraverso Windows Update o, a scelta, come pacchetto standalone da scaricare pubblicamente da Internet.

Disponibili in download anche i Language Pack delle lingue più diffuse.

Ecco un link Microsoft (in inglese) dove potete trovare le Release Notes di Windows 7 SP1 :

http://technet.microsoft.com/it-it/library/ff817622(WS.10).aspx

In quest’altro link Microsoft (in inglese),  le Release Notes di Windows Server 2008 R2 SP1 : 

http://technet.microsoft.com/it-it/library/ff817647(WS.10).aspx

Per i sottoscrittori Technet e MSDN, è già disponibile per il download anche il “Windows Automated Installation Kit” (WAIK) per Windows 7 e Windows Server 2008 R2 SP1, 32 e 64 bit (1,3 Gb la grandezza del download).

Buon download a tutti!!

  • Share/Bookmark

Pubblicato in Generale, Windows 7, Windows Server 2008 R2 | Nessun commento »

Seminari dal vivo in programma

Scritto da Ivan Salvade' il 14 febbraio 2011

Ho in programma diversi seminari dal vivo su tematiche Microsoft.  Ecco le date e  le sedi :

Milano, 21 febbraio 2011 :  Windows 7 Deployment                                                     

Padova, 11 marzo 2011 :    Windows 7 Management & Troubleshooting                   

Milano, 22 marzo 2011 :    Server Virtualization                                                         

Roma, 25 marzo 2011 :      Windows 7 Management & Troubleshooting                  

Bologna, 15 aprile 2011 :   Windows 7 Management & Troubleshooting

Padova, 18 aprile 2011 :     Server Virtualization

Torino, 30 maggio 2011 :   Windows 7 Management & Troubleshooting

E’ possibile partecipare ai seminari “Server Virtualization” solo se invitati ufficialmente via mail da Microsoft.

Gli altri seminari sono riservati ai Microsoft Partner di qualunque livello, ed è’ possibile iscriversi gratuitamente sul sito PLC (Partner Learning Center) di Microsoft, ove potrete trovare anche l’elenco preciso degli argomenti trattati e gli indirizzi delle sedi.

E’ possibile scaricare le slides che ho utilizzato al seguente link :   http://ivansalvade.it/attualita/

Gli orari : dalle 09.30 alle 13.00 e dalle 14.00 alle 17.30.

Vi aspetto numerosi…

  • Share/Bookmark

Pubblicato in Generale | Nessun commento »

Applicazioni non si installano su Windows 7 / Windows 2008 R2

Scritto da Ivan Salvade' il 19 novembre 2010

A volte capita che i files .MSI e/o .EXE di installazione di alcune applicazioni rifiutano di eseguirsi, oppure procedono con l’installazione, ma al termine non si trova l’applicazione presente tra i programmi installati o non si trovano i servizi previsti presenti nell’elenco dei servizi (services.msc).  Questo comportamento è frequente soprattutto quando si tenta di installare su Windows 7 o Windows Server 2008 R2 applicazioni previste per sistemi operativi precedenti (es. Windows XP/Vista/2003/2008).  

Quando l’applicazione rifiuta di installarsi tramite il file .MSI indicando subito un’incompatibilità del sistema operativo sottostante, ciò è dovuto al fatto che il file .MSI esegue lui stesso dei controlli sul sistema operativo per verificare che sia compreso tra quelli compatibili con l’applicazione.   Per bypassare il controllo, è necessario editare il file .MSI e togliere o modificare questo controllo.  E’ possibile fare questo utilizzando un editor di MSI (per es. “Orca”, scaricabile da http://www.technipages.com/downloads/Orca.Msi)  e modificando la sezione “LaunchCondition” del file .MSI,  come visualizzato nella seguente figura :  

appcompatdiagnostics.gif    Clicca sulla figura per ingrandire

 Il modo più semplice è inserire, dopo un operatore booleano “OR”, una voce del tipo “VersionNT >= 600”, che indica al MSI di accettare qualunque sistema operativo con codice di riconoscimento superiore a 600 (questo è il codice identificativo di Windows Vista/2008): in questo modo i vari Windows 7, Windows 2008 R2 ed anche i successivi saranno accettati dall’installatore. 

La proprietà “VersionNT” identifica una particolare versione del sistema operativo:

Valore 500 : Windows 2000 no SP o con SP1,SP2,SP3,SP4

Valore 501 : Windows XP no SP o con SP1,SP2,SP3

Valore 502 : Windows Server 2003 no SP o con SP1,SP2

Valore 600 : Windows Vista no SP o con SP1,SP2 e Windows Server 2008 no SP o con SP2

Valore 601 : Windows 7 e Windows Server 2008 R2

Per una migliore precisione, è possibile anche utilizzare le proprietà “ServicePackLevel” e “WindowsBuild” per identificare con precisione un certo Service Pack o una certa Build dei sistemi operativi (i codici precisi sono al seguente link : http://msdn.microsoft.com/en-us/library/aa370556(VS.85).aspx ). 

Quando invece il file .MSI non esegue il controllo di versione, ma l’applicazione comunque rifiuta di installarsi su Windows 7 o Windows Server 2008 R2 (o si installa ma senza attivare i servizi previsti), ciò è tipicamente causato dai controlli di compatibilità che per default eseguono Windows 7 e 2008 R2.  Questi controlli di compatibilità sono molto utili, in quanto ci permettono di evitare l’installazione di applicazioni non compatibili, che metterebbero a repentaglio la stabilità del sistema.  Questi controlli sono attivati da dei settaggi di Group Policy o Local Policy indicati nelle figure seguenti. 

FIGURA 1

 application-compatibility.gif   Clicca sulla figura per ingrandire

In figura 1 sono visualizzati i settaggi nella categoria “Computer Configuration\Administrative Templates\Windows Components\Application Compatibility” : andrebbero posti a “Enabled” tutti quelli indicati in figura per disattivare diversi controlli di compatibilità (per dafault quei settaggi sono tutti “Not Configured”, cioè i controlli di compatibilità sono attivi)

FIGURA 2 

msilaunchcondition.gif   Clicca sulla figura per ingrandire

In Figura 2 sono visualizzati i settaggi nella categoria “Computer Configuration\Administrative Templates\System\Troubleshooting and Diagnostics\Application Compatibility Diagnostics” : andrebbero posti a “Disabled” tutti i settaggi indicati in figura per evitare la comparsa di numerose finestre di errore che interromperebbero l’installazione dell’applicazione (anche tutti questi settaggi sono posti per default a “Not Configured”, il che lascia attivi i diagnostici) 

Una volta modificati i settaggi come indicato sopra, le applicazioni dovrebbero installarsi tutte senza problemi, anche quelle incompatibili con Windows 7 / Windows Server 2008 R2. 

La configurazione di questi settaggi come indicato nelle figure, e la modifica dei files .MSI indicata in precedenza,  sono a totale rischio e pericolo dell’utente.

Si ricorda che in questo modo si impedisce a Windows 7 e Windows Server 2008 R2 (o al servizio Windows Installer) di eseguire una moltitudine di controlli sulla compatibilità delle applicazioni che vengono installate;  le applicazioni, a questo punto, è molto probabile che vengano installate, ma se non effettivamente compatibili con Windows 7/2008 R2 possono mettere a repentaglio la stabilità dell’intero sistema.  Si consiglia di provare queste procedure in ambiente di testing, e solo dopo essersi accertati che le applicazioni installate non creano problemi ai sistemi, procedere all’implementazione in produzione.

  • Share/Bookmark

Pubblicato in Gestione dei Sistemi, Windows 7, Windows Server 2008 R2 | Nessun commento »

 
Usiamo i cookie per assicurarti la migliore esperienza di navigazione nel nostro sito web.
Ok