Può essere necessario alle volte, ad esempio per far fare al pc delle operazioni notte tempo (non necessariamente il backup, la macchiana potrebbe essere riavviata con il WoL) modificare la combinazione di risparmio energetico predefinita, che su Windows 7 è “Bilanciato”.
Come modificare questa impostazione con uno script e magari da remoto?
In nostro soccorso ci sono powercfg e psexec!
Innanzittutto dobbiamo scoprire il GUID della combinazione “Prestazioni Elevate”, che su tutti i 7 dovrebbe essere
C:\Users\admin>powercfg /list
Combinazioni risparmio energia esistenti (* attive)
———————————–
GUID combinazione risparmio energia: 381b4222-f694-41f0-9685-ff5bb260df2e (Bila
nciato)*
GUID combinazione risparmio energia: 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c (Pres
tazioni elevate)
GUID combinazione risparmio energia: a1841308-3541-4fab-bc81-f71556f20b4a (Risp
armio di energia)
a questo punto settiamo “Prestazioni elevate” così
powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c
Per rendere questa operazione eseguibile da remoto su di un pc basterà scrivere la riga di cui sopra in un file *.cmd ed eseguirlo remotamente con psexec.
psexec \\PC-REMOTO -c power.cmd
all done
Scenario, installazione di un dominio 2008 R2, livello di funzionalità comunque 2003, operazione fatta svariate volte nell’ultimo decennio ma…strano, nslookup non funziona, strano è bindato sull’ip giusto, strano su 127.0.0.1 funziona…strano non funziona niente!!!!!
Dopo qualche ricerca ecco svelato l’arcano, 2008 R2 di default usa EDNS, purtroppo ancora poco usato e quindi INCOMPATIBILE!
La cosa assurda è perchè Microsoft lo imposti “on” di default, e la stessa cosa successe anni fa con il rilascio di Windows Server 2003, mha…
Comunque per risolvere semplicemente il problema e SENZA riavvio basta andare in CMD e scrivere
dnscmd /config /EnableEDNSProbes 0
e tutto sarà risolto (parlando di DNS è proprio il caso di dirlo!! 
)
Continuiamo sulla falsa riga del post precedente, ma qui la situazione è ben più grave, infatti per qualche ragione avrete perso l’associazione ai file exe e cliccandoci sopra mestamente apparirà la finestra che vi chiederà “come volete aprire questo file?”
Ovviamente NON funzionerà il regedit per cui niente modifiche al registro!
Formattone??
No…semplicemente create un file di testo chiamato “miracolo_divino.txt” e dentro metterete una sola riga, “assoc.exe=exefile” senza le virgolette.
A questo punto modificate l’estensione in .bat, eseguite il file e gioite! 
Nel titolo c’è tutto, può capitare (mi è successo in un vecchio server di un utente) che alcuni file exe non si aprano, mentre altri si, ad esempio non mi partiva l’installazione del vSphere Client, ma nemmeno semplicemente il putty.
L’errore è un messaggio del tipo “Impossibile accedere alla periferica, al percorso o al file specificato.È probabile che non si disponga delle autorizzazioni necessarie“, anche se siete amministratori.
Questo sarà dovuto (come nel mio caso) quasi sicuramente ad internet explorer, infatti bisogna andare da “Installazione applicazioni” su Installazione componenti di Windows”. Da quì alla voce Protezione avanzata di Internet Explorer bisogna disinstallare il gruppo amministrativo.
Fatto ciò sloggatevi e riloggatevi, tutto sarà apposto.
Può capitare, che riavviando o semplicemente tendando di stoppare un servizio Windows, questi si blocchi in arresto in corso e dopo non sia più possibile intervenire tramite la solita MMC.
Come fare?
Semplicemente tramite una console cmd lanciare
sc queryex nomeservizio
Otterremmo una cosa del tipo
NOME_SERVIZIO: wuauserv
NOME_VISUALIZZATO: Windows Update
TIPO : 20 WIN32_SHARE_PROCESS
STATO : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_PRESHUTDOWN)
CODICE_USCITA_WIN32 : 0 (0×0)
CODICE_USCITA_SERVIZIO : 0 (0×0)
PUNTO_CONTROLLO : 0×0
INDICAZIONE_ATTESA : 0×0
PID : 776
FLAG :
prendendo nota del PID, in questo caso 776 per Windows Update possiamo killarlo in maniera forzata tramite il comando
taskkill /PID 776 /F
Dove appunto l’opzione /F indica la chiusura forzata
Potrà capitarvi che durante l’installazione di un determinato software in Windows 7 vi venga restituito questo errore generico, ovvero 2738.
Non temete, la soluzione è piuttosto semplice vi basterà aprire con diritti d’amministratore un “cmd” a questo punto
per 32bit => cd %windir%\system32
per 64bit => cd %windir%\syswow64
e poi
regsvr32 vbscript.dll
Se questo non dovesse bastare c’è anche da cancellare questa chiave nel registro, quindi lanciate un regedit sempre come amministratore e cancellate questa chiave
HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{ B54F3741-5B07-11CF-A4B0-00AA004A55E8}
e poi di nuovo
regsvr32 vbscript.dll
Fatto ciò dovreste comodamente poter installare il vostro software.
Echecazz!!!!
Scusate eh, ma dopo due sere sono riuscito a recuperare un pc, no…non di un collega o di un cliente, ma di una amica della mia ragazza, ebbene si, mi portano il lavoro anche a casa!
Comunque con il solito mix dei tools, Combofix, MalwareBytes e SuperAntispyware (e come antivirus il mitico Avira), avevo ripulito il tutto, ma rimaneva un problama grosso….al boot nessuna icona nel desktop e niente barra!
Di solito questo è il comportamento tipico di certi spyware, ma dopo il trattamento di cui sopra, tutto tornava ok, ma non stavolta.
Primo indizio, CTRl+ALT+DEL, File, Esegui, explorer e tack, magicamente il desktop, quindi il valore “shell” in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon corrispondeva a explorer.exe
Provato a prendere da c:\i386 il file explorer.ex_, espanderlo e sostituirlo a quello, ma niente.
Altra procedura, rinominare explorer.exe in explore.exe e cambiare il valore di shell, niente.
Pensa pensa pensa, ecco l’illuminazione! La chiave Userinit era corretta a “C:\WINDOWS\system32\userinit.exe,”, ma quando sono andato a guardare il file, userinit.exe, indovinate chi era??! iexplorer.exe!!!!!!!
Il malefico spyware aveva fatto questa sostituzione, quindi espanso sempre da i386 il file userinit.ex_ nella cartella system32 e tutto magicamente ha ripreso a funzionare!
Marco 1, virus bastardi 0
Tempo fa acquistammo in azienda Acronis Recovery per il nostro server Exchange 2007 per fare il backup dell?information Store.
Vidi che c’era una simpatica funzione, ovvero la possibilità di effettuare il backup ed il recovery “brick-level”, ovvero salvare e ripristinare la posta al singolo livello di mail..bello!
bhe….quasi!
Dopo diverso tempo, controllando che comunque tutti i backup (il completo giornaliero ed i 4 incrementali ogni tre ore) erano tutti eseguiti.
Un bel giorno decido di buttare un occhio all’occupazione del DB, 18GB, bhe buono, il disco è da 100GB (macchina virtuale) quindi avrò libero…..cosaaaaaa????? 3GB?????
Il mistero dura 0 secondi, ci sono 56GB di log che per qualche motivo non sono mai stati puliti e consolidati.
Ovviamente saprete, o se non lo sapete è bene saperlo, un backup COMPLETO di IS, dovrebbe consolidare tutti i log e cancellare quelli superflui, cosa che Acronis NON MI HA MAI FATTO!
Senza sentire il loro supporto mi sono dato però una risposta, il problema sta nel brick-level appunto, infatti convertendo il backup nel classico modo, ovvero backuppando l’intero IS “monolitico”, il log non necessari sono cancellati magicamente dopo ogni backup.
Il che ha anche una logica, la caratteristica di salvare ogni singola mail, non può presupporre il cosolidamento di tutti i log, nemmeno se questa tecnica viene utilizzata per salvare l’intero IS.
Una soluzione per evitare il lievitare dei log, ma mantenere i vantaggi della tecnologia brick-level potrebbe essere fare un backup giornaliero “classico” la domenica ad esempio e mantenere i 6 giornalieri brick-level, con tanto di incrementali gli altri giorni, così da eliminare i log superflui una volta la settimana.
Recentemente ho installato un Remote Desktop Services (WS 2008 R2), il nuovo Terminal Server per capirsi ed è presente una nuova features che come saprete facilita l’utente nello stampare nella stampante (ma va!) a lui più comoda.
Consente inoltre agli utenti di ottenere prestazioni di stampa più uniformi tra sessioni locali e remote.
I client in questione erano XP SP3 con tanto di .NET Framework 3.0 SP2 e .NET 3.5 SP1, però quando andavo a stampare dala sessione RDS nella stampante locale, mi veniva a video un errore di Windows, relativo all’eseguibile TsWpfWrp.exe
Documentandomi ho scoperto che su XP è presente una versione più vecchia, di quella presente ad esempio su 7, la 3.0.6920.1201.
Semplicemente sistituendo l’eseguibile vecchio con questo, l’errore scompare, ma ancora non c’è stampa, quindi ho reinstallato il .NET Framework è tutto è partito alla perfezione, sia con il client RDP 6.1 (di default su XP Sp3, che con il nuovo 7, che consiglio caldamente!)
Oggi da un cliente mi è capitato un problema strano, ovvero l’impossibilità di raggiungere un host tramite il nome Netbios oppure con l’indirizzo FQDN, mentre tramite l’indirizzo ip è raggiungibile e comuqnue tramite il nome èpingabile tranquillamente.
L’errore specifico è 0×80070035, percorso di rete non trovato.
Questo è il solo Windows 7 che mi ha dato questo problema, sembra che succeda solo nel caso di upgrade da Vista.
Per eliminare il problema ho provato a mettere il nome nel file hosts ma non ha dato risultati, l’unica cosa risolutiva è stato togliere il supporto ad IPv6.
Soluzione empirica, mi piacerebbe sapere perchè!!!
Previous Entries
Categories
Tag Cloud
Blog RSS
Comments RSS
Last 50 Posts
Back
Void 
Life 
Earth 
Wind 
Water 
Fire