It is a pretty seamless migration as BSR 3.5 uses a different architecture than iBRSD. When you install BSR 3.5, the iBRSD functionaity is turned off, and you'll need to configure BSR. Below is the link to the install guide. There is a video that talks about the installation.
I am also planning to migrate IBRSD with BSR 3.5. How was your experience. Have you faced any challenges during this implementation ?
1 of 1 people found this helpful
I encountered serious issues in this migration.
I suggest to read carefully the knowledge articles available and the comments added by users to the product documentation pages.
Please feel free to open discussions in case you need support...I'm quite a BSR expert now... :-p
1 of 1 people found this helpful
Sorry for the long delay to reply.
The migration tooks time but finally we did it. We had to manage a lot of issues with HTTPS and work with the support.
Also in ITSM there were a lot of changes due to the new method to create incident.
It depends also what kind of incident you create and how you assign them.. because with BSR, it's more restritive that IBSRD to pass info to ITSM.
Can you be a bit more specific about issues you ran into and which knowledge articles helped in resolving those issues? This would prove to be very valuable to others. In addition, from those references, we can review and act on those issues.
Can you clarify how BSR is more restrictive in passing info to ITSM than iBRSD?
2 of 2 people found this helpful
Please find the issues and the solutions/workarounds I could find so far (the migration is still in progress and the project go-live has been delayed of months)
BSR 3.5 documentation states:
>With BMC Service Resolution 3.5, the incident_assignee_group parameter is available out of the box in the ibrsd_event_incidentinfo.baroc and ibrsd_ci_incidentinfo.baroc files.
BSR 3.5 delivered with the TSIM 10.7 installer does not contain this ootb slot. I had to add it manually as suggested for the previous versions.
The new variables introduced in the DefaultMapping.map file are not called as the reported in the documentation:
The correct names are:
Incident_assignee = <please map the slots which would have assignee info>
Incident_Support_Group_Name= <please map the slots which would have support group info>
Incident_Support_Company = <please map the slots which would have support company info>
Incident_Support_Organization = <please map the slots which would have support organization info>
In addition, the following variable must be modified because of a mistake in the code:
Otherwise the use of the new variables introduced in 3.5 will fail.
To ensure compatibility of BMC Service Resolution 3.5 with BMC Remedy ITSM 9.1.00, add the following property under the TraceParametersSrc group in the IBRSD.conffile located at the installationDirectory\pw\integrations\ibrsd\conf directory:
4. Apply the following steps as per KA 000143190 in order to enable the Incident Auto-Resolution
Modify also HPD:ISI:EventLevel1_699_CheckForExistingEventIncident
Add bsrversion=184.108.40.206 to IBRSD.conf if not present (it was not)
Apply step #2 of KA 000122615
In defaultmap of ibrsd, you can passed whatever you want to ITSM if you have an overlay in ITSM...
If you known the internal of the ITSM field you can assign this field in Defautmapping file with event slots
Now with BSR you can only use what is in defaultmapping files and also the temp variable... if you try to pass other info,, nothing arrived to ITSM
You cannot add a field who exist in ITSM or we were not able...
The Temp variables are meant to pass any extra information that needs to be passed from Truesight to ITSM.
Could you please elaborate on the need of passing some more information and could Temp variables be used for it?