Shrink log file in un database SQL Server

Se non si effettua un regolare backup del database sql server, può succedere che il file di log cresca molto in dimensioni, arrivando a saturare il disco.

E’ possibile con la seguente query effettuare lo shrink del file di log, liberando lo spazio necessario.

USE [DATABASE]
GO
ALTER DATABASE [DATABASE] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC SHRINKFILE(“[NOME_LOGICO_LOGFILE]”, 1)
ALTER DATABASE [DATABASE] SET RECOVERY FULL WITH NO_WAIT
GO

Il nome logico del file di log è visibile nelle proprietà del database stesso.

Ubuntu failed to get udev uid: Invalid argument

Su una macchina virtuale VMware, anche subito dopo l’installazione probabilmente troverete il file syslog pieno di questi errori

Jul 16 14:15:42 database06 multipathd[383021]: sdb: triggering change event to reinitialize
Jul 16 14:15:42 database06 multipath: sdb: failed to get udev uid: Invalid argument
Jul 16 14:15:42 database06 multipath: sdb: failed to get sysfs uid: Invalid argument
Jul 16 14:15:42 database06 multipath: sdb: failed to get sgio uid: No such file or directory
Jul 16 14:15:42 database06 multipathd[383021]: sdb: failed to get udev uid: Invalid argument
Jul 16 14:15:42 database06 multipathd[383021]: sdb: failed to get unknown uid: Invalid argument
Jul 16 14:15:42 database06 multipathd[383021]: sdb: failed to get path uid
Jul 16 14:15:42 database06 multipathd[383021]: uevent trigger error

Il problema è risolvibile modificando la configurazione del servizio multipathd, ed in particolare aggiungendo le seguenti righe al file /etc/multipath.conf

blacklist {
    device {
        vendor "VMware"
        product "Virtual disk"
    }
}

successivamente riavviare il servizio

service /etc/init.d/multipath-tools restart

Visualizzare lo stato del servizio fail2ban

Il post che segue è un vero e proprio foglio di appunti, in modo che anche io possa ritrovare in seguito questo comando utilissimo a capire lo stato del servizio fail2ban su tutte le entità monitorate.

Il comando è:

