This content has been marked as final. Show 10 replies
Hello - I have a very similar amount of machines (between 6-7K). We are not syncing to AD anymore either, (which is somewhat of a hassle but that's another thread).
We were using 3.6.xxx agent. (184.108.40.206 console) I recently installed 220.127.116.110 to the repository. I simply made sure that all the groups were not inheriting the deployment task, and choose "Ignore" for the ePO Agent on the deployment task. After I installed the new agent into the Repository, I double checked all the groups and they were still set to "Ignore". I have so far switched the task to Install on two small groups and it's gone out to those small groups only. Currently the previous admin had all 6K+ workstations under one group. I'm working on dividing those up based on three locations before I unleash it to the rest of the workstations. We have 400 servers and I'm so far doing those manually as we do our regular server scheduled maint.
Thanks for your email. Its good to be in touch with someone who is going through similar issues.
One thing that springs to mind, is that if you are not synching to AD anymore how do you ensure that new machines on the network have the agent installed e.g do you do this via logon script or have the agent in a ghost image? (with the GUID removed).
I currently rely on Desktop support to add the agent to the Ghost image and remove the agen GUID upon saving the image. (which is what I used to do in a past position) The bad part about that is if they forget to delete the GUID with an image update. The other bad thing is keeping up with machines that come from a vendor and might be added to the domain manually, or machines that are on the network but not added to the domain. I almost have a complete handle on the system (I inherited it about a year ago and just got around to updating it). As soon as the Agent is rolled out everywhere, I'm going to update the console to the latest patch for 3.6, then I'm going to push out 8.5i patch 7. After that I'm going to try to master the Rogue sensor thing.
Seems like we are doing exactly the same thing. I am currently running 3.6.1 patch 3 on the server - will upgrade to patch 4 once agents are out. I'll then push out anti-spywhere to certain clients.
When you check in the new agent do you then check in the nap for that agent? Preumably if that is the case you can manage the old agents with the old nap and the new ones with the new nap.
We have quite a few servers set up as super agent repositories. I assume that the check in process will allow them to stay as SAs.
Did you experience any gotchas with the check in process at all?
Thanks for your info so far, as I find things out I'll update this post.
I also run a similar setup. My directory structure is divided into named subnets via IP. The top level "deployment task" is disabled with nothing set to install. All of the sub groups inherit the deployment task from the top level.
When I want to test a new EPO agent, I will drag/drop select systems to the Lost & Found folder. I have the deployment task enabled for "Lost &Found" to install "EPO agent". As soon as I am sure that we don't have any issues, I will then select certain groups and change their deployments tasks to install the agent.
We use the helpdesk to manually install the agent and also to put it into software images. I have had several instances where they forgot to delete the EPO agent GUID registry key.
Doing this is a lot easier than pushing out patches. This morning, I installed Patch 7 and tried to only have it deploy to Lost & Found via an "Update" task. However, about 30 other systems in another group received this patch. Not really a big deal as today I decided to release Patch 7 to the helpdesk for distribution as it seems to be okay.
I actually didn't check in that Cma360WIN.nap file before checking in the package. I just now followed the readme a bit more closely, and checked in the .nap and then rechecked in the package. I don't quite understand what the nap does as it all looks the same. I do need to read the manual a bit more... happy It was all working well on the small group of 300 machines it deployed to last week. I'll be sending it out to another small campus in two days, then I'll hit the rest of the machines.
Thanks for both of your inputs.
I'll be checking in the agent/nap today so I'll report how this goes.
I have 2000 machines on 18.104.22.1684 (3.6 patch 3) so far and a lot on older versions so I will check in 3.6 patch 3 to update the older versions so all machines are running that version (as in testing it seems to work ok).
Now that I am looking after EPO I have had two issues reported back that I will investigate later. These are:
1) Machines not updating from local repository - epo agent is set to find local repository based upon "subnet value" rather than ping time, but doesn't always go to the local repository.
2) Reports that twice per day machines appear to freeze as they update. This may or may not be related to the epo agent reporting back its "full properties" to the server.
3) NaPrdMgr.exe using up to 300mb of virtual memory on some machines. Restarting the McAfee Framework Service, reduced it to use 1.5mb of virtual memory.
Either of you guys noticed any of these issues?
Also a quick question for "twenden". Has CMA 3.6 patch 4 been fairly trouble free as an agent?
Windows 2000 SP4
Separate SQL 2000 Windows 2000 Database server
EPO 3.6.1 Patch 3
CMA version - gradual move to 22.214.171.1244
VSE 8.0 / 8.5 | Anti-Spyware 8.0 / 8.5 | Desktop Firewall
Also, do either of you check in the language packs with the CMAs - e.g. so the agent shows up in French / German etc
Yes, the CMA 3.60 Patch 4 (126.96.36.1998) has been trouble free for us. We deployed it out a while back to over 1500 systems.
I am presently deployed VSE 8.5i Patch 7 which also seems to be going okay. I was considering switching to the 4.0 agent but several people recommended that we wait until we move the server to EPO 4.0. Our EPO server is running EPO 3.61 with the latest patches and is working find so we don't have an immediate need to upgrade to 4.0 yet.