Quando si cerca di accedere alla cartella condivisa di un PC che esegue Microsoft Windows XP si potrebbe visualizzare il messaggio di

“Memoria insufficiente nel server per eseguire il comando.”

Nel registro eventi del sistema che condivide la cartella si potrebbe avere il seguente messaggio:

Il parametro di configurazione “irpstacksize” del server è troppo piccolo per usare una periferica locale. Incrementare il valore del parametro.

CAUSA:

Una delle possibili cause di tale errore potrebbe essere l’installazione di Norton Ghost v8 o altri prodotti Norton.

SOLUZIONE:

1. Aprire il registro di registro di sistema:

START -> Esegui -> regedit.exe

2. Creare la seguente chiave DWORD e/o modificarla impostando il valore a 14 (esadecimale):

HKEY_LOCAL_MACHINE SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\IRPStackSize

3. Riavviare il PC

NOTE:

Il problema sembra risolversi installando l’ultima versione di Ghost (attualmente la v15).

RIFERIMENTI:

http://support.microsoft.com/kb/225782/it

SOLUZIONE: per modificare il formato predefinito delle email in arrivo su cartelle pubbliche, è necessario seguire la seguente procedura:

1. Aprite il registro di sistema e portatevi alla seguente chiave di registro:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\Public-<GUID>

2. Create la seguente chiave “DWORD”:

Incoming defaults to IPM.Note

assegnatele uno dei seguenti valori ESADECIMALI (per la soluzione al problema assegnate “1″):

Valore “1″ per visualizzare le email in ingresso come “IPM.Note” (ovvero email normali)
Valore “0″ per visualizzare le email in ingresso come “IPM.Post” (ovvero inserimenti)

3. Riavviate il “Microsoft Exchange information store” o “Archivio informazioni di Microsoft Exchange” per le versioni italiane.

NOTE: la modifica avrà effetto unicamente dal recapito dei nuovi messaggi, quelli già recapitati rimarranno in formato “Inserimento”.

Al click di “Salva e Chiudi”  per un nuovo appuntamento con un promemoria in, Outlook potreste ricevere uno dei seguenti errori:

“Il promemoria non verrà visualizzato perché non si trova nella cartella Calendario o Attività in uso.”

“Impossibile visualizzare il promemoria per “nome_appuntamento”. La cartella che contiene l’elemento non supporta i promemoria. Continuare?

SPIEGAZIONE: Il motivo di tale errore (che di errore non si tratta) è che il promemoria calendario o attività non risiede nella cartella principale. Difatti in Outlook esiste un Calendario/Attività “predefinito“, che risiede nella cartella principale (PST o Mailbox che sia). Ogni promemoria abilitato su appuntamenti o eventi in questo calendario verrà regolarmente eseguito.

E allora perchè dell’avviso??? Probabilmente perchè si è verificata una delle seguenti condizioni:

• Il Calendario/Attività utilizzato risiede in una Cartella Pubblica di Exchange
• Il Calendario/Attività utilizzato risiede in una Casella di Exchange aggiuntiva
• Il Calendario/Attività utilizzato risiede in un file PST aggiuntivo (risolto in Outlook 2007)

Quando si crea un nuovo appuntamento/evento e si abilita il promemoria Outlook alimenta una propria tabella nascosta in cui vengono tracciate queste scadenze. Un processo interno si occuperà poi di verificare, ogni minuto, se è arrivata l’ora di mostrare il promemoria. Proprio per evitare di gestire in questa tabella informazioni non permanentemente legate alla mailbox principale (come nei tre casi citati sopra), i promemoria vengono gestiti solo per il calendario predefinito. <fonte>

E’ possibile resettare questa tabella con il comando:

START – ESEGUI: outlook.exe /cleanreminders

SOLUZIONE: una vera a propria soluzione al problema non esiste, ma esistono alcuni programmi di terze parti che permettono di aggirare il problema, permettendo i promemoria anche a cartelle non generalmente comprese (entrambi a pagamento):

“Extended Reminders”

“Reminder Manager”

Personalmente non li ho mai provati, ma sulla carta promettono di farlo!

