1 16/10/2026 12 min

Prima di lanciare il setup di Lync Server 2013, conviene trattare l’installazione come un cambio controllato, non come un wizard da seguire a occhi chiusi. Il punto critico non è il programma di installazione in sé: è l’allineamento tra Active Directory, DNS, certificati, prerequisiti Windows e connettività tra i server coinvolti. Se uno solo di questi elementi è fuori posto, l’installazione si ferma più avanti, spesso con errori poco leggibili e tempo perso in diagnosi.

La regola pratica è semplice: prima si valida l’ambiente, poi si prepara lo schema AD, poi si installano i ruoli e le feature, infine si esegue il deployment wizard. In questa fase iniziale non serve “fare tutto”; serve verificare che il dominio, i server e la PKI siano coerenti con i requisiti del prodotto. Il risultato atteso è un host Windows Server pronto a ospitare i componenti Lync senza dipendenze mancanti e senza ambiguità di naming.

Architettura minima da avere chiara prima di iniziare

Lync Server 2013 non si installa bene in un ambiente “generico”. Anche in un laboratorio, bisogna distinguere almeno tra dominio Active Directory, server di front-end o back-end, eventuale server edge, infrastruttura DNS e autorità di certificazione. Se il progetto prevede un deployment standard, il server Lync deve essere membro di dominio, con risoluzione DNS interna corretta e accesso ai controller di dominio e alla CA aziendale. Se invece stai preparando un proof of concept, puoi ridurre la complessità, ma non eliminare i prerequisiti fondamentali.

Il prerequisito più sottovalutato è il nome dei server. Il FQDN del server, i record DNS e i certificati devono raccontare la stessa storia. Se il server si chiama lync-fe01.contoso.local, ma il certificato contiene un subject diverso o DNS non risolve correttamente, il wizard può partire ma i componenti successivi no. Lo stesso vale per l’uso di alias, CNAME e split-brain DNS: vanno progettati, non improvvisati.

Primo controllo: sistema operativo, patch e membership di dominio

Lync Server 2013 è sensibile alla versione del sistema operativo e al livello di aggiornamento. Prima di tutto verifica che il server sia una release supportata e che sia stato aggiornato con le patch necessarie. Il controllo base è banale, ma evita errori a cascata. Su Windows Server puoi partire da PowerShell e raccogliere le informazioni essenziali:

systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
wmic os get caption,version,buildnumber

Conferma anche che il server sia membro del dominio e non un host workgroup. In caso contrario, fermati: Lync richiede integrazione stretta con AD per service account, gruppi di sicurezza e pubblicazione degli oggetti dello schema. La verifica rapida la fai così:

systeminfo | findstr /B /C:"Domain"
whoami /fqdn

Se il dominio non è quello atteso, il problema non è del setup ma dell’identità del server. In quel caso la correzione è a monte: join corretto, DNS del dominio impostato sui server interni e sincronizzazione dell’orologio con il dominio. Un offset temporale eccessivo può rompere autenticazione Kerberos e generare errori apparentemente scollegati dal problema reale.

DNS interno: il prerequisito che rompe meno in apparenza ma più in profondità

Per Lync, il DNS non è un dettaglio operativo: è parte del funzionamento. I record A e, dove previsto, i record SRV devono essere coerenti con i nomi che i client e i server useranno. Prima di installare, controlla che il server risolva correttamente il dominio, i domain controller e i nomi che userai per il pool o per il front-end. La verifica minima è questa:

nslookup contoso.local
nslookup lync-fe01.contoso.local
nslookup _ldap._tcp.dc._msdcs.contoso.local

Il primo comando ti dice se il resolver punta al DNS interno corretto. Il secondo verifica il nome host del server. Il terzo controlla la scoperta dei domain controller, utile per escludere un problema di AD o di DNS dinamico. Se uno di questi punti fallisce, non andare avanti con il wizard: sistemare il DNS dopo l’installazione è più costoso e produce sintomi ambigui su autenticazione, discovery e pubblicazione dei servizi.

Se usi split DNS, documenta chiaramente quali zone esistono internamente e quali record devono essere pubblici. Per i deployment con edge, la distinzione tra namespace interno ed esterno va pianificata prima, altrimenti i certificati e i service discovery finiranno fuori allineamento. Un errore frequente è creare il record solo lato pubblico e poi scoprire che il server interno non risolve il namespace usato dal wizard.

Active Directory: schema, permessi e gruppi di sicurezza

L’installazione di Lync Server 2013 richiede preparazione dello schema AD e permessi adeguati per pubblicare la topologia. Qui il punto non è solo “avere un account admin”, ma sapere quale account ha diritto di fare quale operazione. In pratica, il setup tocca schema, foresta, dominio e oggetti di configurazione. Se separi i ruoli, riduci il rischio operativo e hai audit migliore.

