Environment variables in exclusions SUPPORT!

[jeremyf]

I dug up the old thread for this, which was abandoned last summer, but it was too old to post in...

I wanted to find out from the guru's in here, does ESET support environment variables when setting up exclusions YET?!?!?! (I see no mention of it in ANY changelogs, including the new 4.2 release...)

Stuff like:

%Program Files%\
C:\Users\%USERNAME%\AppData\
%windir%\

Refer to this link:

http://support.microsoft.com/kb/822158

for MS recommended exclusions, and NOTE HOW IT *ASSUMES* YOUR AV SOLUTION SUPPORTS SYSTEM VARIABLES!

Somebody make my day and tell me ESET doesn't NEED to support this...

[Manu7204]

would love to see an answer to this

[timid]

afaik environment variables are nod supported.

[jeremyf]

Originally Posted by timid

afaik environment variables are nod supported.

You mean, you don't know but you just assume? Or you actually have tested and found it to work?

I am using version 4.0.474 currently, and have NOT been able to get environment variables to work...

I am looking for a definitive answer...

*edit*
on second thought, are you just making a joke? "environment variables are *nod* (not) supported"? If so, I LOL'ed...

[timid]

nah i just mistyped, lol

and yeah i have tested it and it does not work. so from me, that is a definitive answer

[agoretsky]

Hello,

Support for environment variables as part of path specifications is being considered for a future release.

Normally, you should not need to manually set up the exclusions mentioned in Microsoft Knowledgebase Article #822158, "Virus scanning recommendations for computers that are running currently supported versions of Windows," however, some customers do implement these for performance or other reasons.

Regards,

Aryeh Goretsky

[Brambb]

Altho most variables are not really needed the %username% variable is really nice to have and really no other way to proper exclude files in user profiles.

[jeremyf]

Originally Posted by agoretsky

Hello,

Support for environment variables as part of path specifications is being considered for a future release.

Normally, you should not need to manually set up the exclusions mentioned in Microsoft Knowledgebase Article #822158, "Virus scanning recommendations for computers that are running currently supported versions of Windows," however, some customers do implement these for performance or other reasons.

Regards,

Aryeh Goretsky

Hey! Wow man, I really appreciate you weighing in with at least a hint of future support for this! Thank you!

Can you explain what you meant by "normally" we would not have to set up the exclusions specified in the MS linked article?

I have seen numerous threads of people having difficulty, ESPECIALLY with servers, that point to setting up proper exclusions properly being the solution ...

I have also seen solutions suggested like having ESET hard code MS suggested exclusions right into the AV, or an "easy button" method, where simply clicking on it sets up the standardized, accepted exclusions...

I manage a number of servers and workstations, in a mixed Windows 2003, XP Pro, and Windows 7 environment. Wouldn't you recommend those same exclusions in the MS article for all of these cases?

Again, thanks for the response!

[jimwillsher]

For me, the preferred option would be an option in the config XML to allow auto-setup. That way the installer (or the ESET kernel) could detect what is installed on the system and then filter accordingly. This means you could roll out the same config to different systems and not have to worry.

At the moment it's a real pain, especially if you want to use the same config on x86 and x64 systems (different program files folder etc.). Also, not all systems have windows on C:\ (especially when dual-booting with XP or earlier) which makes C:\Windows exclusions much mroe tedious to code (we have a couple of XP machines running legacy apps where we have C:\Windows, D:\Windows\, E:\Windows, F:\Windows and G:\Windows installations!


Certainly, we really need something. On servers there is a predefined, reasonably static list of exclusions to apply - and ESET staff will often reply to problem threads here with "...and have you applied the server exclusions...." etc. It would make life easier for all if the exclusions were easier to apply.

Just my 2p


Jim

[Marcos]

Hi Jim,
this is surely something we'll be considering for future versions. I presume it makes sense to resolve variables when pushing configuration to clients. I've put it on the wish list so we'll see what our developers will say.

[jeremyf]

Originally Posted by Marcos

Hi Jim,
this is surely something we'll be considering for future versions. I presume it makes sense to resolve variables when pushing configuration to clients. I've put it on the wish list so we'll see what our developers will say.

Once again I appreciate another heavy hitter posting in this thread.

Just let us know how it goes, Marcos!

[agoretsky]

Hello,

Many organizations use ESET's software on servers without having to apply any exclusions, however, sometimes a performance or compatibility issue appears which is solved by using one (or more) of the exclusions.

Regards,

Aryeh Goretsky

Originally Posted by jeremyf

Hey! Wow man, I really appreciate you weighing in with at least a hint of future support for this! Thank you!

Can you explain what you meant by "normally" we would not have to set up the exclusions specified in the MS linked article?

I have seen numerous threads of people having difficulty, ESPECIALLY with servers, that point to setting up proper exclusions properly being the solution ...

I have also seen solutions suggested like having ESET hard code MS suggested exclusions right into the AV, or an "easy button" method, where simply clicking on it sets up the standardized, accepted exclusions...

I manage a number of servers and workstations, in a mixed Windows 2003, XP Pro, and Windows 7 environment. Wouldn't you recommend those same exclusions in the MS article for all of these cases?

Again, thanks for the response!

[techie007]

Originally Posted by Marcos

I've put it on the wish list so we'll see what our developers will say.

Is there any way for us users to view and/or add feature requests to this 'wish list'?

If not, what is the best way to submit feature requests?

[agoretsky]

Hello,

Every ESET section on Wilders has a "stickied" message thread to request changes. For example:

Future Changes to ESET NOD32 Antivirus
Future Changes to ESET Smart Security
Future Changes to all other ESET Products
Future Changes to NOD32 (v2.x is no longer being actively developed)

Posting a message in any of these threads ensures that it is read by many of ESET's customer care representatives, developers, localization managers, product marketing managers, technical support engineers, technical writers and virus lab staff, to name a few.

Regards,

Aryeh Goretsky

Originally Posted by techie007

Is there any way for us users to view and/or add feature requests to this 'wish list'?

If not, what is the best way to submit feature requests?

[jeremyf]

For anyone monitoring this thread, apparently this suggestion has been accepted and will be implemented!

Marcos reports so in the first thread agoretsky lists in the post above this one...check it out!

Kudos to Eset if they can get this implemented!

[jimwillsher]

Woohoo! My configuration tasks at new sites just got easier :-)

Nice one, ESET, thank you!


Jim

[Marcos]

Just remember that it won't work for user variables as ekrn.exe is run in the local system account and thus cannot resolve them.

[jimwillsher]

WINDIR and PROGRAMFILES are good enough for me :-) Oh, and hopefullly ProgramFiles(x86) to check for x64.


Jim

[Brambb]

So that means that %temp% (c:\users\username\AppData\Local\Temp) and %userprofile% (c:\users\username\) do not resolve for example?

Its not a nightmare for me but I can imagine those variables are most usefull since system variables are located on the same place 9 out of 10 times.