No Aclient best practice now?

MentalDragon · 12-23-2009, 05:09 AM

Question... is it now best practice to not use the AClient?

I took over an Altiris position at a new company. They use DS to image. After the imaging process is done, the AClient is disabled and NS is used for all Patch management and Software Deployments.

Is this common practice now?

They said they were told that everything you could do with DS, you could do with NS and that the AClient has too much "Chatter" on the network.

I actually like the option to have DS available. Some things are just quicker using DS rather than having to script things and make it work in NS.

I think I'm going to try and talk them into leaving the AClient enabled... but I need to have a good sell.

Does anyone have any recommendations as to how I could convince them to keep the AClient enabled?

let me know your thoughts please.

negal · 12-23-2009, 09:41 AM

What are you using over there? what product versions?

chris.crowell · 12-24-2009, 12:27 PM

We uninstall the Aclient after imaging a machine to prevent workers from accidently wiping a machine. The largest drawback is that nothing in the NS is real-time; the best you can do is near-time. The Aclient is great if you need something done right now. Some of the features available in the DS can be executed without actually installing the Aclient you don't loose all of your functionality when uninstalling the Aclient.

TRYDL · 12-29-2009, 09:49 AM

If the NS agent became corrupt, how would you fix it without another management agent. Hence why I keep the aclient on the box.

And yes you can redeploy the aclient, but that is simply redoubling the work.

Conversely, I have been in institutions where the aclient is just an imaging agent and if the NS agent goes south, they just reimage the box using lite-touch processes.

It really depends on your internal processes and established rule sets.

andykn · 12-30-2009, 06:05 PM

In any large (ish) organisation, strictly speaking everything should be planned, so NS is ideal.

One way you might be able to get round having the aclient turned off is to turn it on remotely and turn it off afterwards.

Run Script (locally on DS, agent not connected)

Code:

 
REM Set startup to automatic
REM Note no space before the = but one after
sc \\%COMPNAME% config aclient start= auto
REM Start service
sc \\%COMPNAME% start aclient
REM wait 10 seconds for service to start
ping -n 10 127.0.0.1 > nul

Bill Sullivan · 12-31-2009, 03:27 PM

How about using security in DS so that specific groups or people cannot "accidentally" re-image a computer or server.

andykn · 01-01-2010, 02:45 PM

Quote:

Originally Posted by Bill Sullivan

How about using security in DS so that specific groups or people cannot "accidentally" re-image a computer or server.

Anyway you should always have a "Build Container" - only Computer Records in there can be imaged or scripted installed by anyone.

That way it takes two actions to wipe a computer.

Brandon · 01-04-2010, 04:54 PM

Quote:

Originally Posted by MentalDragon

Question... is it now best practice to not use the AClient?

I took over an Altiris position at a new company. They use DS to image. After the imaging process is done, the AClient is disabled and NS is used for all Patch management and Software Deployments.

Is this common practice now?

They said they were told that everything you could do with DS, you could do with NS and that the AClient has too much "Chatter" on the network.

I actually like the option to have DS available. Some things are just quicker using DS rather than having to script things and make it work in NS.

I think I'm going to try and talk them into leaving the AClient enabled... but I need to have a good sell.

Does anyone have any recommendations as to how I could convince them to keep the AClient enabled?

let me know your thoughts please.

Due to the fact NS is a little more complex and requires much more planning, I think you would tend to see more people using DS only rather than NS only. I would find it hard to believe NS only installs are ever a common practice. I may be surprised though.

What are your client reconnect intervals? Is it just the WOL part that is "chatty"? If the networking people could be more specific with defining this, it could likely be adjusted.

The NS *can* perform the same tasks as the DS to some extent, but it comes down to is having the right tool for the job. Using only one or the other is going to complicate some part of your job.

Lets say an end user calls in to get something like the latest adobe reader (yes, I know this is probably in your image, so this is just an example).
NS:
1. Open the NS and navigate to the collections tab to find the proper collection.
2. Edit the collection to add the person’s computer.
3. Now tell the user to wait for a while and it will eventually show once their machine checks into the server, or else walk them through several more steps to check their computer in manually.

DS:
1. Drag job to user's computer and allow install to run and complete.

The DS is great for imaging machines and handling software installs from tickets real-time.

I personally couldn't imagine trying to work in the NS for day-to-day tasks. However, if you are doing an enterprise wide deployment (software update, patches, etc.) then I believe the NS makes the most sense. It is the tool for steady-state operation.

Derek Reedman · 01-07-2010, 04:21 PM

I agree with Brandon. Those are the same issues that I had and work the console the same way. DS is great for right now deployments. I have also into issues where the NS client is corrupted. I use the DS to uninstall and reinstall the client. I know the NS does the same thing, but ran into some issues in the past where the DS saved me from visiting the workstation.

LilDrunkenSmurf · 01-11-2010, 10:30 AM

I typically only use the DS. I've never used the NS actually. I've seen it used once or twice when he had it implemented, but no one's actually been shown HOW to use the NS.

We did *try* to get away from the DS, but that never happened.

dsowby · 01-27-2010, 01:19 PM