JAILLIST=($(fail2ban-client status | awk -F’:’ ‘/Jail list:/ {print $2}’)); for (( n=0; n<${#JAILLIST[@]}; n++)); do fail2ban-client status ${JAILLIST[$n]//,/}; done

va immesso in un’unica riga, e ritorna l’elenco delle entità monitorate da fail2ban con il dettaglio degli ip bannati

Blue screen al lancio di una stampa dopo aggiornamento di Windows 10

Dopo l’aggiornamento del 9 marzo 2021 gli utenti di windows 10 versione 20H2 e 1909 hanno notato l’impossibilità di stampare a seguito dell’errore APC_INDEX_MISMATCH in un noiosissimo bluescreen. Il problema si verifica con le stampanti Kyocera, Utax, Triumph Adler, Gestetner, Olivetti.

La soluzione è la disinstallazione dell’aggiornamento KB50000808 (per Windows 10 1909) oppure del KB50000802 (per Windows 10 20H2), oppure l’installazione dell’ultimo driver PCL6.

Per una rapida risoluzione del problema procedere come segue:

Cliccare su start e selezionare impostazioni

Selezionare Aggiornamento e sicurezza

Cliccare su Sospendi aggiornamenti per 7 giorni (sperando sia sufficiente per attendere il rilascio di un aggiornamento corretto) 

Cliccare su Visualizza cronologia aggiornamenti

Cliccare su disinstallare gli aggiornamenti

Selezionare l’aggiornamento KB50000808 (oppure KB50000802) e cliccare su disinstalla

Attendere il termine dell’operazione e riavviare il pc.

Per i più esperti è possibile disinstallare l’aggiornamento da riga di comando con:

wusa /uninstall /kb:5000802

oppure per l’aggiornamento kb5000808

wusa /uninstall /kb:5000808

 

Microsoft ha appena reso disponibile un workaround in attesa del rilascio di una patch aggiornata. E’ possibile consultare le indicazioni a questo link

https://docs.microsoft.com/en-au/windows/release-health/status-windows-10-2004#1570msgdesc

Buon divertimento!

 

Troubleshooting Connessione Exchange Hybrid Configuration Wizard

Hybrid Configuration Wizard è un tool indispensabile per creare i connettori che gestiscono il flusso di posta interno durante una migrazione su Office 365 da un Exchange on-premisis. Come spesso accade la configurazione richiede pochi click ed è molto intuitiva, ma può capitare di incorrere in problemi come ad esempio errori di connessione, ed il log generato dal tool a volte è davvero poco di aiuto per risolverli.

Butto giù due righe su quello che mi è capitato, e spero che faccia risparmiare a qualcuno un po’ di tempo.

Nel mio caso avevo un errore di connessione verso Office 365, come si vede dal seguente screenshot

Individuato il file di log nella cartella:

%appdata%\Microsoft\Exchange Hybrid Configuration\

L’unica riga significativa era la seguente

2020.05.29 17:58:24.321 WARNING 10079 [Client=UX, Activity=Tenant Connection Validation, Thread=6] La connessione al server remoto non è riuscita con il messaggio di errore seguente: Connessione al server remoto non riuscita con il seguente messaggio di errore: Impossibile stabilire la connessione SSL. Verificare che il servizio nell’host remoto sia configurato correttamente per l’ascolto di richieste HTTPS. Consultare i registri e la documentazione del servizio WS-Management in esecuzione nella destinazione, nella maggior parte dei casi IIS o Gestione remota Windows. Se la destinazione è il servizio Gestione remota Windows, eseguire il comando seguente per analizzare e configurare il servizio Gestione remota Windows: “winrm quickconfig -transport:https”. Per ulteriori informazioni, vedere l’argomento della Guida about_Remote_Troubleshooting.

Non diceva quindi niente di più di quanto già letto nella schermata precedente.

Per analizzare meglio lo scambio di dati con il server remoto ho quindi abilitato il network trace sulla macchina dove stavo installando HCW, utilizzando questo comando da un prompt di comandi con privilegi elevati:

netsh trace start persistent=yes capture=yes tracefile=c:\temp\trace.etl

Consiglio di eseguire questa operazione immediatamente prima di confermare l’ultimo step in cui si verifica l’errore, in modo da evitare la cattura di pacchetti che possono generare confusione

Ho quindi riprodotto l’errore sul tool HCW e subito dopo interrotto il trace con

netsh trace stop


A questo punto ho convertito il file trace.etl che è stato generato nella cartella temp per renderlo leggibile da Wireshark, un analizzatore di rete che utilizzo in questi casi, e che non è però in grado di aprire direttamente i file di tipo etl.

Per la conversione ho utilizzato Microsoft Message Analyzer, un tool deprecato e quindi non semplicissimo da trovare in rete, scaricandolo da qui

https://download.microsoft.com/download/7/1/0/7105C7FF-768E-4472-AFD5-F29108D1E383/NM34_x64.exe

Ho semplicemente aperto il file e subito dopo salvato scegliendo estensione .cap

Ho potuto a quel punto aprire il file trace.cap con wireshark (potete scaricare wireshark da qui https://www.wireshark.org/download.html)

Da quel momento è tutto in mano alla fantasia, è possibile utilizzare i filtri per isolare le righe interessanti tra le migliaia che troverete

Io ho usato questo metodo ma ovviamente ognuno è libero di gestire la situazione a proprio vantaggio in maniera diversa:

– impostato la visualizzazione del nome dns invece dell’ip
– ordinato la colonna destination per ip
– cercato qualcosa che comunicasse con “microsoft”, “office”
– individuato un pacchetto verso zrh-efz.ms.acdc.office.com
– tasto destro sul pacchetto -> segui -> Flusso SSL (perché l’errore che avevo era sul protocollo SSL)

 

A questo punto ho notato dei tentativi di connessione con protocollo SSLv3 a cui non veniva data risposta, ed ho immaginato che potesse dipendere dal protocollo SSLv3 disabilitato

 

Cosi, come indicato nella pagina https://support.microsoft.com/it-it/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

Ho modificato le seguenti chiavi di registro per abilitare SSLv3

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

creando una chiave di tipo DWORD chiamata DefaultSecureProtocols con valore esadecimale 00000800

Ho riavviato poi il server per attivare l’impostazione, e quindi rilanciato il wizard.

La connessione a questo punto è andata a buon fine

 

Errore nella connessione di Outlook ad Exchange 2010 on-premises

Ho riscontrato un errore nella mia configurazione di test di un server Exchange 2010 SP2 Rollup update 27, che causava l’impossibilità di connettere un client remoto Outlook.
Il problema era dovuto al malfunzionamento della feature “RPC over HTTP”, un componente di IIS necessario per il login remoto.
Il componente infatti si occupa di “girare” le richieste di autenticazione NTLM al server exchange utilizzando la sola porta Https 443.
Nel mio caso ho indivuato l’errore con un test di connettività effettuato su https://testconnectivity.microsoft.com, che restituiva l’errore:

Testing HTTP Authentication Methods for URL https://exchange2010.virtuopia.it/rpc/rpcproxy.dll?EXCHANGE2010.migrationdemo.local:6002.
The HTTP authentication test failed.

Navigando direttamente sull’url del proxy RPC infatti ottenevo il seguente errore:

Server Error in ‘/Rpc’ Application.
Runtime Error

Questo indicava un’eccezione generata dal componente RPC, e ricercando nell’event log ho individuato questo errore:

Log Name: Application
Source: ASP.NET 4.0.30319.0
EventID: 1310

Event code: 3008
Event message: A configuration error has occurred.
Event time: 7/6/2019 9:04:40 AM
Event time (UTC): 7/6/2019 9:04:40 AM
Event ID: 30da70481e1447e9917f9b757e038855
Event sequence: 1
Event occurrence: 1
Event detail code: 0

Exception information:
Exception type: ConfigurationErrorsException
Exception message: Could not load type ‘System.ServiceModel.Activation.HttpModule’ from assembly ‘System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’.

A questo punto ho utilizzato il comando aspnet_regiis per registrare le associazioni della versione corretta del .NET Framework all’interno dell’IIS.

cd %windir%\Microsoft.NET\Framework64\v4.0.30319

aspnet_regiis.exe /iru

Ora provando a navigare sull’URL del Proxy RPC la pagina richiedeva l’autenticazione, segno che l’esecuzione dello stesso andava a buon fine senza generare eccezioni.

Anche Outlook, a questo punto, si è connesso senza problemi.

Impossibile installare VMware-ClientIntegrationPlugin

Se ottenete un errore durante l’installazione di VMware-ClientIntegrationPlugin-6 per l’integrazione dei componenti client di VMWare all’interno del browser eseguite la i seguenti passi:

Quando visualizzate l’errore “There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor” NON cliccate su OK e NON chiudete il popup.

Aprite la cartella %temp% e sfogliate l’interno delle cartelle temporanee create dall’installer di VMWare (sono quelle create più di recente), troverete all’interno il file vcredist_x86.exe

Copiate il file vcredist_x86 in un’altra posizione (ad esempio sul desktop) e solo a questo punto chiudete il popup di errore.

Eseguite l’installazione di vcredist_x86 e successivamente reinstallate il VMWare client.

Nessun server di accesso disponibile per soddisfare la richiesta di accesso

Su un domain controller Windows 2012 R2 mi è capitato che dopo aver installato degli aggiornamenti e programmato un riavvio notturno, l’indomani risultava impossibile effettuare i login sulle macchine della LAN.
Non era nemmeno possibile effettuare il login in locale sul DC stesso, poichè si riceveva questo errore:
“Nessun server di accesso disponibile per soddisfare la richiesta di accesso”

L’errore stava ad indicare l’impossibilità di contattare un domain controller in fase di login, ma essendo il server stesso DC, la situazione era sicuramente da ricondurre ai servizi Active Directory non avviati.

E’ stato possibile effettuare il login con un utente amministratore locale, così da effettuare un po’ di troubleshooting, notando che il server era avviato in modalità provvisoria.

Evidentemente qualcosa nell’installazione degli updates o nel riavvio notturno non era andata a buon fine ed il sistema era in modalità di ripristino, così per tornare alla normalità è stato sufficiente:

– avviare msconfig da riga di comando
– da Opzioni di avvio togliere il flag Modalità provvisoria
– riavviare

A questo punto il server, avviato regolarmente, è di nuovo in grado di erogare i servizi di Active Directory.

In arrivo Windows Subsystem for Linux 2

Microsoft ha appena annunciato nella Build 2019 conference che in estate sarà disponibile la versione 2 di Windows Subsystem for Linux.
La nuova versione di questa particolare funzionalità promette performance molto più elevate, poichè dopo l’ottimizzazione delle risorse CPU e RAM si sta lavorando sul miglioramento delle operazioni di accesso in I/O sullo storage.
Un’altra grande novità sarà il supporto nativo per Docker; in questo modo sarà possibile far girare i containers senza installare alcun software aggiuntivo!
Il nuovo WSL 2 sarà basato sulla versione 4.19 del kernel Linux.