Impossibile avviare SQL Server 2019 su Windows 11

Talvolta installando Microsoft SQL Server 2019 su Windows 11 risulta un errore al termine dell’installazione, ed è impossibile avviare il servizio.

L’errore ricevuto in fase di installazione è “Impossibile trovare l’handle di avvio del motore di database”; provando ad avviare il servizio, inoltre, si riceve “Errore 1067: processo terminato in modo imprevisto. Impossibile avviare il servizio SQL Server nel computer locale”.

L’errore è dovuto al fatto che a volte Windows 11 non riporta correttamente la dimensione del cluster disco, e ricordiamo che SQL server supporta l’installazione solo su unità che hanno una dimensione di settori di 4KB.

E’ possibile risolvere il problema eseguendo questi semplici passaggi:

1) Disinstallare SQL Server

2) Aggiungere una chiave di registro, ad esempio eseguendo un prompt di comandi da amministratore e lanciando il comando

REG ADD “HKLM\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device” /v “ForcedPhysicalSectorSizeInBytes” /t REG_MULTI_SZ /d “* 4095” /f

3) Riavviare il computer

4) Reinstallare SQL Server

Il servizio verrà così installato correttamente e potrà essere avviato.

 

Outlook 2013 Modern Authentication

Molti utenti stanno rilevando difficoltà nella connessione agli account di Microsoft Exchange Online; il server risulta disconnesso e viene richiesta continuamente l’immissione della password. Sulla barra di stato di Outlook, inoltre, è scritto Password Necessaria.

All’apertura di Oultook, o cliccando sulla barra di stato in corrispondenza del messaggio relativo alla password si aprirà la finestra per l’immissione delle credenziali.

L’inserimento delle stesse, però, non risolverà il problema, premesso ovviamente che siano corrette, e vediamo perché.

E’ proprio il tipo di finestra che ci suggerisce la soluzione, incidando che il nostro Outlook utilizza Basic Authentication, ed in questi giorni Microsoft ha definitivamente disabilitato questo tipo di autenticazione in favore della Modern Authentication, per motivi di sicurezza.

Così la connessione ai servizi di posta sarà permessa unicamente ai client che utilizzano, la nuova modalità di autenticazione, ma il suo utilizzo dipende dal client in uso.

In particolare su Office 2010 non è supportata, e su Outlook 2013 non è abilitata di default, sarà quindi necessario eseguire delle operazioni. Outlook 2016 e successivi, invece, compreso Outlook 365, hanno questa modalità abilitata di default, e non sono quindi interessate dalla disattivazione del metodo obsoleto.

Su Outlook 2013 sarà necessario creare o modificare le seguenti chiavi di tipo DWORD assegnando valore 1:

HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version

Per facilitare l’operazione è possibile salvare con estensione .reg il testo seguente in un file, ed eseguirlo.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Exchange]
“AlwaysUseMSOAuthForAutoDiscover”=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common]

[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Identity]
“EnableADAL”=dword:00000001
“Version”=dword:00000001

Al successivo riavvio di Outlook (non è necessario riavviare il computer) ci verranno richieste le credenziali, ma questa volta con la finestra relativa alla Modern Authentication

Una volta inserite, sarà di nuovo possibile utilizzare l’account di posta elettronica.

Migrazione da FRS a DFSR

Per eseguire la migrazione di active directory da un DC con Windows server 2003 ad un sistema operativo più recente è necessario prima di tutto migrare il servizio che si occupa della replica dei file.

Questo articolo più che una guida è un cheatsheet, e lo pubblico qui in modo da poterlo trovare facilmente, in un formato leggibile speditamente.

Fase 1: Prepared State
dfsrmig /setglobalstate 1

verificare con:
dfsrmig /getmigrationstate

Fase 2: Redirected State
dfsrmig /setglobalstate 2

verificare con:
dfsrmig /getmigrationstate

Fase 3: Eliminated State
dfsrmig /setglobalstate 3

verificare con:
dfsrmig /getmigrationstate

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.