1 13/04/2026 11 min

Query SCCM per rilevare Office a 32 e 64 bit

In SCCM la differenza tra Office a 32 bit e a 64 bit non va cercata “a occhio” nel nome del prodotto. La strada affidabile passa dai dati inventariati dal client, di solito tramite WMI o, in ambienti più moderni, tramite i metadati di inventario hardware/software che ConfigMgr raccoglie e normalizza. Se il tuo obiettivo è fare reporting, compliance o targeting di una collection, la query deve appoggiarsi a un campo che indichi davvero l’architettura del pacchetto installato, non a un prefisso del nome o a un’assunzione sul sistema operativo.

Il punto pratico è questo: Office può essere installato a 32 bit anche su Windows a 64 bit, e questo è ancora comune in molte aziende per compatibilità con add-in, macro e componenti legacy. Quindi una query SCCM utile deve separare almeno tre casi: Office 32 bit su OS 32 bit, Office 32 bit su OS 64 bit e Office 64 bit su OS 64 bit. Se ti limiti a “x64 OS” stai sbagliando bersaglio.

Dove leggere l’architettura di Office in SCCM

La fonte più comoda, quando disponibile, è la classe WMI legata al prodotto Office installato. In molti ambienti si finisce a interrogare la vista di inventario software o una classe come Win32_Product, ma quella strada è sconsigliata perché lenta e potenzialmente invasiva. Per SCCM conviene appoggiarsi a hardware inventory o, meglio, a una classe custom/estesa che esponga il dato di architettura in modo pulito.

Se hai già esteso l’inventario con una proprietà che identifica la bitness, la query diventa banale. Se non l’hai fatto, la parte difficile non è la query ma la raccolta del dato. In altre parole: prima verifica che il client stia effettivamente inventariando il campo giusto, poi costruisci il report. Senza quel passaggio, il rischio è ottenere risultati parziali o incoerenti.

Verifica rapida dei dati disponibili

Prima di scrivere una query definitiva, controlla quali classi e proprietà sono presenti nel database SCCM. Il modo più pratico è usare SQL Server Management Studio sul database del site, oppure il report viewer se hai già un report base. L’obiettivo è capire se l’informazione sull’architettura è esposta in un campo interrogabile.

Un controllo utile è partire dalle viste di inventario software e cercare i record di Microsoft Office. Se l’architettura è stata mappata, la vedrai come valore testuale tipo 32-bit, 64-bit, oppure come indicatore nel nome prodotto. Se invece il dataset contiene solo il nome marketing del prodotto, serve correggere la raccolta dati prima di fare reporting serio.

Query di esplorazione iniziale, da adattare al tuo schema:

SELECT TOP 50
    Name0,
    Version0,
    Publisher0,
    InstalledLocation0
FROM v_Add_Remove_Programs
WHERE Name0 LIKE '%Microsoft Office%'
ORDER BY Name0;

Se la tua istanza usa le viste classiche di inventario software, il risultato ti dirà subito se il nome del prodotto contiene già la bitness. In molti casi troverai stringhe come Microsoft Office Professional Plus 2019 - en-us senza alcun riferimento all’architettura. In quel caso la query va spostata su un’altra fonte, altrimenti stai solo indovinando.

Query SQL SCCM consigliata per distinguere 32 e 64 bit

Quando il dato è disponibile in una vista inventariata che espone l’architettura, la struttura della query deve unire i device con il record Office e mostrare chiaramente la bitness. Un modello robusto è questo: prima estrai i computer, poi unisci il prodotto Office, infine filtra per le varianti che ti interessano.

Esempio SQL da usare come base di reporting, da adattare alle viste reali del tuo ambiente:

SELECT
    sys.Name0 AS ComputerName,
    arp.Name0 AS ProductName,
    arp.Version0 AS ProductVersion,
    CASE
        WHEN arp.Name0 LIKE '%64-bit%' OR arp.Name0 LIKE '%x64%' THEN '64-bit'
        WHEN arp.Name0 LIKE '%32-bit%' OR arp.Name0 LIKE '%x86%' THEN '32-bit'
        ELSE 'Unknown'
    END AS OfficeArchitecture
FROM v_R_System AS sys
INNER JOIN v_Add_Remove_Programs AS arp
    ON sys.ResourceID = arp.ResourceID
WHERE arp.Name0 LIKE '%Microsoft Office%'
ORDER BY sys.Name0, arp.Name0;

Questa query funziona solo se il nome prodotto contiene davvero un indizio affidabile, come x86 o x64. Se il nome non lo contiene, il CASE restituisce Unknown, che è esattamente il comportamento corretto: meglio un buco esplicito che un dato inventato.

