omi new is often used in OMI scripting or shell commands to create a new instance of a class or to initiate a query. For example:
omi new root/cimv2 Win32_OperatingSystem
If the result is "not found," OMI cannot map the requested class to the target machine’s WMI repository.
Enable-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)"
Then test from the client:
omi new root/cimv2 Win32_OperatingSystem
Symptom: Win32_ComputerSystem also fails, or log shows access denied.
Solution:
Grant DCOM/WMI permissions for WMI remoting (if using legacy WMI bridge): win32operatingsystem result not found via omi new
Ensure WinRM is configured (even if OMI uses DCOM, it may fallback):
winrm quickconfig
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" -Force
Open Management Infrastructure (OMI) is an open-source project originally developed by Microsoft (and now maintained by the Open Group) to act as a high-performance CIM server. It is the engine behind:
When you run a command like omi new root/cimv2 Win32_OperatingSystem, you are asking the OMI client to connect to a remote Windows machine’s OMI server (which wraps WMI) and instantiate an object representing the OS. omi new is often used in OMI scripting
Windows WMI organizes classes into namespaces. Win32OperatingSystem resides strictly in root\cimv2. If your OMI command or script specifies root\default, root\wmi, or any other namespace, the result will be empty.
Verification: On the Windows target, open PowerShell and run:
Get-WmiObject -Class Win32OperatingSystem -Namespace root\cimv2
If this works locally, the issue is with the OMI query path. If the result is "not found," OMI cannot
# OMI CLI syntax
omi query 'root/cimv2' "SELECT Name, Version, OSType FROM Win32_OperatingSystem"
Expected output (truncated):
"Name": "Microsoft Windows Server 2019 Standard",
"Version": "10.0.17763",
"OSType": 18