How to Maintain a Standardized Computer Naming Convention for Active Client Computers

Many enterprise users have computer naming requirements that are strict, specifically deriving the name of the managed computer with a variety of constraints. Examples of some of these constraints are computer type, geographic location, building number, floor, and cubicle location.

For example, Tom Smith works for Symantec on the 4th Floor of the Lindon, UT North East facility. He works in Row 4, Cubicle 10, and he has a standard desktop computer. His computer name might look like:

Your specific situation may be different, but this example should provide a reference for understanding.

In our fictional scenario, it is also a corporate policy that when a new computer replaces the old one for Tom Smith, the replacement computer will have the exact same name as its predecessor. The name of the computer remains the same, constant, because its definition comes from computer type, geographic and physical location data.

The challenge exists when attempting to report historical information on a computer. A large majority of the reports that we use access data that has been collected from the current computer asset. If that computer has been replaced, the Altiris management environment knows, by virtue of the computers Name.Domain data, that the computer checking in with that name should have a specific inventory, etc. If hardware or software is different on the new machine, all of that data, once an inventory cycle completes, now reflects the new computer hardware and software inventory, taking away the ability to report on the historical data for that computer.

In our quest to preserve historical data, and still be able to meet the naming requirements restrictions, we discovered that the only way would be to use the Altiris Purging mechanism to retire the computer, and then rename the retired asset to something nearly the same as the original computer name. Connector Solution provides the capability to address this.

Our steps to resolve are listed below.

When a machine has reached end of life, to the support the policy that the replacement computer, going to a specific location, has to be given the exact same name. While this policy has some very good standardization concepts, this policy makes it more difficult to track history on both the old and the new computers. Since the policy requires that the ACTIVE machine maintain the correct naming standard, we needed to devise a way to reuse the exact name for the active machine, and still maintain the ability to report on the history of the asset, whether active or not.

To resolve this, we performed the following procedure:

1. We set the Purging Maintenance Task to Retire Computers, as opposed to deleting them. When this runs, it initially retires them with the ACTIVE machine name. See Figure 1 to set the machines to retire.
   
   

   Click to view.

   Figure 1 - Purging Maintenance Screen

2. We then used the Altiris Connector to query the Altiris database and generate a data set of retired computers. As a part of this process, we appended the resulting computer names with a "-old" suffix. Specifically, we created an "OleDB Data Source Configuration" object. See Figure 2.
   
   

   Click to view.

   Figure 2 - OleDB Data Source Configuration

   We provided a name, 'Retired Computer Import'. We did not add a description but you can further detail this data source by adding one. We specified as our Data Source Type a 'MS SQL Server Database'. Other options include MS Access, MS Excel, Oracle, or a direct data source connection string.

   Once we provided the Data Source Type, we were then required to configure the DB server Name. Also a User ID, and the Password are required. It was our experience that only an SA account would work here. Regular Windows access credentials did not seem to connect.

   We also then selected the appropriate DB name.

   We then specified that data was to be created via an Import Query. , we used the following query to generate the data:

   SELECT vi.name + '-OLD' as [RetiredName],vi.Guid,va.Status,va.[Asset Type],rahd.ChangeType,rahd.ChangeDate FROM vasset va 
      JOIN vitem vi on vi.guid=va._resourceguid
      JOIN ResourceAssociationHistoryDelta rahd on va._resourceguid=rahd.parentresourceguid
        AND rahd.ChangeType = 'I'
        AND rahd.ChangeDate > getdate () -1
   WHERE va.status = 'Retired'
        AND vi.name not like '%OLD'
   
   

   This query was pasted into the 'Import Query' windows, and collects the following information to comprise our data source:

   1. From the VASSET view:
      Status (whether or not the resource is retired), and the Asset Type (making sure we only collect assets that are computers).
   2. From the VITEM views:
      Name (and, at the same time, converting the name in the result set to computername-OLD), and the GUID of the resource.
   3. From the ResourceAssociationHistoryDelta table:

      ChangeType (to know that the resource change was an Insert, so we did not collect any already deleted resources), and ChangeDate (so we can collect and calculate its time eligibility for the rename procedure).

      The query then makes sure that we don't affect any resources that may already have a "-OLD" suffix.

      We then named the configuration object something that reminded us of its function - in this case "Retired Computer Import".

3. Once we have the data source tested, and we were assured that the data set is accurate, we then created an Import/Export rule. See Figure 3.
   
   

   Click to view.

   Figure 3 - Import/Export Rule Configuration

   1. To use this, you must first provide a 'Name:' for the rule. We named the rule 'Retired Asset Name Conversion'. Again, you can add a description as necessary.
   2. We then specified its data source as the "Retired Computer Import", which is the OleDB Data Source Configuration Object we created previously.
   3. The 'Replication Direction' we chose was 'Import'.
   4. We then specified a 'Resource Type', and chose 'Computer'. There are quite a few other options in this dropdown, but since our reference source data was computers from the VASSET view, COMPUTER is the correct choice here.
   5. As we were only bringing in computer assets, we did not check the "Multiple Resource Type Import" box. We were not creating new assets, but our plan was to simply rename the old ones, so we did not check the "Allow Resource Creation" box either. However, knowing that we were changing retired computer names, we DID check the "Allow Resource Update" box.
   6. Other than the rename, no other changes were being performed to the asset. Therefore, the "Removed Assets should be :" option was set to "Left Unchanged in the NS". Other options could have deleted the resource, or changed it status to 'Active', 'Disposed', 'Retired', etc, providing the standard Altiris Asset Management status options.
   7. We set no data filter, and the "Import processing rate:" option was left to "Fast".
   8. We did need to make sure that the column mappings options for Resource Lookup key were set to connect the correct guids. Therefore, we selected 'Resource Guid' to look up and match the 'Guid:' choice of 'Guid', again as shown in Figure 3.
   9. The next option, 'Resource Name' is VERY IMPORTANT to have set correctly. This essentially links the final resulting Resource Name to a column in the data source set. If you were to drop down the box, in our case you would see the five column headings of data we selected in our import query, RetiredName, Guid, Status, Asset Type, Change Type, and Change Date. Since we wanted the new name of the resource to have a '-OLD' suffix, and we had provided for that in the original query, in the 'RetiredName' column, we set the 'Resource Name:' option to "RetiredName", thus renaming the computer asset to the corresponding 'RetiredName' entry.
   10. We then specifically opened each of the options for 'Data Class Mapping', 'Association Mapping' and 'Reverse Association Mapping', and made sure that no other mappings were selected. We did not require additional data mappings.
   11. Since the Purging Maintenance task, which was set and configured at the beginning of this document, runs on a regular schedule, we needed to make sure that we appropriately used the procedure to accommodate (rename) any newly retired computers. Therefore, a daily recurring Run Schedule was set.
   12. Lastly, and most importantly, a test of the rule is necessary to assure that the data and renaming procedure does its job as designed. This is done by selecting the 'Test Rule' button at the bottom of the screen, as shown in Figure 3. This was done, and reviewed, including a selection of the detailed log option. Once assured that the data is correct, the rule was run. Select 'Apply' to save the rule, and 'Run Now', if you wish to run it immediately.

This allowed us to essentially rename the retired resource to the same name, and only appending a "-OLD" suffix to the name, and automating this procedure, thus making it possible to still report history on the retired asset, and using the same computer name for the active computers.