Data la grande moda scoppiata per questi strani e costosi oggetti di culto, ovvero le chiavette Internet, eccovi un articolo su alcuni possibili problemi legati alla connettività Internet.  Il cosiddetto e alquanto generico:

Mi connetto ad Internet ma non navigo.

SINTOMI: la chiavetta risulta connessa correttamente alla rete (GPRS, UMTS, HSDPA o altro), il segnale è buono, ma per qualche strano motivo non riesco ad aprire nessun sito. Un interessante prova da fare è verificare l’effettivo funzionamento della rete.

Avviate il “prompt dei comandi” (start -> esegui -> cmd.exe) e digitate:

ping 151.1.1.1

Nel caso abbiate una risposta dal server (vedi screenshot) la vostra connessione (senza DNS) è perfettamente funzionante e potete proseguire al cambio DNS, mentre nello sfortunato caso in cui i ping non siano costanti oppure si riceva un messaggio di “richiesta scaduta” vi consiglio di verificare la copertura del segnale ed eventualmente di chiamare l’assistenza Vodafone per degli accertamenti.

SPIEGAZIONE: questo problema potrebbe verificarsi nel caso in cui la vostra chiavetta Internet non prenda correttamente i DNS forniti dalla rete (vedi note), oppure più semplicemente tali DNS sono temporaneamente irraggiungibili. Molti in rete consigliano a tal proposito di sostituire i DNS di Vodafone con quelli di OpenDNS (o altro). Ma cosa sono i DNS? Oltre alla definizione di Wikipedia posso dirvi in poche parole che sono dei server che permettono di tradurre gli indirizzi nominali (es.www.google.com) in indirizzi IP comprensibili dalle macchine (es. 151.1.1.1). Nella prova precedente abbiamo quindi provato a contattare un server senza chiedere al DNS di tradurre per noi il nome, in questo modo abbiamo verificato la funzionalità della rete senza DNS.

RISOLUZIONE: la soluzione più veloce per sopperire al problema di DNS malfunzionanti è ovviamente quella di cambiarli! Nelle attuali connessioni create dal famoso programmino VMC Lite le modifiche dirette sono inutili, perchè ad ogni avvio del programma la connessione visibile in “connessioni di rete” viene reimpostata. Per modificarla seguite quindi i seguenti passaggi:

• avviate “Vodafone Mobile Connect Lite”
• andate nel menu Impostazioni e selezionate APN
• selezionate Impostazioni APN manuali
• inserite nel campo APN l’indirizzo: web.omnitel.it
• lasciate vuoti i campi ID utente e password
• inserite quindi i campi DNS primario e secondario desiderati (es: DNS1:208.67.222.222DNS2: 208.67.220.220)

Alla successiva riconnessione avrete dei nuovi DNS server molto più performanti e le vostre navigazioni non dovrebbero più avere problemi.

NOTE: un paio di clienti (che dispongono di vecchie Vodafone key) mi avvertono che da un paio di settimane la loro connessione ha smesso di funzionare. Da verifiche risulta che i DNS assegnati in fase di connessione da Vodafone (83.224.66.134 e 83.224.65.134) non sono più attivi. La cosa strana è che aggiornando il software VMC Lite e il Firmware della chiavetta all’ultima versione disponibile nel sito Vodafone i DNS cambiano e la connessione riprende a funzionare. Quindi se disponete di una vecchia versione avvalorate anche questa opzione.

Nel mio caso mi son ritrovato a combattere con un Word 2007 impazzito, nello specifico il programma si avviava ma la clessidra (o cerchietto rotante) rimaneva sempre in esecuzione rendendo difatti il programma inusabile. A volte il bravo tecnico deve conoscere il giusto momento di arrendersi e il mio è arrivato dopo due ore di prove (disattivazione plugin, componenti aggiuntivi e reinstallazioni varie). Ho quindi optato per ricreare il profilo (dato che con la creazione di un nuovo utente il problema non si ripresentava) e mi sono scontrato con alcuni piccoli cambiamenti apportati in Vista.

Ricreazione nuovo profilo in Vista:

Quando le cose iniziano ad andar male e il tuo profilo è stato gravemente danneggiato da un Virus/Malware o affini è necessario farsi una copia di sicurezza e provvedere a ricrearlo in toto ricopiando poi i vari documenti e impostazioni (non tutto altrimenti si ritorna al punto di partenza).

