Q&A Session for Connect with Remedy - CMDB Best Practices Coffee Break

Transcription

1 Q&A Session for Connect with Remedy - CMDB Best Practices Coffee Break Date: Thursday, March 05, 2015 Q: When going to Asset Management Console and making an update on there, does that go to a sandbox or does it update the BMC.ASSET record? A: The Asset Management product has a configuration option for whether you are using a Sandbox or not. The best practice recommendation is to ALWAYS use the Sandbox mode. If using Sandbox mode, reads for Asset Management are done from the production dataset (BMC.ASSET) but writes are done to the Asset Management Sandbox which is then reconciled into the production dataset. In the current release of Asset Management, the sandbox is a permanent dataset and there is workflow to immediately trigger a reconciliation of any change to the sandbox into the production dataset (best and where we are going in the future is to use continuous reconciliation on this dataset). In releases before 8.0, this was a dataset that reconciled and then was flushed. This is not good practice and we recommend that you fix this behavior by removing the purge step from the job in these earlier releases. If not in Sandbox mode, reads and writes are directly to BMC.ASSET. This is not recommended as you lose the ability to track which updates came from where and changes made manually tend to get overwritten by automated feeds at a later point. Q: Does Lifecycle and CMDB auditing tag the username of the person who made a change in a Person's Sandbox that then gets reconciled to Production dataset? Q: How do automated discovery approach and thoughtful "only touch CIs after change request" fit together? A:The CMDB should hold WHAT IS. That is, the CMDB should reflect the reality of your environment to contain what is really present in the environment. Anything else will cause you to fail because if the CMDB does not reflect reality, it cannot be used for root cause analysis and decisions cannot be based on the data it contains. So automated discovery is a critical requirement and it brings in what it really finds. Now, should you always have change requests for changes to your environment? Of course. But, you need to know about everything even if there were no change requests. Now, about change updating the CMDB. Don t do it. Change changes the environment, it does not update the CMDB. Discovery updates the CMDB. You can have the last task of a change request trigger discovery to happen right now on a device you are changing (actually is a good practice) to make sure that the change is picked up quickly. But, it should be discovery that updates the CMDB as it reflects WHAT IS rather than what you hope is. (yes, of course if the discovery source of something is manual discovery so a person is typing it in, then you will have someone updating the CMDB that seems to be part of the change. But, you should still think about it as change request making the change to the environment and then discovery -- a person in this case -- is updating the CMDB with new data it has found. Q: On the topic of "Sandbox" for updates from the Asset Mgmt module, there has been some fluctuation on what is the OOTB behavior. What is current best practice, and will that change in the future. A: The best practice is to have all changes from Asset management console go through sandbox. Yes, There are few product fixes have been made to improve the customer experience in this area, but that doesn't change the best practice. Prior to 8.0, the sandbox reconciled into production and then purged data from itself. This is a bad practice. It was corrected with the 8.0 and later releases. As more learning about how to succeed with a CMDB has been made, practices have been improved and that has led to some changes in the Asset management product.

