My End User Got Married - Now What?

The interaction between various Altiris products can be a mixed blessing. When the interactions behave and work as expected, things go smoothly; however there are a few bumps along the road. One of those bumps involves a scenario that occurs when a female employee gets married and the Active Directory account is updated with her new last name. For illustration purposes, using Peter Parker's girlfriend Mary Jane Watson, I will walk through one of the bumps for Asset and Helpdesk customers running Altiris Notification Server 6 (NS6). The good news is that this scenario no longer happens with the Symantec Management Platform 7 (SMP7). The bad news is that not everyone can migrate to SMP 7.

Notification Server 6 includes a feature known as the "Active Directory Connector (ADC)." A simplified explanation of the ADC is that it allows NS6 to connect to a Microsoft Active Directory Domain Controller and import computer and user account information into the NS for use by the various Altiris components. In our scenario the ADC has been used to import Mary Jane Watson's AD account into NS6. When the import of users is completed by ADC, a User Resource Type is created. This can be found by navigating in the NS 6.5 console to View > Resources > Resources > Organizational Structures > YourDomainName > Users. When Altiris Asset & CMDB Solution has been installed, Asset & CMDB references the ADC location for user information and populates the Organizational Type named "User" with the same information. The Asset view of the Mary Jane Watson can be found by navigating in the NS 6.5 console to View > Resources > Resource Management > Resources > Organizational Types > Users. When Altiris Helpdesk 6 (HD6) is installed, because the product uses a separate SQL database, there is a database copy option that copies User information from a subset of the NS6 Asset tables into HD6 _ including this user information. With user account information about Mary Jane Watson stored in 3 separate locations we have the groundwork laid for the bump in the road.

Peter asks Mary Jane Watson to marry him. She accepts. They kiss and she is now Mary Jane Watson Parker. After the honeymoon, she informs the HR department of her modeling agency of the name change, they call the outsourced IT helpdesk and Mary Jane Watson's Active Directory account is updated with her new last name: Parker. The next time ADC runs, a second account is created in NS for Mary Jane Parker. Let me type that again _ a second account is created. The existing account is not updated because of a bug in the ADC. This bug is documented in Altiris KB 43504 available at http://kb.altiris.com. This is the root cause of the bump in the road. The good news is that ADC 7 does not have this problem. The bad news is that you are not yet running ADC 7. However, implementing the workaround documented in KB 43504 will help with this problem. Did you notice I used the word "help" and not "solve" in the last sentence? If you only run NS6 and ADC and Asset then you can stop reading and implement the workaround in KB 43504. However if you are running Helpdesk you might wish to continue reading. The reason the workaround does not solve the problem is related to Helpdesk. Let's examine this in more detail.

Forgive me Marvel Comics, but Mary Jane Parker decided to make a career change with her marriage so she accepted a position on the IT Helpdesk. Being Geek is cool right? Lucky for us, she made this transition prior to the name change in Active Directory. The Altiris Administrator has set Mary Jane Watson's account in HD6 as a Worker and Mary Jane Watson has logged into Helpdesk and opened a few incidents. This is a key point in this scenario because of how HD6 handles Worker accounts. There is also one more configuration detail that must be pointed out. For performance reasons, HD6 BulkProcessing has been disabled. Not to digress, but BulkProcessing is used by HD6 anytime a helpdesk worker or administrator deletes incidents or contact. It is a useful feature and is enabled by default but in our scenario it is turned off.

Back from the honeymoon with Spiderman, Mary Jane Parker sees the yellow sticky note on her monitor letting her know that her AD account has been updated _ she should now login as Mary Jane Parker instead of Mary Jane Watson. Prior to implementing the workaround described in KB 43504, what happens in the background is that the Asset to Helpdesk synchronization process has run. There are now two Contact records in Helpdesk _ one for each of her names. When Mary Jane Parker logs into Helpdesk, instead of gaining access to the worker console (which is linked to Mary Jane Watson), she is prompted by Helpdesk to complete the self-enrollment. Now the bump in the road gets nasty.

