OMI communicates over HTTP/HTTPS (ports 5985/5986) using WS-Management. Windows requires WinRM to be running and configured and the firewall to allow these ports. Even if WMI works locally over DCOM, OMI will fail if WinRM is broken.
Check WinRM:
Test-WSMan -ComputerName <target>
If that fails, OMI cannot reach the CIM server.
The class exists in WMI, but a corrupted WMI repository can block OMI’s access. win32-operatingsystem result not found via omi
On the Windows machine (as Administrator):
cd "%PROGRAMFILES%\Microsoft OMI\bin"
omiserver.exe –register
net stop omi
net start omi
namespaceRestriction = false
Then restart OMI:
net stop omi
net start omi
You run a simple OMI query from Linux, macOS, or another Windows host:
omicli query "SELECT * FROM Win32_OperatingSystem"
Or via Python with pyomi:
session.query("SELECT * FROM Win32_OperatingSystem")
Expected result: OS details (name, version, serial number, etc.).
Actual result: Nothing — an empty list, a null response, or a "class not found" error. If that fails, OMI cannot reach the CIM server
omicli ei root/cimv2 Win32_OperatingSystem
If empty, enable debug logging on the OMI agent:
/opt/omi/bin/omiconfigeditor -c loglevel DEBUG
/opt/omi/bin/omiconfigeditor -c logmask 255
systemctl restart omiagent
Check logs in /var/log/omi/.
Ensure WinRM listens on HTTP/HTTPS:
Enable-PSRemoting -Force
winrm set winrm/config/service/auth '@Basic="true"'
winrm set winrm/config/service '@AllowUnencrypted="true"' # For testing only
Note: OMI can use just HTTPS/certificate authentication if Basic is not desired.
Older versions of Windows (Windows Server 2008 R2 and earlier, Windows 7) have limited CIM/WBEM support. The OMI client might negotiate a CIM schema version that does not include Win32_OperatingSystem as expected. While the WMI class exists, the OMI-WMI bridge may be incomplete in older OMI builds for those OSes.