[Today's post is provided by Carol Bailey]
Torsten Meringer (MVP) brought to my attention an interesting scenario that he ran into when his duplicated configuration baseline disappeared from his reports, and his original configuration baseline seemed to come back from the dead after deleting it.
Torsten had created the original configuration data on a test network, exported it and imported it to his main Configuration Manager hierarchy. The imported configuration items and baselines imported fine, and they were locked, because they weren't created at the site. He wanted the ability to change them if necessary, so he did the following:
This was exactly the right thing to do so that he could then edit the configuration items and configuration baseline if required. However, when he looked at his desired configuration management reports, he couldn't find his newly duplicated configuration baseline. But almost by accident, he did find a report for what looked like his original configuration baseline - which he thought he had deleted. So what was going on?
I did some testing of my own and discovered that the duplicated configuration baseline reverts to the original baseline name. Although you are more likely to run into this scenario when using imported configuration data that you then duplicate for editing, it actually has nothing to do with the original configuration baseline being imported - the same set of circumstances will happen with any duplicated configuration baseline. But to help explain what happened, let's walk through what happens if you import, duplicate, and then edit a configuration baseline:
Without further intervention, the duplicated configuration baseline will continue to use the reverted name. For example: "Original Baseline" will be displayed in the Configurations tab on the client when it is downloaded for compliance evaluation, and the reports will display results for "Original Baseline" instead of "New Baseline".
Thanks to Richard Xia's investigation from the product group, he pointed out a key factor that I missed at step 2 above - probably because I was so focused on editing my configuration baseline for step 3. I should have paid more attention to the Properties pane beneath the results pane. The properties for New Baseline actually display the old name of Original Baseline, as shown in the following picture:
When I saw this mismatch in the console, that's when I remembered .... I had already documented this as a known troubleshooting issue - in Problems Editing Configuration Data in the Configuration Manager Console :
Duplicated Configuration Items Display Original Name
When you create a duplicate configuration item, it might display the original name rather than the new name in the Configuration Manager console in the following circumstances:
After creating a duplicate configuration item, edit it and change the duplicate configuration item display name to the required value. The duplicate configuration item name will then display correctly in all places.
I think what threw me off track, was that the problem we investigated was for a configuration baseline, rather than a configuration item, and I didn't associate it immediately with a display issue. In Torsten's case, he didn't notice the console display disparity but discovered it because he couldn't find the configuration baseline in the reports. This was when I realized this would be good to blog, because you might come across this in different ways - as missing report data, or as missing compliance results from clients, or as a console display problem.
I'll update the troubleshooting entry in the documentation so that it refers to configuration baselines as well as configuration items, and make it clearer that it's not just a display problem.
Fortunately, once you realize what's happening, it's a really easy fix.
Solution to the name reverting behavior:
After the initial duplication and naming of the configuration baseline, re-type your choice of name when you edit it (step 3 above). This time it will "stick".
This posting is provided "AS IS" with no warranties, and confers no rights.
In case you missed them, the following posts were published on the System Center Configuration Manager
237 Microsoft Team blogs searched, 109 blogs have new articles in the past 7 days. 245 new articles found