Is there a way to determine what process or user renamed a computer to a different name?
This white paper article provides information on how computer names can be changed without any apparent cause. Unfortunately, it is not simple to determine what or who renamed the computers or on what date the changes occurred on, as the Symantec Management Platform does not specifically track computer name changes in its database. Note: While this article specifically refers to a computer's name, it can also be used for any asset type, such as for monitors, network printers, etc. These instructions can also be adapted to find other changes to an asset, such as when its Comment was changed; however, the Resource Change History of the asset should instead be reviewed for these types of changes.
Searching the Database
If the computers are being renamed with a specific syntax, such as they are having their names appended with something specific, it may be possible to search the Symantec Management Platform database to find what may be causing this. For example, if the renamed computers all have names that are appended with "-OLD", this phrase can be used to be search upon in the database. The following methods can be used to accomplish this.
Search the Item Table
SELECT CAST (State AS XML), *
FROM Item
WHERE State LIKE '%<phrase>%' -- Change "<phrase>" to what the computer names are being appended with. For example, WHERE Name Like '%-OLD%'. Remove the wildcard "%" from the beginning or end of the statement as necessary.
Depending on what is found, the user would need to evaluate what this is and if this is something specific that can be physically found in the Symantec Management Console. If so, this item, such as a custom task, should be changed or disabled. Refer to the Troubleshooting Automatic Processes section for more information on this.
Search the Evt_NS_Item_Management Table for the Change
The Evt_NS_Item_Management table may be able to help determine what or who changed a computer's name. The following instructions demonstrate how to use SQL scripts to find this information.
Part 1: Obtain the computer's GUID, original and new names.
Select a computer to be evaluated. Its GUID, old and new names must be obtained before the Evt_NS_Item_Management table can be evaluated. These instructions assume that the user knows what the old and new names are but not necessarily what the GUID is. The following SQL script can help find the GUID:
USE Symantec_CMDB
SELECT Guid, Name
FROM vItem
WHERE Name = '<Computer name>' -- Change "<Computer name>" to be the renamed computer name to check.
This SQL script should return only one record. If there are more than one, the user will need to further investigate what the computer's GUID is to ensure they are using the correct GUID. For example, editing the computer in the Symantec Management Console will include its GUID in the URL of the browser at the end. This can be copied and then used in these SQL scripts.
Part 2: Search the Evt_NS_Item_Management table to find the last entry with the computer's original name.
USE Symantec_CMDB
SELECT TOP 1 _eventTime 'Event Time', ItemName 'Computer', [User] 'User'
FROM Evt_NS_Item_Management
WHERE ItemGuid = '<GUID of computer>' -- Change "<GUID of computer>" to be the GUID found in Part 1.
AND Action = 'Modify'
AND ItemName = '<Original computer name>' -- Change "<Original computer name>" to be the computer's original name.
ORDER BY _eventTime DESC
This SQL script should return the last record for when the computer's original name was used. However, the records in the Evt_NS_Item_Management table are not kept forever. It may be that by the time the user checks these, this information is already automatically purged out of the table. If no records are returned, for example, this is likely an indication that this has happened. Without this information, it becomes virtually impossible to tell what or who renamed the computers. If the user needs this information, the only recourse is to attach a backup of the database made around the time that the computers were renamed so that these SQL scripts can be used to help find this information. Note: These instruction's usefulness may be questionable. If the original computer has had no modifications that were tracked in this table for a long period of time but then more recently had its name changed, the user may find it difficult to tell when this occurred. For example, if the original computer hasn't been modified for a year, but then today is renamed, there's no method to determine how far back in the past the original name was used last unless the user evaluates multiple backups of the database with old versions of the Evt_NS_Item_Management table to find when the last use of the original name was.
Part 3: Search the Evt_NS_Item_Management table to find the first entry with the computer's new name.
USE Symantec_CMDB
SELECT TOP 1 _eventTime 'Event Time', ItemName 'Computer', [User] 'User'
FROM Evt_NS_Item_Management
WHERE ItemGuid = '<GUID of computer>' -- Change "<GUID of computer>" to be the GUID found in Part 1.
AND Action = 'Modify'
AND ItemName = 'New computer name' -- Change "<New computer name>" to be the computer's new name.
ORDER BY _eventTime
This SQL script should return the oldest record for the computer's new name. Optimally, this will be somewhere date-wise close to the last original computer name entry from Part 2. If both original and new names appear in the table, then it can be derived that the first time the new name is used is the date and time when it was renamed. The user who performed the rename will be listed. If the user is the Application Identity, this could have either have been the user if they logged in (if that user account is also an active real user and the App ID is not just a service account) or it could have been a Symantec Management Platform process that used the App ID as its authority to invoke a task that changed the name, such as a custom task, CMDB rule, Data Connector import, etc. If the user is not the App ID, then this is likely a real user that was logged in that performed the change manually or by themselves running a process, such as those mentioned.
Troubleshooting Automatic Processes
For automatic processes, if there were many computers that were renamed, the date and time can be evaluated by looking in the Windows Task Scheduler on the Symantec Management Platform server to see what Altiris processes ran during that time frame. The Altiris server logs may also be useful for determining this. Knowing when or how often this occurred can help the user determine which process is causing this. For example, a custom task can be scheduled to be ran once a day that could be doing this. This could be ran at a custom time or be part of the NS Daily task.
Areas in the Symantec Management Console can also be evaluated to try to find automatic processes that are renaming computers. The following are the most common areas. Look for any apparent custom folders or processes; however, out of box tasks could be modified to do this too so that it may be necessary to check virtually everything. This can be a tedious and time consuming project for the user. Note: The only out of box process that will automatically rename a computer is when the computer is managed by a Symantec Management Agent. When the Symantec Management Agent checks in, it will (1) change the computer's name to by the computer's WIndows name and (2) change the computer's Status to Active. This is a process that cannot be modified and does not appear as a viewable task in the Symantec Management Platform.
Computer Merges
It's possible that a computer merge was the cause of the renamed computers if the merge key wasn't Resource Name. While this is not technically referring to the same situation as described in this article, this may result in confusion over what happened to computer names that can't be found anymore (because they were merged with differently named computers). As this article is intended for a single computer that actually did have its name changed, merges are not further discussed here. For more information about merges, refer to the following article:
How to troubleshoot duplicate assets
HOWTO98810