Nel dominio D7 l’esame smette di chiedere «come si configura» e chiede «perche’ non funziona». La forma e’ quasi sempre la stessa: un output grezzo — tre righe di PortQry, una media di Performance Monitor, tre event ID, uno stato Failed — e quattro cause plausibili.

Connettivita’: PortQry dice tre cose, non due

Stato Che cosa e’ successo davvero
LISTENING La porta ha risposto: qualcuno ascolta
NOT LISTENING La macchina e’ raggiungibile ma la porta e’ chiusa: TCP RST, o ICMP «Port Unreachable» per UDP
FILTERED Nessuna risposta. Un processo potrebbe esserci comunque: qualcosa in mezzo scarta i pacchetti

NOT LISTENING accusa il servizio; FILTERED accusa il firewall interposto. Le porte TCP sono interrogate tre volte, quelle UDP una sola, prima di dichiararle FILTERED. La sintassi e’ portqry -n <fqdn> -e 389 -p udp: sulla 389 lo strumento invia una vera query LDAP e stampa il rootDSE del domain controller, sulla 135 interroga l’RPC endpoint mapper ed elenca le interfacce registrate con la porta effettiva di ciascuna.

L’autenticazione contro AD DS non si esaurisce nelle porte note (88 Kerberos, 389 LDAP, 636 LDAPS, 3268/3269 global catalog, 445 SMB, 53 DNS, 135 endpoint mapper): le interfacce RPC di Active Directory usano porte dinamiche, che il client scopre chiedendole alla 135. Un firewall che pubblica la 135 ma non l’intervallo dinamico produce lo scenario da rete perimetrale: LDAP, Kerberos ed endpoint mapper rispondono, e l’autenticazione fallisce lo stesso. In alternativa: LDP.EXE sulla 389 con Connectionless attiva, oppure nltest /sc_reset: verso un DC del proprio dominio.

Risoluzione dei nomi: il record giusto, dall’adattatore sbagliato

Il caso classico e’ un server che fa insieme DNS e Routing and Remote Access. Quando un utente si collega in VPN, RRAS crea un adattatore PPP e ne registra l’indirizzo in DNS o in WINS: i client della LAN che risolvono il nome del server ricevono l’IP del PPP, irraggiungibile. Il sintomo e’ intermittente e correlato alle sessioni VPN attive: il ping risolve l’indirizzo sbagliato, le share non si aprono, e se il server e’ anche DC compaiono «No Logon Servers Available».

Il rimedio impedisce la registrazione: valore stringa PublishAddresses con l’IP della scheda LAN sotto HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters, DWORD RegisterDnsARecords a 0 sotto ...\Services\Netlogon\Parameters, riavvio di DNS e Netlogon; su un DC vanno poi creati a mano i record A nella zona e sotto _msdcs. Lato WINS l’equivalente e’ DisableNetbiosOverTcpip a 1 sotto ...\Services\RemoteAccess\Parameters\IP; in alternativa, un pool statico VPN su una subnet diversa dalla LAN.

Windows Update: il log non e’ un file di testo

Il log di Windows Update e’ in formato ETL e va ricostruito con Get-WindowsUpdateLog; gli errori di servicing stanno in %windir%\Logs\CBS\CBS.log. Ma prima dei log vengono due domande. Da dove scarica? Lo dice l’oggetto COM Microsoft.Update.ServiceManager con la proprieta’ Services, che distingue Windows Update, Microsoft Update e Windows Server Update Service; con UseWUServer a 1 il server parla con WSUS, e un update non approvato li’ non si installera’ mai. Passa da un proxy? Quello di Internet Explorer e quello di WinHTTP sono distinti: netsh winhttp set proxy o netsh winhttp import proxy source=ie; e il proxy deve consentire le richieste HTTP RANGE, altrimenti compare 0x80d05001. Download fermo a 0% con 0x800706D9: il servizio Windows Defender Firewall e’ disabilitato e BITS non crea il job. Component store corrotto: DISM /Online /Cleanup-Image /RestoreHealth e poi sfc /scannow. In ibrido lo strumento corrente e’ Azure Update Manager, non il ritirato Azure Update Management di Automation.

Servizio Time: l’errore sta sull’host

Un domain controller virtualizzato che non ha il ruolo PDC emulator e registra gli event ID 24, 29 e 38 di W32Time sincronizza da due sorgenti insieme: la gerarchia di dominio (Type = NT5DS) e il VM IC Time Synchronization provider dell’host Hyper-V. I salti d’orologio lasciano lingering object nelle cache e possono fermare la replica. Si corregge sull’host: Hyper-V Manager, impostazioni della VM, Integration Services, si deseleziona Time Synchronization. L’unico DC che punta fuori e’ il PDC emulator del dominio radice, con w32tm /config /manualpeerlist:"..." /syncfromflags:manual /reliable:yes /update. Diagnostica: w32tm /query /status, /query /source, w32tm /stripchart /computer:DC1 /dataonly, w32tm /resync. La soglia che conta resta lo skew Kerberos di 5 minuti.

Prestazioni: la soglia, non la sensazione

Si raccoglie con un Data Collector Set (logman.exe create counter ... -si 00:00:15). I 15 secondi non sono arbitrari: Performance Monitor disegna al massimo 1.000 punti per grafico, e sotto riassume i campioni falsando minimi e massimi.