Prima di eseguire qualsiasi estensione dello schema, verifica che l’account usato sia davvero quello previsto e che il DC più vicino sia raggiungibile. Un controllo utile è:

whoami /groups
nltest /dsgetdc:contoso.local

Per la preparazione AD, il criterio è semplice: schema master raggiungibile, replica sana, permessi corretti, backup recente. Se la replica AD è in ritardo, puoi propagare oggetti parziali e trovarti con comportamenti diversi tra controller. Prima del change, controlla la salute della directory con strumenti nativi:

repadmin /replsummary
repadmin /showrepl
dcdiag /v

Se emergono errori di replica, risolvili prima di toccare lo schema. Lync non è il punto giusto dove scoprire che un dominio ha problemi di AD replication. Anche in ambienti piccoli, è una cattiva idea procedere con un’infrastruttura directory instabile.

Prerequisiti Windows: ruoli e feature da installare prima del wizard

Una parte del lavoro si può preparare prima con ruoli e feature di Windows Server. L’obiettivo è evitare che il setup debba scaricare o abilitare componenti a metà installazione, con il risultato di allungare i tempi e complicare il troubleshooting. L’elenco esatto dipende dal ruolo che stai installando, ma i prerequisiti tipici includono .NET Framework, Windows Identity Foundation, Media Foundation e vari componenti IIS per i server che ospitano servizi web.

Per avere un quadro ripetibile, conviene usare PowerShell e registrare cosa è presente e cosa manca. Esempio di verifica dei ruoli installati:

Get-WindowsFeature | Where-Object {$_.InstallState -eq 'Installed'} | Select-Object Name,DisplayName

Se devi installare prerequisiti di base, meglio farlo in una finestra di manutenzione e con reboot pianificato. Alcune feature richiedono riavvio e lasciare il server in stato intermedio è il modo più rapido per generare errori successivi. In caso di change controllato, conserva l’elenco dei pacchetti installati e la data del reboot: ti servirà se qualcosa non torna dopo il deployment.

Per IIS e componenti correlati, non limitarti a “installare tutto”. Installa solo ciò che il ruolo richiede. La logica è least privilege anche qui: meno superficie, meno ambiguità, meno tempo perso a capire quale feature ha introdotto il problema. Se il server ospita anche altri servizi, documenta eventuali conflitti prima di proseguire.

Servizi di dominio, ora e connettività: tre controlli che evitano falsi positivi

Lync si appoggia pesantemente su autenticazione integrata e discovery di dominio. Per questo il servizio di ora deve essere coerente con il dominio e la connettività verso i controller deve essere stabile. Se l’orologio è sfasato, Kerberos fallisce; se il server non raggiunge i DC, il setup può dare errori che sembrano di autorizzazione ma sono in realtà di rete o DNS.

w32tm /query /status
w32tm /query /source
ping contoso.local
Test-NetConnection dc01.contoso.local -Port 88
Test-NetConnection dc01.contoso.local -Port 389

Il controllo su porta 88 serve a verificare Kerberos, quello su 389 la connettività LDAP. Se il test fallisce, non è un problema di Lync ma di rete, firewall o routing. In ambienti con segmentazione aggressiva, assicurati che tra server applicativi e controller di dominio siano ammessi i flussi richiesti. È un classico errore da “funziona in laboratorio ma non in produzione”.

Certificati: prepararli prima evita blocchi dopo

I certificati sono uno dei punti più delicati del progetto. Lync usa nomi FQDN, SAN e catene di fiducia in modo rigoroso. Prima dell’installazione, devi sapere quali nomi pubblicherai internamente e, se previsto, esternamente. Non aspettare di arrivare al wizard per decidere subject e SAN: a quel punto il problema è già costoso da correggere.

Controlla che la CA sia raggiungibile dal server e che il template scelto sia idoneo. Se usi una CA interna, verifica anche il rilascio della CRL e la sua raggiungibilità. Un certificato valido ma con CRL non accessibile può creare problemi di trust difficili da diagnosticare. La verifica di base del certificato installato sul server può partire da MMC o da PowerShell:

Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject,NotAfter,Thumbprint

Se il certificato non è ancora disponibile, prepara almeno la richiesta con i SAN corretti e i nomi esatti dei servizi previsti. Nella fase iniziale, l’errore tipico è confondere il nome del server con il nome del pool o del namespace. Sono oggetti diversi e non sempre coincidono. Quando li fai coincidere senza criterio, poi paghi la confusione in DNS, certificati e configurazione client.

Firewall e porte: aprire il minimo necessario, non il massimo comodo

