Discovery: A Windows virtual server discovered both via IP and vCenter could have different RAM values in each CIIssue <!-- div.margin { padding: 10px 40px 40px 30px; } table.tocTable { border: 1px solid; border-color: #e0e0e0; background-color: #fff; } .title { color: #d1232b; font-weight: normal; font-size: 28px; } h1 { color: #d1232b; font-weight: normal; font-size: 21px; margin-bottom: 5px; border-bottom-width: 2px; border-bottom-style: solid; border-bottom-color: #cccccc; } h2 { color: #646464; font-weight: bold; font-size: 18px; } h3 { color: #000000; font-weight: bold; font-size: 16px; } h4 { color: #666666; font-weight: bold; font-size: 15px; } h5 { color: #000000; font-weight: bold; font-size: 13px; } h6 { color: #000000; font-weight: bold; font-size:14px; } ul, ol { margin-left: 0; list-style-position: outside; } --> Symptoms If a Windows VM is being discovered as a server (cmdb_ci_win_server) and, at the same time as a VMware Instance (cmdb_ci_vmware_instance) because vCenter discovery is enabled, the RAM values might not match. If you log into the VM and vCenter, both show the same amount of RAM. Cause If RAM is added dynamically to a Windows VM through vCenter while it is running the Win32_PhysicalMemory class isn't updated. As the ServiceNow Windows probes use this class to recover the memory information it appears incorrectly in the cmdb_ci_win_server CI. It appears correctly on the server because the Win32_OperatingSystem class is used to retrieve the information. You can verify this by running the following command against the target server as per the documentation provided here: Manage ECC Queue content powershell.exe 'Get-WmiObject -Class Win32_OperatingSystem -ComputerName <TARGET_SERVER_NAME_OR_IP> -Property FreePhysicalMemory' NOTE: This is not a platform limitation, this is a consequence of how Windows WMI and dynamic memory assignment interact. Resolution Reboot the VM, this will update Win32_PhysicalMemory.