Why are my computers in the “Manage Lost Recovery Solution Clients”?
|Article:TECH28903|||||Created: 2007-04-18|||||Updated: 2008-07-21|||||Article URL http://www.symantec.com/docs/TECH28903|
Why are my computers in the “Manage Lost Recovery Solution Clients”?
The most common reasons for computers being in the “Manage lost computers collection” are because the information about this client in the Altiris database (Altiris) is different from the information about the same client in the Recovery Solution database (AeXRSDatabase).
There are many different reasons for this. Below, is an outline of common reasons, and in most cases, how to fix the discrepancy. Computers in this collection may still be able to actively take snapshots and restore files. Best practices would be to have this collection emptied on a regular, perhaps monthly, basis. The SQL queries may be run from Query Analyzer in default environments. To delete the account from this collection, if determined below, use the right-click menu option and choose Mark Computer Account for Deletion.
Note: If the account is active and deleted, the client will see a “The administrator has deleted your account” message.
- The Altiris Agent has been uninstalled from the client. All Recovery Solution server mode clients, as of Recovery Solution 6.1, require that the Notification Server agent is installed on the computer. If the Notification Server Agent is not installed, the Altiris database will not have a record of the computer, and Recovery Solution Tasks will not be available via the Notification Server Console.
- The Notification Server record of the computer has been manually deleted, but the delete was not cascaded to the Recovery Solution Database.
- The computer has been taken offline and the Notification Server purging settings have deleted the Notification Server account.
- The NSWorkstationGUID field is NULL in the Recovery Solution’s SBS table. To view computers with this problem, run this SQL:
SELECT * FROM SBS WHERE NSWrkstaGUID = NULL
- The NSWorkstationGUID field in the Recovery Solution’s SBS table does not match the Notification Server’s GUID. This can be checked by comparing the results of these two queries:
SELECT * FROM SBS WHERE [name] LIKE '<name of computer>'
SELECT * FROM vComputer WHERE [name] LIKE '<name of computer>'
- The Altiris Agent has not gotten a GUID from the Notification Server at the time the Recovery Solution Agent was installed. This may happen often when a .bat file installs both clients. You may be able to populate the correct settings on the client side by using the following command line: "C:\Program Files\Altiris\Altiris Agent\AeXAgentUtil.exe" /server:<server name>
- The client’s FQDN has changed since the first time the computer has sent basic inventory. For example, the computer was discovered originally via network discovery where the TCP/IP stack did not report the domain as part of the computer name or the computer has been added to a Domain. The key that the computer is being tracked by can be found with the following SQL:
SELECT * FROM resourcekey WHERE KeyValue LIKE '%<name of computer>%'
The name.domain is a common key for indexing computers. If network discovery discovered the computer’s name as “test”, and the computer is really “domain\test”, Notification Server will think that this is a new computer account and not give it the original GUID.
- If the IP address is the KeyName listed for the computer in the SQL query above, the IP address changing can result in the computer appearing in this collection.
- Using a .bat file to install the Altiris Agent immediately followed by a line that installs the Recovery Solution Agent.
- Multiple Recovery Solution Accounts have been created after the Recovery Solution Agent has been reinstalled on the same client with the Create New Account option each time. If there are multiple accounts, the older accounts usually just need to be purged. In the future, end user’s accounts should use the Reregister option when trying to associate the computer with the original snapshots.
- The computer may have been formatted or no longer exist. In this case, the Notification Server purging maintenance has likely cleaned up the record and the account should be deleted from the collection.
To mark computer accounts for deletion, the computer description file could be changed to something like "delete me" so that when viewing the Manage lost computers section of the Notification Server console, it will be apparent which account to right click on and mark for deletion. If the SBS key is known of the computer to delete, this SQL can be used to mark update the description:
SET ComputerDescription = 'delete me'
WHERE (SBSKey = <Enter SBS Key>)
A simpler script for looking for Recovery Solution Database and Notification Server Database synchronization problems might look like this:
DECLARE @computerName varchar(255)
SET @computerName = '%<Enter Computer Name>%'
Use AeXRSDatabase select * from sbs where [name] like @computerName
Use Altiris select * from vcomputer where [name] like @computerName
If you have a large group of computers that could possibly be out of synch with their guids you can use this script to see which computers have mismatched guids:
--Must change SERVER to be name of your SQL Server
SELECT vc.name, vc.guid, sbs.nswrkstaguid FROM vcomputer vc
JOIN SERVER.aexrsdatabase.dbo.sbs sbs ON sbs.name = vc.name
AND vc.guid != sbs.nswrkstaguid
Note: If you do have a large collections of machines that have out of synch guids between the Notification & Recovery databases you can run the attached sbsfix script on your Notification Server database to resynch your machines information.
What is the SQL behind this collection? (The declaration & variables were added to allow for users to run this query against their Altiris database without having to specify their cluster guid or location of AeXRSDatabase.)
DECLARE @cluster_guid AS VARCHAR(40)
DECLARE @rs_server AS VARCHAR(40)
DECLARE @query AS NVARCHAR(4000)
SELECT @cluster_guid = guid, @rs_server = '[' + DbServer + '].[' + DbName + ']' FROM RS_Clusters
SET @query='SELECT sbs.SBSKey, sbs.SBSName, sbs.DomainName, sbs.IPAddress,
sbs.ComputerDescription, sbs.LoginName, sbs.InstallationDate,
sbs.LastBackup, sbs.ComputerGuid, c._ResourceGuid
SELECT s.SBSKey AS SBSKey, s.Name AS SBSName, s.DomainName, s.IPAddress,
s.ComputerDescription, s.LoginName, s.InstallationDate, st.LastBackup,
WHEN s.NSWrkstaGUID = '''' THEN NULL
END AS uniqueidentifier
) AS ComputerGuid
FROM ' + @rs_server + '.dbo.sbs s
LEFT JOIN ' + @rs_server + '.dbo.SnapShotTimes st ON s.SBSKey = st.SBSKey
) AS sbs
LEFT JOIN Inv_AeX_RSA_Configuration c ON sbs.ComputerGuid = c._ResourceGuid
WHERE sbs.SBSKey NOT IN
SELECT DISTINCT c1._SBSKey
FROM vComputerResource comp
JOIN dbo.Inv_AeX_RSA_Configuration c1 ON comp.Guid = c1._ResourceGuid
WHERE comp.Guid IN
FROM Inv_AeX_AC_Client_Agent a
JOIN Inv_AeX_RSA_Configuration c ON a._ResourceGuid = c._ResourceGuid
JOIN RS_Clusters cl ON c._ClusterGuid = cl.Guid
WHERE c.[_SBSKey] > 0
AND cl.Guid = ''' + @cluster_guid + '''
AND IsManaged <> 0
Article URL http://www.symantec.com/docs/TECH28903