One of the hardest tasks of an Altiris Administrator is maintaining agent coverage across the estate by ensuring all machines are managed and remain managed. This article will provide a brief guide on how to extend the AD import to include the pwdLastSet and lastLogonTimeStamp attributes of the computer accounts (see http://blogs.technet.com/b/ken_brumfield/archive/2008/09/16/identifying-stale-user-and-computer-accounts.aspx for further details of these attributes) and how to compare that data to the last configuration request data of the Symantec Management Agent to determine if there are any machines that are likely to have a broken agent. See screenshots.pdf for pictorial representation of the expected outcome of some of the steps.
The first step is to create a custom data class (I have attached the data class I created - Comp_Acct_Updates.xml) to store the data in;
The next step is to assign the data class you have just created to the Computer resource type to allow us to import the data against computer accounts.
Now we need to edit the AD import rule for computer accounts to import this additional data and write it to the data class you created above.
The final step is to build a report that will compare this data and show machines that are likely to have a broken agent (although this data could also be used to create a filter to add to the push computers schedule or used in a workflow to create a Service Desk ticket to get the client looked at by field engineering etc.). These steps will talk you through creating a very basic report using 30 days as the key number of days to consider an agent broken, however I have attached a report where this number is configurable within the report.
DECLARE @v1_TrusteeScope nvarchar(max)
SET @v1_TrusteeScope = N'%TrusteeScope%'
select vce.Name, acct.[last pwd change] 'Last Computer Account PWD Change', acct.[last logon] 'Last Computer Logon', mrt.Request 'Last Altiris Config Request' from vComputerEx vce
left join inv_comp_acct_updates acct on acct._resourceguid = vce.Guid
left join (select ccr.resourceguid, MAX(ccr.StartTime) Request from Evt_NS_Client_Config_Request ccr group by ccr.resourceguid)mrt on mrt.ResourceGuid = vce.Guid
where datediff(day,mrt.Request,getdate()) > '30' and (datediff(day,acct.[last logon],getdate()) < '30' or datediff(day,acct.[last pwd change],getdate()) < '30')
and vce.guid IN (SELECT [ResourceGuid] FROM [ScopeMembership] WHERE [ScopeCollectionGuid] IN (SELECT [ScopeCollectionGuid] FROM dbo.fnGetTrusteeScopeCollections(@v1_TrusteeScope)))
Click Save Changes.
N.B. the data we have imported above can have a multitude of uses, for example if a client is inactive in both locations the asset status could be set to missing and an automation policy created to email the last logon user or primary user to ask them to confirm the assets status.
@Dan - Hope you don't mind me adding something on I found at an ITMS 8.0 customer that others may be interested in.
ITMS 8.0 For ITMS 8.0, there is an additional option within the AD Import Section that I thought might be worth mentioning:
After selecting the import options, you'll see that there is an additional dropdown for "Merge existing data", I believe for this to function as intended then you will want to be selecting "Don't Merge" - shown below:
There are a number of other options, but if you're interested then reading the below will give an explanation into all the options (source), then my opinion on which is correct:
Don't merge If no key field (for example 'guid') has changed, the scenarios are the following: If the field is populated both in the Active Directory and in the database, the database data gets overwritten. If the field is populated in the database, but empty in the Active Directory, the data in database remains unchanged. If the key field has changed, the scenarios are the following: If the field is populated both in the Active Directory and in the database, the database data gets overwritten. If the field is populated in the database, but empty in the Active Directory, the data in database is set to NULL.
Merge existing value If the field is populated in the database, the Active Directory does not overwrite the existing data even if the value in the Active Directory is different.
Merge existing value (if not NULL) The Active Directory overwrites the NULL values in the database. If the field is populated in the database, the Active Directory does not overwrite the existing data even if the value in the Active Directory is different.
Merge existing value (if not NULL/empty) The Active Directory overwrites the empty fields and the NULL values in the database. If the field is populated in the database, the Active Directory does not overwrite the existing data even if the value in the Active Directory is different
Opinion: I believe "Don't Merge" is the correct option as you want the data within Altiris to be overwritten on each import. The data you are importing from AD (pwdLastSet and lastLogonTimeStamp) will be forever changing if the user is active, and you want this active data reflecting in the report so you can determine if the Symantec Management Agent is working as expected. Cheers!
Thanks for spotting my deliberate (*cough cough*) error!
I have updated the SQL accordingly
Thank you! We will be putting this report to good use!
fyi...had to make a couple changes to Report sql to get it to work in our environment -
We needed an underscore at end of Table name:
left join Inv_Comp_Acct_Updates_ acct on acct._resourceguid = vce.Guid
and had to remove the underscore in mrt._ResourceGuid and ccr._resourceguid