2 Q: We create directly to the Production data set so a Change Record can be logged against the CI immediately after it is created. The recon turnaround is not able to run on a frequent enough basis. What is the quickest turnaround for the recon engine? A: You want to look at continuous reconciliation for this type of need. This reconciliation model picks up changes and runs at near real time pace. There may still be a small delay between the entry of the data and it showing in production, but it is within minutes. Alternatively, you can have process that is told to run (say by workflow) as soon as a change is made. This can get a bit confusing in logs as every change triggers the job and so you can get dozens of starts in a small window and if a job is running it cancels the new job so you get lots of cancelled job notices even though there are no issues and no problems. Q: We've just begin researching the Multi-tenancy options regarding ADDM and CMDB. Can you give a brief overview of this process if I'm wanting to implement this using multiple ADDM scanners/consolidators and 1 CMDB? Q: What is the best practices on checking for Normalization or Recon errors. I know right now you have to go directly to the server backend and look in the log directory. Which these logs don't give the best info. Is there better practices for this process? Q: If I load my it hardware assets via spreadsheets in to Asset Mgmt I would also create a dataset for the hardware source (the spreadsheet). the data is written into the CMDB. then if I no longer want the spreadsheets and delete them b/c I won't use them any longer that means that I have an orphaned data set? A: This discussion is really about wanting to eliminate a data source. You would still load it into a discovery dataset and then reconcile into production. However, if you wanted to then eliminate this source, you just need to make sure that all the data it covers has a home elsewhere so that you are not leaving an orphaned piece of data in production with no source. Then, you can remove this dataset as you don t have this source any more. This question was discussed verbally. Q: Is there much of an impact to each recon identification rule? For example, if a rule can speed identification once a year, would it be best to add the rule only when needed, or is impact so trivial that we might as well leave it always on? A: In general, the impact of a single rule running is not significant (unless something is doing a poorly structured query of the system and the SQL search takes a long time -- and if that is the case, the problem is much worse than the premise of this question). I would suggest paying the slight overhead for the extra rule rather than trying to add when needed. Identity is such a critical concept and critical part of the CMDB that anything that messes with it or gets it wrong (even by accident) is a problem. Rather than hoping this rule applies only sometimes -- with no exceptions -- just leave the rules on. Data accuracy and cleanliness is the most important thing. Q: what would you suggest as a strategy to manage hi level asset CI/CMDB info that will be one-time uploaded via spreadsheets? reconciliation will occur down the road, but not sure how far down the road. what do I need to be aware of to prevent data errors A: Using the best practice recommendation that every data source loads into a discovery dataset is the right strategy. Then, you can run normalization or not on the dataset. You can do it now or later. You can have special rules unique to this data if appropriate. Then, you can run reconciliation or not on the dataset. You can do it now or later. You can have whatever rules you want for identity or merge.

3 Then, if you decide to obsolete the source, you follow the process for the question above about obsoleting and removing a discovery dataset. You need to make sure the data is owned by some source so you don t have orphaned data in the target. Q: What is the recommended approach when a discovery dataset does actually have accurate information concerning an AST:Attribute-held attribute? A: The CMDB is for configuration data. If your source also has Asset lifecycle data that you want to load: Best -- Load the configuration data to the CMDB and the lifecycle data to AST:Attributes. This means two load processes (both can be done using AI) and having an instance ID or reconciliation ID to link the data together. OK -- use the interface forms that Asset management supplies to load the data into. This merges the configuration and lifecycle data onto the same form and the data is sent to the appropriate location (CMDB or AST:Attributes) by workflow. Workaround -- Add the lifecycle attributes into the CMDB and have workflow that pushes the lifecycle data to AST:Attributes. This way you can load the data to the CMBD discovery dataset and have it push the lifecycle to AST:Attributes. This is not a long term answer as it does not solve the problem with a single load that you may have been doing pre 8.0 without having to change the loader. Q: How do you explain to users that some fields show up immediately (AST:Attributes; such as Status, etc), when other fields process per schedule through the Reconciliation process; and how should they know which fields do what? A: This question was discussed verbally Q: Hi! what exactly are delta and response in reconciliation? A: In case of reconciliation, there is no concept of delta and response. These are features from Atrium Integrator. With Delta feature, only changed/new records will be loaded in CMDB dataset. With response feature, the source record can be updated as an acknowledgement of specific record been loaded in target side. Q: Also if I want to add certain fields to existing class how to do so? does it involve any workflow changes too?? A: You can use Atrium Console -> Class Manager to add attribute in CMDB class. This will allow you to add or modify existing attributes. Make sure you do not add attributes casually. Have a clear requirement and clear definition of what the characteristics of the attribute are. No workflow needs to be changed when you modify a class. Q: As to the MAD/SCCM question being asked, is there a date on the CI indicating when the MAD flag was set? A: We don't have date recorded especially for MarkAsDeleted attribute, however see if you can use ModifiedDate for your purpose assuming this Ci is not being updated after its soft-deleted. This question was discussed verbally Q: Is there any Common Data Model documentation available for 8.1 SP2? Similar to what is in , is there a single document. It is our understanding that some classes from to 8.1 have been consolidated and there are plans for more consolidation A: There have been several attributes and a few classes added in the 8.x releases, but nothing major. There has not been any significant restructuring of the CDM.