Recognizing there was a problem with her helpdesk account, Mary calls over a new coworker, Bob, who is also an Altiris Helpdesk Administrator. Bob looks at the problem, logs back into Helpdesk as himself, and pulls up the Contacts in Helpdesk. He sees there are now two contacts listed _ Mary Jane Watson and Mary Jane Parker. If Mary Jane had not already completed self-enrollment, Bob could at this point delete the Mary Jane Parker account, edit the NT_ID of Mary Jane Watson to match her new AD account and life would have been okay - well sort of. Remember with BulkProcessing turned off, the contact would be marked for deletion in the database (as seen by an x in the status of the contact table), but the delete would not actually happen. However, because self-enrollment had already been completed, there are now two worker accounts associated with Mary Jane, both associated with a worker account. Remember that Helpdesk Contacts that are associated with Worker accounts cannot be deleted.

What if self-enrollment had not been completed? Bob uses the HD6 console to delete the Mary Jane Parker account. Why the new account and not the old? This is because the end goal is to keep the link between her old incidents and her new NT_ID. In this case BulkProcessing is still disabled, so on the backend the contact is flagged for deletion; however the delete is never performed because BulkProcessing is disabled. Bob thinks everything is deleted because when an account is marked for deletion it no longer appears on the page to delete contacts. Thinking things are okay, he tells Mary Jane to login to Helpdesk. She does and she's presented with the self-enrollment screen. In the database, Helpdesk has now allowed a worker to be associated with a contact that is flagged for deletion. Had BulkProcessing been enabled, the contact would have been deleted, and at this point the worker would be orphaned. None of these scenarios leave Mary Jane Parker with a functional helpdesk account.

How can we save the day for Mary Jane Parker?

The first step is to turn back on BulkProcessing. However if it has disabled, it will be important to understand what is going to happen when it is turned back on. Understand that a Helpdesk Administrator told the Helpdesk to perform everything we are about to look at so it should not be a problem when it actually does them _ but just in case it helps to know what is going to happen.

When a job is submitted for BulkProcessing, a new row in the Altiris_Incidents.BatchJob table is created. The comment column gives a brief explanation of what the job was for. After the row is written in the Altiris_Incidents.BatchJob table, a new row is added to the Altiris_Incidents.JobQueue table for each contact or incident that needs to be processed. For example assume Helpdesk needs to delete 10 contacts. There will be one row in the Altiris_Incidents.BatchJob table and 10 rows in the Altiris_Incidents.JobQueue table. There are different status levels for the items that appear in these tables. In the JobQueue a status of "s" means the job completed successfully. There might also be "p" for pending or "f" for failed. In the Altiris_Incidents.BatchJob table "a" means active. To figure out what BulkProcessing will do when it is turned back on, take a look at the Altiris_Incidents.JobQueue table and match up the BatchJob_id to the items listed in the BatchJob table.

To turn on BulkProcessing, edit the Windows Registry on the Helpdesk server by changing HKLM\Software\Altiris\eXpress\Helpdesk Package\DisableBulkProcessing from "true" to "false" and reboot the Helpdesk server. When the server reboots, BulkProcessing will begin. When BulkProcessing is complete, and after the Asset to Helpdesk synchronization runs, you will no longer be able to edit the contact for Mary Jane. You will still have two accounts in Helpdesk and most likely both accounts will be listed in the "List Workers" screen in Helpdesk. At this point to save Mary Jane Parker's account, we have to move into unsupported territory and do direct SQL database updates.

To repeat our end goal, the idea is that Mary Jane Watson's open incidents need to be linked to Mary Jane Parker's NT_ID. We cannot edit the contact directly in the Helpdesk Console due to the previous errors. The link is achieved by editing the Altiris_Incidents.Worker table to set the contact_id to match the new contact. Begin by identifying in the Altiris_Incidents.Contact table what the ID is for the new contact. In the worker table you'll notice that the contact_id is set to the old ID. You'll be changing this to match the new id. So using the new contact ID, run:

Update Altiris_Incidents.worker 
Set contact_id = IDfromContactTable of the new ID
Where id = CorrectIDnumber in the worker table.

At this point, Mary Jane Parker can login to Helpdesk using her new AD Login and she will have access to her older incidents. Now who's your hero Mary Jane?

To prevent this from happening in the future, leave BulkProcessing enabled, and ensure the workaround from KB 43504 is in place on the NS. You might also consider migrating to Symantec Management Platform 7 along with ServiceDesk 7 where this is no longer a problem.