How do you handle Software Delivery for traveling or teleworking users?
As the number of laptop users grows throughout our company, I'm running into more and more situations where I can't satisfy the neesd/expectations of these users. I'm curious to hear from the community how Software Delivery administrators are addressing the challenges that these remote users create.
Our company information:
Retail organization with approximately 1800 Altiris-managed corporate workstations (not including our store infrastructure or servers).
40-50 users who are never or rarely at headquarters, but regularly work out of one of our stores. Many of these users also frequently work from home.
An Altiris infrastructure that is divided between 'corporate', 'retail' and 'servers' -- specifically, these 40-50 users are part of the corporate (HQ) infrastructure, not the retail infrastructure.
Scenario:
Installation of Windows XP SP3 (310 MB).
Very low bandwidth between stores and Headquarters that is heavily throttled during business hours.
Don't always know where these users will be working on any given day -- including from home.
Over the past few weeks we have rolled out to our remote distribution centers and to the IT users. Tonight I am scheduled to roll out to "everyone else". Stating the obvious: I'm not looking for an answer for tonight, I'm trying to prepare for the future.
Due to bandwidth constraints I have pulled these laptop users from the distribution. I have the option of scripting an installation for these users to pull their update from a local store server, but that takes more effort than it does to schedule an install for our corporate users. I have to "borrow" space from our retail infrastructure to stage the install files, as well as build intelligence into the script so the laptop knows exactly which store server to pull from. Not a big obstacle, really, but more time consuming than a vanilla rollout. I also have to coordinate with the users, as this install has been taking up to 90 minutes to complete, increasing the probability that I will be impacting their work.
The users who might be working from home are killing me. 310 MB over a home broadband connection can be a real bear. I've singled out these 40-50 users by IP address, because it's easy for Altiris to determine when they're in a store, but when they're working from home we have to deal with 10.x and 192.x addresses, which sometimes coincide with legitimate IP addresses that exist at HQ. In other words, I can't set up the collections to skip a specific subnet because I run the risk of skipping clients that really are at HQ and can easily receive the update.
I assume that I am not the only admin that has encountered these types of problems. Tell me -- how do you do it at your company?
Comments
Some thoughts
So, you didn't really say what kind of an Altiris infrastructure you were running in terms of DS or NS. I'm assuming you're delivering your swd packages, such as XP sp3, via NS to your clients. With that few clients, you should be able to use a single NS and have a package server in each store, would be the first thing that comes to mind. A ps can be a desktop or a shared server if cost is the issue. With package servers in place, your clients in the stores should be able to pull the package from the local source. The NS Agent also has bandwidth controls built in that you could use for your telecommuting audience. Possibly a separated out NS Agent config for telecommuters vs. in office? So with these bandwidth restrictions in place, the package will make it to the client, but it might take longer for the copy. Sometimes, we don't care and just allow the package to launch as soon as it gets to the client, but sometimes its nice to be able to coordinate the installation times. In these cases, we've staged packages by using a dummy program within the swd package that forces the file copy. Then we can use reporting to tell when the client base is ready to run the execution. It's also a lot of managing expectations and communicating to these users to make sure they understand what to expect in terms of timing.
Same problem
We are running into similar issues, we have a lot of laptop users (about 150) also and we're beginning to push out Service Pack 3. We are planning to use a method pretty similar to what plindqui described with package servers and bandwidth restrictions. The idea of the dummy program is a welcome addition though that I think we'll make use of, thanks plindqui.
I'd be interested in hearing what you decide to do.
Thanks for the responses
Here's some additional detail (I'm still dealing with this same package and users, BTW).
We do use NS for rollout to our typical users, but we have two different NS silos: Retail has their own NS server and essentially runs their own NS infrastructure, so it's not quite as easy as creating a package server in each store. The servers and workstations in the stores are reporting to their own NS server, not to "mine" (the one that the laptop users report to).
As I type this, I realize that our environment is pretty unique in how we combine use of NS and DS across their different silos. It's probably not realistic to expect anyone to help me work around our own bizarre implementations.
Since our network bandwidth is throttled by the Infrastructure team, I'm thinking it's best that we simply stage our packages weeks in advance. I think this is something I just haven't been willing to do. Typically I'm expecting to enable a job in the morning and run it later that night, but this is a case where I need to adjust *my* processes and then focus on communication to these employees. Give it a couple of weeks to stage on the client, then make sure everyone knows exactly which night to leave their laptop powered on so it can run. At that point it doesn't matter if they're in the store or not. If they don't leave their systems powered on, well... They were warned.
Thanks again! I appreciate the idea of the dummy package.
Dave
Would you like to reply?
Login or Register to post your comment.