Client Management Suite

 View Only
Expand all | Collapse all

'very' Remote Users

  • 1.  'very' Remote Users

    Posted Oct 06, 2010 08:02 AM

    Hi,

    How does everyone treat their users who travel quite a lot and are normaly connected to the Office by VPN (3G)

    My Patch Management group i've simply managed to exclude these users from reeceiving updates, but what happens when we upgrade our NS7 server to CMS7 SPK2 MR2, theres quite a few updates in this upgrade and i need to make sure they not being pushed to these users who are on very limited bandwidth.

    I know Recovery Solution used to have an option which said 'not to snapshot' if client computer was more than 2 hops?

    Something similar in CMS7?

    Throttling i'm a bit concerned about, because in some cases i think this generates more traffic...(well not more, but its abusive)

    Regards



  • 2.  RE: 'very' Remote Users

    Posted Oct 06, 2010 09:30 AM

    Most VPN ranges are set by the network team, so you could define an targeted agent configuration policy to apply to a set target comprised of a number of subnets.

    Or, you can use the normal desktop target agent policy. Either way, you need to configure bandwidth throttling, either as a general rule (for the above option) or when speed falls below for the default option.

    You trickle the patches down, or exclude the target from all deployments.



  • 3.  RE: 'very' Remote Users

    Posted Oct 06, 2010 02:11 PM

    The use % of bandwidth can be a bit abusive, as it does do ping checks for speed every six hours by default, only during the download of packages, and only by the systems downloading the package(s) being distributed.

    In my experience, it is easier, and less visible to the prying eye of network teams if you just set a specifc bandwidth usage.



  • 4.  RE: 'very' Remote Users

    Posted Oct 06, 2010 03:10 PM

    Sorry to jump in on this topic but I was looking for something in the past as I have the exact situation but we are not currently doing anything special for our VPN users, yet.  Although we are not yet sending large file transfers via CMS yet either.  Only doing inventory collections.

    I was looking for a best practices guide for mobile users.



  • 5.  RE: 'very' Remote Users

    Posted Oct 06, 2010 03:37 PM

    There is a Targeted Agent settings policy which actually specifies 'All Windows Mobile' but how or what it uses to determine if a machine is mobile, i'm not quite sure. ...actually come to think of it, are they refering to cell phones or mobile pc's :-p



  • 6.  RE: 'very' Remote Users

    Posted Oct 06, 2010 04:38 PM

    Well I'm referring to Mobile PC's.  Not sure on this policy will need to look into this.



  • 7.  RE: 'very' Remote Users

    Posted Oct 06, 2010 07:30 PM

    But I don't know the details.  Mobile Management is something the teams here have been working on.  It's possible there may be policies for this coming in 7.1, but don't quote me on that - it's not my field.

    What I would suggest is doing a bit of research into this and possibly asking your Sales Rep about any word on Mobile management.  Sales tends to know the "answers" about upcoming stuff before anyone else, if that makes sense.  :D



  • 8.  RE: 'very' Remote Users

    Posted Oct 07, 2010 07:50 AM

    Thomas, having a simple policy in place for VPN users does no good if it doesn't address the fact that they are still connecting via a VPN.  If your only options are "Come into the office" or "get what you can before your VPN connection times out"  then you DO NOT have a solution.

    What Altiris is missing is (among other things) the ability to pull in updates directly across the internet in an encrypted fashion without the need for local network or VPN connectivity.  I have touched on this in the "Ideas" section.  You can read my idea for this HERE.

    If you don't have time to read the entire idea, then allow me to sum up;  We need the ability to set up a site server "Round Robin" as a client policy, AND the ability to set a "Site Server" for all clients reporting in from outside the company intranet.   This would allow us to configure mobile users with TWO site servers:  Thier local Intranet server for when they are in the office, and a secure "proxy" site server that is accessible from a public IP address directly across the internet.  This would allow us to continue to manage offsite clients just as if they were onsite as long as they are attached to the internet in some fashion.

    There are more details in my idea post, but suffice to say YOUR COMPETITION ALREADY DOES THIS.  It's time for you to step up.



  • 9.  RE: 'very' Remote Users

    Posted Oct 07, 2010 08:01 AM

    What I do know is that what you describe here is being discussed.  What I don't know is to what level anything is actually being done.  Perhaps you know more than I do - it wouldn't be a first.  :-)  Nor would it be a first for the competition to get something out before we do.  We do the same for them in many areas.  That's the nature of competition.  All you have to do is look at gaming consoles to see this in action.  Anyone here looking forward the next xBox?

    Your suggestion is excellent, and yes, I've heard this before.  Again, something is coming, and I wish it were my team so I'd know more about it.  Since this isn't my specialty, I'll leave off on this thread with that, and let someone else answer.

    Good luck!  Thanks again for the feedback!



  • 10.  RE: 'very' Remote Users

    Posted Oct 07, 2010 09:57 AM

    The Windows Mobile targeted policies are for systems that have a higher WAN vs. LAN connected policy, not smartphones. I forget the exact balance (60/40?) and how the WAN\LAN connection determined by Altiris, suffice it to say, I prefer to create my own targeted policy for a specific criteria.

    I know the remotely connected process\idea is something kicked around for quite sometime. Currently you could setup a NS\Site Server combo in the DMZ or internet facing areas, but it is a bit cumbersome, and may require you to open more holes than it's worth.

    I have been (especially in my previous consulting life) looking forward to the model mmoney has described, and I'm also aware that other products currently do it.

    Needless to say, mmoney, not everyone on here, even if they are marked as Symantec employees, are product managers. So, keep it easy on the " ALL CAPS YOU SHOULD BECAUSE..." comments.



  • 11.  RE: 'very' Remote Users

    Posted Oct 07, 2010 10:12 AM

    I'm trying to know everything...  LOL

    And for whatever it's worth, what both of you have said is NOT falling on deaf ears.  I'm not a PM, so I don't have the power that one of them would, but I remember.  Sometimes, one voice can make a difference (not often) so I'll keep remembering.

    Thanks both for the comments.  I learned a lot today.  :-)



  • 12.  RE: 'very' Remote Users

    Posted Oct 08, 2010 05:14 AM

    Wouldnt it just be easier to have an option (or tick box) when creating deployment jobs, that the client would check to see if it had a local site server (same subnet) and then if yes - downlod, or if NO then dont attempt to download?



  • 13.  RE: 'very' Remote Users

    Posted Oct 08, 2010 08:23 AM

    but it doesn't exist. The options provided are what works today. There are a number of active posts that discuss potential scheduling\timing issues and some hope that changes are on the horizon. However, they aren't available today.

    In lieu of the checkbox, you would have to setup a target in some fashion to accomplish that, whether or not you do agent configuration settings or bandwidth throttling.



  • 14.  RE: 'very' Remote Users

    Posted Oct 08, 2010 08:48 AM

    This comment was off-topic.  I don't mind if you already read it, but trust me, it does not address what was in the thread.

    For the sake of simplicity, I'll stick with the previous posted comments and shut up - again.  LOL

     

    If you did read what this USED to say, then suffice to say it's a correct response to "select from the closest server for deployments" if taken out-of-context of the thread being about people out-of-the-office.  We have a completely seperate issue with Deployment jobs not pulling from the "correct" site server which I've been posting on other threads, and my mind got all scrambled and posted the wrong response here.

    If you have a question about THAT (which applies inside the DMZ and has nothing to do with internet users), then please post seperately in a new thread.

     

    Again, sorry.