Eh, how to say that - if you tamper with LocalSystem account, you _should_ know what are you doing. The installation program on NTs needs high privileges - just to write to 'Program Files', to play with services, etc. It doesn't need high user's privileges, but it needs high LocalSystem privileges - the default are high enough, no new special 'avast_installer' user is not created. And, if some user deletes the privileges, installer won't run at all.

I do know what I am doing (or at least I would like to think so) and hence as a result realize why this process fails. I have no problem with the install (high privs aren’t really necessary to write to program files, but to windows directory by default I believe. On my system what you said does hold true, but it was installed with administrator privs so was moot.) nor do I have a big problem with the autocorrect as I realize the reason for the design as well as why my system wont allow for it, but the way I have it setup is on a domain account that does not allow for unsolicited traffic, because my website (which has been hacked through the local system account) is on the same subnet. So I just thought I would ask on the off chance that this was a group of independent procedures that could be setup to turn off with a check box even though I figured it would not be that way.

This was more of an inquiry not a feature request. So I’m not expecting a solution at this point other than to deal with it. I’m rather new to using avast on my workstations and in general (I was a big trend micro person after turning off certain web services) so I guess the next question I would ask is what service is this feature actually integrated into when it comes to write privs in the registry and/or program files. If this is the case I would just raise its priv level and be done with it, but as you know it takes 4 or 6 hours to test it making the process rather tedious for me to seek out myself and easy to miss.