Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 1 subscriber
  • Views 1417 views
  • Users 0 members are here
Options
Suggested
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

Is there a way to tell EM to protect more computers in bulk?

nduda78

Say you highlight 100 computers and protect them, it does then in batches of how many, like 5? Basically, the 100th computer on the list gets protected last and it can take a long time for that to happen. 


Maybe we are impatient, but deploying globally at once, we rely on some offices to complete first. I've been staring at a system with the orange hourglass for a couple hours now just waiting for it to get its place in queue.

Anyway to tell EM or the SUM to open up more install threads?

:20503


This thread was automatically locked due to age.
  • 0

    Hi,

    As far as I know, there is one install task queue background thread and one install result queue background thread.
     
    Every twelve seconds, if install task queue is not empty, it will create schedule task on endpoint machine and run it.  Then computer will be added to request queue background thread (for feedback). 

    Every twelve seconds, for each computer in the result queue, if setup is not completed for 20 minutes than it'll time out and GUI will display install failure installation time out.  If setup is completed but no RMS message for 1 hour, then it'll time out and GUI will display install failure no message received

     
    So for 50 computers it should take 50 X 12seconds = 10 minutes to finish setting up schedule tasks and running them. 


    The install queue simply creates schedule task and run and keep on doing that, if it fails to create/run scheduled task, error will be logged and it’’’’ll carry on.   The result queue will poll computer to check the result and set as time out after a period, so there is no blocking/waiting.


    The DWORD keys that can be used to alter this behavior are as follows: 
     
    HKLM\SOFTWARE\[Wow6432Node]\Sophos\EE\Management Tools\InstallResultTimeInterval                    

    12*1000                               = 12 seconds


    This is the interval time install result queue background thread will check for install status (for all computers in the queue, not just for one)
     
    HKLM\SOFTWARE\[Wow6432Node]\Sophos\EE\Management Tools\InstallTimeInterval                                

    12*1000                               = 12 seconds
    This is the interval  time install task queue background thread will schedule and run scheduled task on endpoint machine.
     (we don’’’’t want all endpoints to be installed and log in\request certificate all at the same time, so this will do gradually)
     
    HKLM\SOFTWARE\[Wow6432Node]\Sophos\EE\Management Tools\MaximumInstallTimeInterval            

    20*60*1000                        = 20 mins
    This is maximum time management service will wait for client booststrap setup to complete.
     
    HKLM\SOFTWARE\[Wow6432Node]\Sophos\EE\Management Tools\MaximumInstallMessageTime          

    60*60*1000                        =  1 hour


    This is maximum time management service will wait for first RMS message to reach management service.

    So you could fiddle with these DWORD keys, you would need to restart the Sophos Management Service after adding/changing the keys.

    For real speed for mass deployment an AD startup script could break the back of it?

    Hope it helps.

    Regards,

    Jak
     

    :20511
  • 0

    Thanks, I'll play with these.

    Our official stance is to not use AD for anything Sophos related, even GPO installs, for a couple reasons.

    Sophos using AD syncing is only good if your AD structure (OU's) and administration is clean. I know, it's a sysadmin training thing, but we have 14 sites globally, and New OU's pop up (which get default policies base on sync folder, which isnt always good), and new systems are added to the domain where they are never put into OU's or the correct OU's, which would get wrong policies.


    If we use GPO to put Sophos to an endpoint that isnt in a group (instead unassigned) it gets no policies. Helpdesk staff has this issue where if they see the white/purple shield on a client they "assume" sophos is installed and getting the right policies.

    By not using AD (except for computer discovery) the only way to install SEPP is manually through the EC or from the CID share (which is not broadcasted as the proper way of installing). By manually installing SEPP in the console, the admin is also required to move it to the correct folder for policies.

    This menthod is allowing us to have a cleaner dashboard, and truly track who has and doesnt have sophos installed. It's working well for 9000 systems in 14 sites so far.

    :20543
  • 0

    Hi,

    I hope they help.

    With the group on bootstrap switch (http://www.sophos.com/support/knowledgebase/article/12570.html ) you can specify the group the machine goes into on initial install.  As the machine becomes managed (RMS installed) the management server will send down the policies for the given group.

    So this maybe used if the script has the logic in it to map the machine to a SEC group.  I guess it depends on what property of the machine you could use to map it.  E.g. Part of machine name, description, OU, OS, etc...  So for example a VBScript as an AD start-up script could have in it a "lookup" table of SEC groups within it with conditional cases to construct the command line needed.


    Just another idea.  

    Regards,

    Jak

    :20549