Thanks Rick! We made the suggested changes on the Email Message form and all seems to be well. We've had discussions with a lot of our our customers on reducing the amounts of email sent and they re a bit resistant to it... :) but we keep trying. :)
thanks again to you and everyone! Mary --------- ORIGINAL --------- ** Yes, Mary. You turn on/off the capability at an AR Server level, but the number is done form by form. Multiple NM (Network Monitoring) systems, like would be in place at a large corporation comprised of an assortment of smaller acquisitions not yet all on the same platform, could feed large numbers of alarms into Remedy as Incidents. I've seen 30k tickets a day in one system (90% NM-sourced), and I am sure that some run higher than that. Gaps will occur on AR System restart, and all unused Entry IDs are lost. In a server group, this will mean that each server has its own set for pre-allocated IDs, and restarting all servers would cause all sets to be lost on restart. This can be disconcerting to users as well as those who do reporting/metrics. If you work in an industry that audits Remedy data, having missing blocks of IDs may show as a red flag - something to consider. The advice about turning off the Change History is a good one, and indicates the better path to the solution to performance issues. If performance is an issue, my advice is to address it in different ways (like that one) that don't have the negative side effects of the Entry-ID-Block. That being said, I would have a lot less of an issue using the ID allocation for a back-end form like Email Messages than I would for a customer facing one with lots of metrics and reports like Incidents. For instance, I don't know the details of your mail distribution, but you may be able to cut it substantially by turning off some notifications, creating Exchange aliases and sending ONE email out from AR System to that group vs. having the notification group in Remedy that sends a separate email to each person in the group, etc. Email output was actually the source of my testing, as we were doing some consolidation of ticket status update emails to only send one email/person/day instead of one per person/ticket/day. The solution cut the number of outgoing emails by about 85%, if memory serves, and gave the email servers some of their resources back. Rick _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