In Windows XP era sufficiente cancellare/rinominare (da un utente che non usi il profilo incriminato) la cartella:

C:\Documents and Settings\nome_utente

per ritrovarsi al successivo logon un bel profilo nuovo!

In Windows Vista però le cose si complicano ed è necessario compiere un passaggio in più, pena il ritrovarsi con un profilo “temporaneo” che verrebbe perso al successivo logon (esperienza personale).

Entrate come amministratori (o un utente che non sia quello del profilo da ricreare) cancellate/rinominate la seguente cartella:

C:\Users\nome_utente

Aprite poi il registro di sistema (tasto scorciatoia WINDOWS-R, digitate regedit.exe e OK per confermare) e andate alla chiave di registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Eliminate la chiave S-1-5-xx che identifica il percorso del profilo incriminato.

Riavviate quindi il PC e al successivo logon riavrete nuovamente il profilo nuovo e pulito!

Ulteriori dettagli potete trovarli nel nel Forum di Technet.

Partendo dal presupposto che ogni bravo utente dovrebbe avere a disposizione un backup aggiornato, sappiamo altrettanto bene che quando succedono queste cose, il backup non c’è MAI e il PC contiene SEMPRE dati importantissimi.

Sintomi: avviando il PC e cercando di entrare con un utente il sistema effettua istantaneamente il logoff e veniamo riportati alla schermata iniziale.

Cause: il sistema non riesce a caricare il file indicato nel registro di sistema alla seguente voce:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon

ovvero

“C:\WINDOWS\system32\userinit.exe,”

I motivi per cui il sistema risulta compromesso sono sostanzialmente due:

1. Il file è stato rimosso
2. La chiave di registro punta ad un percorso non valido (ad esempio manca la virgola finale)

Maggiori dettagli: in Internet la stragrande maggioranza di casi imputa tale errore ad un rimozione dello spyware BlazeFind (o qualsiasi altro virus) ad opera di Ad-Aware (o altri software antispyware) che, rimuovendo il file modificato dallo spyware rendono di fatto impossibile il logon. Nel mio caso tuttavia l’infezione era provocata dallo spyware “XP Antispyware 2009″ che contrariamente a Blazefind non modifica la chiave di registro ma direttamente il file userinit.exe rendendo alcune delle seguenti soluzioni inapplicabili.

Soluzione: eccoci quindi arrivati alla parte più interessante, seguirà quindi una lista di possibili interventi da effettuare nel vostro PC al fine di ripristinarne il funzionamento (o se non altro l’accesso) in ordine di complessità.

Ovviamente dato che il sistema non è avviabile dovrete dotarvi di apposita live distro (personalmente consiglio MiniPE, ma vanno benissimo tutte), in alternativa se siete fortunati potrete entrare in modalità provvisoria:

1. Controllate la succitata chiave di registro e assicuratevi che non punti a percorsi strani e che sia presente la “virgola” alla fine del percorso. Nel caso in cui la chiave fosse stata alterata da un virus, potete optare per ripristinare il percorso corretto tramite regedit oppure tramite Recovery console potrete copiare rinominandolo il file userinit.exe con il nome identificato nel registro (es. copy C:\Windows\system32\userinit.exe C:\Windows\system32\wsaupdater.exe).
2. Verificate la presenza del file userinit.exe nella cartelle system32. Se non fosse presente ripristinatelo da un backup, dalla cartella system32 di un sistema gemello, o come nel mio caso dalla cartella di backup del ServicePack C:\WINDOWS\ServicePackFiles\i386.
3. Ultima possibile soluzione, valida unicamente nel caso in cui il sistema si avvii in modalità provvisoria, scaricate il programma Autoruns e provvedete alla disabilitazione selettiva di tutti i programmi che vengono caricati al logon, quasi sicurametne sarà uno di questi a provocare l’immediata disconnessione.

E con questo è tutto! Buona fortuna!

Il nome server del certificato SSL non è corretto. ID: c103b404

L’errore sembra si verifichi solo in alcune installazioni di Windows2003 (o SBS2003), quando il nome indicato nel certificato SSL installato in IIS non corrisponde al FQDN del server locale. Il problema non si riscontra in installazione di Exchange Front-end/Back-end.

