Come inviare messaggi obbligatori ai PC della rete aziendale (dopo la fine di net send)

Il problema: gli strumenti di Windows non ci sono più

Chi lavora nell’IT da abbastanza tempo ricorda net send: un comando, un nome di computer, un messaggio, e sul PC di destinazione compariva un pop-up. Funzionava grazie al servizio Messenger di Windows, che Microsoft ha disattivato per default con Windows XP SP2 e rimosso completamente da Windows Vista in poi, perché era diventato un vettore di spam e di attacchi in rete.

Il sostituto ufficiale è msg.exe. Sulla carta fa la stessa cosa. Nella pratica, chi prova a usarlo oggi su una rete Windows 10 o 11 si scontra quasi sempre con la stessa sequenza di ostacoli:

• Non è incluso nelle edizioni Home di Windows: su metà dei PC di un ufficio piccolo il comando semplicemente non esiste.
• Richiede una chiave di registro sul PC di destinazione (AllowRemoteRPC a 1) e un riavvio, da fare postazione per postazione.
• Richiede credenziali amministrative valide sulla macchina remota e il traffico RPC aperto sul firewall, cosa che in reti con criteri di sicurezza decenti è chiusa apposta.
• Restituisce l’errore 5 (accesso negato) o 1722 (RPC non disponibile) con una frequenza tale che la maggior parte dei thread di supporto si chiude con “usa un altro strumento”.
• E soprattutto: non dice mai se il messaggio è stato letto. Nessuna ricevuta, nessuno storico, nessuna prova.

L’alternativa commerciale esiste — piattaforme di internal communication e di alerting aziendale — ma quasi sempre significa un server da installare, un canone per postazione, un account cloud e i dati che escono dalla rete. Per una comunicazione interna che deve solo dire “fermiamo la linea 2”, è una risposta sproporzionata.

La domanda giusta: non “mandare”, ma “far confermare”

Il punto che cambia il progetto è questo. Il problema non è tecnicamente recapitare un messaggio: quello lo fa già la mail. Il problema è ottenere la prova che qualcuno l’ha visto — e renderlo impossibile da ignorare mentre succede.

Da lì nascono i tre requisiti che hanno guidato tutto il resto:

1. La notifica deve occupare lo schermo e non deve essere chiudibile se non con un gesto esplicito di presa visione.
2. Quel gesto deve lasciare una traccia scritta: chi, quale messaggio, a che ora.
3. Il sistema deve funzionare senza aggiungere infrastruttura a una rete che già esiste e che nessuno vuole toccare.

La soluzione: MustRead

MustRead è un’applicazione desktop Windows (.NET 8, WinForms) che gira silenziosa nella system tray di ogni postazione. Quando un utente autorizzato invia un messaggio, sul PC del destinatario compare una finestra a schermo intero, sempre in primo piano, senza pulsante di chiusura, senza ESC, senza Alt+F4. L’unico modo per toglierla è cliccare “HO LETTO” — e quel clic viene registrato.

Il mittente può scegliere tre destinazioni: un utente Windows specifico, un computer specifico, oppure tutti in broadcast.

L’architettura: una cartella condivisa, e basta

Questa è la decisione di progetto di cui sono più convinto. MustRead non ha un server. Non ha un database. Non ha un backend da aggiornare, mettere in sicurezza o pagare. Usa una sola cosa che in ogni rete Windows aziendale è già presente e già funzionante: una cartella condivisa SMB.

Il flusso è volutamente banale, ed è proprio questo il pregio:

1. Il mittente scrive il messaggio e sceglie i destinatari.
2. MustRead lo salva come file JSON nella sottocartella giusta della condivisione: inbox\users\, inbox\computers\ oppure inbox\all\.
3. Su ogni PC l’applicazione controlla quelle cartelle a intervalli regolari (di default ogni 3 secondi, configurabile).
4. Appena trova un file destinato a sé, apre la finestra a schermo intero.
5. Al clic su “HO LETTO” scrive la conferma nello storico e non mostra più quel messaggio.

Le conseguenze pratiche di questa scelta valgono più di qualsiasi funzionalità aggiuntiva. Non c’è niente che possa andare giù: se la rete funziona, MustRead funziona. Niente Internet: tutto resta dentro la LAN. Nessun privilegio di amministratore per ricevere le notifiche. E la sicurezza non è un sistema di permessi da inventare, ma quella che l’azienda ha già configurato: i permessi NTFS della cartella.

I due problemi che la semplicità non risolve da sola

