Avendo spesso la necessità, per motivi ammnistrativi di eseguire explorer.exe (in italiano Esplora Risorse) con privilegi elevati, mi sono imbattuto in grosse difficoltà. Infatti il comando runas non sempre sembra funzionare: quando fallisce il problema risiede nel fatto che essendo il processo exlorer.exe in esecuzione è necessario poterlo eseguire in un processo separato.
Se explorer (come accade spessissimo) non è settato per essere eseguito in questo modo, il comando non fornisce alcun risultato.
runas /user:Administrator explorer.exe
Ci viene in soccorso una simpaticissima opzione di exlorer.exe ovvero lo switch /separate che permette eseguirlo (come si intuisce dal termine) in un processo separato.
runas /user:Administrator explorer.exe /separate
Spero di non dimenticarlo più.
Spesso mi è capitato di dover creare dei collegamenti a risorse/file presenti in rete per poi doverli distribuire a tutti gli utenti di un dominio Actie Directory.
Di fronte a questa richiesta la prima cosa che viene in mente è quella di creare i collegamenti e poi copiarli facendo il giro dei client nella cartella C:/Documents and Settings/All User/Desktop. Ma quando i client in questione sono numerosi la cosa può essere parecchio dispendiosa in termini di tempo.
Perchè non sfruttare uno script da lanciare via GPO?
Basta applicare una GPO alle OU alle quali vogliamo distribuire i collegamenti. Tale GPO non dovrà far altro che eseguire uno script .bat in Configurazione Utente/Impostazioni di Windows/Script (Accesso/Fine Sessione)/Accesso
Lo script non dovrà far altro che eseguire il comando DOS copy per copiare i collegamenti preventivamente salvati su una share di rete nella cartella C:/Documents And Settings/All Users/Desktop sfruttando la variabile d’ambiente %AllUsersProfile%
copy /Y \\NomeServer\NomeShare\*.* %AllUsersProfile%\Desktop
Capita spesso che, dopo aver dovuto effettuare l’accesso ad un client (in un dominio AD) come Administrator, il povero sistemista (che magari ha lavorato alacremente per sistemare le ca..ate di un utente) si senta chiamare al peggio al cellulare, tipicamente dopo le 19 di sera, dall’utente genius del PC: “Senti, dopo che sei passato tu io non riesco il mio computer non va più, continuo a digitare la password e sono sicuro che sia giusta ma non va più niente! Ma cosa hai fatto?”
E non serve a nulla lasciare un appunto scritto ricordando di inserire il proprio nome utente e di impostare il dominio nel campo Accedi a: nella schermata di logon. Il 95% degli utenti non sa neppure il proprio nome utente.
Un consiglio: prevenire è meglio di curare.
Allora il nome utente nella schermata di logon lo ripristino io, prima di spegnere la macchina, quando sono ancora connesso come Administrator, modificando due chiavi nel Registry in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Le chiavi in questione sono:
DefaultUserName
DefaultDomainName
Ed il gioco è fatto! Il lobotom non si accorgerà nemmeno che siete passati di lì.
Dovendo sostituire un vecchio server MS Windows 2000 sul quale l’Exchange 2000 serviva solo alla condivisione della rubrica aziendale (!), in tempi di estreme ristrettezze economiche mi sto adoperando per trovare un’alternati FOSS al costoso prodotto di Microsoft. In realtà mi sarei accontentato della sola possibilità di condividere (anche sul Web) la rubrica dei contatti, ma nel corso delle mie ricerche mi sono imbattuto in questo interessante progetto (di cui la versione Community è Open Source) capitanato da Yahoo e credo che mi ci cimenterò. Stay tuned.
Ma qualcuno me lo sa spiegare perché le GPO nonostante millllioni di gpupdate /force lato client e lato server e riavvii delle macchine si applicano spesso assolutamente in maniera non deterministica?
Scenario
Rete scolastica Microsoft con client Windows XP Pro e AD fornito da una macchina Windows 2003 Server R2
Problema
Sui client è stato installato software datato (sviluppato credo ancora per Windows 98) che per funzionare deve permettere all’utente un accesso in scrittura nella cartella C:\Programmi\software
Ovviamente di questo ci si accorge in ritardo e a questo punto si presentano due tipi di soluzioni (per pietà nei confronti degli insegnanti ho scartato l’ipotesi di cassare tutti gli applicativi vecchi):
- accedere come utente Administrator in locale a TUTTI i singoli client e cambiare amanina i permessi sulle cartelle (nonbuono);
- provare a sfruttare le Goup Policy (GP) messe a disposizione sui server Windows a partire dalla versione 2000 per cercare di settare i permessi sulle cartelle locali delle macchine in maniera accentrata (migarba).
Srtumenti necessari
Per modificare i permessi sulle cartelle via script (è quello che voglio fare) mi viene in aiuto una straodinaria utility gratuita rilasciata con licenza GPL che si chiama SetACL e permette proprio di manipolare i permessi in filesystem NT. Scarichiamola da qui
A noi serve la versione da riga di comando.
Soluzione
Come prima cosa dobbiamo distribuire SetACL.exe (ci serve per poter far eseguire il nostro script) a tutti i client. Questo lo facciamo impostando sulla OU del nostro laboratorio una GPO che impone uno script di startup al computer che copia il file da una share di rete nella system32 del client:
copy \\nomeserver\nomeshare\SetACL.exe %systemroot%\system32
Benissimo, ora abbiamo a disposizione l’utility SetACL sui computer locali (ovviamente dopo aver dato un gpupdate sul client o comunque al prossimo riavvio della macchina XP).
Non ci resta che creare un’altra GPO sulla OU del nostro laboratorio che, sempre mediante uno script di startup sul computer setti correttamente i permessi sulla cartella incriminata ( nel nostro caso genericamente C:\Programmi\software) concedendo ad esempio ai Domain Users i diritti di scrittura:
setACL.exe -on "C:/Programmi/software" -ot file -actn ace -ace "n:nomedominio\Domain Users;p:change”
Benissimo, l’orrendo e vetusto software inguardabile è tornato però a funzionare per la gioia degli insegnanti (ma perchè non si aggiornano?) 
Ovviamente in caso di necessità questo metodo è riutilizzabile e velocissimo e probabilmente mi consentirà di sbloccare anche il prossimo programma del 1997.
Ho perso talmente tanto tempo (inutilmente) con una stampante HP: scrivo un post che mi serva da promemoria e possa essere d’aiuto anche ad altri che si trovino nella mia situazione.
Stampante: HP Color LaserJet 2600n
Server di stampa: MS Windows Server 2003 R2
Dopo aver scaricato gli ultimi driver ho installato la stampante e l’ho distribuita come al solito con le GPO.
Ogni volta che un utente di dominio lanciava una stampa questa si bloccava in coda e nemmeno da amministratore su server si riusciva a ripulire la coda.
Arrestando e riavviando lo spooler di stampa con:
net stop spooler
net start spooler
la stampa si riavviava correttamente.
Dopo un po’ di ricerca ho scoperto che per risolvere il problema è sufficiente disabilitare il Supporto bidirezionale nella scheda Porte raggiungibile dalle Proprietà della stampante.
Il problema dovrebbe essere causato da un conflitto tra il driver della stampante e il il print monitor status software cme si evince anche da questa KB Microsoft.
Ed infatti tutto è tornato a funzionare a meraviglia. Occhio quindi alle stampanti di rete HP.
Grazie a Tevac ho scoperto l’esistenza di questo applicativo gratuito, multipiattaforma che permetterebbe meraviglie, ovvero la possibilità di convertire macchine fisiche, ma anche macchine virtuali create con altre piattaforme e addirittura immagini di backup di macchine (magari realizzate con il noto Symantec Norton Ghost) in macchine virtuali VMware.
Inutile dire che passo immediatamente a provarlo, ovviamente su Mac OS X.
[EDIT] Non esiste per Mac OS X (e io che volevo fare un P2V di un Server Mac…), ma per Windows e Linux
VMware vCenter Converter: schemo di funzionamento
Nehalem, la nuova architettura che farà fare un salto prestazionale/generazionale al mondo dei computer basati su processori Intel è prossima al debutto.
Intel, nel suo sito spiega la nuova architettura con delle animazioni che valgono mille parole.
Server Primergy Fuijtsu Siemens appena consegnato con preinstallato Windows 2008 Server.
Configuro l’AD, appena il tempo di pensare “che DE esagerato ed esoso per un server!”, riavvio e al successivo logon…. ops
[UPDATE] La colpa è dell’antivirus, che peraltro è il blasonato Kaspersky. La beffa è che in Windows 2008 Server in modalità provvisoria (l’unica funzionante) Windows Installer non si avvia e quindi da lì non si può procedere a disinstallazione!!! Per fortuna esiste un removal tool reperito sul sito di Kaspersky che mi ha risolto il problema (anche se ora non so come procedere con l’installazione dell’antivirus visto che la mia non sembra un’incompatiblità nota, nonostante mi sia successa su due (2) server diversi, un Fujitsu Siemens ed un Intel).