Errore ricevuto a video

Per tale codice di errore la KB di Microsoft suggerisce di rimuovere la crittografia obbligatoria dalla cartella Exadmin del sito web predefinito. Tuttavia, nel mio caso e in molti altri il problema persiste.

Ecco quindi la soluzione al problema tramite l’uso di ADSIEdit:

1 – Installate ADSIEdit (reperibile dal CD dei support tools di Windows)

2 – Avviate la Microsoft Management console (tart->Run->MMC)

3 – Aprite il file ADSIedit.msc (che troverete nella cartella dei Support Tools)

4 – Andate quindi alla seguente voce:

Configuration > Services >  Microsoft Exchange > Domain Name > Administrative Groups >     First Administrative Group > Servers > Servername > Protocols > HTTP > 1 > Exadmin

5 – Tasto destro e selezionate proprietà di

msExchSecureBindings

6 – Selezionate e quindi rimuovete la voce 443, chiudete con OK.

Clicca sull'immagine per ingrandire

7 – Per applicare le modifiche assicuratevi di aver riavviato IIS e l’Exchange System Attendant

]]> http://www.ildisinformatico.com/2009/01/the-ssl-certificate-server-name-is-incorrect-id-c103b404/feed/ 0 http://www.ildisinformatico.com/2009/01/change-the-store-limits-in-exchange-2003-sp2/ http://www.ildisinformatico.com/2009/01/change-the-store-limits-in-exchange-2003-sp2/#comments Thu, 15 Jan 2009 16:39:19 +0000 Bertoweb http://www.ildisinformatico.com/?p=32 Di default la dimensione massima di ogni database in Exchange 2000/2003 è di 16GB. Con l’introduzione del Service Pack 2 Microsoft ha impostato il limite a 18GB e “concesso” alle versioni Standard e SBS2003 di alzarlo  fino a 75GB.

Ma come viene effettuato il controllo della dimensione del database? Eccolo spiegato:
Tutte le mattine alle ore 5.00 (parametro configurabile) il sistema effettua un controllo del database e se lo spazio occupato è arrivato al 10% della dimensione massima impostata (altro parametro configurabile) viene segnalato il problema nel registro eventi. Se però tale soglia al successivo controllo dovesse nuovamente essere superata, il database viene messo offline (per evitare corruzioni) e nel registro applicazioni viene visualizzato il seguente evento di errore ID 9689.

Ma vediamo ora la procedura per personalizzare questi limiti:

1. Avviare regedit.exe sul Server che esegue Exchange.

2. Aprire una delle seguenti chiavi di registro:

Impostazioni database delle cassette postali:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\Server name\Private-Mailbox Store GUID

Impostazioni database delle cartelle pubbliche:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\Server name\Public-Public Store GUID

dove in “Server name” sarà presente il nome del vostro Server Exchange.

Chiave di registro per la modifica dei limiti (clikka per ingrandire)

3. Per modificare la dimensione massima del database:

create una nuova DWORD denominata “Database Size Limit in Gb” e assegnategli il valore desiderato in “DECIMALE“:

- Per Exchange Server 2003 Standard Edition digitate un valore tra 1 e 75 (predefinito è 18)

- Per Exchange Server 2003 Enterprise Edition digitate un valore tra 1 e 8000 (predefinito è 8000)

Limitare il database in un Exchange Enterprise è caldamente consigliato nel caso non disponiate dello spazio su disco sufficiente ad ospitare 8TB di database.

4. Per modificare la soglia di avviso di dimensione massima:

create una nuova DWORD denominata “Database Size Buffer in Percentage” e assegnategli un valore “DECIMALE” compreso tra 1 e 100 (predefinito è 10).

5. Per modificare l’ora in cui viene eseguito il controllo della dimensione del database:

create una nuova DWORD denominata “Database Size Check Start Time in Hours From Midnight” e assegnategli un valore “DECIMALE” compreso tra 0 e 23 (predefinito è 5).

6. Chiudete quindi il registro di sistema. Da notare che le modifiche saranno applicate solo dopo aver smontato e rimontato l’archivio, oppure dopo aver riavviato il servizio “archivio informazioni di Microsoft Exchange”

