Autoupdate Architect problem 4

[rrgg]

I use AutoUpdate Architect ver. 1.1.1. now the scheduled update doesn't work, if I try manual pull (pull now) I obtain immediatly this error: Action denied.
To solve this I find only this operatios:
- UnInstall AutoUpdate Architect
- Reboot the system
- Install AutoUpdate Architect
- Reboot the system
- create scheduled autoupdate Job

For some day all works fine but now the problem is the same.

Best Regards.

 

[dave107west]

Which site are you attempting download from - FTP or HTTP.
I have had similar experiences with AutoUpdate Architect and usually find I am also unable to browse to the site.
I was having difficulty with the FTP site yesterday, switched to HTTP site and was successful in the manual pull.

 

[McTech]

I ran into the same problem on my ePO server, as well as all repositories last week - a simple reboot of each server got rid of the 'Access Denied' message in every case....dj

 

[rrgg]

The situation don't depend to FTP or HTTP.
I try to reboot Server but the result is the same:
1) Action denied (when I try manual PULL).
2) The scheduled tasks don't work.

Tks to all.

 

[VictorySabre]

Whenever I get the "Access Denied" error when I perform the Pull Now task manually, it is usually when the AutoUpdate Architect is doing a scheduled pull at the same time. As soon as the scheduled task completes, then a manual Pull Now works fine.

In most cases, I would be denied for about 5 minutes. If the download takes longer than usual, then I would be locked out longer.

Could it be possible that the scheduled job is hanging on your side? Maybe you can verify that you have the proper directory permissions for the DAT files to pull down to and then try creating a job to run once to see if it completes successfully?

Good Luck.

 

[P3dr0]

With ePo 3.0.1
Did you check the replication credentials ?
You can check the sitemgr.log to see what's the problems.

I also had problems with scheduled tasks (pull and replication task) on ePo 3.0.1

NAi helpdesk tell me to delete all tasks,
then to desinstall ePo agent on the server,
then reinstall ePo Agnet on the server
Then recreate the tasks.

We use Linux FTP Server as repositories, and we had change the ftp programs on linux, because the old one was not compatible with ePo. Now, we use WuFTP, and it's work fine.

It works for me

 

[stki]

We discovered the same issue with ePO 3.0.1.

Reason was that we set a maximum run time for the replication task and sometimes it took longer so ePO killed the job. Unfortunately some locks are still set.

To fix the issue we did the following:

Step 1:
Delete file disabledsitestat.xml (if existing - File is located at ..\epo\3.0.1\db\software).

Step 2:
Check the file sitemgr.ini (located at epo\3.0.1\db).
The entry for Status should be 0. If not (e.g. you find an entry like Status=4) just reset it to Status=0.

The pathnames for AutoUpdate Architect will be different but you should find the files.

 

[rrgg]

Tks stki.
I don't have ePO 3.0.1; in my situation (AutoUpdateArchitect 1.1.1) is sufficient Check the sitemgr.ini file and reset the "Status" entry to 0.
Now the question is: Why happen this? Is possible force this value to 0?

Best regards

 

[stki]

We have an open case at NAI regarding this issue but looks like there is no solution available.
In normal environment the value is reset to 0 when the job ends. You should not force it to 0 because during replication etc. this value is used to lock the repository. Otherwise you would be able to run several replication + pull tasks the same time.

 

[abnrange]

Go to Program files\Network Associates\McAfee AutoUpdate folder. Locate a file called SITEMGR.INI - edit with notepad change STATUS=1 to 0. Now try to poll. This should work for ePO and AutoUpdate.

 

[potts007]

stki, thanks for bringing this to our attention. I have been struggling with this for a couple of days now. It seems that maybe a job fails so it locks the status at 1 (or whatever it end up being), rather than dropping it to 0.

Thanks again.

Tim

Tim