IT Management Suite

What process is being used to deploy the Symantec Management Agent for those technicians that are NOT Symantec Administrators within Altiris?  I have provided the embeded web page and as a Symantec Administrator, can deploy myself, but what about those that are not administrators within the console and cannot get to the SMA Deployment page?  If a client needs to be removed and reinstalled for whatever reason, how is everyone managing that with their level 1, level 2 and level 3 technicians that are not administrators in the console?

 

Thanks for the insight!

You can simply give those roles the relevant privileges and permissions pertaining to that console page, so that they can push the sma.

Thanks, I have tried that and it seems they can turn off/on the automatic push that we have set up which we do not want.  Any further thoughts?

Hi,

how to make possible to give access for "Push Agent" settings policy for "Level 1" role in SMP:

1. Open SMP Console under account from "Symantec Administrators" role ⇒ open "Symantec Management Agent Install" ⇒ mouse right click menu and click on "Security"

 

2. In "Security Role Manager" choose "Symantec Level 1 Workers" role ⇒ click on + ⇒ from drop down menu expand "Agents/Plug-ins" folder ⇒ expand "Symantec Management Agent" folder ⇒ click on "Settings" folder ⇒ click on "Symantec Management Agent Install" move it to selected items ⇒ click "OK.

3. Now you can set appropriate permissions for users from "Symantec Level 1 Workers" role. I've set "read" and "write" and now Level 1 user is able to open "Symantec Management Agent Install" from "Actions" tab in SMP Console.

 

4. Logon to SMP Console, using account from "Symantec Level 1 Workers" role ⇒ click "Actions" tab ⇒ "Agents/Plug-ins" ⇒ click "Push Symantec Management Agent". Now user from Level 1 role is able to push SMA:

 

Thanks,

IP.

Thanks, I had previously been able to set these permissions up, but this does not restrict the ability of those that have access to turn on/off the "Scheduled Push to Computers".  When I originally posted this, I was at the point mentioned above, but those users could still mess with the filter we had set up under "Scheduled Push to Computers" as well as turn it on and off.  Is there a way I can disable that section only?

 

Thanks again!

Yep, forgot about this option.I Will try to find how to disable write access for Level 1 workers role.

Fantastic.  Thanks Igor.  I look forward to your response!!!

Unfortunately I didn't find a place where this schedule option can be set as restricted for Level 1 workers role.

OK, thanks for trying.  Anyone else?

You could do it by making the agent part of your image (install it, stop the Symantec Management Agent service and remove the GUID before using sysprep). Here's a guide: 
http://www.symantec.com/docs/HOWTO2169

If you don't use images, but scripted installs, you can make it part of the runonce section in your unattend.xml (preferably by using WSIM which is part of the Microsoft ADK and is free)

If you just want your guys to install the SMA in rare cases, make the agent install script available to them on a share and make sure they can log in with local admin permissions.

Removing broken clients can also be done like that via aexagentutil.exe, which you can find in c:\program files\altiris\altiris agent. Just type aexagentutil.exe /? for a list of commands.

Hope this helps..

 

Yes, we have already made it part of our image.  I am mostly concerned with those cases when the agent is not communicating.  I want to give them the ability to install without going to the web page....ie do a remote install.

 

Thanks!

In case you want to avoid a site visit to fix a broken agent, you could also use psexec.exe to do a remote install/repair or removal. http://msdn.microsoft.com/en-us/library/bb897553.aspx

They do still need local admin permissions on the endpoint though, which you could realise through a GPO in case they don't have it currently. Best practive is to create specific admin accounts for that so they don't have to use their personal credentials, e.g. username_ad.

Or through a powershell script...