7 Replies Latest reply on Dec 28, 2009 2:25 PM by sthayden

    Repository issues

    sthayden

      I am running into an issue I'm slightly stuck on. I setup a new Distributed Repository today at a remote location and also built a new Agent policy to make the agents in that tree location to check with that repositry first. I applied everything and ran an update task and it is jumping over every Distributed repository and stopping at the 6th in the list which is my EPO server.

       

      I looked in the McScript.log and I am seeing this sort of message on every one of my Distributed repositories...

       

      2009-12-22 14:31:07 I #1008 naInet UNC Session initialized
      2009-12-22 14:31:07 E #1008 bldtrob Error trace:
      2009-12-22 14:31:07 E #1008 Thread  [Main thread]->
      2009-12-22 14:31:07 E #1008 SessMgr  [initializeScript]->
      2009-12-22 14:31:07 E #1008 creposi  [setNextRepositoryToUse]->
      2009-12-22 14:31:07 E #1008 creposi  [Candidate Indianapolis: testing]->
      2009-12-22 14:31:07 E #1008 creposi  [downloadFile,SiteStat.xml,C:\WINDOWS\TEMP]->
      2009-12-22 14:31:07 E #1008 imsite  [downloadFile,SiteStat.xml,,C:\WINDOWS\TEMP,1]->
      2009-12-22 14:31:07 E #1008 imsite  [checkBuildTransferObject]->
      2009-12-22 14:31:07 E #1008 bldtrob  [inetmgr::CreateTransferItfFromProperties()]->
      2009-12-22 14:31:07 E #1008 bldtrob   Failed >> Setting naInet transfer option DomainName =
      2009-12-22 14:31:07 I #1008 imsite  Download to: C:\WINDOWS\TEMP\SiteStat.xml
      2009-12-22 14:31:07 I #1008 imsite  Download from: (Indianapolis) SiteStat.xml
      2009-12-22 14:31:07 I #1008 NaInet Connecting to UNC Server: indianapolis-16
      2009-12-22 14:31:07 I #1008 NaInet Trying logged on user account privilege for impersonation
      2009-12-22 14:31:07 I #1008 naInet Impersonated logged on user token successfully
      2009-12-22 14:31:07 I #1008 NaInet Connected to UNC Server: indianapolis-16
      2009-12-22 14:31:07 I #1008 NaInet Downloading file: \\indianapolis-16\McAfee\SiteStat.xml from UNC Server
      2009-12-22 14:31:09 E #1008 naInet Error trace:
      2009-12-22 14:31:09 E #1008 Thread  [Main thread]->
      2009-12-22 14:31:09 E #1008 SessMgr  [initializeScript]->
      2009-12-22 14:31:09 E #1008 creposi  [setNextRepositoryToUse]->
      2009-12-22 14:31:09 E #1008 creposi  [Candidate Indianapolis: testing]->
      2009-12-22 14:31:09 E #1008 creposi  [downloadFile,SiteStat.xml,C:\WINDOWS\TEMP]->
      2009-12-22 14:31:09 E #1008 imsite  [downloadFile,SiteStat.xml,,C:\WINDOWS\TEMP,1]->
      2009-12-22 14:31:09 E #1008 naInet   File \\indianapolis-16\McAfee\SiteStat.xml Open() failed 1385
      2009-12-22 14:31:09 E #1008 imsite Error trace:
      2009-12-22 14:31:09 E #1008 Thread  [Main thread]->
      2009-12-22 14:31:09 E #1008 SessMgr  [initializeScript]->
      2009-12-22 14:31:09 E #1008 creposi  [setNextRepositoryToUse]->
      2009-12-22 14:31:09 E #1008 creposi  [Candidate Indianapolis: testing]->
      2009-12-22 14:31:09 E #1008 creposi  [downloadFile,SiteStat.xml,C:\WINDOWS\TEMP]->
      2009-12-22 14:31:09 E #1008 imsite  [downloadFile,SiteStat.xml,,C:\WINDOWS\TEMP,1]->
      2009-12-22 14:31:09 E #1008 imsite   NaInet library returned code == -5
      2009-12-22 14:31:09 E #1008 imsite Error trace:
      2009-12-22 14:31:09 E #1008 Thread  [Main thread]->
      2009-12-22 14:31:09 E #1008 SessMgr  [initializeScript]->
      2009-12-22 14:31:09 E #1008 creposi  [setNextRepositoryToUse]->
      2009-12-22 14:31:09 E #1008 creposi  [Candidate Indianapolis: testing]->
      2009-12-22 14:31:09 E #1008 creposi  [downloadFile,SiteStat.xml,C:\WINDOWS\TEMP]->
      2009-12-22 14:31:09 E #1008 imsite  [downloadFile,SiteStat.xml,,C:\WINDOWS\TEMP,1]->
      2009-12-22 14:31:09 E #1008 imsite   NaInet library returned code == -5
      2009-12-22 14:31:09 I #1008 NaInet Impersonated token closed
      2009-12-22 14:31:09 I #1008 naInet UNC Session closed

       

      Now, the first thing I thought was maybe a permissions issue. I recently changed the download permissions on the server. I previously had it configured so that it used the EPO service account, which has admin rights on our computers to download the file. This was causing some issues with other things, so I changed it to Impersonate the logged in user. I changed the Share permissions on the Distributed repository shares to reflect that Everyone and Domain Users have Read access so that they are able to download the files. Looking at the log, it looks like it is Impersonating them fine and connecting to the share to grab the files, but is getting a failure opening the SiteStat.xml, trying a couple times and then moving on to the next repository in the list.

       

      I have googled this error, I have searched on these forums and looked everywhere I can think, but I cant seem to find an answer to this. Every computer at that site seems to be doing this and I have verified the SiteList.xml is being pulled correctly from the EPO server. My big fear is that all my other sites are doing this as well which is something I am going to be checking very shortly here.

       

      If anyone has any insight into this or if you need anymore info, please let me know.

       

      I am running EPO 4.0 box with latest patches, and McAfee Agent 4.0 with Patch 3.

        • 1. Re: Repository issues
          sthayden

          Anyone? Every once and a while a computer at that site will connect to this repository but they mostly get this same error for all the other repositories until it hits my EPO server.

          • 2. Re: Repository issues

            Can you try this pls.

             

            For the folder that you making a distributed repo,add a user name with read/write permissions in sharing and also in security with full permission(preferably the user to be a part of local admin group of the distributed repo)

             

            In the ePo console,under the distributed repo settings for this specific repo,for replication credentials -use this username and try.If you are having troubles in giving a domain user account there for whatever reasons,create a local username in the distrbuted repo server with read/write access to the UNC which you are making as a distributed repo.

            • 3. Re: Repository issues

              sthayden ,

               

              Let me start by explaining why the agent is looking for the SiteStat.xml file. The sitestat.xml is used to determine if a repository is up to date. If you were to open it you would see that there is a catalog version with time stamp information. Each agent also has a copy of this file locally, if the agent version is newer it will skip the repository and move to another in the list.

               

              It looks like you should double check that the repository has been replicated to, in your case the  indianapolis-16 . The repository should have its own copy of the sitestat.xml.

               

              If you were not aware, you will want to always replicate to your distro-repos and superagent repos after a repository pull on the master repository. Doing this will ensure that each repository has the latest version, and that client machines wont fail over to the ePO_server. For more information about why the clients are needing to call back to epo check the McScript.log file a few machines attempting to update.

               

              Hope this helps.

              William

              • 4. Re: Repository issues
                sthayden

                I have my task to pull from the HTTP, I also have my distributed repository replication task set to run at noon and midnight every day. I have also changed the share permissions to give everyone full read and write access to see if that corrects the issue also. What I am finding odd i that I will test 2 or 3 computers as a time, I will flip on a deployment task to all of them and then do a wake up to them all at the same time. It seems like the first one that hits will pull from the proper repository and the other ones will then go down to the EPO server. I made sure that the share is set to maximum connections, so I dont know why the other ones arent hitting. It should not be because of permissions nor should it be because the repository is not updated. I'm just baffled...

                • 5. Re: Repository issues

                  Hi,

                   

                  Just try this in one repository.

                  Stop mcafee framework service in repository server replace the sitestat.xml with master server.

                  Start the service and run update.

                   

                  It may resolve issue.

                   

                   

                  Regards,

                  Mohan

                  • 6. Re: Repository issues
                    sthayden

                    Ok, I made sure the repository I am working with has the same sitestat.xml file that my master does. I checked the sitestat on the computer I was going to update and I verified that the date stamp in it was older then what was in my repository and it still if failing over to the master. I am still getting the failed 1385 message in the McScript_error.log. It may be time to call support but boy are those wait times long.

                    • 7. Re: Repository issues
                      sthayden

                      Ok, now I'm starting to get somewhere...

                       

                      Error code 1385 = "Logon failure: the user has not been granted the requested logon type at this computer."

                       

                      Now I have to figure out why it is not allowing access when I have the share set to do so...