I agree - I was just thinking that if you had not manually forced a policy enforcement after manually setting the protection to allow you access then youm would have a "window of opportunity" where you could possibly modify the file before the next enforcement interval reset it as per the policy....
I've just tried a simple reboot and log on as non-priv user and one of my problem workstations has now updated O.K. - so you could be correct about this. Unfortunately the usual user of the W/S has gone home sick so I will need to check with him next wee in case it's soemhow user account specific.
I believe the reboot will fix the problem as it effectively kills all processes and unlocks all files. Its not an elegant resolution, but so far the best I can come up with. Please keep me informed as to your testing with a reboot. If I am correct I wll be able to pass the information out to remote support agents.
Yup having the same issue. I tried modifiying the permissions to the folder like someone else suggested and I stopped getting the could not write to ini file but it still doesnt update the dat.
Starting task: AutoUpdate Checking update packages from repository NAIHttp. Initializing update... Verifying catalog.z. Extracting catalog.z. Loading update configuration from: catalog.xml These updates will be applied if they are in the repository: Engine, DAT, VSCANCEU1000, EXTRADAT1000, BOCVSE__1000, VIRUSCAN8700. Downloading PkgCatalog.z. Verifying PkgCatalog.z. The requested file does not exist