Un’architettura a file condivisi ha due punti dolenti noti, e vanno affrontati o il sistema è inaffidabile.

Il primo è la concorrenza sui file. Più PC che leggono e scrivono gli stessi file di storico contemporaneamente, su SMB, portano a scritture perse o file corrotti. Lo storico è gestito in formato JSON Lines (un evento per riga, in append) e ogni accesso passa da un helper dedicato che riprova in caso di lock del file. Tre registri separati: messaggi inviati, messaggi mostrati a schermo, conferme di lettura.

Il secondo è la doppia notifica. Se il timer ricontrolla la cartella ogni 3 secondi mentre una finestra è ancora aperta, rischia di riaprire lo stesso avviso più volte — il modo più rapido per far odiare uno strumento agli utenti. Il ricevitore tiene quindi due elenchi distinti: i messaggi già confermati e quelli attualmente a schermo o in attesa di conferma. È una distinzione sottile che copre proprio la finestra temporale fra “mostrato” e “confermato”, dove altrimenti l’avviso si duplicherebbe.

Sono dettagli invisibili all’utente finale. Sono esattamente il tipo di dettagli che separano un prototipo da qualcosa che si può lasciare acceso in produzione.

Le cose che servono davvero in azienda

• Consegna differita. Se un PC è spento, il messaggio resta nella coda e compare al primo avvio successivo. Nessun avviso va perso perché qualcuno era in ferie.
• Presenza in tempo reale. Ogni client scrive periodicamente un file di heartbeat: chi invia vede l’elenco di chi è effettivamente collegato in quel momento.
• Sessioni RDP e Terminal Server. L’identificativo del client include l’ID di sessione, così sullo stesso server più utenti in Remote Desktop restano distinti e ognuno riceve il proprio messaggio.
• Mittenti autorizzati. Un file di configurazione sulla condivisione elenca chi ha il diritto di inviare. Senza quella lista, un sistema di avvisi impossibili da chiudere diventa uno scherzo di pessimo gusto fra colleghi.
• Avvio automatico senza amministratore. La voce viene registrata in HKCU, la parte di registro dell’utente corrente: non serve un tecnico con credenziali di dominio per ogni postazione.

I numeri del progetto

I 104 test non sono un vezzo. Un’applicazione che scrive file condivisi da più macchine contemporaneamente ha un comportamento difficile da verificare a mano: la suite copre i modelli dati, i sette servizi e gli helper di lock e serializzazione, ed è quello che permette di modificare la logica di polling senza scoprire tre settimane dopo che un reparto non riceve più gli avvisi.

Quello che MustRead non fa (e perché lo scrivo qui)

Un caso studio che elenca solo i pregi è pubblicità. Questi limiti sono documentati nel progetto stesso, e chiunque valuti uno strumento del genere deve conoscerli prima:

• Non recapita nulla a un PC spento o ibernato: il messaggio aspetta il prossimo avvio.
• Non compare sulla schermata di login né supera il blocco schermo: l’avviso arriva quando l’utente ha sbloccato la sessione.
• Un amministratore locale può terminare il processo dal Task Manager. La finestra è a prova di distrazione, non a prova di sabotaggio.
• I messaggi sono file JSON in chiaro: la riservatezza è affidata ai permessi della cartella. Non è lo strumento adatto a dati sensibili.
• Non è un sistema di emergenza certificato e non sostituisce allarmi antincendio, PEC o notifiche a valore legale.

Detto in una riga: MustRead risolve il problema di chi non legge, non il problema di chi vuole deliberatamente non leggere. Per la comunicazione operativa quotidiana, è esattamente il confine giusto.

Perché racconto un progetto interno su questo sito

MustRead è nato da un’esigenza concreta e ha seguito il percorso che seguono tutti i software su misura che costruisco: un problema che nessun prodotto sullo scaffale risolveva alla giusta scala, un’analisi di quello che l’azienda ha già, e una soluzione costruita intorno a quel vincolo invece che contro.

È lo stesso metodo che uso quando un’attività mi chiede un gestionale su misura o quando serve sostituire un foglio Excel diventato ingestibile: prima capire cosa esiste già e cosa non si può toccare, poi scrivere il codice. Il risultato, quasi sempre, è più piccolo e più solido di quello che si immaginava all’inizio.

Il codice di MustRead è pubblico con licenza MIT su GitHub, con la documentazione di installazione, il deployment su Terminal Server e l’elenco completo delle limitazioni.