Failed to update configuration. HTTP status 302: The requested resource was assigned a different Uniform Resource Identifier (URI). This change is temporary (0x8FA1012E)
Article ID: 220270
Updated On:
Products
Issue/Introduction
The customer started to notice the following message in the Agent UI when the client machines are in CEM (Cloud-enabled Management) mode:
"Error: HTTP status 302: The requested resource was assigned a different Uniform Resource Identifier (URI). This change is temporary (0x8FA1012E)"
When they are connected via VPN, they don't see this issue.
The agent logs show the following messages:
[157C6910010, WS: F68, RECV: 5F1A4000] UPGRADE request failed, error: HTTP status 302: The requested resource was assigned a different Uniform Resource Identifier (URI). This change is temporary (0x8FA1012E)-----------------------------------------------------------------------------------------------------Date: 7/8/2021 3:04:33 PM, Tick Count: 490558281 (5.16:15:58.2810000), Size: 456 BProcess: AeXNSAgent.exe (20076), Thread ID: 16940, Module: AeXNetComms.dllPriority: 1, Source: SMAIO.WSTransport.Socket
Failed to establish main persistent server connection, error: HTTP status 302: The requested resource was assigned a different Uniform Resource Identifier (URI). This change is temporary (0x8FA1012E)-----------------------------------------------------------------------------------------------------Date: 7/8/2021 3:04:33 PM, Tick Count: 490558281 (5.16:15:58.2810000), Size: 428 BProcess: AeXNSAgent.exe (20076), Thread ID: 18184, Module: AeXNSAgent.exePriority: 2, Source: Agent
Environment
ITMS 8.5, 8.6
Cause
HTTP 302 errors are usually associated with network misconfiguration. Most of the HTTP 302 errors refer to direct connections, so it is not completely related to how CEM works.
Agent gets an unexpected response that specifies that redirection to another URI was performed by the server-side and breaks the connection. Information about the redirected location is not logged, so we can't say anything about it.This behavior can be related to having a load-balancing device, SSL offloading, or some sort of wildcard DNS usage. Neither SMP server nor Internet Gateway performs HTTP redirections, that's why it is not expected by the agent and is treated as an error. So there must be some intermediate entity. Either legal or rogue one.
1. You may see an error text in the agent logs: "Operation 'Direct: ...'", this is direct mode, meaning, connected internally or via VPN. In CEM there will be an "Operation 'CEM: ...'".
Here is an example of the first sequence from agent logs:
a. Direct connection using IP: <IP Address>, Port: 443 <-- This is an internal IP Address.
b. Operation 'Direct: Connect' completed successfully.
c. Operation 'Direct: Head' failed.
Host: prodsmp.domain.com:443
Path: /altiris/NS/Agent/GetClientPolicies.aspx
...
Error code: The remote web server is down or not responding properly, cannot determine Notification Server version, or Notification Server version is not compatible (0x80042D24)
Error note: HTTP Status 302: 302 Moved Temporarily
2. This is not about a connection to the SMP server. The Agent connects, performs HTTP call, and gets a redirection response that is treated as "bad" since this kind of response is not expected by the agent. prodsmp.domain.com does not redirect the agent to any other address.
Resolution
Since this issue is generally caused by some sort of network configuration or intermediate device, please check the following:
1. In the Agent logs you should see what is been passed during the CEM connection attempts. Something like this:
Operation 'Direct: Head' failed.
Protocol: HTTPS
Host: SMPServername.example.com:443
Path: /altiris/NS/Agent/GetClientPolicies.aspx
Connection Id: 44.20076
Communication profile Id: {A5281119-6990-4094-XXXX-4901A2C1XXXX}
Throttling: 0 0 0
Error type: SMP Server error
Error code: The remote web server is down or not responding properly, cannot determine Notification Server version or Notification Server version is not compatible (0x80042D24)Error note: HTTP Status 302: 302 Moved TemporarilyServer HTTPS connection info:Server certificate:Serial number: XX XX XX XX 27 XX XX XX XX 6a 3c XX XX XX XX 13 XX 5fThumbprint: XX XX XX XX XX XX XX XX XX b7 d6 7b XX XX XX XX f6 XX 4bCryptographic protocol: TLS 1.2Cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384Cipher algorithm: AESCipher key length: 256Hash algorithm:Hash length: 0Key exchange algorithm: ECDHKey length: 256
You can try detecting that intermediate device by looking for the server's certificate - the server's certificate info is logged with every "Operation XXXX" log message. In this case, the agent was able to connect to some server and the agent got some certificate from that other device. See above in bold. That thumbprint should match the thumbprint for the CEM certificate in use.
2. If you see that in CEM mode the agent gets an unknown certificate, check that you are not using some sort of wildcard DNS (It's intended for something like distributed web applications when the client can connect to any of *.mydomain.com servers and work correctly with any of them. DNS query even selects those sets of IP addresses randomly. It is not meant for direct host address resolution).
The Agent can't establish the proper connection for "non-resolvable" server names if they are used.
3. You can try adding the external IP address of the Gateway to the Gateway policy on the SMP server. With this, we make sure the client machine knows that if the external name can't resolve at least has the external IP address available to try. Usually, we don't need to do this but this scenario is quite different from other implementations that we are aware of.
4. Try using the "Prefer Secure Gateway Connect" regkey under "HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Communications" on one of those client machines that can't connect in CEM mode. Change this key from "0" to "1". That will force the agent to try the gateway first and avoid going to the SMP server first. See 151144 "How to use "Prefer Secure Gateway Connect" regkey for CEM machines"
After making the change for the "Prefer Secure Gateway Connect" regkey, see if the agent logs show that now the agent is able to reach the gateway.
Pay attention if there is a connection from the gateway to the SMP server and if by chance you see revoked certificates under the Internet Gateway UI>Servers tab. If you have a large number of revoked certificates, check this:
On the Gateway:
1. Go to C:\Program Files\Symantec\SMP Internet Gateway\crl
2. Remove crl.txt file.
3. Restart the gateway service.
Feedback
