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_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
