Jump to content
jkfweb

Advice for mass deployment using a product like SCCM

Recommended Posts

I am trying to plan a deployment to multiple clients across the world in many countries. Some are directly connected to a Kaspersky Server via lan and will be managed by a Policy, while a few others are just floating on the internet with the base client and no agent.

 

We currently use a piece of software called BMC Footprints for Software deployment and it's very similar to SCCM except we can push to any client on the internet.

 

Below I have worked up a few scenarios from the information I have gathered

 

Option 1:

1) Create a Standalone Package with Client and Agent (Setup.exe 225MB) with current virus database updates for each managed server

2) Create an Install Package in Footprints and push out to all clients

3) Restart Machine and manage updates with KSC

 

Option 2:

1) Create a Standalone Package for the Agent (Setup.exe 26MB) for each managed server

2) Create an Install Package for Footprints based on the MSI (117MB), Setup.ini, CFG File, and Key to push out to all clients

3) Restart Machine and manage updates with KSC

 

Option 3:

Deploy updated KES client from KSC to clients in different locations with Kaspersky Server

Use Option 1 or 2 for clients not connected to a local Kaspersky server

 

I am leaning towards Option 2 because it would only weigh in at 143MB total, MSI installs seem to go smoother than Standalone, and all the clients are configured the same. The agent/policy installs would have to be the only thing customized per location which weigh in at 25MB and are much easier to manage.

 

I originally leaned towards Option 1 but after some thought we wouldn't be keeping those packages up to date with the Virus Definitions and the clients would have to update anyways and I just didn't think the extra 81MB was worth it in that case.

 

I do have a few questions, and hope some people who have done this in past can provide some feedback:

 

1) Do I have to uninstall the previous client before installing the new one? I've been told by 3 support agents that if the client is 8.1.0.1042 or higher then we shouldn't have to uninstall first but the install but I have a co-worker who is telling me that is wrong.

2) What is the best way to perform the install if the previous version requires a password to uninstall.

3) Any other issues I should be expecting or looking out for.

 

I am just now starting testing but am seeking the wisdom of my predecessors and those who have done this before.

 

Thanks,

 

Joshua

 

EDIT:

 

I forgot to mention most of our clients are 8.1 or 10.1 right now, and the goal is to upgrade to 10.2

Edited by Joshua Fredrickson

Share this post


Link to post

We are actually just finishing up our deployment to over 5500 machines with about 600 of them being off our network. We used a similar product to SCCM as well to do some of the deployment work for us. Here is what we did.

 

1. Created a Standalone Package for the Network Agent (Setup.exe 26MB)

2. Deployed that standalone network agent via our SCCM equivalent product to all machines both on and off our network. It was a quick way to get the newest agent on the machines since we were moving a a brand new KSC server.

3. Used KSC tasks to push out the updated version of KES 10. We were running KES 8.1.0.831 that we had lost the password to but luckily KES 10 removed it without a problem. We then prompted our users to reboot when they wanted to. We used Update Agents to help lighten the load on the network and the server.

4. Machines there were off our network were able to talk back to our KSC server as we had them configured for that. We also had a backup plan for machines off our network which was a SCCM type package that had just the client install in case we needed to install it that way.

 

Hopefully some of that helps.

Share this post


Link to post
We are actually just finishing up our deployment to over 5500 machines with about 600 of them being off our network. We used a similar product to SCCM as well to do some of the deployment work for us. Here is what we did.

 

1. Created a Standalone Package for the Network Agent (Setup.exe 26MB)

2. Deployed that standalone network agent via our SCCM equivalent product to all machines both on and off our network. It was a quick way to get the newest agent on the machines since we were moving a a brand new KSC server.

3. Used KSC tasks to push out the updated version of KES 10. We were running KES 8.1.0.831 that we had lost the password to but luckily KES 10 removed it without a problem. We then prompted our users to reboot when they wanted to. We used Update Agents to help lighten the load on the network and the server.

4. Machines there were off our network were able to talk back to our KSC server as we had them configured for that. We also had a backup plan for machines off our network which was a SCCM type package that had just the client install in case we needed to install it that way.

 

Hopefully some of that helps.

 

That is actually helpful Dustin.

 

How many of these clients did you run into problems with(Crashes, Blue Screens or other serious issues)?

Edited by Joshua Fredrickson

Share this post


Link to post
That is actually helpful Dustin.

 

So you did the upgrade from 8.1 to 10 on all those machines primarily using the KSC. Did you have to uninstall the client as a seperate step, or just have the install client pull off the previous version?

 

How many of these clients did you run into problems with(Crashes, Blue Screens or other serious issues)?

We moved all of our machines from 8.1 to 10.2.1.23. I would say on 90% we used KSC to upgrade them once the network agent was loaded. The remaining 10% was mostly machines that had poor network connection and our SCCM type product just seemed to handle the larger package better. I think that was in part because KSC can sometimes take time to check-in with the client even after doing a force synchronization and our other product was a push method so we can force it on those machines quicker.

 

We did not uninstall it as a separate step. When we installed 10.2.1.23 it automatically detected an older version of KES and uninstalled it before installing the new version.

 

The biggest issue we ran into was on machines running "Windows XP Embedded POSready 2009". Those we had to keep on version 8.1 but it was only a couple of them. KES 10 just wouldn't load but the newest Network Agent did.

One other minor problem was users having incompatible software installed; examples were left over Symantec Live Update files from years ago when we had that product and a CheckPoint VPN driver. We had to manually touch those machines as Kaspersky wouldn't uninstall them; wasn't a big deal as the numbers were below 50 and we had enough technicians to slowly fix the issue.

 

We are running Windows 7 or Windows 8.1 on our machines.

Share this post


Link to post
We moved all of our machines from 8.1 to 10.2.1.23. I would say on 90% we used KSC to upgrade them once the network agent was loaded. The remaining 10% was mostly machines that had poor network connection and our SCCM type product just seemed to handle the larger package better. I think that was in part because KSC can sometimes take time to check-in with the client even after doing a force synchronization and our other product was a push method so we can force it on those machines quicker.

 

We did not uninstall it as a separate step. When we installed 10.2.1.23 it automatically detected an older version of KES and uninstalled it before installing the new version.

 

The biggest issue we ran into was on machines running "Windows XP Embedded POSready 2009". Those we had to keep on version 8.1 but it was only a couple of them. KES 10 just wouldn't load but the newest Network Agent did.

One other minor problem was users having incompatible software installed; examples were left over Symantec Live Update files from years ago when we had that product and a CheckPoint VPN driver. We had to manually touch those machines as Kaspersky wouldn't uninstall them; wasn't a big deal as the numbers were below 50 and we had enough technicians to slowly fix the issue.

 

We are running Windows 7 or Windows 8.1 on our machines.

 

Dustin, I really appreciate your time. The information you provided was great.

 

We are almost exclusively Windows 7 and Windows 8 in our environment though some of our smaller international operations still have a random Windows XP or Vista machine.

 

 

Share this post


Link to post

×
×
  • Create New...

Important Information

We use cookies to make your experience of our websites better. By using and further navigating this website you accept this. Detailed information about the use of cookies on this website is available by clicking on more information.