Ghost Solution Suite

 View Only
  • 1.  GSS 3.0 - How Do I Globally Change DAgent Settings For Already Managed Computers?

    Posted Dec 07, 2015 08:30 PM

    Coming from GSS 2.5.1, (which we've been using for around 10yrs.), I've become more familiar with GSS 3.0 since beta.

    What I understand so far is (2) options affect new computers and their "Production Agent Settings" (DAgent located on client);

    • Tools/Options/Agent Settings
    • Tools/Remote Agent Installer

    Both have their settings for new PCs and I don't understand why there are (2) separate options or know their differences, as one doesn't affect the other. While changing either of these do affect new clients, they have no affect on managed clients.

    What my immediate question is, fine, 1 of 2 of these will address setting for new computers, but how are already "managed computers" (those known to the console) receive updates/changes to the local client's DAgent in real time?  I know they can be made to individual PCs/Groups thru a "rt. click/Change Agent Settings/Production Agent/Access" but when our console is in production we'll have multiple groups/hundreds of PCs.  Is there a global change we could make affecting all managed PCs at once?

    Changes would have to be made to our "Administrator credentials" every 90 days (security - best practices), thus we're looking for a way to globally change all of our DAgents for managed clients in real time.

    I've read all available documentation/videos I could find (i.e. User Guide, Automation Folders, forum postings, etc.) and I haven't been able to locate an answer.  Any insight further would be greatly appreciated!

     

     



  • 2.  RE: GSS 3.0 - How Do I Globally Change DAgent Settings For Already Managed Computers?
    Best Answer

    Trusted Advisor
    Posted Jan 25, 2016 12:59 PM

    The reason for the resounding silence is because this isn't well documented.

    To deliver a new agent settings you need to,

    1. Craft an aclient.inp file which contains the settings you want
      (there is a sample aclient.inp file on the express share which you can use to help you craft your own)
       
    2. Create a job called "Update Agent Settings". In here have copy file task that copies the this aclient.inp file to settings:aclient.inp on the client
      (yes, this is an odd destination path, but don't worry it's OK)
       
    3. Test this on a couple of machines to be sure everything is OK
       
    4. Target your entire estate with the job. Schedule in batches to reduce the server load of all the agent reconnections.

    There are faster, but less 'nice' ways. For example, after you've updated the default settings for all production agents you can simply delete all the computer objects (or delete in batches). As they report back in they should take on the new default settings automatically.

    Kind Regards,
    Ian./

     



  • 3.  RE: GSS 3.0 - How Do I Globally Change DAgent Settings For Already Managed Computers?

    Posted Feb 03, 2016 10:30 AM

    Ballen,

     

    Right click on your label that says "All Computers" in the left hand pane and navigate down to change agent settings-> production agent.

     

    Capture_0.PNG

    Capturdde.PNG

     

    You should now be able to change your agent settings for all computers



  • 4.  RE: GSS 3.0 - How Do I Globally Change DAgent Settings For Already Managed Computers?

    Trusted Advisor
    Posted Feb 03, 2016 11:21 AM

    Please beware of usng the right-click "Change Agent Settings" approach. There are two huge issues with this and I disuade enterprise admins from using it where possible.

    1. Auditing
      There is no audit trail at all if you use the right-click option to "Change Agent Settings". If you use a settings file you have a complete audit trail in the console for changed settings. 
       
    2. No Ability to Pilot Changes To Agent Settings
      When you select one computer and go through the agent change process, you can't save it. So, when you do this across all machines you have to go through the whole process again which introduces the risk of a major (and unaudited) screw-up. One which would require an at-desk visit to resolve.

      I've seen for example someone use this feature to change their deployment server. The tested on one machine changing the deployment server name via the right-click option and all was good. They then applied this globally through the right-click but mispelt the Deployment Server name. Every machine became inmanaged in the space of a heart-beat.

      If you use a settings file the settings you test are the settings you deploy.



    In short -I only recommend this feature to be used in small environments and test/dev scenarios. These two issues will pretty much contravene most enterprise environment change process, and it's something I recommend is removed from Console Tech permissions.