Error: Policy request failed, COM error: The specified resource or other object does not exist (0x80041003)
Article ID: 170095
Updated On:
Products
Issue/Introduction
A client machine has not received configuration for quite some time. In the Agent Health page for that machine, it shows that every other process, like sending basic inventory and posting NSEs has been working just fine. All other client machines are receiving configuration updates just fine.
Severity: 1
Process: AeXNSAgent.exe (10528)
Module: AeXNSAgent.exe
Source: ConfigServer
Description:
Policy request failed, COM error: The specified resource or other object does not exist (0x80041003)
Severity: 1
Process: AeXNSAgent.exe (10528)
Module: AeXNetComms.dll
Source: NetworkOperation
Description:
Operation 'Direct: Post' failed.
Protocol: HTTPS
Path: /Altiris/NS/Agent/GetClientPolicies.aspx
Id: 12921.10528
Error type: SMP Server error
Error code: The specified resource or other object does not exist (0x80041003)
Error note: HTTP Status 200: 200 OK
Server HTTPS connection info:
Server certificate:
Serial number: xx xx xx xx xx 4e 88 9a 4f 74 01 f1 31 b0 50 0e
Thumbprint: xx xx xx xx xx 2b e1 35 74 31 c1 75 8b 45 2c 32 f4 0d 57 9f
Cryptographic protocol: TLS 1.2
Cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
Cipher algorithm: AES
Cipher key length: 256
Hash algorithm: SHA384
Hash length: 384
Key exchange algorithm: ECDH_P256
Key length: 256
Environment
IT Management Suite (ITMS) 8.1 and later
Cause
This error is common with machines from virtual environments (VMware) migrated to Nutanix, etc. The Symantec Management Agent is not able to determine the machine is a Virtual Machine so it sends in its requests claiming to be a "computer" or physical machine. However the database has the original machine's resource type recorded as a Virtual Machine and a merge cannot be completed.
Explanation: The client machine was merged before (virtual machine to virtual machine) but, being unable to merge the computer from virtual to physical machine, or visa versa, it stays as virtual. The policy process needs to match the right Resource Type while generating the client policy and since it has 2 different types, it didn't pass the check done under spPolicyRequestGetResources.
If you run a profiler trace while this machine is requesting configuration, you may see something like this:
EXECUTE spPolicyRequestGetResources @keyNames=N'name.domain', @keyValues=N'My-clientmachine.CORP', @resTypes=N'493435f7-3b17-4c4c-b07f-c23e7ab7781f', @resGuids=N'4668a15d-99db-4d3e-80ce-c7903bd8802c', @delim=N';', @allowDerived=0
where @resTypes=N'493435f7-3b17-4c4c-b07f-c23e7ab7781f' refers to "Computer" type (physical machine). The actual client machine is sending records that it is a physical machine rather than a virtual, causing a resource type mismatch between what the database has and what the client machine sent.
Resolution
This issue was fixed in ITMS 8.5 RU4 to avoid falling into this scenario but any previous machines in this state will need to be fixed manually as described below. Also there are other reasons why even with newer ITMS versions this issue could still be present.
You may see entries like this:
"Resource f2aa2634-b4d7-4dba-a661-6ac39e57d092 was promoted from type 493435f7-3b17-4c4c-b07f-c23e7ab7781f to type 2c3cb3bb-fee9-48df-804f-90856198b600","Altiris.NS.ResourceManagement.Resource.Promote","Altiris.NS.dll","9","Informational"
The current workaround on versions previous to ITMS 8.5 RU4 is to move the resource from virtual to physical. You can use the following SQL to change it to a physical (make sure you have a recent backup of the database in case it is needed):
--Check if this machine is a physical or virtual as far as the database goes
select * from RM_ResourceVirtual_Machine where guid = 'Machine GUID Here'
select * from RM_ResourceComputer where guid = 'Machine GUID Here'
--Run the following query to make the change from a virtual machine to a physical machine resource type
declare @guid as uniqueidentifier = 'ADD-GUID-HERE' --Change this GUID with the one from the affected client machine
insert into RM_ResourceComputer
select Guid, Name, OwnerNSGuid, ProductGuid, ProductUninstalled, Attributes, CreatedBy, ModifiedBy, CreatedDate, ModifiedDate, '9EFF444F-83CC-47BF-ACF9-C5D55733E4E7', Deleted, Description, IsManaged
from RM_ResourceVirtual_Machine
where guid = @guid
update ItemResourceType
set ResourceTypeGuid = '493435F7-3B17-4C4C-B07F-C23E7AB7781F'
where Guid = @guid
delete from RM_ResourceVirtual_Machine
where Guid = @guid
NOTE: In one instance of this issue (VM moving to cloud) we had to delete the endpoint from the console, restart the agent, and manually run the Delta Resource Membership Update which resolved the issue. This approach should not be taken unless no other solutions are found.
Feedback
