Re: Remedy 8.1 SP2 - Hanging on Startup
The drop table statements show threads shutting down and cleaning up temporary tables. The number at the end of the name is the thread ID so I suspect this is the preload threads finishing work rather than a thread crashing – you’re not seeing any stack traces in the arerror.log re you? It looks a lot like some sort of metadata corruption so you may be able to get a hint of what the issue is with the –t startup option. Copy the arserver.exe line from armonitor.cfg and run it at the command line but insert –t after the arserver.exe – this will create a arstartup_PID.log and cause some validation of the metadata to be run and logged. Once you have that you’re likely to need a support case with BMC to get some further insight as to where it is getting stuck. Mark From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of BradRemedy Sent: 20 January 2015 06:23 To: arslist@ARSLIST.ORG Subject: Re: Remedy 8.1 SP2 - Hanging on Startup ** Hi Jason I did get SQL profiler running and checked what was being called by remedy and found the following entries: SQL:BatchStarting DROP TABLE AR0int5212 182 2015-01-20 07:38:58.553 SQL:BatchStarting DROP TABLE AR0int8000 166 2015-01-20 07:38:58.553 SQL:BatchStarting DROP TABLE AR0int7664 178 2015-01-20 07:38:58.560 SQL:BatchStarting DROP TABLE AR0float5212 182 2015-01-20 07:38:58.560 SQL:BatchStarting DROP TABLE AR0float8000 166 2015-01-20 07:38:58.560 SQL:BatchStarting DROP TABLE AR0float7664 178 2015-01-20 07:38:58.560 SQL:BatchStarting DROP TABLE AR0char5212182 2015-01-20 07:38:58.560 SQL:BatchStarting DROP TABLE AR0char8000166 2015-01-20 07:38:58.560 SQL:BatchStarting DROP TABLE AR0char7664178 2015-01-20 07:38:58.560 SQL:BatchStarting DROP TABLE AR0decimal5212 182 2015-01-20 07:38:58.560 SQL:BatchStarting DROP TABLE AR0decimal8000 166 2015-01-20 07:38:58.560 Audit Logout 182 2015-01-20 07:38:58.180 SQL:BatchStarting DROP TABLE AR0decimal7664 178 2015-01-20 07:38:58.560 Audit Logout 166 2015-01-20 07:38:57.217 Audit Logout 178 2015-01-20 07:38:58.020 SQL:BatchStarting DROP TABLE AR0int7732 171 2015-01-20 07:38:58.563 SQL:BatchStarting DROP TABLE AR0float7732 171 2015-01-20 07:38:58.567 SQL:BatchStarting DROP TABLE AR0char7732171 2015-01-20 07:38:58.570 SQL:BatchStarting DROP TABLE AR0decimal7732 171 2015-01-20 07:38:58.570 Audit Logout 171 2015-01-20 07:38:57.280 SQL:BatchStarting DROP TABLE AR0int6804 183 2015-01-20 07:38:58.627 SQL:BatchStarting DROP TABLE AR0float6804 183 2015-01-20 07:38:58.627 SQL:BatchStarting DROP TABLE AR0char6804183 2015-01-20 07:38:58.627 SQL:BatchStarting DROP TABLE AR0decimal6804 183 2015-01-20 07:38:58.633 Not sure what the system is trying to do - should i leave it and see ? I have also logged this with BMC Software to see if they have any ideas. As always, thanks for the suggestions and help guys - it is really appreciated. I am hoping my company approves my proposal to attend the BMC Engage event this year so that I can meet you guys and thank you in person. Cheers Brad On Tue, Jan 20, 2015 at 6:36 AM, Jason Miller jason.mil...@gmail.commailto:jason.mil...@gmail.com wrote: ** I would definitely run a trace on the db as LJ mentioned to see what if any activity is going on. You can also turn on a startup log by adding a switch in you armonitor.cfg/config file. I can't think of it off the top of my head but it has been mentioned on the list before and should be on docs.bmc.comhttp://docs.bmc.com. Wait... I think it might be -i. It gets added to the line that actually starts arserver. Jason On Jan 19, 2015 8:28 PM, BradRemedy bradrem...@gmail.commailto:bradrem...@gmail.com wrote: ** Hi, I checked in the ar.cfg file and the Record-Object-Relationship is set to F. As a test I restarted the entire server yet the service still says Starting with the memory usage for the arserver.exe process sitting at 390mb. It will stay like this for hours and wont start. There is nothing in the arerror log file besides the remedy version information and the startup log file has the same entries as per my original post. The last line is still Mon Jan 19 2015 13:40:05.7000 Startup TID: 004696 Loading field mapping information Thanks in Advance Brad On Mon, Jan 19, 2015 at 3:41 PM, Harshad Wagh harshad.w...@vyomlabs.commailto:harshad.w...@vyomlabs.com wrote: ** Hi Brad, I wonder if there is Record Object Relationship is set to true in under Configuration tab of Server Information tab then Remedy Application Service takes longer time to start. you can check this in
Need Suggestion
Hi All, I have below requirement from one of the Customer. Wanted to check if anyone has done this before for such volume. Requirement - Customer wants to send SMS to the stakeholders for any escalations on the tickets generated from Alarm (Fault Management System). Volume of tickets to be generated from Alarms - 3.5 million per day on day 1. Eventually the count to increase to 9.5 million per day. For any given ticket,2 to 3 SMS to flow from the system as part of the escalation matrix. Is remedy system the right place to handle SMS flow of this volume? I am in disagreement to use the Remedy System as SMS dispatcher for such a large volume of tickets. What are your thoughts on this? Any suggestions? Regards, Praveen ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Need Suggestion
Great points, Janie. I don't know that Remedy would scale to processing 5 million Incidents a day, unless the DB was kept VERY well trimmed and tuned. If they processed through some very tiny form, then maybe. But the issue is why are there 3-9 million alarms a day going INTO the system. No one will ever actually process those, so deal with the duplicates and non-actionable items some other way, and specifically whitelist those you want/need to actually be tracked in an Incident. Rick Cook On Tue, Jan 20, 2015 at 8:54 AM, Janie Sprenger jrsrem...@gmail.com wrote: ** Are you in disagreement because you don't think Remedy can handle the volume or the volume won't be appropriately handled by personnel once it's in Remedy? Some additional things to think about are: By ticket, do you mean Incident or Change Request or Task or Work Order or something custom, by escalations do you mean related transaction records? Are all of the tickets that get generated supposed to end up being handled manually by people? Is there more processing and automation that occurs once the ticket is generated in Remedy? Is the process flow escalation intended to be more than a historical audit record of the event? Obviously, the volume is really high and it's hard to think of any companies that can manually handle that kind of volume on a daily basis so that means there is more to the story. IMO, Here's the thing to keep in mind, the customer is trying to solve a problem. They are attempting to use Remedy to solve that problem, which is good so you don't want to deter from them from what Remedy can and should be doing. But you also need to help to find a solution for the actual issue at hand because if they really have 3.5 to 9.5 million daily faults occurring in their environment, then they really do have a problem they have to sort out. Perhaps it's a matter of getting a handle on what is faulting, maybe SMS or FMS is or isn't configured correctly, maybe the faults are warnings and some are faults that need to be addressed. Maybe there is something to be aware of other than just processing millions of individual tickets into a 1 to 1 mapping between the fault and the ticket. My suggestion is to find out what the end goal is for the data that goes into Remedy, regardless of the volume and see where that takes you with whether or not Remedy can assist with solving the customer's problem. HTH, Janie On Tue, Jan 20, 2015 at 3:25 AM, Saraswat, Praveen psaras...@columnit.com wrote: ** Hi All, I have below requirement from one of the Customer. Wanted to check if anyone has done this before for such volume. Requirement – Customer wants to send SMS to the stakeholders for any escalations on the tickets generated from Alarm (Fault Management System). Volume of tickets to be generated from Alarms – 3.5 million per day on day 1. Eventually the count to increase to 9.5 million per day. For any given ticket,2 to 3 SMS to flow from the system as part of the escalation matrix. Is remedy system the right place to handle SMS flow of this volume? I am in disagreement to use the Remedy System as SMS dispatcher for such a large volume of tickets. What are your thoughts on this? Any suggestions? Regards, Praveen _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
Re: Need Suggestion
Are you in disagreement because you don't think Remedy can handle the volume or the volume won't be appropriately handled by personnel once it's in Remedy? Some additional things to think about are: By ticket, do you mean Incident or Change Request or Task or Work Order or something custom, by escalations do you mean related transaction records? Are all of the tickets that get generated supposed to end up being handled manually by people? Is there more processing and automation that occurs once the ticket is generated in Remedy? Is the process flow escalation intended to be more than a historical audit record of the event? Obviously, the volume is really high and it's hard to think of any companies that can manually handle that kind of volume on a daily basis so that means there is more to the story. IMO, Here's the thing to keep in mind, the customer is trying to solve a problem. They are attempting to use Remedy to solve that problem, which is good so you don't want to deter from them from what Remedy can and should be doing. But you also need to help to find a solution for the actual issue at hand because if they really have 3.5 to 9.5 million daily faults occurring in their environment, then they really do have a problem they have to sort out. Perhaps it's a matter of getting a handle on what is faulting, maybe SMS or FMS is or isn't configured correctly, maybe the faults are warnings and some are faults that need to be addressed. Maybe there is something to be aware of other than just processing millions of individual tickets into a 1 to 1 mapping between the fault and the ticket. My suggestion is to find out what the end goal is for the data that goes into Remedy, regardless of the volume and see where that takes you with whether or not Remedy can assist with solving the customer's problem. HTH, Janie On Tue, Jan 20, 2015 at 3:25 AM, Saraswat, Praveen psaras...@columnit.com wrote: ** Hi All, I have below requirement from one of the Customer. Wanted to check if anyone has done this before for such volume. Requirement – Customer wants to send SMS to the stakeholders for any escalations on the tickets generated from Alarm (Fault Management System). Volume of tickets to be generated from Alarms – 3.5 million per day on day 1. Eventually the count to increase to 9.5 million per day. For any given ticket,2 to 3 SMS to flow from the system as part of the escalation matrix. Is remedy system the right place to handle SMS flow of this volume? I am in disagreement to use the Remedy System as SMS dispatcher for such a large volume of tickets. What are your thoughts on this? Any suggestions? Regards, Praveen _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
FW: Job - Remedy Solutions Architect/Developer (UPDATE)
Job Title: Remedy Solutions Architect/Developer THIS IS A FULL TIME JOB WITH BENEFITS, MUST BE ONSITE. Job Title: Remedy Solutions Architect/Developer Overview: Jacobs is actively seeking a Remedy Solutions Architect/Developer at the U.S. Special Operations Command in Tampa Florida. The Remedy Solutions Architect will be responsible for implementing and developing best practices for delivery of the BMC Remedy ITSM suite (Version 7.6.04 and 8.1) Atrium CMDB Product Family (Version 7.6.04 and 8.1), and BMC MyIT (Version 2.2) Responsibilities: Remedy Solutions Architect/Developer Job Description: The Remedy Architect/Developer will participate in usability and requirements meetings and then implement a solution or workflow based on specific customer needs. He/she will install, configure, customize, deploy and administer BMC products to include the integration of BMC products and other third party applications. The Remedy Architect/Developer will participate in usability and requirements meetings and then implement a solution or workflow based on specific customer needs. He/she will assess, develop, install, configure, document and test all proposed solutions and create migration packages for deployment into the production environment. The Remedy Architect/Developer will be responsible for configuring and integrating BMC products with other third party applications and databases. Qualifications: Minimum Education/Experience Requirements: Bachelor's degree in a computer or system science discipline and fourteen (14) years experience or equivalent combination of education and experience. Required Skills: * Full product life-cycle to include development, integration, testing and documentation using contemporary delivery methodologies (Scrum, Agile, RUP, etc.). * Custom Remedy workflow, forms, reports and filters to meet specified requirements. * ARS administration (v7.6 or above). Version 8.1 preferred * ARS development (v7.6 or above including Filters, Active links, Mid-tier web interface, and a help desk module). * Extensive experience with BMC Remedy Developer Studio * Extensive experience with CMDB reconciliation against multiple data sets * Experience with web services and Atrium Integrator * SQL Database administration preferred * Excellent negotiation skills with the ability to work with others to reach mutually agreed upon solutions. * Strong problem solving skills with the ability to influence consensus and agreements. * Solid written and verbal communications skills. * Ability to communicate and work effectively with a variety of government and contractor individuals at all levels. * Ability to work autonomously; self-starter. * Ability to work occasional night and weekend shifts to support operations and product upgrades. * Position includes on-call responsibilities one week a month. * Ability to obtain DoD IAT Level II certification within 6 months of being hired. Preferred Certifications: * ITIL V3/V2 Foundations * BMC Certified Administrator: BMC Remedy IT Service Management 7.6.04 Interim Secret Clearance required to start with ability to obtain Top Secret/SCI Clearance. Thanks, Elmo Gentry Remedy Application Developer ITSM-J636, Jacobs DSN: 299-0340 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Need Suggestion
Praveen, I'm sure you have already done the math9.5M/day is roughly 110/sec if averaged out, which it of course wouldn't be. This sort of volume would be large just to store that many records per day, let alone 'process' them, but Remedy is scalable, and is a workflow engine, so yes, an infrastructure COULD be setup to handle itI'm not sure if Remedy would be doing more than being a DB repository and lookup location at that point, so it might make sense to bypass Remedy altogether and just write a Java Daemon or something that did direct DB lookups for the data you need and called the external program that's actually doing the paging... On Tue, Jan 20, 2015 at 11:08 AM, Saraswat, Praveen psaras...@columnit.com wrote: ** Hi Janie, Customer has one of worlds largest passive support for Telcos due to which the volume of alarms from different EMSs is high. Actual need was to notify the stakeholders through SMS before it qualified to be converted to an Incident and follow a set escalation matrix in case Alarm is not able to clear itself from EMS systems. You are right in your understanding that Customer is trying to solve a problem which the FMS(Alarm System) owner has declined to do due to various reasons. There is a lot of processing done to get appropriate information for SMS ,before it goes from Remedy System to the SMS gateway. Yes, the volume of the Alarms to be converted to Incidents( only incidents will be created from Alarms) is high and the Customer is least bothered about handling of these tickets. He just wants to trigger Escalation(SLA breach) SMS if the Alarm is not automatically cleared. In addition to the above type of tickets. Remedy system is supposed to handle approx 70k tickets per day , which will be assigned to the appropriate groups and it needs to be worked upon by ground staff using a Mobile App. These tickets(Incidents/Change/Problem) also have their own processing and automation before it hits the database.SMS flows for these type of tickets as well. We have already implemented this for 70k tickets per day, but the new volume of Alarms makes me little hesitant to commit to the Customer. Also I don’t want to make the Remedy System as a SMS dispatcher tool instead of its core functionalities of ticket tracking and service management. I really appreciate your thoughts and opinion. Thanks Regards, Praveen *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Janie Sprenger *Sent:* 20 January 2015 22:24 *To:* arslist@ARSLIST.ORG *Subject:* Re: Need Suggestion ** Are you in disagreement because you don't think Remedy can handle the volume or the volume won't be appropriately handled by personnel once it's in Remedy? Some additional things to think about are: By ticket, do you mean Incident or Change Request or Task or Work Order or something custom, by escalations do you mean related transaction records? Are all of the tickets that get generated supposed to end up being handled manually by people? Is there more processing and automation that occurs once the ticket is generated in Remedy? Is the process flow escalation intended to be more than a historical audit record of the event? Obviously, the volume is really high and it's hard to think of any companies that can manually handle that kind of volume on a daily basis so that means there is more to the story. IMO, Here's the thing to keep in mind, the customer is trying to solve a problem. They are attempting to use Remedy to solve that problem, which is good so you don't want to deter from them from what Remedy can and should be doing. But you also need to help to find a solution for the actual issue at hand because if they really have 3.5 to 9.5 million daily faults occurring in their environment, then they really do have a problem they have to sort out. Perhaps it's a matter of getting a handle on what is faulting, maybe SMS or FMS is or isn't configured correctly, maybe the faults are warnings and some are faults that need to be addressed. Maybe there is something to be aware of other than just processing millions of individual tickets into a 1 to 1 mapping between the fault and the ticket. My suggestion is to find out what the end goal is for the data that goes into Remedy, regardless of the volume and see where that takes you with whether or not Remedy can assist with solving the customer's problem. HTH, Janie On Tue, Jan 20, 2015 at 3:25 AM, Saraswat, Praveen psaras...@columnit.com wrote: ** Hi All, I have below requirement from one of the Customer. Wanted to check if anyone has done this before for such volume. Requirement – Customer wants to send SMS to the stakeholders for any escalations on the tickets generated from Alarm (Fault Management System). Volume of tickets to be generated from Alarms – 3.5 million per day on day 1. Eventually
Re: Need Suggestion
Most organizations that I’ve worked in where Incidents are created via a monitoring tool do that escalation on the monitoring tool’s side. That’s really where you want to look. Leave the Incidents for things that actually require human intervention. I would propose getting the monitoring team to do two things: 1) Group alarms into logical relationships to weed out unnecessary alarms (e.g. if a switch that has ten servers connected to it is down, you don’t get 11 Incidents.) 2) Create a prioritization structure so that Incidents are only created when either 1) major failures are reported via monitoring, or 2) medium alarms are not resolved in a timely manner and must be looked at by a person. Additionally, there should be some Problem Management in place to address the issues causing these alarms. That way there can be a representation in Remedy as a Problem Investigation or Known Error, yet you don’t need to store each and every example of a minor alarm as an entire record in Remedy. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Saraswat, Praveen Sent: Tuesday, January 20, 2015 12:09 PM To: arslist@ARSLIST.ORG Subject: Re: Need Suggestion ** Hi Janie, Customer has one of worlds largest passive support for Telcos due to which the volume of alarms from different EMSs is high. Actual need was to notify the stakeholders through SMS before it qualified to be converted to an Incident and follow a set escalation matrix in case Alarm is not able to clear itself from EMS systems. You are right in your understanding that Customer is trying to solve a problem which the FMS(Alarm System) owner has declined to do due to various reasons. There is a lot of processing done to get appropriate information for SMS ,before it goes from Remedy System to the SMS gateway. Yes, the volume of the Alarms to be converted to Incidents( only incidents will be created from Alarms) is high and the Customer is least bothered about handling of these tickets. He just wants to trigger Escalation(SLA breach) SMS if the Alarm is not automatically cleared. In addition to the above type of tickets. Remedy system is supposed to handle approx 70k tickets per day , which will be assigned to the appropriate groups and it needs to be worked upon by ground staff using a Mobile App. These tickets(Incidents/Change/Problem) also have their own processing and automation before it hits the database.SMS flows for these type of tickets as well. We have already implemented this for 70k tickets per day, but the new volume of Alarms makes me little hesitant to commit to the Customer. Also I don’t want to make the Remedy System as a SMS dispatcher tool instead of its core functionalities of ticket tracking and service management. I really appreciate your thoughts and opinion. Thanks Regards, Praveen From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Janie Sprenger Sent: 20 January 2015 22:24 To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Re: Need Suggestion ** Are you in disagreement because you don't think Remedy can handle the volume or the volume won't be appropriately handled by personnel once it's in Remedy? Some additional things to think about are: By ticket, do you mean Incident or Change Request or Task or Work Order or something custom, by escalations do you mean related transaction records? Are all of the tickets that get generated supposed to end up being handled manually by people? Is there more processing and automation that occurs once the ticket is generated in Remedy? Is the process flow escalation intended to be more than a historical audit record of the event? Obviously, the volume is really high and it's hard to think of any companies that can manually handle that kind of volume on a daily basis so that means there is more to the story. IMO, Here's the thing to keep in mind, the customer is trying to solve a problem. They are attempting to use Remedy to solve that problem, which is good so you don't want to deter from them from what Remedy can and should be doing. But you also need to help to find a solution for the actual issue at hand because if they really have 3.5 to 9.5 million daily faults occurring in their environment, then they really do have a problem they have to sort out. Perhaps it's a matter of getting a handle on what is faulting, maybe SMS or FMS is or isn't configured correctly, maybe the faults are warnings and some are faults that need to be addressed. Maybe there is something to be aware of other than just processing millions of individual tickets into a 1 to 1 mapping between the fault and the ticket. My suggestion is to find out what the end goal is for the data that goes into Remedy, regardless of the volume and see where that takes you with whether or not Remedy can assist
Re: Need Suggestion
Hi Janie, Customer has one of worlds largest passive support for Telcos due to which the volume of alarms from different EMSs is high. Actual need was to notify the stakeholders through SMS before it qualified to be converted to an Incident and follow a set escalation matrix in case Alarm is not able to clear itself from EMS systems. You are right in your understanding that Customer is trying to solve a problem which the FMS(Alarm System) owner has declined to do due to various reasons. There is a lot of processing done to get appropriate information for SMS ,before it goes from Remedy System to the SMS gateway. Yes, the volume of the Alarms to be converted to Incidents( only incidents will be created from Alarms) is high and the Customer is least bothered about handling of these tickets. He just wants to trigger Escalation(SLA breach) SMS if the Alarm is not automatically cleared. In addition to the above type of tickets. Remedy system is supposed to handle approx 70k tickets per day , which will be assigned to the appropriate groups and it needs to be worked upon by ground staff using a Mobile App. These tickets(Incidents/Change/Problem) also have their own processing and automation before it hits the database.SMS flows for these type of tickets as well. We have already implemented this for 70k tickets per day, but the new volume of Alarms makes me little hesitant to commit to the Customer. Also I don’t want to make the Remedy System as a SMS dispatcher tool instead of its core functionalities of ticket tracking and service management. I really appreciate your thoughts and opinion. Thanks Regards, Praveen From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Janie Sprenger Sent: 20 January 2015 22:24 To: arslist@ARSLIST.ORG Subject: Re: Need Suggestion ** Are you in disagreement because you don't think Remedy can handle the volume or the volume won't be appropriately handled by personnel once it's in Remedy? Some additional things to think about are: By ticket, do you mean Incident or Change Request or Task or Work Order or something custom, by escalations do you mean related transaction records? Are all of the tickets that get generated supposed to end up being handled manually by people? Is there more processing and automation that occurs once the ticket is generated in Remedy? Is the process flow escalation intended to be more than a historical audit record of the event? Obviously, the volume is really high and it's hard to think of any companies that can manually handle that kind of volume on a daily basis so that means there is more to the story. IMO, Here's the thing to keep in mind, the customer is trying to solve a problem. They are attempting to use Remedy to solve that problem, which is good so you don't want to deter from them from what Remedy can and should be doing. But you also need to help to find a solution for the actual issue at hand because if they really have 3.5 to 9.5 million daily faults occurring in their environment, then they really do have a problem they have to sort out. Perhaps it's a matter of getting a handle on what is faulting, maybe SMS or FMS is or isn't configured correctly, maybe the faults are warnings and some are faults that need to be addressed. Maybe there is something to be aware of other than just processing millions of individual tickets into a 1 to 1 mapping between the fault and the ticket. My suggestion is to find out what the end goal is for the data that goes into Remedy, regardless of the volume and see where that takes you with whether or not Remedy can assist with solving the customer's problem. HTH, Janie On Tue, Jan 20, 2015 at 3:25 AM, Saraswat, Praveen psaras...@columnit.commailto:psaras...@columnit.com wrote: ** Hi All, I have below requirement from one of the Customer. Wanted to check if anyone has done this before for such volume. Requirement – Customer wants to send SMS to the stakeholders for any escalations on the tickets generated from Alarm (Fault Management System). Volume of tickets to be generated from Alarms – 3.5 million per day on day 1. Eventually the count to increase to 9.5 million per day. For any given ticket,2 to 3 SMS to flow from the system as part of the escalation matrix. Is remedy system the right place to handle SMS flow of this volume? I am in disagreement to use the Remedy System as SMS dispatcher for such a large volume of tickets. What are your thoughts on this? Any suggestions? Regards, Praveen _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
BMC Atrium SSO Question
Am researching installing BMC Atrium Single Sign-On and have a question for those of you that have already done this. BMC recommends that it is installed on a separate server from other BMC products. So I have an ARS server, MidTier server, SmartIT server, and now will have an SSO server. Does that sound correct to those who have installed SSO? Thank you, ~~~ Terri ARS 8.1.01 ITSM 8.1.01 Midtier 8.1.01 SRM 8.1.01 Windows 2008 R2 MS SQL 2008 R2 SP2 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: BMC Atrium SSO Question
Hi Terri, Based on what is recommended I believe that is correct. I didn't have a separate server for SSO so I put it on the same ARS Server for our upgrade staging environment. Thanks, Jon On Tue, Jan 20, 2015 at 12:02 PM, Terri Lockwood teresa.lockw...@sungard.com wrote: ** Am researching installing BMC Atrium Single Sign-On and have a question for those of you that have already done this. BMC recommends that it is installed on a separate server from other BMC products. So I have an ARS server, MidTier server, SmartIT server, and now will have an SSO server. Does that sound correct to those who have installed SSO? Thank you, ~~~ Terri ARS 8.1.01 ITSM 8.1.01 Midtier 8.1.01 SRM 8.1.01 Windows 2008 R2 MS SQL 2008 R2 SP2 _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
Does the LDAP authentication service for remedy 7.1, running on SunOS 5.9 support SHA2 encryption?
Hi All, This is a query related to AREA LDAP authentication for ARS 7.1. Would like to know experts' opinions. Our LDAP servers are currently using SHA1 and soon they are going to be using SHA2, hence want to know if it is possible in remedy to have AREA LDAP configuration supporting SHA2. Need some expert advice urgently on this please. Does the LDAP authentication service for remedy 7.1, running on SunOS 5.9 support SHA2 encryption? If yes how can we configure it or it has to do something from LDAP and not from remedy. Regards, Saurabh -- View this message in context: http://ars-action-request-system.1.n7.nabble.com/Does-the-LDAP-authentication-service-for-remedy-7-1-running-on-SunOS-5-9-support-SHA2-encryption-tp120382.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
