Integrating with CTM:People vs. BMC_People
Good afternoon, As I'm upgrading from ITSM 7.0.3 to 7.6.4, one thing I'd like to do is continue to have my People data updated from Active Directory. For 7.0.3, I built an integration where some escalations run and dump the People data into a staging form that then goes into CTM:People. However, now that I have the BMC_People class in the CMDB, I'm considering if it would be better to put the data there instead, and use that to update the People data. I'd like to know what your thoughts are on this. It's obviously easier for me to take my pre-existing code and migrate it to my 7.6.4 servers, but if there is an advantage to loading it into BMC_People first, I'm open to going that route instead. Thanks, Shawn Pierson Remedy Developer | Southern Union Private and confidential as detailed here: http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access the link, please e-mail sender. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
Re: Integrating with CTM:People vs. BMC_People
You still need to use CTM:People the BMC_Person in the CMDB will have an entry created when toy do the People save. User entries are created if the People record has a login ID. -Original Message- From: Pierson, Shawn To: arslist Sent: Tue, Aug 2, 2011 2:07 pm Subject: Integrating with CTM:People vs. BMC_People ** Good afternoon, As I’m upgrading from ITSM 7.0.3 to 7.6.4, one thing I’d like to do is continue to have my People data updated from Active Directory. For 7.0.3, I built an integration where some escalations run and dump the People data into a staging form that then goes into CTM:People. However, now that I have the BMC_People class in the CMDB, I’m considering if it would be better to put the data there instead, and use that to update the People data. I’d like to know what your thoughts are on this. It’s obviously easier for me to take my pre-existing code and migrate it to my 7.6.4 servers, but if there is an advantage to loading it into BMC_People first, I’m open to going that route instead. Thanks, Shawn Pierson Remedy Developer | Southern Union Private and confidential as detailed here. If you cannot access hyperlink, please e-mail sender. _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
Re: Integrating with CTM:People vs. BMC_People
The BMC_Person is created automatically when a CTM:People record is created and not the reverse. In any event, the BMC_Person class is more or less a dummy containing very few attributes (including critically, the CTM:Person Request ID and Instance ID) and is there so that (Dependency) relationships may be created between people and CIs (rather than "only" associations (in AST:AssetPeople). So, if your integration creates CTM:People records, the BMC_Person records will be created - albeit in the SANDBOX dataset. Ensure that you have a proper recon job configured to move it to the BMC.ASSET Dataset. The BMC_Person will most likely be expanded and really used in a (very) future release. Cheers Ben Chernys Senior Software Architect Software Tool House Inc. Canada / Deutschland / Germany Mobile: +49 171 380 2329GMT + 1 + [ DST ] Email:<mailto:ben.cher...@softwaretoolhouse.com> Ben.Chernys _AT_ softwaretoolhouse.com Web: <http://www.softwaretoolhouse.com> www.softwaretoolhouse.com Check out Software Tool House's free Diary Editor. Meta-Update, our premium ARS Data tool, lets you automate your imports, migrations, in no time at all, without programming, without staging forms, without merge workflow. <http://www.softwaretoolhouse.com/> http://www.softwaretoolhouse.com/ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pierson, Shawn Sent: August-02-11 12:07 To: arslist@ARSLIST.ORG Subject: Integrating with CTM:People vs. BMC_People ** Good afternoon, As I'm upgrading from ITSM 7.0.3 to 7.6.4, one thing I'd like to do is continue to have my People data updated from Active Directory. For 7.0.3, I built an integration where some escalations run and dump the People data into a staging form that then goes into CTM:People. However, now that I have the BMC_People class in the CMDB, I'm considering if it would be better to put the data there instead, and use that to update the People data. I'd like to know what your thoughts are on this. It's obviously easier for me to take my pre-existing code and migrate it to my 7.6.4 servers, but if there is an advantage to loading it into BMC_People first, I'm open to going that route instead. Thanks, Shawn Pierson Remedy Developer | Southern Union Private and confidential as detailed here <http://www.sug.com/disclaimers/default.htm#Mail> . If you cannot access hyperlink, please e-mail sender. _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
Re: Integrating with CTM:People vs. BMC_People
An OOB filter triggers off of CTM:People that creates/ updates BMC_PERSON just push to CTM:People and set 'z1d Action' to "PEOPLESYNC_CREATE" or "PEOPLESYNC_UPDATE". You will be able to see a new record create in BMC.Sandbox and the reconcile into your CMDB. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pierson, Shawn Sent: Tuesday, August 02, 2011 1:07 PM To: arslist@ARSLIST.ORG Subject: Integrating with CTM:People vs. BMC_People ** Good afternoon, As I'm upgrading from ITSM 7.0.3 to 7.6.4, one thing I'd like to do is continue to have my People data updated from Active Directory. For 7.0.3, I built an integration where some escalations run and dump the People data into a staging form that then goes into CTM:People. However, now that I have the BMC_People class in the CMDB, I'm considering if it would be better to put the data there instead, and use that to update the People data. I'd like to know what your thoughts are on this. It's obviously easier for me to take my pre-existing code and migrate it to my 7.6.4 servers, but if there is an advantage to loading it into BMC_People first, I'm open to going that route instead. Thanks, Shawn Pierson Remedy Developer | Southern Union Private and confidential as detailed here <http://www.sug.com/disclaimers/default.htm#Mail> . If you cannot access hyperlink, please e-mail sender. _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
Re: Integrating with CTM:People vs. BMC_People
Does this filter pick or choose which CTM:People entries to populate into BMC_People? I am about to re-develop my integration that takes LDAP data from a SQL Server and shoves it into CTM:People, User, and CTM:PeoplePermissionGroups and maintains those records with a live feed. There are currently about 266,400 people and user records, of which 336 are support staff (that generates about 341,000 CTM:PPG recs). When we upgraded to 7.6.04.01 we saw 475 records created in the BMC.CORE.BMC_Person table; three more have "appeared" since then. We have made no effort to deal with these, having no experience with the CMDB or reconciliation. After the upgrade we turned off all of the integration filters and AIE jobs, although RRR|Chive updates the individual tables from production nightly. Personally, I can only see adding the IT staff initially, but it will probably be easiest to filter to the active faculty/staff records (14,170 recs including student employees - they have a custom role flag in CTM:People that is set by the integration). Has anyone already tackled this, and able to shed some light on the process?? Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Tommy Morris Sent: Tuesday, August 02, 2011 1:31 PM To: arslist@ARSLIST.ORG Subject: Re: Integrating with CTM:People vs. BMC_People ** An OOB filter triggers off of CTM:People that creates/ updates BMC_PERSON just push to CTM:People and set 'z1d Action' to "PEOPLESYNC_CREATE" or "PEOPLESYNC_UPDATE". You will be able to see a new record create in BMC.Sandbox and the reconcile into your CMDB. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pierson, Shawn Sent: Tuesday, August 02, 2011 1:07 PM To: arslist@ARSLIST.ORG Subject: Integrating with CTM:People vs. BMC_People ** Good afternoon, As I'm upgrading from ITSM 7.0.3 to 7.6.4, one thing I'd like to do is continue to have my People data updated from Active Directory. For 7.0.3, I built an integration where some escalations run and dump the People data into a staging form that then goes into CTM:People. However, now that I have the BMC_People class in the CMDB, I'm considering if it would be better to put the data there instead, and use that to update the People data. I'd like to know what your thoughts are on this. It's obviously easier for me to take my pre-existing code and migrate it to my 7.6.4 servers, but if there is an advantage to loading it into BMC_People first, I'm open to going that route instead. Thanks, Shawn Pierson Remedy Developer | Southern Union Private and confidential as detailed here<http://www.sug.com/disclaimers/default.htm#Mail>. If you cannot access hyperlink, please e-mail sender. _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
Re: Integrating with CTM:People vs. BMC_People
This isn't based on anything but educated guesses, so with that in mind let me see if I have the structure down: In pre-7.6 versions, relationships between People and CIs were dealt with by querying the CTM:People form. That was ok, but a case can be made for managing specific people (not necessarily all) in the CMDB. So the 7.6 way we're talking about now is at least a transitional shift away from the standard people forms toward using the CMDB BMC_People form for setting relationships between CIs. That makes a cleaner relational model as well as a more flexible one. It also has the benefit of allowing customers who use a CMDB apart from ITSM the ability to easily do so without giving up the ability to track people/CI relationships. Seems a sound strategy to me. Thoughts? Rick On Tue, Aug 2, 2011 at 12:38 PM, strauss wrote: > ** > > Does this filter pick or choose which CTM:People entries to populate into > BMC_People? > > ** ** > > I am about to re-develop my integration that takes LDAP data from a SQL > Server and shoves it into CTM:People, User, and CTM:PeoplePermissionGroups > and maintains those records with a live feed. There are currently about > 266,400 people and user records, of which 336 are support staff (that > generates about 341,000 CTM:PPG recs). When we upgraded to 7.6.04.01 we saw > 475 records created in the BMC.CORE.BMC_Person table; three more have > “appeared” since then. We have made no effort to deal with these, having no > experience with the CMDB or reconciliation. After the upgrade we turned off > all of the integration filters and AIE jobs, although RRR|Chive updates the > individual tables from production nightly. > > ** ** > > Personally, I can only see adding the IT staff initially, but it will > probably be easiest to filter to the active faculty/staff records (14,170 > recs including student employees – they have a custom role flag in > CTM:People that is set by the integration). Has anyone already tackled > this, and able to shed some light on the process?? > > ** ** > > Christopher Strauss, Ph.D. > Call Tracking Administration Manager > University of North Texas Computing & IT Center > http://itsm.unt.edu/ > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Tommy Morris > *Sent:* Tuesday, August 02, 2011 1:31 PM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Integrating with CTM:People vs. BMC_People > > ** ** > > ** > > An OOB filter triggers off of CTM:People that creates/ updates BMC_PERSON > just push to CTM:People and set ‘z1d Action’ to “PEOPLESYNC_CREATE” or > “PEOPLESYNC_UPDATE”. You will be able to see a new record create in > BMC.Sandbox and the reconcile into your CMDB. > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Pierson, Shawn > *Sent:* Tuesday, August 02, 2011 1:07 PM > *To:* arslist@ARSLIST.ORG > *Subject:* Integrating with CTM:People vs. BMC_People > > ** ** > > ** > > Good afternoon, > > ** ** > > As I’m upgrading from ITSM 7.0.3 to 7.6.4, one thing I’d like to do is > continue to have my People data updated from Active Directory. For 7.0.3, I > built an integration where some escalations run and dump the People data > into a staging form that then goes into CTM:People. However, now that I > have the BMC_People class in the CMDB, I’m considering if it would be better > to put the data there instead, and use that to update the People data. > > ** ** > > I’d like to know what your thoughts are on this. It’s obviously easier for > me to take my pre-existing code and migrate it to my 7.6.4 servers, but if > there is an advantage to loading it into BMC_People first, I’m open to going > that route instead. > > ** ** > > Thanks, > > ** ** > > *Shawn Pierson * > > Remedy Developer | Southern Union > > Private and confidential as detailed > here<http://www.sug.com/disclaimers/default.htm#Mail>. > If you cannot access hyperlink, please e-mail sender. > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
Re: Integrating with CTM:People vs. BMC_People
The record created in BMC_People is very basic and keys off the login id. This could be beneficial for integrations. You could tie multiple people source systems into the CMDB, reconcile the information, and then push the info into CTM:People. This could provide you a way of having virtually unlimited pointers into unlimited systems for people data. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Tuesday, August 02, 2011 3:53 PM To: arslist@ARSLIST.ORG Subject: Re: Integrating with CTM:People vs. BMC_People ** This isn't based on anything but educated guesses, so with that in mind let me see if I have the structure down: In pre-7.6 versions, relationships between People and CIs were dealt with by querying the CTM:People form. That was ok, but a case can be made for managing specific people (not necessarily all) in the CMDB. So the 7.6 way we're talking about now is at least a transitional shift away from the standard people forms toward using the CMDB BMC_People form for setting relationships between CIs. That makes a cleaner relational model as well as a more flexible one. It also has the benefit of allowing customers who use a CMDB apart from ITSM the ability to easily do so without giving up the ability to track people/CI relationships. Seems a sound strategy to me. Thoughts? Rick On Tue, Aug 2, 2011 at 12:38 PM, strauss wrote: ** Does this filter pick or choose which CTM:People entries to populate into BMC_People? I am about to re-develop my integration that takes LDAP data from a SQL Server and shoves it into CTM:People, User, and CTM:PeoplePermissionGroups and maintains those records with a live feed. There are currently about 266,400 people and user records, of which 336 are support staff (that generates about 341,000 CTM:PPG recs). When we upgraded to 7.6.04.01 we saw 475 records created in the BMC.CORE.BMC_Person table; three more have "appeared" since then. We have made no effort to deal with these, having no experience with the CMDB or reconciliation. After the upgrade we turned off all of the integration filters and AIE jobs, although RRR|Chive updates the individual tables from production nightly. Personally, I can only see adding the IT staff initially, but it will probably be easiest to filter to the active faculty/staff records (14,170 recs including student employees - they have a custom role flag in CTM:People that is set by the integration). Has anyone already tackled this, and able to shed some light on the process?? Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Tommy Morris Sent: Tuesday, August 02, 2011 1:31 PM To: arslist@ARSLIST.ORG Subject: Re: Integrating with CTM:People vs. BMC_People ** An OOB filter triggers off of CTM:People that creates/ updates BMC_PERSON just push to CTM:People and set 'z1d Action' to "PEOPLESYNC_CREATE" or "PEOPLESYNC_UPDATE". You will be able to see a new record create in BMC.Sandbox and the reconcile into your CMDB. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pierson, Shawn Sent: Tuesday, August 02, 2011 1:07 PM To: arslist@ARSLIST.ORG Subject: Integrating with CTM:People vs. BMC_People ** Good afternoon, As I'm upgrading from ITSM 7.0.3 to 7.6.4, one thing I'd like to do is continue to have my People data updated from Active Directory. For 7.0.3, I built an integration where some escalations run and dump the People data into a staging form that then goes into CTM:People. However, now that I have the BMC_People class in the CMDB, I'm considering if it would be better to put the data there instead, and use that to update the People data. I'd like to know what your thoughts are on this. It's obviously easier for me to take my pre-existing code and migrate it to my 7.6.4 servers, but if there is an advantage to loading it into BMC_People first, I'm open to going that route instead. Thanks, Shawn Pierson Remedy Developer | Southern Union Private and confidential as detailed here <http://www.sug.com/disclaimers/default.htm#Mail> . If you cannot access hyperlink, please e-mail sender. _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
Re: Integrating with CTM:People vs. BMC_People
We are on ITSM 7.6 patch 1 so my answers on based on that. I personally have found the BMC_Person class rather useless and a waste of time to maintain. The reason is that most of the ITSM workflow fires on the AST:AssetPeople relationships. In addition the related CIs on the CTM:People form will not show up when looking at the people record unless you go through AST:AssetPeople. I heard rumors though that in later versions of remedy that there was a design to merge BMC_Person and CTM:People into one table. Thanks, Sean From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Tuesday, August 02, 2011 3:53 PM To: arslist@ARSLIST.ORG Subject: Re: Integrating with CTM:People vs. BMC_People ** This isn't based on anything but educated guesses, so with that in mind let me see if I have the structure down: In pre-7.6 versions, relationships between People and CIs were dealt with by querying the CTM:People form. That was ok, but a case can be made for managing specific people (not necessarily all) in the CMDB. So the 7.6 way we're talking about now is at least a transitional shift away from the standard people forms toward using the CMDB BMC_People form for setting relationships between CIs. That makes a cleaner relational model as well as a more flexible one. It also has the benefit of allowing customers who use a CMDB apart from ITSM the ability to easily do so without giving up the ability to track people/CI relationships. Seems a sound strategy to me. Thoughts? Rick On Tue, Aug 2, 2011 at 12:38 PM, strauss mailto:stra...@unt.edu>> wrote: ** Does this filter pick or choose which CTM:People entries to populate into BMC_People? I am about to re-develop my integration that takes LDAP data from a SQL Server and shoves it into CTM:People, User, and CTM:PeoplePermissionGroups and maintains those records with a live feed. There are currently about 266,400 people and user records, of which 336 are support staff (that generates about 341,000 CTM:PPG recs). When we upgraded to 7.6.04.01 we saw 475 records created in the BMC.CORE.BMC_Person table; three more have "appeared" since then. We have made no effort to deal with these, having no experience with the CMDB or reconciliation. After the upgrade we turned off all of the integration filters and AIE jobs, although RRR|Chive updates the individual tables from production nightly. Personally, I can only see adding the IT staff initially, but it will probably be easiest to filter to the active faculty/staff records (14,170 recs including student employees - they have a custom role flag in CTM:People that is set by the integration). Has anyone already tackled this, and able to shed some light on the process?? Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Tommy Morris Sent: Tuesday, August 02, 2011 1:31 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Integrating with CTM:People vs. BMC_People ** An OOB filter triggers off of CTM:People that creates/ updates BMC_PERSON just push to CTM:People and set 'z1d Action' to "PEOPLESYNC_CREATE" or "PEOPLESYNC_UPDATE". You will be able to see a new record create in BMC.Sandbox and the reconcile into your CMDB. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Pierson, Shawn Sent: Tuesday, August 02, 2011 1:07 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Integrating with CTM:People vs. BMC_People ** Good afternoon, As I'm upgrading from ITSM 7.0.3 to 7.6.4, one thing I'd like to do is continue to have my People data updated from Active Directory. For 7.0.3, I built an integration where some escalations run and dump the People data into a staging form that then goes into CTM:People. However, now that I have the BMC_People class in the CMDB, I'm considering if it would be better to put the data there instead, and use that to update the People data. I'd like to know what your thoughts are on this. It's obviously easier for me to take my pre-existing code and migrate it to my 7.6.4 servers, but if there is an advantage to loading it into BMC_People first, I'm open to going that route instead. Thanks, Shawn Pierson Remedy Developer | Southern Union Private and confidential as detailed here<http://www.sug.com/disclaimers/default.htm#Mail>. If you cannot access hyperlink, please e-mail sender. _attend WWRUG11 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the A
Re: Integrating with CTM:People vs. BMC_People
We load people from a Peoplesoft->LDAP->SQL Server source with AIE, pushing to a custom form, then to CTM:People, User, and CTM:PeoplePermissionGroups as well as User Preferences. To get that working again on the 7.6.04.01 system (developed/used originally on ITSM 7.0) required that I overlay and disable all 39 of the filters that load and maintain BMC_Person. We will revisit them when we can control who they are injecting - less than 10,000 records for active employees versus 266,000. OOTB, it wants to try to load them all. In this version, you may be correct that what we want in Asset to User relationships can all be done without populating BMC_Person; it's on my "to-do list" to find out. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Garrison, Sean (Norcross) Sent: Wednesday, August 10, 2011 3:27 PM To: arslist@ARSLIST.ORG Subject: Re: Integrating with CTM:People vs. BMC_People ** We are on ITSM 7.6 patch 1 so my answers on based on that. I personally have found the BMC_Person class rather useless and a waste of time to maintain. The reason is that most of the ITSM workflow fires on the AST:AssetPeople relationships. In addition the related CIs on the CTM:People form will not show up when looking at the people record unless you go through AST:AssetPeople. I heard rumors though that in later versions of remedy that there was a design to merge BMC_Person and CTM:People into one table. Thanks, Sean From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Tuesday, August 02, 2011 3:53 PM To: arslist@ARSLIST.ORG Subject: Re: Integrating with CTM:People vs. BMC_People ** This isn't based on anything but educated guesses, so with that in mind let me see if I have the structure down: In pre-7.6 versions, relationships between People and CIs were dealt with by querying the CTM:People form. That was ok, but a case can be made for managing specific people (not necessarily all) in the CMDB. So the 7.6 way we're talking about now is at least a transitional shift away from the standard people forms toward using the CMDB BMC_People form for setting relationships between CIs. That makes a cleaner relational model as well as a more flexible one. It also has the benefit of allowing customers who use a CMDB apart from ITSM the ability to easily do so without giving up the ability to track people/CI relationships. Seems a sound strategy to me. Thoughts? Rick On Tue, Aug 2, 2011 at 12:38 PM, strauss mailto:stra...@unt.edu>> wrote: ** Does this filter pick or choose which CTM:People entries to populate into BMC_People? I am about to re-develop my integration that takes LDAP data from a SQL Server and shoves it into CTM:People, User, and CTM:PeoplePermissionGroups and maintains those records with a live feed. There are currently about 266,400 people and user records, of which 336 are support staff (that generates about 341,000 CTM:PPG recs). When we upgraded to 7.6.04.01 we saw 475 records created in the BMC.CORE.BMC_Person table; three more have "appeared" since then. We have made no effort to deal with these, having no experience with the CMDB or reconciliation. After the upgrade we turned off all of the integration filters and AIE jobs, although RRR|Chive updates the individual tables from production nightly. Personally, I can only see adding the IT staff initially, but it will probably be easiest to filter to the active faculty/staff records (14,170 recs including student employees - they have a custom role flag in CTM:People that is set by the integration). Has anyone already tackled this, and able to shed some light on the process?? Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Tommy Morris Sent: Tuesday, August 02, 2011 1:31 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Integrating with CTM:People vs. BMC_People ** An OOB filter triggers off of CTM:People that creates/ updates BMC_PERSON just push to CTM:People and set 'z1d Action' to "PEOPLESYNC_CREATE" or "PEOPLESYNC_UPDATE". You will be able to see a new record create in BMC.Sandbox and the reconcile into your CMDB. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Pierson, Shawn Sent: Tuesday, August 02, 2011 1:07 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Integrating with CTM:People vs. BMC_People ** Good afternoon, As I