If you are like me, dealing with package servers is cumbersome. You have so much maintenance to do on them, you never know if they are going to stay connected, or if someone will just decide to turn one of them off. While they provide a great benefit to your Altiris environment they are just hard to manage.

This was the position that our company was in a few years ago. Let me give you some background on the challenges that we faced and our attempts to solve them. In the end I will show you the solution we now use and how it has made our Altiris Infrastructure a huge success.

We were trying to upgrade to Outlook 2003 at the time and it was our first major software push using our Altiris environment. We setup Software Delivery jobs to push the 350MB package to 14,000 PCs. We knew that bandwidth was going to be a problem.

Our largest links to our 150 locations was a T1. That is a very small pipe when most of these locations had 70-80 PCs. So we tried to start slow and only do a few at a time for each site. This process was taking months to get finished. Management was getting excited about the time it was taking to get the rollout complete and was tired of hearing it’s not done yet.

There had to be a better way to get software deployed to 1000’s of remote PCs. Especially since this was going to be the first of many large rollouts.

In came the Package Servers

Since the Altiris recommendation was to utilize their Package Server technology we began researching and testing these.

We first approached our server team to ask about using their file and print servers, since these were already at all of the locations, as package servers. As you can probably guess that was a quick dead end. They were not happy with the idea of having to place an agent on their servers that they did not have control over.

The only other alternative that we could think of was to buy a bunch of PCs and place them at each of the locations and make them our package servers.

So we setup 20 PCs at some of our largest locations to see how well this new concept would work. We locked the PCs down as best we could so people would not be able to use them and interfere with our deployments. We got approval to place the PCs at each of the locations in the data closets with the servers and routers. That should keep them secure and always available when we need them. Or so we thought.

We were now faced with the challenge of how to make sure these things were out there and working like they should. After all, if they were not working then we could completely shut a location down with all of the network traffic a software deployment would create.

So we setup monitoring to make sure the PCs were connected and turned on. That is when we started noticing the problems. Almost every day a different PC was turned off or had some other problem. We were spending 5+ hours a week just trying to make sure these things stayed connected and that was with only 20 of them.

Since they were PCs they would get unplugged when someone needed the network line to test a sever or a switch. People would try and take the PC to use as their own since they thought it was just a spare PC sitting in the closet. Disregard the big “DO NOT TOUCH” sign on the side of it.

So that idea turned out to be a big bust. After just a couple of months we gave up on trying to keep them updated and just gave the PCs away for other uses.

So now we were back at square one. Management and the business wanted to know when they could deploy these large application updates and the networking group wanted to know when they could pull the plug on our Altiris server because of all the bandwidth it was using.

Our CE in Shining Armor

Thankfully we were not the only ones out looking for a solution. Our networking group started to ask their favorite company Cisco what options they could deliver. After hearing that we were using Altiris they said they had the perfect solution that they also used internally.

They showed us a great little device called the Cisco Content Engine (CE). This little appliance was designed to do web caching and video streaming. Since Altiris Software Delivery can also transfer packages hosted on a web site using HTTP these appliances had a 3rd use.

The concept behind them was to be an appliance that sits alongside the router at each of the locations and intercepts HTTP traffic. The CE has a big hard drive inside of it that maintains a copy of the information you want to keep cached.

For us, we wanted to have all of our Altiris Software Packages cached on these devices. Once the files are cached locally on the CE and a request is sent to the server for that file the CE intercepts the request and serves the file up from its local hard drive. The traffic never crosses the WAN and the PC never knew that the file came from somewhere else.

The beauty behind this technology is that you are not relying on a piece of software on your computers to try and figure out where the best place to download the file is. It does not have to figure out if there is a package server nearby. The PC simply makes the file request to the network and the network makes the decision of where the best place to get the file is. This way you are allowing the network gear to do what it does best, route traffic.

We have been using these devices at almost all of our locations for about 4 years now with incredible success. We have deployed numerous software packages of over 1GB in size and have not had to worry about bandwidth.

On a typical day we see an average bandwidth savings on the WAN of 1-2mbps. It is just a simple task of turning the Software Delivery job on and forget about it. No more are we trying to slowly deploy software so as not to bring the network down. No longer are we getting complaints from the networking group about breaking their network links. No more are we causing a disruption in business just to keep the PCs up to date.

Other Uses

There have been numerous other uses for these devices that have only added to their ROI. Here is a list of some of the other applications where we have made use of this technology.

1. Patching: Patch jobs can be easily modified to work the same as Software Delivery jobs. We simply change the patch packages over to use URL’s instead of UNC paths and now we can push patches out as fast as the PCs can be notified.
2. Anti-virus software: Our AV solution utilizes HTTP transfers for all of its pattern and engine updates. Once we found the URL that it was using we set the Content Engines to replicate this information as well and they immediately began to work. We have one AV server that can push pattern updates out to the entire company of over 14,000 computers in less than 2 hours with no impact on the WAN.
3. Remote Installs: With all of our software library setting out at the remote location the Content Engines have also acted as remote installation shares. Not all of our installs are done with Altiris. Many may be done manually for break-fix situations. Since the Content Engines can also be accessed individually via UNC paths our technicians use these for all of their software installs on the PCs. This saves them and the customer a great deal of time in installing and re-installing applications.

How to set it up

The setup of making this work from the Altiris side is very simple. When you create your Software Delivery Package you need to select “Access package from a URL” as the Package source. That is the only configuration you will need to do in Altiris, everything else is done the same.

For your file server that your software packages reside on you will need to do two things. First install IIS onto the server. The default install of it will work fine. Second make the root folder that your software packages are in a Virtual Directory.

You can then point the Content Engines to the new web site that you just setup and it will manage the replication of all of the packages to the remote locations. It will synchronize these on a set schedule so you will never have to worry about the files staying up to date.

In Review

Just to recap here are the highlights of using Content Engines.

• Minimal bandwidth utilization
• Fast deployments for large packages
• Multiple uses beyond Altiris
• Simple and easy to manage
• Always available with almost no down time

While they may not be the greatest thing since sliced bread they are very close to it.