4 Q: When you delete a CI (Mark as Deleted), don't you lose the relationships to Incidents and Changes for that CI once it is deleted? A: There is a misconception about relationship between CIs and with incident. When CI gets MarkAsDeleted it only will mark as deleted (not actually delete) relationship between this and other CIs. There is no effect on the links to Incident or Change which are not CMDB relationships but links tied to the Reconciliation ID of the CI (and that CI is still there, just marked as deleted) so no problem. Q: What are the best practices with regards to preventing orphan child CI records from existing in the CMDB if the parent CI gets set to MarkedAsDeleted and gets purged. That leaves the child CIs still in the CMDB. Q: If that CI is not purged and "seen" again from ADDM for instance, are the relationships automatically rebuilt (I am referring to the relationships in the CMDB, not ITSM)? Q: For the relationship class such as hosted system component, cascade delete makes sense for CIs such as Memory, Processor, Product, etc. however it doesn't really work for CIs such as Monitor, UPS and some Card CIs for instance. A: The cascade delete feature should be used with caution as it deletes CIs physically. Make sure cascade feature will be applied only on soft-deleted (i.e. MarkAsDeleted=Yes) parent CIs. This question was discussed verbally Q: Is there a best practice document for one time load of CI's for asset management? Once loaded we will be managing the asset lifecycle in Remedy and will obsolete the initial load file. A: This question has been asked earlier and the answer is there. Q: I think having this as a quarterly or some kind of discussion. Including maybe something that is coming in the future that is eluded to during this call. A:Having more of this type of Q&A session seems to be popular. The team is working on a plan for logistics and frequency. Q: In version 8.1 CMDB, using the normalization custom features significantly slowed down the time to complete a normalization job in our environment. The custom rule was just to set an attribute to UPPER. In CMDB has the norm engine been tuned better A: All the engines are constantly under review for performance tuning and improvement. Just changing a value to UPPER should not be a significant delay. I cannot comment on the specific case without further investigation. The biggest problem with slow normalization comes from reloading data that is not changed. Make sure you don t reload unchanged data so the normalization engine has to reprocess things that have already been completed. Q: OOTB if a CI exists in two datasets, such as a discovery dataset and BMC.ASSET, if a user goes to the AST:CompSys form and sets the CI to Delete, after saving the record goes back to Deployed. I know the CIs share the AST:Attribute record, but users are confused. Is there a setting somewhere to inform the user on why the status went back to Delete? A:If the AST:Attribute record is being updated due to a change of data in a discovery dataset, that is a bug. Only data changing in the production dataset should have any effect on an AST:Attribute record. The change in discovery may not be carried forward due to reconciliation precedence so should not change the lifecycle. If the change happened only on production dataset changes, there would not be confusion.

5 If you are seeing changes propagated through the system from discovery datasets, that should be reported to the support team as a bug. Q: my questions relate to a very immature environment. not all of the ITSM apps are being used today. of the ones being used they have some clean-up that need to be completed (especially on foundation data). Q: we really need to know how to keep our license counts correct by removing the relationship between software and CI records when SCCM no longer sees it. A:Just use the MarkAsDeleted flag. The items marked this way should not show up in a query for checking license counts. Q: Is it possible to hide some of the statuses that are available in the CI records? We don t want to use some of them and I am trying to figure out a way to stop them from using the ones we don t want used. A:You can always change the names of the statuses or you could put workflow in place that error if any status not allowed is selected. But that is after the fact. The status field can be edited as it is just an attribute like any other. But, the field is a selection field and it is important that the choices retain the same ID within the field as they have always had to avoid issues with related tools,. Upgrades do not reload the CDM or any definition that was from a previous version.