In our organization we have 8,000 comptuers. I use the DS exclusively thru the installable XP (and Win7) console. I dislike the web interface of both the DS and NS and dread having to upgrade from Deployment server 6.9 to 7.0 in the future.

We use it for imaging, software installs, and scripted changes like registry settings. For updates we Microsoft's WSUS server (free).

JeffreyJRiggs · 03-03-2010, 01:57 PM

mainly the way i have always looked at NS and DS is this..

NS

pro:
Schedule software
report on items
patch management
package servers
bandwidth throttling
highly configurable 6.5 console - only see what i let you

con:
agent interval could mean a machine just checked in and wont for a while
takes getting around it to get to places
ns6 task server doesnt work for us in the branches

DS

pro:
I.T. NOW tool - want to do it run it
desktop builds with 1 image
Security Lockdown

con:
no bandwidth throttling
no package servers so need 98 conditions to roll out to our environment if you want it as a local install. (There are ways around it which we havent done yet but im contemplating)

all in all i am starting to use the DS more.. but NS is where i do most...
app metering, app denial, inventory, patch management, software delivery

masonje · 03-04-2010, 10:24 AM

We had an issue of scale. We don't have enough servers (nore want them) to support all our clients on DS, but wanted it there post imaging for trouble shooting if needed. So I created this collection that shows all the PCs in the domain with the aclient installed and fit our naming standards (should have that post imaging):

Code:

select Guid from vResource where ResourceTypeGuid in  
 (select ResourceTypeGuid from ResourceTypeHierarchy where BaseResourceTypeGuid='493435f7-3b17-4c4c-b07f-c23e7ab7781f') 
 and 
 ( 
  Guid in ( 
   select [_ResourceGuid] from [Inv_AeX_AC_Client_Agent] where [Inv_AeX_AC_Client_Agent].[Agent Name]  =  'Altiris eXpress AClient' )   
   and   Guid in (select [Guid] from [vComputer] where [vComputer].[Domain]  =  'MyDomain' )   
 )and (   
   Guid in (select [Guid] from [vComputer] where [vComputer].[Name]  like  'OF%' )   
   or Guid in (select [Guid] from [vComputer] where [vComputer].[Name]  like  'SB%' )   
 )

Then I have a task that runs once a day to PCs in that collection.

Code:

'---------------------------------------------------------------------------------------'
' Programmer:    Jon Mason      '
' Date Created:  9/22/2008      '
' Description:  remove altiris "AClient" after a given number of days
'       '
'Revision History:
' v1.0 - 9/26/08 - JM - Initial release
'---------------------------------------------------------------------------------------'
Option Explicit
On Error Resume Next
dim objWshShell, objFSO
Set objWshShell = WScript.CreateObject("WScript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")
Dim strAclientReg, strAltirisDir, strAClient, intDaysToWait, strDSEReg, strReadDate, strDateDif, intParm
 
if NOT WScript.Arguments.Item(0) = "" then
 intParm = CInt(WScript.Arguments.Item(0))
else
 WScript.quit
end if
intDaysToWait = intParm
strAclientReg = "HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Client Service\InstallDir"
strDSEReg = "HKEY_LOCAL_MACHINE\SOFTWARE\DSE\AClientRemove"
if RegVerify(strAclientReg) then
 strAltirisDir = objWshShell.RegRead(strAclientReg)
 
 strAClient = strAltirisDir & "\ACLIENT.EXE"
 strAClient = Replace(strAClient, "\\", "\")
 if objFSO.FileExists(strAClient) then
  if RegVerify(strDSEReg & "\date") then
   'reg value is there, start counting
   strReadDate = objWshShell.RegRead(strDSEReg & "\date")
   strDateDif = DateDiff("d",date(),strReadDate)
 
   if strDateDif <= 0 then
    'time to remove the AClient
    RemoveAClient strAClient
    objWshShell.regdelete strDSEReg & "\date"
   end if
  else
   'insert todays date
   objWshShell.regwrite strDSEReg & "\date", DateAdd("d", intDaysToWait, Date()), "REG_SZ"
  end if
 end if
end if
 
wscript.quit
 
'############### Functions ###############
'function to verify if a reg value exists
Public Function RegVerify(ByVal sRegEntry)
 Dim WSH, sKeyTmp
 Set WSH=CreateObject("WScript.Shell")
 
 On Error Resume Next
 sKeyTmp = WSH.RegRead(sRegEntry)
 
 if err.number=0 then
  RegVerify = True
 else
  RegVerify = False
 end if
 
    On Error Goto 0
 
 err.clear
End Function
Function RemoveAClient(file)
 dim strCMD, ret
 
 On Error Resume Next
 strCMD = """" & file & """ -remove -silent"
 ret = objWshShell.Run(strCMD, 0, TRUE)
 RemoveAClient = ret
    On Error Goto 0
end Function

So in the package job, call this script with a peramiter of the number of days you want to remove the agent. The PC will then fall out of this collection for the task and the job is complete. We set ours for 7 days.

Oh and forgive me for some of the legacy code. I don't use that RegVerify function any more...