Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SGN Product Enhancement Suggestions

Might be a good idea to star this list early so it's in early. My wishlist

- Better AD synchronization (automated, configurable schedule, and built into MC)

- "Policy for a slider" - meaning give user the option via policy to control how fast they want to encrypt the HD. Of course if this policy is disable user cannot control that (aka today's status). Giving the users a little power will simplify the deployment of such invasive product

- Better policy stamping on the client. Today you can see "Last Received" but that's misleading as policy might not have been changed for long before that. I would rather see a hashmark or some kind of name where I could match the server policy name with the client (the date should be in the name)

:145


This thread was automatically locked due to age.
  • The problem with your winpe disk is you neglected to make it with any network support. And in 5.4 USB does not work properly. You can get it to work but it neglects to display the drive in the A43 app unless you do a refresh. What I would like to see if for you to provide the drivers needed and the keyrecovery app so I can make my own winpe disk.
    :623
  • Mike-F,

    There was a KB article that described how to make your own WinPE disc with the recoverykeys app. The article isn't available anymore.

    If you send me a private message in this forum with your company email address or contact Sophos Global Support you will be able to receive a document to create you own WinPE recovery disc.

    :637

  • Thomas wrote:

    I added the feature request: Remember last "pass through logon to Windows" selection.

    With compliments,

    Thomas


    Thanks Thomas.

    :642

  • Thomas wrote:

    - Better policy stamping on the client. Today you can see "Last Received" but that's misleading as policy might not have been changed for long before that. I would rather see a hashmark or some kind of name where I could match the server policy name with the client (the date should be in the name)

    We hear this suggestion for the first time.


    I mulled over this for a while and while not (yet) being a SafeGuard customer I think it expresses a more general problem: "If I'm not in control then at least I want to be informed" - and a usual answer is (no offence meant, Thomas) "this is too complex to understand (for you)".

    A simple example: the ABS in your car. Of course you want to know if it works - that is, you want to be sure it will work when you need it. But how can you be sure? If it's telling you with a green light that it will - can you trust it? So the arrangement is, it will tell you with a red light in advance that it definitely wont work - otherwise assume it will. Still ...

    Or take the SAV icon: it has the white-on-red x when the update has failed. Otherwise it's telling you when it has last successfully searched for updates. I've heard from several people that this is not satisfactory: it should also tell you the last time it has received an update. Whereupon I say: and what might this tell you? It always turns out that the underlying fear is that the client is not protected from the very latest threat.

    Of course all the arguments are to a certain extent valid - nevertheless they are rationalisations. What do you, vojta, or your users want to find out? Whether the client has the correct policies applied? Or whether "something" has changed recently or not? Do you have an example where this would really be needed?

    Changing sides: vojta said "will simplify the deployment of such invasive product".  Perception and acceptance by the (end-)user are not unimportant (at least for some of us "intermediaries" - and "This is how Sophos is doing it"  is not an answer you want to give all the time). It's hard to know what exactly is needed - and even harder to explain and it might not make sense from an engineering point of view. Take the "slider": it would be a solution to an imaginary (unless two processes are "competing! for the idle cycles) problem - nevertheless it could also solve the real problem. Of course the "slider" wont help if CPU monitors still show near 100% usage ... Sometimes it's more psychology than technology

    Christian

    :645
  • Christian, on the policy date stamps, it's solely for troubleshooting purposes for IT admins to keep their environment protected. I yet have to see software where green light is what it is in ABS. There is way too many variables in systems and I have seen way too many flawed reportings. Given that, we (who care) need more information. Sure, hide it for the others but I want the option to see when, where, what anytime. I just can't trust it works. SEP (newer SAV) is a good example of implementation of the policy time/date stamping that already saved us many hours in deployments, troubleshootings, etc.

    On the slider, it's absolutely about the perception. I work in environment where the most successful deployments are where the end user is engaged and you give them something back (such as the slider). I really don't care what number it represents but having the option to use it if you choose to is what I'm after. Again, there will be environments that just dump it in and that's fine. However, you shouldn't not assume that we can all do that.

    Vojta

    :646
  • This is what I expected, Vojta :smileyhappy:.

    You said: SEP is a good example of implementation of the policy time/date stamping - could you tell us how this stamping looks like and how it helped? I think others who either don't know how it looks like or aren't aware how it might help could benefit from that.

    Christian

    :687
  • Hi vojta, 


    vojta wrote:

    <snip> SEP (newer SAV) is a good example of implementation of the policy time/date stamping that already saved us many hours in deployments, troubleshootings, etc.


    Policy stamping:

    Today, the client tells you the time of the last SGN Server contact. It also tells you if it received a new policy.

    If I understand you correctly, you want always to be able to see which time the last policy was from. Right?

    So we should add the time of the latest policy change. I guess that's the time, when the client received it from the server, what you want (vs. the time when the last effective policy was updated by an admin on the server).

    Best regards,

    :761
  • Thomas,

    Exactly, that's what I would like to see. I would actually maintain two separate fields, I would keep the "last server contact" but then I would like to see policy-serial-number which should embed the date AND time and however else you want to format it. Date/time stamp would of course do as well.

    Vojta

    :771
  • Hi Mike-F,
    Mike-F wrote:
    The problem with your winpe disk is you neglected to make it with any network support. And in 5.4 USB does not work properly. You can get it to work but it neglects to display the drive in the A43 app unless you do a refresh. What I would like to see if for you to provide the drivers needed and the keyrecovery app so I can make my own winpe disk.

    I agree with David Schwartzberg. It's actually not too difficult to create your own custom Windows PE CD without networking and USB restrictions. You might want to have a look at Microsoft's knowlegde base articles.

    The SGN Client has a tool called "AddSGN2WinPE" (can be found in the "program files\utimaco\safeguard enterprise\baseencryption" folder) which patches your WinPE installation. Additionally, you have to add the "RecoverKeys.exe" (can be found on the SGN install CD in "tools\keyrecovery and restore").

    Hope this helps you,

    :795
  • Hi vojta,


    vojta wrote:

    Exactly, that's what I would like to see. I would actually maintain two separate fields, I would keep the "last server contact" but then I would like to see policy-serial-number which should embed the date AND time and however else you want to format it. Date/time stamp would of course do as well.


    I just checked the SGN client functionality again, because not even a product manager knows every feature off pat...

    Right-click the SGN tray icon and then select the "status" menu. You will see that the time of the last policy update is recorded. Of course, you don't see it easily in the tool tips, but you already have this function in SGN.

    I think that a policy serial number is not appropriate, as you might have many policies which apply to one computer/user. Then it might be misleading, especially if you use policy hierarchies.

    With compliments,

    :797