3 Replies Latest reply on Mar 3, 2009 1:11 PM by jawuk

    URGENT: - Agents communicating to replica EPo server despite different IP/Hostname

      Hi there

      OK . I have a pretty strange problem.

      We have an environment with 14,000 3.6 agents and an EPO 3.6.1 server. We have 15 distributed repositories at UNC paths


      We were looking to migrate to EPO 4.0 so to test the upgrade process, we made a replica of the EPO 3.6.1 server with server name (eposerver1) and IP address 10.10.10.1 for arguments sakes. We then created a replica from the VM template and renamed the server to (devserver1) and gave it a different IP address 10.10.10.2.

      The SQL database is stored on the actual EPO server itself, so i went through the process on the devserver1 to point it to the correct Databse on it self.

      Now this is where it gets funny. There was an incremental distributed repository server task setup on the server, and on the dev box which i disabled, but only 3 days after it was up, so for 3 days it could have been trying to replicate its repository along with the eposerver1 box to the distributed respositories. Anwyay, all seemed well, and i disabled the server task


      Yesterday , i went through the process of upgradeing the devserver1 box to EPO4, so i got the Framepackage out of the software repository on the devserv1 box, and run it on a couple of workstations to point it to the devserver1 box (as the IP and hostname is bundled in with the Framepkg.exe). and they were reported in to the devserver1 box as expected. No other agents were talking into the devserver1 box at this stage, and why would they, it was on a differnt IP address and hostname.

      Now, a day later, i looked this morning and all agents were still communicating with the eposerver1 box as normal and no others.

      Now, i look this afternoon and there are litterally hundereds of clients now talking to this devserver1 box! I have seen it myself, i had a laptop that was turned off, turned it on, run an update on the EPO agent with check of policies and enforce, then i clicked it again, and now, its updating from the devserver1 box!!

      this is not good as this was supposed to be a test box and i thought i had this all sussed! How the hell are workstations finding out about this devserver1 box, they woudl neede their EPO agent updated to find out about this box but i havnt knowlingly deployed an agent to these workstations from the dev box!

      Any ideas what i have missed!!

      J
        • 1. RE: URGENT: - Agents communicating to replica EPo server despite different IP/Hostname
          Update: -

          for some reason the Sitelist.xml in the Master repository and all the distributed repositories has the Server , ServerName and ServerIP changed to point to the dev box!

          Not only that but the siteinfo.ini file on the eposerver1 boz also has the devserver1 referenced it in

          below is a cut from the sitelist.xml in the DB folder and the DB/SoftwareCurrent/49/EPO3000*** folder. Notice how it has strangley kept the EPO 'Name' ePO_eposerver1'but changed the networking details. . . .

          <SpipeSite ID="{27DFD792-7236-4388-8B49-8847A4xxxxxx}" Enabled="1" Type="master" Name="ePO_eposerver1" Server="devserver1.mydomain.co.uk:8090" ServerName="devserver1:8090" ServerIP="10.184.80.38:8090


          note i have blacked out the last bit with 'xx's '

          that explains it , but how the hell has this addition been made to the master repository Sitelist.xml file ! which has then obviously replicated to the rest!



          this thread looks quite similar to what i am expericing

          http://forums.mcafeehelp.com/showthread.php?t=215669&highlight=sitelist.xml
          with the old server suddently recieving entries about the devserver1 in its sitelist.ini and then triggering the creation of the sitelist.xml files with the IP and hostnames of the devserver1 box in it! . . .not cool
          • 2. RE: URGENT: - Agents communicating to replica EPo server despite different IP/Hostname
            Im starting to think this might be an issue with the EPO 3.6 console that you install locally on a workstation to control remote EPO 3.6 servers. I just remembered that the console had somehow managed to find the existance of the other EPO server in the environment and listed it without me having to specify it. Im starting to think that it was THIS that has done something funny, maybe there is some weird undocumented broadcast thing that happens from EPO servers for the console to communcate on.

            How would the 3.6 console have found out about the other EPO server without me specifying the Hostname/IP?

            this might help lead me to a reason why this has occured
            • 3. RE: URGENT: - Agents communicating to replica EPo server despite different IP/Hostname
              Wow, 69 views and not even a single attempt to try and answer this issue, lol, i must admit, it has me stumped too.

              Situation we are in now is a state of flux. Late friday i decided to restart the eposerver1 box holding the dodgy sitelist.xml file, so computers coming on monday morning wouuld recieve this updated sitelist file and re-drect to the devserver1 box, so i would end up with them all in one place, but it turns out when restarting the service on the eposerver1 box recreated the sitelis.xml file again, and now it has the correct infomation! So we have over 7000 connected to the devserver1 box and the other half to eposerver1, managed to configure it so they are all getting thier updates but my god what a mess, and i am still no closer to working out what the hell happened, which is NOT reassuring, and Mcafee Primesupport didnt seem to be able to shed any light on the situation either sad

              What was strange was the date modified stamp on the siteinfo.ini and the server.ini files in the root of the DB folder on the eposerver1 box. They had a stamp of 19/02/2009 11:31, which correspondents to a server task to do a master repository pull. Earlier on that day the server had been cloned in VM ware, and the clone brought back up under a different name/IP, but the impact to the clients was only on 25/02/2009 when the sitelist.xml file was regenerated on eposerver1 and must have taken these incorrect settings from the server.ini and the siteinfo.ini ammended on the 19/02/2009. Weird thing is now, after restarting the epo services on the eposerver1 box on friday, both those server.ini and serverinfo.ini files AND all the sitelist files, now hold all the correct infomation, but the eposerver1's siteinfo.ini file in DB still has infomation about this other devserver1 box and its IP but impotantly the ''MasterSiteServer= '' field is correctly pointing to itself now, rather than before when it had =devserver1. now its ''MasterSiteServer=eposerver1'' and all the Sitelist.xml files have nothing in them about this devserver1 box.

              Such a mystery . . . . only way forward now seems like a redeployment of the FrmInst.exe to 14,000 machines. . . needless to say. . .i bet you are glad you are not me.

              I am weighing up my options to rectify the issue, but its highlly frustrating/embarassing when i cannot explain what/why it happened, so odd.


              Could it have anything to do with the fact that for 3-4 days both epo servers were 'talking' to the same database, despite the fact that no agents were connecting to the devserver1 box during this time before i reconfigured it to look at its own database, AND AFAIK server connectivity configuration is stored in the DB folders NOT in the database itself?