Endpoint Protection

Agree with you. You can mitigate your pain if you save user name and password so that you don't need to insert them during logon:

Admin > Domains > Edit Domain Properties > Password tab > Allow users to save credentials when logging on

Now the system is at least as insecure as with the Never setting for the console :-)

This can be done pretty easily when you know how; for myself I´m facing your "would be cool if that will work via policy"-thoughts everytime I apply a new SEP version to our clients, too. This is so seldom I forget it every time that the way to achieve this is slightly different. Because of that I´m documenting it here, not unselfish :) :

1) In client view, define your packages with the needed settings in a group:

2) After that, on the left side of SEPM there´s the option "Apply current deployment settings". Click it. (btw. also available via right-click):

3) In the now appearing "Copy Deployment Settings" dialogue window right-click the parent group and select "Select this and all subgroups". Now all groups under the selected parent group will inherit/copy your installation package.

Please be aware: during my experiences this works like a charm with one group and its subgroup(s). If you´ve got a sub-sub-group, eg. "Site (parent group) - Department (subgroup) - Servers (sub-sub-group)" the packages will not be applied. It works with like a charm with 2 levels of groups. Like in screenshot above: select Hall E and subgroups: Hall E and underlying departments are getting the packages. Doing the same with the parent group of Hall E will have no effect.

Best Regards

Peter Renner

IT Int. Sourcing AG

While I can and do appreciate a lot of the changes and improvments, even though the ugprade failed and trashed one SEPM and is giving nothing but troubles on the other related to virus defs, the one thing I wish they had left alone and left up to me, stop telling me how to work is the timeout. They took away my ability to keep the console open more than 1 hour. I should be the one to determine that, not the coders. When I am up to my eyeballs in alligators due to failed upgrades and updates and need to do a lot of back and forth there is little more frustrating than having to START ALL OVER logging in again. I have exclusive ability to get to the console, others cannot. I've got things locked down well, but this feels like they are dumbing it down to protect people who don't know better or should NOT be playing with security software - protecting them from themselves.

I will decide, not someone forcing me to log in every hour when I'm already dealing with a half-dozen fires, some of them caused by the upgrade to RU5.

Give back my right to leave the console open to specific pages and logs for more than an hour - and I will be opening a case on this as it's just plain dumb to dumb down an interface for a profesional in order to protect amateurs.
I also have to keep that open as it's our way of monitoring events since with the 12 series they totally broke the device control alerts, and there was a case open on that but the writers refused to believe anyone actually used it and decided it was best to report on ALL events not just blocked events. More dumb...... they broke a perfect great alerting system back then, they told me tuff as no one cared to use it like we did - as a replacement for our other device control app.
So now I have to keep logging in to the console and keep opening up the monitor pages again, all because some don't know how to lock things down.

I want the ability to set the console timeout put back.

nice information..!

Hallo,

Thank you for fixes and improvements. I have a qustion about "Install Packages" tab under Groups.

it will be very usefull if I can set (apply) same "install packages" settings also for sub-groups in the Clients tree regardless if inheritance is enabled/disabled. In the large environment with hundreds groups and 3-5 subgroup depth it can really help.

Thank you,

Ondrej