Se invece la bitness è esposta in una proprietà specifica del tuo inventario, la query va semplificata. Il pattern migliore è sempre lo stesso: un campo dedicato per l’architettura, nessuna inferenza dal nome. Esempio concettuale:

SELECT
    sys.Name0,
    off.DisplayName0,
    off.Architecture0
FROM v_R_System sys
INNER JOIN v_GS_OFFICE_PRODUCT off
    ON sys.ResourceID = off.ResourceID
WHERE off.DisplayName0 LIKE 'Microsoft Office%';

Il nome della vista personalizzata cambia da ambiente a ambiente. Il punto non è copiare il nome della tabella, ma usare la stessa logica: una proprietà dedicata per l’architettura, un join con il device, un filtro sul prodotto Office.

Come evitare falsi positivi

Il rischio più comune è classificare come 64 bit un’installazione che in realtà è 32 bit solo perché gira su Windows x64. Questo errore è frequente nei report costruiti con dati parziali. La regola da tenere ferma è semplice: architettura del sistema operativo e architettura dell’applicazione sono due cose diverse.

Per evitare falsi positivi, aggiungi almeno una verifica incrociata con il sistema operativo. Se il device è 64 bit ma Office risulta 32 bit, il dato è plausibile e spesso è proprio quello che vuoi intercettare. Se invece il device è 32 bit e il report indica 64 bit, c’è quasi certamente un problema nel campo sorgente o nel modo in cui stai interpretando la stringa.

Query di confronto utile:

SELECT
    sys.Name0,
    os.Caption0 AS OperatingSystem,
    os.OSArchitecture0,
    CASE
        WHEN arp.Name0 LIKE '%64-bit%' OR arp.Name0 LIKE '%x64%' THEN '64-bit Office'
        WHEN arp.Name0 LIKE '%32-bit%' OR arp.Name0 LIKE '%x86%' THEN '32-bit Office'
        ELSE 'Architecture not detected'
    END AS OfficeBitness
FROM v_R_System sys
INNER JOIN v_GS_OPERATING_SYSTEM os
    ON sys.ResourceID = os.ResourceID
INNER JOIN v_Add_Remove_Programs arp
    ON sys.ResourceID = arp.ResourceID
WHERE arp.Name0 LIKE '%Microsoft Office%';

Qui il valore di OSArchitecture0 serve solo come contesto, non come sostituto del dato applicativo. Se il tuo report evidenzia un numero alto di casi “architecture not detected”, non è un bug della query: è il segnale che devi migliorare l’inventario.

Collection SCCM basata su Office 32 bit o 64 bit

Se l’obiettivo non è un report ma una collection dinamica, la query deve restituire un set pulito e stabile. In SCCM il vantaggio è evidente: puoi poi usare quella collection per deployment differenziati, compliance o remediation. Il limite è altrettanto evidente: se il dato non è affidabile, la collection amplifica l’errore.

Una collection utile per identificare i client con Office 32 bit su OS 64 bit è particolarmente pratica quando devi pianificare la migrazione a 64 bit. Questo è spesso il caso reale: non ti interessa sapere solo “che Office ho”, ma “quali macchine devo toccare prima”.

Esempio di logica per una collection query-based:

SELECT DISTINCT
    sys.ResourceID,
    sys.Name0
FROM v_R_System sys
INNER JOIN v_GS_OPERATING_SYSTEM os
    ON sys.ResourceID = os.ResourceID
INNER JOIN v_Add_Remove_Programs arp
    ON sys.ResourceID = arp.ResourceID
WHERE os.OSArchitecture0 LIKE '%64-bit%'
  AND arp.Name0 LIKE '%Microsoft Office%'
  AND (
      arp.Name0 LIKE '%32-bit%'
      OR arp.Name0 LIKE '%x86%'
  );

Se il nome del prodotto non include la bitness, questa collection non basta. In quel caso devi introdurre una colonna inventariata dedicata oppure cambiare il metodo di rilevazione, per esempio interrogando i registri applicativi o l’inventario di una suite di Office più recente che espone meglio l’architettura.

Office Click-to-Run: attenzione al modello di inventario

Con Office Click-to-Run la situazione può cambiare parecchio rispetto alle installazioni MSI tradizionali. Il nome del prodotto, la chiave di registro e persino il comportamento dell’inventario possono variare. Per questo motivo una query che funziona in un parco macchine “vecchio stile” può fallire in silenzio su un ambiente più recente.

Se stai gestendo Microsoft 365 Apps, verifica prima quale dato viene inventariato dal client. In diversi casi la fonte migliore è un campo di registro o una classe WMI legata alla configurazione C2R, non la classica vista software. La domanda giusta non è “come scrivo la query?”, ma “dove SCCM vede davvero la bitness di questa installazione?”.