Prima di installare, verifica che il firewall locale e quello di rete non blocchino le porte richieste tra i nodi che compongono la soluzione. Non serve aprire tutto “per fare prima”. Serve conoscere i flussi effettivamente necessari tra client, server interni, DC, SQL e, se presente, edge. Una configurazione troppo permissiva complica il debug e aumenta la superficie d’attacco.

Un test utile è verificare le porte verso i servizi chiave. Ad esempio, verso SQL o verso un front-end già predisposto:

Test-NetConnection sql01.contoso.local -Port 1433
Test-NetConnection lync-fe01.contoso.local -Port 443
Test-NetConnection lync-fe01.contoso.local -Port 5061

Il risultato atteso è TcpTestSucceeded : True sulle porte richieste. Se fallisce, identifica subito dove blocca: firewall locale, ACL di rete, policy di sicurezza o servizio non in ascolto. In questa fase non correggere “a sentimento”: documenta il flusso e apri solo ciò che serve al ruolo che stai installando.

SQL Server e dipendenze applicative: non arrivare all’installazione senza verificarle

Se il deployment prevede un database SQL dedicato, il prerequisito non è solo “SQL esiste”. Devi verificare versione supportata, connettività, autenticazione e disponibilità del servizio. Il setup di Lync può fallire se il motore non è raggiungibile o se l’account usato non ha permessi sufficienti a creare database e oggetti. Anche qui, meglio fermarsi prima che il wizard inizi a scrivere configurazioni parziali.

Il controllo operativo è semplice:

sqlcmd -S sql01.contoso.local -E -Q "SELECT @@VERSION"

Se usi istanze nominate o porte non standard, esplicitalo nel documento di progetto e verifica che il DNS punti al target corretto. In ambienti complessi, una risoluzione errata porta a tentativi di connessione verso l’istanza sbagliata e il problema sembra “di Lync” quando in realtà è di naming o routing.

Checklist operativa prima di premere Start

Una checklist breve ma rigorosa riduce molto il rischio di dover rifare il lavoro. Prima di iniziare il setup, assicurati di avere questi elementi verificati e documentati:

1. Server membro di dominio, DNS interno corretto, ora sincronizzata con il dominio.

2. Risoluzione DNS funzionante per dominio, host, controller e namespace previsti.

3. AD sano, replica coerente e permessi adeguati per schema e pubblicazione topologia.

4. Feature Windows e prerequisiti installati, con eventuale reboot già eseguito.

5. Certificati pianificati o disponibili, con subject e SAN coerenti con i nomi reali.

6. Porte richieste aperte tra server, DC, SQL e altri componenti coinvolti.

Se anche uno solo di questi punti è incerto, la scelta corretta non è “provare comunque”. La scelta corretta è chiudere il gap, ripetere il test e solo dopo avviare il wizard. È più veloce sistemare un prerequisito che fare troubleshooting su un’installazione parziale e poi ripulire gli effetti collaterali.

Errore tipico: il setup parte, ma l’ambiente non è pronto

Il caso più comune è il seguente: il server è acceso, il wizard si apre, qualche passaggio passa, e poi compare un errore su schema, permessi, certificati o componenti mancanti. Questo non significa che Lync sia “difficile”; significa che il controllo preliminare è stato fatto in modo incompleto. Il rimedio è riprendere il processo dall’inizio con evidenze tecniche, non con tentativi casuali.

Se vuoi ridurre il rischio, lavora per livelli: prima OS e dominio, poi AD, poi DNS, poi certificati, poi prerequisiti applicativi, poi SQL e infine installazione. Ogni livello deve avere un esito verificabile, non una sensazione di “sembra a posto”. In un deployment sano, il passaggio successivo si fa perché il precedente è stato validato, non perché il timer del progetto sta finendo.

Conseguenza pratica: il tempo speso sui prerequisiti si recupera dopo

La parte meno spettacolare dell’installazione è anche quella che decide il successo del progetto. Un ambiente Lync preparato bene produce un deployment lineare, con meno eccezioni e meno interventi manuali. Un ambiente preparato male invece genera problemi sparsi: autenticazione, discovery, certificati, accesso ai servizi, pubblicazione, client che non si registrano. Il costo reale non è il wizard fallito, ma il tempo speso a inseguire sintomi secondari.

Per questo la preparazione dei prerequisiti va trattata come una fase autonoma, con log, screenshot o output dei comandi principali archiviati insieme al change. Se poi qualcosa non funziona, hai già una baseline da confrontare. E in un ambiente Microsoft complesso, avere una baseline chiara vale spesso più di una procedura lunga.

Assunzione operativa: i controlli sopra sono eseguiti su un server Windows Server membro di dominio, con AD e DNS interni gestiti correttamente e connettività verso i servizi infrastrutturali già prevista nel progetto.