Hi Michelle, Sorry for the delay in response.
Thanks a lot for your suggestion. However, our issue was with FTS, as of now we just disabled o FTS on workflows and that resolved the issue. We are looking into root cause of the issue. Best Regards, Jithin On Wed, Oct 7, 2015 at 7:15 PM, Lucero, Michelle < [email protected]> wrote: > ** > > Hi, Jithin: > > > > I am not sure if the error you’re seeing is related to FTS. > > > > In the past we’ve seen mismatches, because of an added middle initial, > name, space, etc. We’ve also had a format mismatch, where an older record > was stored First Name Last Name and the People record was stored Last Name, > First Name. > > > > 1. Compare the Full Name for this individual in these three places: > > · CTM:People > > · CTM:SupportGroupFunctionalRole > > · User > > > > The Full Name format in all three places must match. > > > > 2. One more thing. Check to see if this individual has the same full > name as someone else? > > > > Hope this helps, > > Michelle > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Jithin T.R > *Sent:* Tuesday, October 06, 2015 2:37 AM > > *To:* [email protected] > *Subject:* Re: FTS Re-index issue > > > > ** > > Hi Manoj, > > > > Thanks you. > > > > The user form and permission are set up for this user without any issue. > > > > From my knowledge I don't think Functional Role are mapped in user form. > > > > Actually there are some workflows setting some temporary values while > setting the Change Manager value in the field. This value will be set if > there is a record CTM:SupportGroupFuncRoleLookUp with Full Name we selected > from the list. > > > > I think because of the FTS issue, the system is unable to search the > records using Full Name and in turn throws an error stating Invalid Change > Manager. > > CHG:CRQ:ValidateChgManager_145 it is searching record using fullname > > CHG:CRQ:ValidateChgManager_146 this one is throwing error > > > > Best Regards, > > Jithin > > > > On Tue, Oct 6, 2015 at 12:25 PM, Manoj Kumar <[email protected]> > wrote: > > ** > > Jithin, > > Check in user form once if the permission exists and try to re-add the > permission. > We had same issue and it worked . > > Thanks, > Manoj > +91 996 223 2006 > > Sent from my Moto Turbo smart phone > > On 6 Oct 2015 11:33, "Jithin T.R" <[email protected]> > wrote: > > ** > > Hi All, > > > > Thanks a lot for your valuable time on this. > > > > *"The issue we are facing is when we try to assign a change request to > change manager system throws an error stating Invalid change manager. We > have everything configured for that users.* > > > > *When we searched the record for that user in > CTM:SupportGroupFuncRoleLookUp using Login ID it retrieves all the > records. However, when try it with full name no records found."* > > > > We are on Remedy 8.1 and have 2 servers. > > > > Both servers are configured as Server Group-Indexer in FTS Configuration > form, there is no Server Group-Searcher defined and both servers have entry > in Server Ranking form for FTS. > > > > Is this mandatory to have a Server Group-Searcher ? or based on ranking in > Server Group Ranking form, will lower ranked server automatically turns > into Searcher ? > > > > Best Regards, > > Jithin > > > > > > On Tue, Oct 6, 2015 at 8:17 AM, William Rentfrow < > [email protected]> wrote: > > ** > > We're in the process of testing version 9, so I can't comment on that yet. > > > > William Rentfrow > > [email protected] > > Office: 715-204-3061 or 701-232-5697x25 > > Cell: 715-498-5056 > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Peter Romain > *Sent:* Monday, October 05, 2015 3:51 PM > > > *To:* [email protected] > *Subject:* Re: FTS Re-index issue > > > > ** > > FTS has changed since Williams description. > > > > Indexes should now be on the disks of the servers doing the indexing for > improved performance. > > Each indexing server creates its own index that it uses for searches. > > Servers that are not indexers (those having no FTS record in the server > group ranking form) use the primary indexing server for searches. If this > server isn’t available the ranking form tells them which server to try next. > > Community posts discuss FTS, e.g.: > > > https://communities.bmc.com/community/bmcdn/bmc_remedy_ar_system/blog/2013/10/11/the-pulse-high-availability-for-fts-in-a-server-group > > > > The fortification does work to reduce the number of fields needing > indexing but we found that adding a customisation to, say, the incident > form caused the index information on indexed fields to propagate to > incident join forms and then be indexed. > > BMC was going to fix this but I’ve not tested this on the latest versions. > > > > > > > > *From:* Action Request System discussion list(ARSList) [ > mailto:[email protected] <[email protected]>] *On Behalf Of *William > Rentfrow > *Sent:* 05 October 2015 16:47 > *To:* [email protected] > *Subject:* Re: FTS Re-index issue > > > > ** > > I disagree. You do NOT want to re-index from every server. > > > > First of all - what version of ARS? Let's assume it's version 8 or > later. > > > > Second - when you re-index there's a specific process. You should disable > FTS on all servers and disable indexing on all servers. Then shut them all > down. Delete all of the index files from the shared index location (see > below). Use a SQL tool and truncate the table FT_PENDING (or write a > Display Only form + workflow to do this, which is what I did for long term > ease of use). Then start the admin server and enable indexing. Then start > a re-index. Start the other servers back up and turn FTS back on when the > re-index is done. > > > > Now as to configuration.... > > > > There's more than one way to do it but BMC definitely has a preferred way. > > > > In a server group BMC prefers you have a shared file location all servers > can access. One server - usually the admin server for the server group - > is the indexing server. It creates all of the index files and updates the > files when new requests are put into the FT_PENDING table. > > > > One of the other servers (or the other server if you only have two > servers) is the search server. It should have FTS indexing disabled and > should be configured to retrieve all searches for FTS. So all of the > plugins in the ar.conf/ar.cfg on every server should reference the search > server. This prevents file locking problems. > > > > Also, there is an FTS fortifications patch out that removes a LOT of > extra/unused indexes and GREATLY reduces the amount of time it takes to do > a full re-index. I highly recommend applying this if you have not. > > > > William Rentfrow > > [email protected] > > Office: 715-204-3061 or 701-232-5697x25 > > Cell: 715-498-5056 > > > > *From:* Action Request System discussion list(ARSList) [ > mailto:[email protected] <[email protected]>] *On Behalf Of *Durga, V > H V Sekhar > *Sent:* Monday, October 05, 2015 8:59 AM > *To:* [email protected] > *Subject:* Re: FTS Re-index issue > > > > ** > > You need to re-index from both the indexer servers. > > > > *From:* Action Request System discussion list(ARSList) [ > mailto:[email protected] <[email protected]>] *On Behalf Of *Jithin > T.R > *Sent:* 05 October 2015 06:55 > *To:* [email protected] > *Subject:* FTS Re-index issue > > > > ** > > Hi Team, > > > > We have an issue, I cannot search using full name (Change Manager) and > throwing error. > > > > This we have fixed by re-indexing. However, no we have an issue when we > run re-index(only on primary server) it works fine in that server but not > in other server. > > > > What is the procedure to FTS re-index in a server group environment ? > > > > We have 2 server both are configured as Server Group Indexer. > > > > Ranked the servers in Ranking form. > > > > Do we need to re-index each server ? > > > > > > Thanks & Regards, > > Jithin Radhakrishnan > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > ------------------------------ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4830 / Virus Database: 4365/10744 - Release Date: 10/02/15 > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > ------------------------------ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4830 / Virus Database: 4365/10744 - Release Date: 10/02/15 > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > ------------------------------ > This message, and any attachments, is for the intended recipient(s) only, > may contain information that is privileged, confidential and/or proprietary > and subject to important terms and conditions available at > http://www.bankofamerica.com/emaildisclaimer. If you are not the intended > recipient, please delete this message. > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
