Bug in ERA Server/Console vs Client?

After a FIRST time ever roll out (completely filled with blue screens/lockups/ and huge slowdowns) of the latest client (4.2.35 upgrade from 4.0.474) to my 1000+ users , I thought that I was in the clear. NOT my first ever roll out, but my first that was this big of a disaster compared to the dozens that went flawless in the past. I have had 200+ complaints as to system slowdown, noticeable enough to mention, so I figured I had to be like others in the forums, looking to strip out protection and features in order to have it not killing my systems. After being with Eset for a long time, I am surprised to see that I have to turn to this. Enough said about that.... I went into the policy manager to tweak out real-time protection so that it would not scan ALL FILES. I figured I would start there, and then head towards scheduled scans next. So after I looked at the policy, when you change from the default of scan all files, it presents you with a list in the ERA console of the extensions that WILL be scanned, there are like about 80 or so listed there. I wait for the 5 minutes and go and check a random client, and the policy did what I expected and made the change on the clients, but....when I open up the client console and look at the list of extensions that will be scanned, there are only 63 listed? What gives? I went back to the ERA console and looked again, and there are 20+ more extensions listed as ones that will be scanned. I went to 20 more clients and verified that same results, 63 extensions to be scanned. So where are the missing extensions, is it a failure in the policy from the ERA server, or a client side problem? If you just go straight to a fresh installed client and make the change, you get the 63 extensions by default. So how do I make the ERA server push out the missing extensions to be scanned that are listed in the ERA server?
Also on a side note is there any expected date for the ERA Server/Console V4 to be released? It would be great to be able to manage the schedules without doing all the export/modify /import things as a workaround to modify a simple scheduled task on the client.
Thanks,
Scott

 

Was this really that difficult of a question to get answered?
Scott

 

If you click Default in the extension setup in the configuration editor, it will create the following structure:

<NODE NAME="Extensions" TYPE="SUBNODE">
<NODE NAME="AddExtensions" VALUE="|*|" TYPE="STRING" />
<NODE NAME="RemoveExtensions" VALUE="" TYPE="STRING" />
<NODE NAME="ExcludeExtensions" VALUE="" TYPE="STRING" />
</NODE>

which means that default extensions will be set according to the default extension set of the client. I've found 3 redundant extensions in the default extension set of the configuration editor which will be removed to match the default set on v. 4.2 clients and prevent further confusion.

 

I guess you are not understanding what I am saying. I understand what you are saying in that the configuration editor will match what is on the client as default, but that does not seem right. I thought that was the whole purpose of having a ERA server and policy manager was to CONTROL what was on the client, and NOT the client controlling what was on the server. If the policy manager has 80 extensions to be scanned listed in the config when I apply it, then the client should OBEY that change and get set with the 80 extensions that I am seeing in the list before my eyes and NOT IGNORE IT! If it does not do this, then what is the point? I clearly understand what you are saying, but it does not make sense to function that way. So what happens then if I add another extension to the set of 80 that are listed? Does it still choose to ignore that one I added because it doesn't see it as a default on the client, or is it still going to choose to ignore the other 20 extra in the list, and then send down just the 1 I added? Bottom line is that if the server shows ".pig" as an extension that it will block when you are configuring the policy, it should NOT matter what the client default set is, this should end up on the client.