Domenico CaldarelliInstallare Windows Server 2025 su Mac M4 PRO
I Mac con processore Apple Silicon sono macchine estremamente efficienti, silenziose e abbastanza potenti da rendere naturale una domanda: possiamo usarli anche per costruire un laboratorio Windows Server?
Con Windows 11 ARM la risposta è relativamente semplice. Parallels Desktop, VMware Fusion e UTM possono virtualizzare un sistema operativo che condivide l’architettura ARM64 del processore Apple. Windows Server 2025, però, introduce un ostacolo meno visibile dell’assenza di una porta USB: l’immagine pubblica distribuita da Microsoft è x64.
Un MacBook M4 Pro non può quindi virtualizzarla direttamente. Per eseguirla deve ricreare via software un processore compatibile Intel/AMD. È la differenza tra virtualizzazione ed emulazione, ed è anche la differenza tra una VM reattiva e una macchina che, durante Windows Update, offre tempo sufficiente per rivalutare alcune scelte di vita.
In questa guida vedremo come installare Windows Server 2025 su un MacBook M4 Pro con UTM, come configurare una VM x86_64, come misurarne le prestazioni e come trasformarla in un Domain Controller. L’obiettivo non è costruire una piattaforma di produzione, ma capire se questo approccio possa sostenere un laboratorio portatile per formazione, test, dimostrazioni e prestazioni.
Prima di iniziare: virtualizzare ed emulare non sono sinonimi
La virtualizzazione consente al guest di eseguire direttamente gran parte delle istruzioni sulla CPU fisica. Perché questo avvenga in modo efficiente, host e guest devono condividere la stessa architettura: ARM64 con ARM64 oppure x86_64 con x86_64.
L’emulazione aggiunge invece un livello di traduzione. QEMU presenta a Windows Server una CPU x86_64 virtuale e traduce le istruzioni affinché possano essere eseguite dal processore ARM64 del Mac. È una soluzione flessibile, ma comporta un costo prestazionale significativo.
| Scenario | Architettura guest | Tecnologia | Esito su M4 Pro |
| Windows 11 ARM | ARM64 | Virtualizzazione | Esecuzione nativa e prestazioni elevate |
| Linux ARM64 | ARM64 | Virtualizzazione | Esecuzione nativa e prestazioni elevate |
| Windows Server 2025 ISO | x86_64 | Emulazione QEMU | Possibile, con prestazioni inferiori |
| VM Windows Server x64 in Azure | x86_64 | Esecuzione remota | Prestazioni dipendenti dalla VM scelta |
Cosa possiamo aspettarci davvero
Una VM emulata può essere sufficiente per installare Windows Server, configurare DNS, creare una foresta Active Directory, gestire utenti e Group Policy ed eseguire dimostrazioni. Non è invece il terreno ideale per SQL Server, nested virtualization, carichi I/O intensivi, più Domain Controller contemporanei o laboratori composti da molte macchine x64.
| Caso d’uso | Valutazione | Motivazione |
| Singolo Domain Controller | Adatto a un laboratorio | Carico generalmente contenuto dopo l’avvio |
| Demo AD DS, DNS e GPO | Adatto | Consente test funzionali e screenshot |
| Due o più server x64 | Da valutare | La traduzione delle istruzioni si moltiplica |
| SQL Server o workload pesanti | Sconsigliato | CPU, disco e memoria diventano colli di bottiglia |
| Produzione | Non appropriato | Piattaforma non supportata e prestazioni non prevedibili |
Prerequisiti
- MacBook con processore Apple M4 Pro e macOS aggiornato.
- Almeno 24 GB di memoria unificata; 36 o 48 GB sono preferibili per laboratori più articolati.
- Almeno 120 GB di spazio libero, per evitare che snapshot e aggiornamenti saturino il disco.
- UTM aggiornato, scaricato dal sito ufficiale o dal Mac App Store.
- ISO ufficiale di Windows Server 2025 Evaluation x64.
- Connessione Internet e una rete di laboratorio separata, se il server verrà promosso a Domain Controller.
Windows Server 2025
Scaricare l’immagine esclusivamente dal Microsoft Evaluation Center. La pagina consente di ottenere la ISO a 64 bit delle edizioni Standard e Datacenter. È consigliabile conservare il file originale e verificarne l’integrità prima di collegarlo alla VM.
|
1 2 |
Get-FileHash .\SERVER_EVAL_x64FRE_en-us.iso -Algorithm SHA256 |
Il valore deve essere confrontato con quello pubblicato o fornito dal canale ufficiale da cui è stata ottenuta l’immagine. Il nome esatto del file può cambiare nel tempo.
UTM
UTM utilizza QEMU per l’emulazione e offre un’interfaccia grafica adatta anche a chi non vuole costruire manualmente ogni parametro da riga di comando. La versione distribuita sul sito del progetto è gratuita; quella del Mac App Store sostiene lo sviluppo e semplifica gli aggiornamenti.
Creazione della macchina virtuale
Aprire UTM e selezionare Create a New Virtual Machine. La prima scelta è quella che determina l’intero laboratorio.
-
Selezionare Emulate.
Figure 1 – UTM Pagina iniziale
Figure 2 – Selezione virtualizzazione/emulazione
- Scegliere Windows come tipologia di sistema operativo.
Figure 3 – Selezione OS
- Configurare CPU, memoria, disco e rete secondo.
Figure 4 – Configurazione hardware virtuale
- Collegare la ISO di Windows Server 2025 come unità di avvio.
Figure 5 – Selezione della ISO
Figure 6 – Configurazione spazio disco
Figure 7 – Configurazione cartella condivisa
Figure 8 – Sommario delle configurazioni
Figure 9 – Schermata iniziale a seguito della creazione della VM
| Componente | Valore iniziale | Nota |
| Architecture | x86_64 | Obbligatorio per la ISO pubblica di Windows Server 2025 |
| System / Machine | Q35 | Piattaforma moderna con firmware UEFI |
| CPU model | Default o Skylake compatibile | Partire dal valore proposto da UTM; cambiare solo dopo un test |
| CPU cores | 4 | Un numero maggiore non garantisce prestazioni migliori in emulazione |
| Memory | 8–12 GB | 8 GB per AD DS base; 12 GB per Desktop Experience e test |
| Disk | 80–100 GB | Preferire un disco espandibile e mantenere spazio libero sul Mac |
| Disk interface | IDE/SATA iniziale | Massima compatibilità durante l’installazione |
| Network | Intel E1000 | Riduce il rischio di dover caricare driver durante il setup |
| Display | VirtIO RAM framebuffer | Adeguato alla console; non aspettarsi accelerazione 3D completa |
Perché partire con una configurazione conservativa
Controller VirtIO e modelli CPU più aggressivi possono migliorare le prestazioni, ma aggiungono variabili proprio nel momento in cui dobbiamo capire se il sistema si avvia. La prima installazione dovrebbe privilegiare la compatibilità. Dopo avere ottenuto una baseline funzionante sarà possibile clonare la VM e provare controller o impostazioni differenti.
Installazione di Windows Server 2025
Avviare la VM e premere un tasto quando viene richiesto di eseguire il boot dall’immagine. Il programma di installazione è quello tradizionale di Windows Server, ma ogni fase può richiedere più tempo rispetto a una VM x64 nativa.
- Selezionare lingua, formato data e layout della tastiera.
- Scegliere Install now.
- Selezionare Windows Server 2025 Datacenter Evaluation (Desktop Experience).
- Accettare le condizioni di licenza.
- Scegliere Custom: Install Microsoft Server Operating System only.
- Selezionare il disco virtuale e avviare la copia dei file.
- Al primo accesso impostare una password robusta per Administrator.
Se il disco non appare, il controller scelto richiede probabilmente un driver non incluso nel setup. Per la prima prova conviene arrestare la VM e passare a un controller IDE o SATA, anziché introdurre subito una seconda ISO di driver.
Primo avvio e controlli di base
Dopo l’accesso, non installiamo immediatamente Active Directory. Prima verifichiamo che sistema, rete, storage e orologio siano stabili.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
Get-ComputerInfo | Select-Object ` WindowsProductName, WindowsVersion, OsArchitecture, ` CsManufacturer, CsModel [System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture Get-CimInstance Win32_Processor | Select-Object ` Name, Manufacturer, NumberOfCores, NumberOfLogicalProcessors Get-NetAdapter Get-NetIPConfiguration Get-Disk Get-Volume |
Gli output consentono di documentare l’elemento più interessante dell’esperimento: Windows Server rileva un ambiente x64, mentre il sistema fisico sottostante è un Mac ARM64.
Figure 10 – Informazioni VM
Aggiornamenti e stabilizzazione
Eseguire Windows Update prima di installare i ruoli. Questa fase può essere la più lenta dell’intero laboratorio e deve essere inclusa nelle misurazioni. Al termine, riavviare il server e verificare che non siano presenti installazioni pendenti.
|
1 2 3 4 5 |
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10 Get-ItemProperty ` 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired' ` -ErrorAction SilentlyContinue |
Oppure tramite interfaccia
Figure 11 – Windows Update
Configurazione della rete di laboratorio
Un Domain Controller deve utilizzare un indirizzo IP stabile. In UTM possiamo scegliere una rete condivisa per ottenere connettività verso Internet oppure una rete isolata per evitare che DNS e servizi di dominio interferiscano con la rete reale. Per questo articolo si è preferito separare il laboratorio e aggiungere l’accesso esterno solo in caso di necessità.
Esempio di configurazione, da adattare al segmento effettivamente assegnato da UTM:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
$Interface = Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object -First 1 New-NetIPAddress ` -InterfaceIndex $Interface.ifIndex ` -IPAddress 192.168.64.10 ` -PrefixLength 24 ` -DefaultGateway 192.168.64.1 Set-DnsClientServerAddress ` -InterfaceIndex $Interface.ifIndex ` -ServerAddresses 192.168.64.10 |
Gli indirizzi sono soltanto un esempio. Prima di eseguire i comandi verificare il gateway e la subnet con Get-NetIPConfiguration. Una configurazione errata potrebbe isolare la VM.
Preparazione del server
Assegniamo un nome significativo e riavviamo.
|
1 2 |
Rename-Computer -NewName 'DC02' -Restart |
Dopo il riavvio, controlliamo l’ora. Kerberos tollera differenze limitate: in un ambiente emulato, sospensione del Mac e pausa della VM possono produrre scostamenti che diventano difficili da diagnosticare.
|
1 2 3 |
w32tm /query /status w32tm /query /configuration |
Figure 12 – W32TM
Figure 13 – W32TM
Installazione di Active Directory Domain Services
Aprire PowerShell come amministratore e installare il ruolo AD DS con gli strumenti di gestione.
|
1 2 |
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools |
Verificare il risultato:
|
1 2 |
Get-WindowsFeature AD-Domain-Services |
Figure 14 – Installazione AD-DS
Creazione della foresta
Fin qui, nulla di anomalo o particolarmente complicato. Per il laboratorio utilizzeremo il dominio adlab.test. Il suffisso .test è riservato alla documentazione e ai test; evita di introdurre nel laboratorio un nome che potrebbe essere risolto pubblicamente. In un ambiente aziendale reale si dovrebbe invece pianificare un sottodominio di un namespace posseduto dall’organizzazione.
|
1 2 3 4 5 6 7 8 9 10 |
$SafeModePassword = Read-Host ` 'Password DSRM' -AsSecureString Install-ADDSForest ` -DomainName 'adlab.test' ` -DomainNetbiosName 'ADLAB' ` -InstallDNS ` -SafeModeAdministratorPassword $SafeModePassword ` -Force |
Il server verrà riavviato automaticamente. La prima autenticazione al dominio può essere più lenta del previsto perché vengono inizializzati database, DNS, SYSVOL e servizi correlati.
Figure 15 – Server manager: hostname e dominio
Verifica del Domain Controller
Dopo il riavvio accedere come ADLAB\Administrator ed eseguire una verifica funzionale prima di considerare conclusa la prova.
|
1 2 3 4 5 6 7 8 9 |
Get-ADDomain Get-ADForest Get-ADDomainController Get-ADReplicationPartnerMetadata -Target * -Scope Server Resolve-DnsName adlab.local Resolve-DnsName _ldap._tcp.dc._msdcs.adlab.local -Type SRV dcdiag /v dcdiag /test:dns /v |
In una foresta con un solo Domain Controller alcuni controlli di replica non possono dimostrare una replica effettiva. DCDiag e i record SRV DNS restano però fondamentali per accertare che i servizi principali siano disponibili.
Un test funzionale, non soltanto cosmetico
Creiamo una Organizational Unit, un utente e un gruppo. In questo modo verifichiamo scrittura nel database AD, risoluzione del dominio e disponibilità dei cmdlet.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
New-ADOrganizationalUnit -Name 'ICTPower Lab' ` -Path 'DC=adlab,DC=local' $Password = Read-Host 'Password utente test' -AsSecureString New-ADUser ` -Name Domenico Caldarelli ` -GivenName 'Domenico' ` -Surname 'Caldarelli' ` -SamAccountName dcaldarelli ` -UserPrincipalName dcaldarelli@adlab.local ` -Path 'OU=ICTPower Lab,DC=adlab,DC=local' ` -AccountPassword $Password ` -Enabled $true New-ADGroup ` -Name 'Lab Admins' ` -GroupScope Global ` -Path 'OU=ICTPower Lab,DC=adlab,DC=local' Add-ADGroupMember -Identity 'Lab Admins' -Members 'dcaldarelli' Get-ADUser dcaldarelli -Properties * | ` Select-Object SamAccountName, UserPrincipalName, Enabled, DistinguishedName Get-ADGroupMember 'Lab Admins' |
Benchmark: come effettuare una misura correttamente
Il confronto deve separare il tempo percepito dai dati misurabili. Un’animazione poco fluida non significa necessariamente che LDAP sia inutilizzabile; allo stesso modo, un desktop reattivo non garantisce tempi accettabili durante aggiornamenti e installazione dei ruoli.
Prima di ogni prova chiudere le applicazioni non necessarie, collegare il Mac all’alimentazione, annotare la modalità energetica e attendere due minuti dopo l’avvio della VM. Ripetere ogni test almeno tre volte, salvo installazione e promozione, e riportare mediana e intervallo minimo/massimo.
Scheda dell’ambiente
| Parametro | Valore da rilevare |
| Modello Mac | MacBook Pro con Apple M4 Pro |
| Memoria unificata | 24 GB |
| Versione macOS | 26.5.2 |
| Versione UTM/QEMU | 4.7.5 (118) |
| Core e RAM assegnati | 4 core – 12GB |
| Controller disco e rete | IDE – Intel Gigabit Ethernet (e1000) |
| Build Windows Server | 24H2 (OS Build 26100.22158) |
| Modalità energetica | Alimentatore |
Test proposti
| Test | Metodo | Indicatore |
| Cold boot | Avvio VM spenta fino alla schermata di logon | Secondi |
| Logon amministrativo | Invio credenziali fino al desktop utilizzabile | Secondi |
| Server Manager | Avvio fino al completamento dell’inventario locale | Secondi |
| Installazione AD DS | Measure-Command sul cmdlet Install-WindowsFeature | Minuti/secondi |
| Promozione DC | Dall’avvio del cmdlet al riavvio | Minuti/secondi |
| DCDiag | Measure-Command con output su file | Secondi ed errori |
| Enumerazione AD | 100 esecuzioni di Get-ADUser su directory popolata | Secondi |
| Disco | DiskSpd o copia controllata di un file di test | IOPS/MBps/latency |
| Consumo host | Monitoraggio Attività durante idle e carico | CPU, memoria, pressione |
Comandi di misurazione
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
Measure-Command { Get-WindowsFeature | Out-Null } Measure-Command { dcdiag /test:dns | Out-Null } Measure-Command { 1..100 | ForEach-Object { Get-ADUser -Filter * | Out-Null } } |
Figure 16 – Prime misure
Possiamo fare meglio. Per evitare che la cache falsi completamente il confronto, riportare sia la prima esecuzione sia la mediana delle successive. Le prove di disco devono utilizzare sempre lo stesso file, la stessa dimensione e la stessa configurazione del controller.
Invece, per il test di enumerazione di AD è possibile utilizzare lo script seguente
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 |
<# .SYNOPSIS Benchmark di 100 interrogazioni consecutive ad Active Directory. .DESCRIPTION Lo script: - verifica la disponibilità del modulo ActiveDirectory; - individua automaticamente il Domain Controller; - esegue una query preliminare di riscaldamento; - effettua tre prove da 100 interrogazioni ciascuna; - calcola tempo totale e tempo medio per query; - determina la mediana delle tre prove; - esporta i risultati in formato CSV. .NOTES Eseguire da Windows PowerShell come amministratore su un Domain Controller o su una macchina con RSAT installato. #> $ErrorActionPreference = "Stop" $NumeroProve = 3 $QueryPerProva = 100 $CartellaRisultati = "C:\Temp" $FileRisultati = Join-Path ` -Path $CartellaRisultati ` -ChildPath "Benchmark-AD.csv" # Creazione della cartella dei risultati if (-not (Test-Path -Path $CartellaRisultati)) { New-Item ` -Path $CartellaRisultati ` -ItemType Directory ` -Force | Out-Null } # Verifica e caricamento del modulo Active Directory if (-not (Get-Module -ListAvailable -Name ActiveDirectory)) { throw "Il modulo ActiveDirectory non è installato. Installare il ruolo AD DS oppure gli strumenti RSAT." } Import-Module ActiveDirectory # Individuazione del Domain Controller $DomainController = Get-ADDomainController -Discover $Server = @($DomainController.HostName)[0].ToString() # Conteggio degli utenti presenti nel dominio $NumeroUtenti = @( Get-ADUser ` -Filter * ` -Server $Server ).Count Write-Host "" Write-Host "Benchmark Active Directory" -ForegroundColor Cyan Write-Host "Domain Controller : $($DomainController.HostName)" Write-Host "Dominio : $($DomainController.Domain)" Write-Host "Utenti restituiti : $NumeroUtenti" Write-Host "Prove : $NumeroProve" Write-Host "Query per prova : $QueryPerProva" Write-Host "" # Query di riscaldamento, esclusa dalle misurazioni Write-Host "Esecuzione della query di riscaldamento..." Get-ADUser ` -Filter * ` -Server $Server ` -Properties DisplayName, Enabled, LastLogonTimestamp | Out-Null # Esecuzione del benchmark $Risultati = for ($Prova = 1; $Prova -le $NumeroProve; $Prova++) { Write-Host "Esecuzione prova $Prova di $NumeroProve..." $Tempo = Measure-Command { for ($Query = 1; $Query -le $QueryPerProva; $Query++) { Get-ADUser ` -Filter * ` -Server $Server ` -Properties DisplayName, Enabled, LastLogonTimestamp | Out-Null } } [PSCustomObject]@{ Prova = $Prova DomainController = $DomainController.HostName UtentiPerQuery = $NumeroUtenti NumeroQuery = $QueryPerProva SecondiTotali = [math]::Round( $Tempo.TotalSeconds, 3 ) MillisecondiPerQuery = [math]::Round( $Tempo.TotalMilliseconds / $QueryPerProva, 2 ) OggettiElaborati = $NumeroUtenti * $QueryPerProva DataEsecuzione = Get-Date -Format "yyyy-MM-dd HH:mm:ss" } } # Calcolo della mediana $TempiOrdinati = @( $Risultati.SecondiTotali | Sort-Object ) $IndiceCentrale = [math]::Floor($TempiOrdinati.Count / 2) if (($TempiOrdinati.Count % 2) -eq 1) { $MedianaSecondi = $TempiOrdinati[$IndiceCentrale] } else { $MedianaSecondi = ( $TempiOrdinati[$IndiceCentrale - 1] + $TempiOrdinati[$IndiceCentrale] ) / 2 } $MedianaSecondi = [math]::Round($MedianaSecondi, 3) $MedianaMillisecondiPerQuery = [math]::Round( ($MedianaSecondi * 1000) / $QueryPerProva, 2 ) # Visualizzazione dei risultati Write-Host "" Write-Host "Risultati delle singole prove" -ForegroundColor Cyan $Risultati | Format-Table ` Prova, UtentiPerQuery, NumeroQuery, SecondiTotali, MillisecondiPerQuery, OggettiElaborati ` -AutoSize Write-Host "Mediana delle tre prove : $MedianaSecondi secondi" ` -ForegroundColor Green Write-Host "Tempo mediano per query : $MedianaMillisecondiPerQuery ms" ` -ForegroundColor Green # Esportazione in CSV $Risultati | Export-Csv ` -Path $FileRisultati ` -NoTypeInformation ` -Encoding UTF8 Write-Host "Risultati esportati in : $FileRisultati" |
Il risultato sarà qualcosa del genere, oltre ad un file csv.
Figure 17 – Benchmark AD
Per il test relativo a DCDiag DNS possiamo utilizzare il seguente script PowerShell
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 |
<# .SYNOPSIS Benchmark del test DNS eseguito tramite DCDiag. .DESCRIPTION Lo script: - verifica la presenza di DCDiag; - individua il Domain Controller locale; - esegue una prova preliminare di riscaldamento; - ripete il test DNS tre volte; - misura la durata di ogni prova; - calcola la mediana; - salva output completi e risultati CSV. .NOTES Eseguire da Windows PowerShell come amministratore su un Domain Controller. #> $ErrorActionPreference = "Stop" $NumeroProve = 3 $CartellaRisultati = "C:\Temp\Benchmark-DCDiag-DNS" $FileCsv = Join-Path $CartellaRisultati "Benchmark-DCDiag-DNS.csv" # Verifica della presenza di DCDiag $DCDiagCommand = Get-Command "dcdiag.exe" -ErrorAction SilentlyContinue if (-not $DCDiagCommand) { throw "DCDiag non è disponibile. Installare gli strumenti di gestione AD DS." } # Creazione della cartella dei risultati if (-not (Test-Path -Path $CartellaRisultati)) { New-Item ` -Path $CartellaRisultati ` -ItemType Directory ` -Force | Out-Null } # Determinazione del nome DNS completo del DC locale Import-Module ActiveDirectory $Dominio = Get-ADDomain $Server = "$env:COMPUTERNAME.$($Dominio.DNSRoot)" # Normalizzazione esplicita come stringa $Server = [string]$Server if ([string]::IsNullOrWhiteSpace($Server)) { throw "Impossibile determinare il nome DNS del Domain Controller." } Write-Host "" Write-Host "Benchmark DCDiag DNS" -ForegroundColor Cyan Write-Host "Domain Controller : $Server" Write-Host "Numero di prove : $NumeroProve" Write-Host "Tipo di test : DNS completo" Write-Host "Cartella output : $CartellaRisultati" Write-Host "" # Prova preliminare esclusa dalle misurazioni Write-Host "Esecuzione della prova di riscaldamento..." & dcdiag.exe ` "/s:$Server" ` "/test:DNS" ` "/DnsAll" ` "/v" ` *> $null Write-Host "Prova di riscaldamento completata." Write-Host "" # Esecuzione delle prove $Risultati = for ($Prova = 1; $Prova -le $NumeroProve; $Prova++) { $FileOutput = Join-Path ` -Path $CartellaRisultati ` -ChildPath "DCDiag-DNS-Prova-$Prova.txt" Write-Host "Esecuzione prova $Prova di $NumeroProve..." $Cronometro = [System.Diagnostics.Stopwatch]::StartNew() & dcdiag.exe ` "/s:$Server" ` "/test:DNS" ` "/DnsAll" ` "/v" ` *> $FileOutput $CodiceUscita = $LASTEXITCODE $Cronometro.Stop() [PSCustomObject]@{ Prova = $Prova DomainController = $Server Test = "DNS completo" SecondiTotali = [math]::Round( $Cronometro.Elapsed.TotalSeconds, 3 ) CodiceUscita = $CodiceUscita FileOutput = $FileOutput DataEsecuzione = Get-Date -Format "yyyy-MM-dd HH:mm:ss" } } # Calcolo della mediana $TempiOrdinati = @( $Risultati.SecondiTotali | Sort-Object ) $IndiceCentrale = [math]::Floor($TempiOrdinati.Count / 2) if (($TempiOrdinati.Count % 2) -eq 1) { $MedianaSecondi = $TempiOrdinati[$IndiceCentrale] } else { $MedianaSecondi = ( $TempiOrdinati[$IndiceCentrale - 1] + $TempiOrdinati[$IndiceCentrale] ) / 2 } $MedianaSecondi = [math]::Round($MedianaSecondi, 3) # Visualizzazione dei risultati Write-Host "" Write-Host "Risultati DCDiag DNS" -ForegroundColor Cyan $Risultati | Format-Table ` Prova, DomainController, SecondiTotali, CodiceUscita ` -AutoSize Write-Host "Mediana delle prove : $MedianaSecondi secondi" ` -ForegroundColor Green # Esportazione CSV $Risultati | Export-Csv ` -Path $FileCsv ` -NoTypeInformation ` -Encoding UTF8 Write-Host "Risultati esportati : $FileCsv" Write-Host "Output dettagliati : $CartellaRisultati" |
Anche in questo caso, il risultato sarà un file csv insieme a dettagli simili alla seguente immagine
Figure 18 – Benchmark DCDiag DNS
Tabella dei risultati
| Metrica | Prova 1 | Prova 2 | Prova 3 | Mediana |
| Cold boot (s) | 88 | 92 | 85 | 88 |
| Logon (s) | 35 | 34 | 37 | 35 |
| Server Manager (s) | 31 | 35 | 32 | 32 |
| Installazione AD DS | n/a | n/a | n/a | Rilevazione singola |
| Promozione DC | n/a | n/a | n/a | Rilevazione singola |
| DCDiag DNS (s) | 33.8 | 37.1 | 32.9 | 33.8 |
| 100 enumerazioni AD (s) | 12.6 | 12.3 | 12.5 | 12.5 |
Ottimizzazioni da provare dopo la baseline
Dopo aver salvato una copia della VM funzionante, possiamo sperimentare una variazione alla volta.
- Confrontare 4 e 6 core emulati, mantenendo invariati memoria e disco.
- Provare un modello CPU alternativo soltanto se UTM/QEMU lo supporta stabilmente.
- Confrontare SATA/NVMe con VirtIO, installando i driver necessari in modo controllato.
- Ridurre gli effetti grafici di Desktop Experience.
- Usare Server Core in una seconda VM per quantificare il risparmio di memoria e il tempo di avvio.
- Disabilitare servizi soltanto se non sono necessari al caso d’uso e documentare ogni modifica.
Attenzione: cambiare un solo parametro per volta. Se modifichiamo contemporaneamente CPU, controller disco, memoria e scheda di rete, non potremo attribuire il miglioramento o il peggioramento a una causa precisa.
Snapshot, sospensione e orologio
Gli snapshot sono utili prima della promozione e prima di modificare driver o controller. Con Active Directory, però, non devono diventare una strategia di backup. Inoltre, dopo una lunga sospensione del Mac, verificare data e ora del Domain Controller: DNS e Kerberos possono fallire in modi apparentemente scollegati dall’emulazione.
|
1 2 3 4 |
Get-Date w32tm /query /status Get-Service NTDS,DNS,KDC,Netlogon |
Figure 19 – Verifica stato servizi
Per esperimenti distruttivi è preferibile clonare la VM a server spento. Per una vera strategia di ripristino di Active Directory servono procedure supportate, backup system-state e conoscenza delle implicazioni del ripristino autorevole e non autorevole.
Sicurezza del laboratorio
- Non collegare la VM a reti aziendali senza autorizzazione e senza un piano di indirizzamento.
- Non riutilizzare password personali o aziendali nel dominio di prova.
- Applicare gli aggiornamenti prima di esporre servizi verso altre reti.
- Limitare le cartelle condivise tra macOS e il guest.
- Conservare ISO e strumenti soltanto da fonti ufficiali o verificabili.
- Considerare la VM compromettibile e facilmente clonabile: non inserirvi segreti reali.
Un laboratorio è uno spazio controllato, non una zona franca. La comodità di portare un Domain Controller nello zaino non lo rende meno Domain Controller.
Problemi frequenti
| Sintomo | Causa probabile | Intervento |
| La VM non avvia la ISO | Ordine di boot o firmware non coerente | Verificare ISO, UEFI e unità rimovibile |
| Il disco non è visibile | Driver del controller assente | Usare IDE/SATA o caricare il driver appropriato |
| La rete non funziona | Modello non riconosciuto o configurazione errata | Provare E1000 e controllare IP/gateway |
| CPU sempre elevata sul Mac | Emulazione e aggiornamenti in corso | Attendere stabilizzazione e misurare a VM idle |
| Avvio estremamente lento | Troppi core, storage lento o update pendenti | Tornare alla baseline e cambiare una variabile |
| Kerberos o logon falliscono dopo la pausa | Scostamento dell’orologio | Verificare w32tm, data e servizi |
| DCDiag segnala errori DNS | DNS client o record SRV non corretti | Controllare DNS locale e registrazione Netlogon |
Un confronto che conta
Il benchmark più utile non è necessariamente contro un altro Mac. Se l’obiettivo è costruire un laboratorio, conviene confrontare tre opzioni: emulazione locale con UTM, VM x64 su un piccolo host Intel/AMD e VM in Azure.
| Soluzione | Vantaggio | Limite | Quando sceglierla |
| UTM su M4 Pro | Laboratorio sempre disponibile e offline | Emulazione lenta | Demo e singolo DC |
| Host x64 locale | Prestazioni native e più VM | Hardware aggiuntivo | Laboratori AD complessi |
| Azure | Scalabilità e immagini pronte | Costo e dipendenza dalla rete | Test temporanei o multi-server |
Il MacBook M4 Pro vince sulla portabilità, non sull’efficienza dell’esecuzione x64. Ovviamente.
Conclusioni
Installare Windows Server 2025 su un MacBook M4 Pro è possibile grazie a UTM e QEMU. Il sistema può essere promosso a Domain Controller, eseguire DNS Server, creare utenti e Group Policy e sostenere un piccolo laboratorio didattico. Non diventa però una VM ARM64: resta un sistema x64 emulato, con tutto il costo di traduzione che questo comporta.
Il valore dell’esperimento non consiste nel dimostrare che qualunque cosa possa essere avviata su qualunque hardware (del resto abbiamo visto installare DOOM praticamente ovunque). Consiste nel capire dove passa il confine tra una soluzione tecnicamente possibile e una soluzione operativamente sensata.
Per un singolo Domain Controller portatile, per una demo o per produrre schermate e test funzionali, il risultato può essere sorprendentemente utile. Per un laboratorio composto da CA, SQL Server, due DC, client Windows e macchina d’attacco, un host x64 o il cloud restano scelte più razionali.
Apple Silicon ha cambiato le regole della virtualizzazione sul Mac. UTM ci permette di aggirarle, ma non di abolirle. Ed è proprio questa la parte più interessante del laboratorio.
Stay tuned!