Ciao a tutti.

Una breve introduzione a cosa sono e a cosa servono: i wmi consistono in una serie di oggetti che permettono la gestione, il controllo e la manutenzione semplificata delle componenti del sistema operativo. Senza di essi molte delle applicazioni installate potrebbero non funzionare correttamente.

In caso di corruzione dei WMI il sistema risulta instabile e in particolar modo il database SQL server 2005 smette di funzionare.

Uno dei possibili errori durante l’esecuzione del setup di SQL Server potrebbe essere il seguente (nel mio caso):

The SQL Server System Configuration Checker cannot be executed due to WMI configuration on the machine JEFF-2007 Error:2147749896 (0×80041008).

Motivi di corruzione posso essere errori di disco, corruzione di dati, arresti inattesi, e altro. Raramente si presentano problemi in condizioni normali di lavoro. Ma ora passiamo alle soluzioni.

Ricostruzione del repository dei WMI – Rebuilding the WMI Repository

Windows XP:

Fare Click su Start, Esegui e scrivere CMD.EXE

Al prompt dei comandi digitare

net stop winmgmt

Rinominate poi la seguente cartella e fate ripartire il servizio

%windir%\System32\Wbem\Repository (es. in %windir%\System32\Wbem\Repository.old)

net start winmgmt

Windows XP SP2:

Fare Click su Start, Esegui e scrivere CMD.EXE

Al prompt dei comandi digitare

rundll32 wbemupgd, UpgradeRepository

Il comando rileva e ripara il repository dei WMI. Il risultato dell’operazione è visibile in %windir%\system32\wbem\logs\setup.log

Windows Vista:

Aprite la console con poteri elevati (su accessori) oppure avviate il prompt dei comandi con tasto destro “avvia come administrator”.

Al prompt dei comandi digitare

winmgmt  /salvagerepository

Il comando effettua un test di consistenza del repository ed eventualmente effettua una riparazione.

Windows 2003:

Al prompt dei comandi digitare

rundll32 wbemupgd, RepairWMISetup

Registrazione componenti – Re-registering the WMI components

Se però doveste avere qualche file .dll e .exe che non sono più registrati nel sistema ecco la procedura per ri-registrarli. I file .exe e .dll utilizzati dai componenti WMI si trovano in %windir%\system32\wbem, nel caso abbiate un sistema a 64bit dovete registrare anche i componenti presenti in %windir%\sysWOW64\wbem.

cd /d %windir%\system32\wbem
for %i in (*.dll) do RegSvr32 -s %i
for %i in (*.exe) do %i /RegServer

ed infine per i casi più gravi ecco la procedura per ripristinare i file utilizzati dai WMI che sono andati persi e/o cancellati:

Ripristino file WMI – Comprehensive rebuild method

Fare Click su Start, Esegui e scrivere CMD.EXE

Al prompt dei comandi digitare

rundll32.exe setupapi,InstallHinfSection WBEM 132 %windir%\inf\wbemoc.inf

Inserite quando richiesto il CD di Microsoft Windows (attenzione ad inserire quello con la corretta versione del service pack), in alternativa utilizzate il seguente percorso: %Windir%\ServicePackFiles\i386.

Il processo di riparazione impiegherà alcuni minuti, dopodiché è necessario riavviare windows.

Buon lavoro!

Se quindi durante l’accesso ad un sito in HTTPS, sia durante il login sia durante l’utilizzo, il browser vi restituisce il classico errore “Impossibile visualizzare la pagina”, è probabile che ricadete in questo caso.

Effettuate i seguenti passi per ripristinare il funzionamento del sito:

1. Aprire Internet Explorer, Selezionare il menù “Strumenti” e cliccare sull’ultima voce “Opzioni Internet”

2. Andare quindi nel menù “Avanzate”, scorrere le voci fino alla fine e verificare che l’opzione “Usa TLS 1.0” sia selezionata”

3. Chiudere e riaprire Internet Explorer. Verificate che il problema sia stato risolto.

Un particolare ringraziamento in merito a questo articolo va a Sistemista Junior che mi ha segnalato la cosa e ha provveduto minuziosamente a preparare gli screenshot! Grazie!