I use cmdbdriver to generate new classes so that the class guids are what I want them to be.
_____ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Ben Chernys Sent: 28 January 2009 21:46 To: arslist@ARSLIST.ORG Subject: FW: ITSM Issue with Sandbox Enablement That is correct. The Class Manager console was used. cmdb2asset is no longer used. The functionality is done with other processes now. But yes, all done with OOTB facilities. The IDs were auto-assigned. (bad!) and (worse) so where the class guids! My OOTB VM "seems" to work as well. BUT, I have not made any new classes there and done a real experiment. Cheers Ben _____ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lyle Taylor Sent: January 28, 2009 10:32 PM To: arslist@ARSLIST.ORG Subject: Re: ITSM Issue with Sandbox Enablement Ben, You said something that I would like clarification on: any attributes (of our hand-constructed classes using default Admin defined field ids) (italics added) Just to be certain I’m understanding things correctly, did you create these classes using the CMDB console using the functionality there for creating classes and adding attributes to them, or did you do any of this work in the Admin tool? While I haven’t added any new classes, I have added a fair number of attributes to existing classes (although we used IDs specified from a specific range of IDs that we were using, rather than letting the system auto-assign IDs), and we never had a problem with the system not bringing these attributes into the sandbox, which is something that I think should be someone analogous to what you’re trying to do in the end. While I’m not an expert on what happens when you use a sample schema, I would expect that the fact that “by ID” is selected, it should bring across all fields with matching IDs regardless of whether or not they’re in the sample schema – which it seem would have to be the case or the majority of the OOB classes would have this same issue. Well, I guess there’s no useful information in the paragraph above. I guess I really just want to confirm that the classes were all created using the CMDB console exclusively, and that any AST forms used to work with those classes were created using the CMDB2Asset utility so that the IDs of the fields on the asset forms and the CMDB forms all match up, regardless of whether they’re OOB or custom. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Ben Chernys Sent: Wednesday, January 28, 2009 1:57 PM To: arslist@ARSLIST.ORG Subject: Re: ITSM Issue with Sandbox Enablement ** Thanks Guys, I agree with you. I noticed the part that doesn't make sense but believe it or not I have a reasonable reason for using it. As for auditing, we've had our share of issues with it but are (over) using it. I disabled the delete activity in the Sandbox reconciliation job so that when a CI in Production (Gold?) is touched by a person, I can have our standard reconciliation job basically use the equal Sandbox CI at a higher precedence and then more or less cancel the normal discovered CI in the recon job. When that normal discovered CI has "caught up" to the human modified CI, in a set of configured fields I might add, then the Sandbox CI is deleted and the CI is no longer human modified and participates in reconciliation updates as normal. I also cannot add an attribute indicating the human modification state to BaseElement. The Sandbox indeed makes no sense whatsoever as implemented with the OOTB workflow. The Updated CI is pushed (supposedly) to the Sandbox, and then immediately reconciled to production AND deleted from Sandbox. Also note the comments about the NULL Option in the OOTB Job. This may be there to cover the issue I encountered below. We now have a ticket with BMC but alas, I am going to have to do something to make it work sooner than I expect a response or a fix. Perhaps the Overlay feature works better? Cheers Ben _____ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: January 28, 2009 9:15 PM To: arslist@ARSLIST.ORG Subject: Re: ITSM Issue with Sandbox Enablement ** I totally agree with Lyle. It just does not make sense to have a sandbox that will be immediately reconciled to production dataset. Besides restricting the updates via permissions or field properties, I would add that enabling auditing on the fields that can be updated is a good complement, from a control/audit perspective. So with access control and auditing, you really don't need a sandbox, and you are going to gain a lot in terms of reducing complexity, maintenance, etc. -Guillaume __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
