Greetings, wonder if any of you have run into the following scenario, which we are running into regularly:
1. MOVE SVM offload server # of connections under threshold and mvadm status on SVM offload server says service is running.
2. Clients connected to SVM say disabled. When we test the TCP connection to the SVM manager, the connection times out. mvadm status is showing the offload server is unavailable and MOVE error message on the client is:
U.3908.4892: Jul 16 2020:14:34:00.096: SYSTEM: evt.c : 1226: Connection to primary offload server failed. Requesting DNS lookup.
K.0004.4576: Jul 16 2020:14:34:00.096: ERROR: ivmc.c : 117: Failed to Connect to primary server, error = 0xc00000b5.
3. Without doing anything eventually the clients are able to re-establish connections and re-enable themselves.
What version of client / SVM are you using? - check against MOVE supported / MP known issues KB`s and update if noted
Check the SVM mvserver and client mvagent logs for exceptions at the same time as the apparent loss of connection. Also check the SVM windows system log for any move service restarts.
Are you using an SVM-MGR ? - if so check against position of the registered SVM by calling the sudo ./msmclient.sh ossdetails script
Our MOVE clients and SVM are 188.8.131.52.
We're not using SVM Manager yet (but hope to soon), clients are currently hardcoded to a single SVM. Presumably if we had a secondary server it should have failed over to the secondary server. We stopped using a hardcoded secondary server as this was doubling the number of connections to the SVMs, which was causing our SVMs to overload and refuse connections when they were only at 50% capacity.
Will check the MOVE server logs and system logs to see if I can get some insight into this.
Ran the powershell command Test-NetConnection -Port xxxx <SVM IP address> and indeed the connections were not being accepted at the time, even though mvadm status on the SVM said that the service was running.
Hi, If you aren`t using an SVM-MGR then load balance across your primary / secondary SVM by creating 2x policies with SVM 1 as primary in one, and SVM2 as primary in the other, with the other SVM as secondary. Now assign half your clients to policy 1 and half to policy 2.
A netstat –an –p tcp | find "9053" run from the cli on the SVM will show you the individual MOVE client connections. Some clients IP`s will have several connections momentarily. This is normal, as scan threads are created / torn down.
Yes the ultimate solution is to go with SVM Manager. Still a bit confused about if we can have multiple SVM Managers in one ePO site - getting conflicting information, so we're going to try it out in our test environment. We want to use two SVM managers because want to make extra that certain MOVE clients never use certain MOVE SVMs. With one SVM Manager, this depends on the systems being tagged correctly, which has the possibility of going wrong. Two SVM Managers is the most certain way of keeping two sets of systems separate.
Thanks for the hint about netstat, this actually is a workaround for another issue we have - we're unable to run the built in query "MOVE AntiVirus: Clients Connected With a given SVM" (or create our own query which does the same thing) and get any results from our SVMs that are NOT registered to our SVM Manager. - I had a case opened up on this and it couldn't be figured out, they suggested to try upgrading the extensions and the client to see if that solved the problem which it didn't. Using netstat can give us the systems that are currently connected which is extremely helpful.
Glad that was of use. Possibly have a look at https://community.mcafee.com/t5/MOVE-AntiVirus/SVM-Managers-can-you-have-multiple-Can-you-configure-... which has more detail on SVM-MGR options.
If you have a small number of SVM use the mvadm status / mvadm stats commands from admin cli on the SVM to review client numbers and performance.
Once you have your SVM-MGR(s) in place .
"netstat -putan | grep 8080" to show connected clients
"netstat -putan | grep 8443" to show connected OSS