Contatore Sano Critico
\Processor Information(*)\% Idle Time oltre 20% sotto 10%
\Processor Information(*)\% Privileged Time sotto 30% oltre 50%
\Memory\Available MBytes oltre il 10% della RAM, e almeno 4 GB sotto l’1% o sotto 500 MB
\Memory\% Committed Bytes In Use 0-50% 80-100%
\LogicalDisk(*)\Avg. Disk sec/Read e sec/Write sotto 15 ms oltre 50 ms

I picchi brevi si tollerano: si indaga quando il valore resta fuori soglia per piu’ di un minuto. Individuata la risorsa satura, il colpevole si cerca per processo con \Process(*)\Working Set, \Process(*)\IO Read Operations/sec e \Process(*)\% User Time — dove 100% vale una CPU, quindi su 16 core si arriva a 1600%.

Estensioni delle VM e di Azure Arc

Su un server Arc-enabled si parte da azcmagent show per lo stato dei servizi dipendenti (l’Azure Arc Proxy si ignora) e da azcmagent check per gli endpoint. Il messaggio utile non e’ nel portale ma nel log del servizio estensioni, %SystemDrive%\ProgramData\GuestConfig\ext_mgr_logs\gc_ext.log: e’ li’ che compaiono i fallimenti di download o verifica del pacchetto, tipicamente proxy, firewall o ispezione TLS. I log per estensione stanno in C:\ProgramData\GuestConfig, impostazioni e file di stato in C:\Packages\Plugins (su Linux /var/lib/GuestConfig e /var/lib/waagent). Un’estensione bloccata in Failed non si sblocca con un riavvio: si rimuove e si reinstalla, con Remove-AzConnectedMachineExtension o az connectedmachine extension delete. Due nomi da tenere dritti: la configurazione via Arc e’ Azure Machine Configuration, non State Configuration/DSC; VM Insights Map e il Dependency Agent sono deprecati (ritiro 30/06/2028) e Defender for Servers non usa piu’ Log Analytics agent ne’ Azure Monitor Agent.

Cifratura dei dischi

On-premises si legge lo stato con manage-bde -status o Get-BitLockerVolume e i protector con manage-bde -protectors -get C:. Il caso ricorrente e’ il server che al riavvio chiede la recovery key dopo un aggiornamento di firmware o una modifica a Secure Boot o al TPM: si previene sospendendo la protezione con manage-bde -protectors -disable C: -rebootcount 1 prima dell’intervento, con le chiavi gia’ in escrow in AD DS o in Microsoft Entra ID. Su Azure la diagnosi cambia natura: Azure Disk Encryption e’ BitLocker nel guest erogato come estensione e richiede un Key Vault con EnabledForDiskEncryption, quindi un guasto si presenta come estensione in errore e si indaga con i log qui sopra. Encryption at host e la server-side encryption con chiave del cliente lavorano invece a livello di piattaforma, senza agenti nel guest.

Storage

Il caso Azure piu’ battuto: si dealloca la VM, si porta il disco OS gestito da 127 GiB a una taglia maggiore, si riavvia — e dentro Windows C: e’ ancora di 127 GiB. Ingrandire il disco gestito non ingrandisce il volume: la partizione va estesa nel guest, con Disk Management, con diskpart (list volume, select volume, extend) o con Get-PartitionSupportedSize e Resize-Partition. Il disco OS arriva a 4.095 GiB ma con MBR ne sono usabili al massimo 2 TiB; ridurre non e’ supportato; i volumi in striping non si estendono; i dischi dati si espandono senza deallocare la VM, il disco OS no.

On-premises, su Storage Spaces e Storage Spaces Direct si guardano Get-PhysicalDisk e Get-VirtualDisk distinguendo HealthStatus da OperationalStatus: No Redundancy e’ dato non piu’ ridondante e volume che puo’ non montare, Detached con dischi fisici sani indica il log di dirty region tracking pieno, che si sblocca con la scheduled task «Data Integrity Scan for Crash Recovery». La riparazione si segue con Get-StorageJob. Azure Stack HCI oggi si chiama Azure Local.

Trappole tipiche d’esame

  • FILTERED non e’ NOT LISTENING. Il primo accusa il firewall interposto, il secondo il servizio. E una 135 LISTENING non prova che l’RPC funzioni: se l’intervallo dinamico e’ filtrato, l’autenticazione fallisce comunque.
  • Nomi risolti a intermittenza su un server RRAS: non e’ la cache DNS. E’ l’adattatore PPP che si registra in DNS o WINS; si interviene con PublishAddresses e RegisterDnsARecords. ipconfig /flushdns nasconde il sintomo per qualche minuto e basta.
  • Event ID 24, 29 e 38 su un DC virtuale: si corregge sull’host. Si deseleziona Time Synchronization negli Integration Services; configurare w32tm /config /manualpeerlist su un DC che non e’ il PDC emulator e’ la risposta sbagliata piu’ attraente del dominio.
  • Avg. Disk sec/Read si misura in secondi, anche se la soglia si cita in millisecondi. 0,080 sono 80 ms, zona critica. E se % Idle Time e’ alto e Available MBytes abbondante, aggiungere CPU o RAM non risolve: il collo di bottiglia e’ il disco.
  • Estensione Arc in Failed per un pacchetto non scaricato: il messaggio utile e’ in gc_ext.log. Rimuovere e reinstallare l’estensione e’ la procedura prevista; riavviare la macchina no.
  • Ridimensionare il disco gestito in Azure non ridimensiona il volume. La partizione va estesa dentro Windows. E il disco OS richiede la VM deallocata, i dischi dati in generale no.