Un controllo operativo minimo sul client può essere questo:

reg query "HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration" /v Platform

Il valore atteso è tipicamente qualcosa come x86 o x64. Se il comando restituisce un errore, il ramo di registro non esiste o il prodotto non è installato in quel formato. Questo non risolve la query SCCM da solo, ma ti dice quale sorgente usare per costruirla correttamente.

Report pratico: separare 32 bit, 64 bit e incerti

In un report serio conviene sempre avere tre categorie: 32 bit, 64 bit e Unknown. La terza categoria non è un difetto del report, è la tua rete di sicurezza. Ti permette di capire dove il dato non è affidabile e dove serve un intervento sul client o sulla raccolta inventario.

Un output ben costruito dovrebbe essere leggibile anche da chi non apre SQL Server. Per esempio, puoi esportare il risultato in CSV e usarlo per priorità di migrazione. Se il 70% dei client risulta Unknown, non hai un problema di Office: hai un problema di telemetria.

Un modello di classificazione più esplicito può essere questo:

SELECT
    sys.Name0,
    CASE
        WHEN arp.Name0 LIKE '%Microsoft Office%' AND (arp.Name0 LIKE '%x64%' OR arp.Name0 LIKE '%64-bit%') THEN 'Office 64-bit'
        WHEN arp.Name0 LIKE '%Microsoft Office%' AND (arp.Name0 LIKE '%x86%' OR arp.Name0 LIKE '%32-bit%') THEN 'Office 32-bit'
        WHEN arp.Name0 LIKE '%Microsoft Office%' THEN 'Office detected, bitness unknown'
        ELSE 'No Office'
    END AS OfficeStatus
FROM v_R_System sys
LEFT JOIN v_Add_Remove_Programs arp
    ON sys.ResourceID = arp.ResourceID;

Questo tipo di query è utile perché non nasconde i limiti del dato. Se il prodotto esiste ma la bitness non è rilevabile, il report lo dice chiaramente. È il comportamento corretto per un ambiente enterprise, dove i dati incompleti sono normali e vanno trattati come tali.

Se la query non torna: cosa controllare nel client SCCM

Quando il risultato è vuoto o incoerente, il problema di solito non è SQL. Prima di cambiare la query, verifica tre cose: che l’inventario sia abilitato, che il client abbia completato un ciclo di hardware inventory e che il dato desiderato sia effettivamente presente nel client locale.

Controlli rapidi sul client:

  1. Verifica il log di inventario hardware, tipicamente InventoryAgent.log, per confermare che la raccolta sia partita e terminata senza errori.
  2. Controlla il registro SCCM del client per eventuali errori di parsing o classi mancanti.
  3. Confronta il dato locale con quello presente nel database, per capire se il problema è di raccolta o di reporting.

Se vuoi una verifica lato client senza toccare SCCM, puoi ispezionare il prodotto installato e la sua bitness con strumenti nativi. Per esempio, su una macchina con Office Click-to-Run, il controllo del ramo di configurazione è spesso il più rapido. Su installazioni MSI, invece, potrebbe essere più utile controllare la presenza dei componenti a 32 o 64 bit nel percorso di installazione e nei valori di uninstall.

Schema operativo consigliato

Se devi portare la query in produzione o in un report distribuito, usa questo ordine operativo. Ti evita di costruire una query elegante ma inutile.

  1. Identifica la fonte del dato: vista SCCM, WMI, registro o classe custom.
  2. Conferma che la bitness sia presente come campo esplicito e non inferita dal nome.
  3. Scrivi una query che distingua 32, 64 e Unknown senza forzare interpretazioni.
  4. Valida il risultato su un campione noto di macchine con Office 32 e 64 bit.
  5. Solo dopo usa la query per collection, report o compliance.

Se il campione noto non coincide con il report, non correggere a mano il risultato. Correggi la sorgente o la logica di join. È il modo più veloce per evitare un report che “sembra giusto” ma non lo è.

Conclusione operativa

La query SCCM per rilevare Office a 32 e 64 bit è affidabile solo se parte da un dato di architettura reale, non da un’ipotesi. In pratica: prima trovi il campo giusto, poi fai il join, poi separi i casi ambigui. Se il dato non esiste, la soluzione non è una query più furba ma un inventario migliore.

In ambienti misti, dove convivono MSI, Click-to-Run, Windows x86 e x64, la categoria Unknown è una funzione utile, non un difetto. Ti segnala dove il reporting non ha abbastanza informazione e ti indica esattamente dove intervenire: client, inventario o schema dati.