I’ve had this question so many times lately that I’ve just got to write a blog post about it!
This is the scenario…
What happens to the user in the CMDB?
To answer that question we must understand the CMDB delete logic for configuration items. When a CI is “deleted” by a user in the console or even programmatically using something like SMLets (unless you use the –Force switch parameter) the CI is not actually deleted from the database. The ObjectStatus property changes to ‘Pending Delete’. This means that it will no longer show up in the Users view in the Configuration Items workspace because that view is configured to only show items which are ObjectStatus Not Equal to Pending Delete. The user object will still show up in the user picker control on forms and will still show up in an object picker dialog. Any objects which have a relationship to that user will still show that relationship.
Most importantly though it will show up in the Deleted Items view in the Administration workspace. From here the administrator can click the Remove Item task to permanently delete the user from the database. At that point, the user will no longer show up in the object picker dialog or in the user picker control. Any previously existing relationships from other objects to the now deleted user will also be removed from the database. The history of all property value changes and relationship adds/removes will also be deleted from the CMDB. At this point not even the SDK will return this object. It actually still exists in the database but a flag is not set on it so that it is essentially deleted. It will be finally dropped from the database by a nightly grooming routine in the database.
It is important to understand though that this process does not remove the user from the data warehouse. The user object and its relationships to other objects remains in the data warehouse for long term storage and reporting purposes.
Now that we understand the logic for deleting CIs it is easy to understand what the AD connector does. If the run as account that is used for the AD connector has List Object rights on the Deleted Items container in Active Directory, it can detect that the object has been deleted in Active Directory. When it determines this the ObjectStatus property will be set to Pending Delete. From there an administrator can go to the Deleted Items view and permanently delete the user object by clicking ‘Remove Items’.
Hey travis is there a way that you can get all the users from active directory via the connector and then when they have all copied, remove the connector and then remove the flag for pending delete so that they will show up as though they had been manually created?
Hey Travis, thanks for the great post, great info! I did have a question thou, how does the connector handle retiring/rebuilds with the same names? For instance, server "AD01" gets decomissioned and deleted from AD/SCCM, the connectors mark the Computer CI Pending Delete as expected from your post. A week later, the server "AD01" gets rebuilt with a new OS, same name. It appears the Connectors move the object back from the Deleted Items Container back to All Computers. Is that correct? The issue here is it makes it hard to track between iterations of the server (I don't know if I am looking at work done on the old AD01 or the new AD01). Is it possible to mark a Computer CI as retired and force the connectors to create a new CI; this way they will be tracked independently? We currently have to leave old Computer CI's in Deleted Items container "indefinetely" because we need tickets to keep their relationship to the CIs for a long time. What is the best practice for retiring CIs; knowing that a new system very likely may be rebuilt with that name again in the future on new or same hardware? Thanks!
@JR52MAR - I think what I would do in that case is just disable the AD connector instead of deleting it.
The computer class uses the fully qualified domain name (aka Principal Name) of the computer as the computer's identity. If the computer is brought back with the exact same name then we assume it is the same computer. Please see this blog post for more information on the computer class and identity.
Travis, thanks for the info, makes sense. However, I do see some wierd behavior in this scenario. My AD Connectors, changes the AD SID property of my CI every hour, then a minute later, changes it back. It is almost like the connector is confused about which SID is the active one in AD (even though the old one has been deleted). Have you seen this before? I see this for all my CIs that have deleted, decomissioned, and then rebuild later with the same server name. Thx!
I'm wondering, if there are any possibility of recording/monitoring this change in SCSM CMDB:
record which new object(s) has been imported and which removed during connector synchronization?
Thanks in advance !
Does SCCM work in a similar fashion? So far I've noticed that AD and SCOM will set the status to "Pending Delete" but SCCM does not. Is this by design?
I've said it before to in-house developers and I'll say it again here. Uniquely identify domain joined objects (i.e. Security Principals) by their SID..
Granting permissions to the AD "Deleted Objects" container is not a trivial task, as the container is hidden. The current official documentation for SCSM 2012 also does not list this is a permissions requirement, yet it is still required. An alternative
approach, keeping with the documentation, for coding the connector to detect deleted objects would be:
1. Read the required CI's from the SCSM CMDB into an array/collection data-type
2. Read the required objects from AD into an array/collection data-type
3. Compare objects from array (1) and (2) and flag objects which match in both (using SID)
4. Items not flagged in array (1) are marked "Pending Delete" in the CMDB
5. Items not flagged in array (2) are added to the CMDB
There are ways to improve the performance of above by either:
a. Making array (2) a dictionary/hash-table data-type
b. breaking out of the internal loop in (3) when a match is found.