My guess is that if you imported some SVTs they are somehow in conflict with the existing z filters. There are definitely z filters active if SVTs are attaching to new incidents. There is a table that records all of the GUID relationships between SVTs and z filters, that you may need to audit (a pain since any SVT will have several z filters) and you know there has to be a disconnect if the SVTs will not Build successfully. Reason #1 that we did an upgrade from SLM 7.1 to 7.6.04.
If you can figure out which filters are "associated" with the bad SVTs (and they are not properly associated if they won't build) you can first disable the filters which should stop them from attaching to new incidents. Later you can try deleting them, and MAYBE that will let you do a new Build on the SVTs. On #2, again, you need to see if you have more than one filter active for the same SVT. My experience with importing SVTs in a test environment (SLM 7.0, 7.1, 7.6.03 and .04) has always been horrific, so I have gone out of my way to avoid it. The relationship between data and workflow is impossible to migrate, and any two SLM servers are going to generate record/workflow combinations that are going to conflict with each other. Also, I did test server groups (and abandoned them in 7.6.04), and I seem to recall that like AREmail, the SLM services could only be running on one of the servers or they would duplicate escalation actions. Just some ideas... Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ On 2/11/12 10:11 AM, "Dan Miller" <[email protected]> wrote: >Hi forum > >I have 3 fairly major issues in SLM, and I am hoping you can help. I >thought about logging 3 discussions but I thought I would start withon, >and then split if need be. > >Remedy version: 7.6.04 SP2 >Platform: Windows 2008 R2 64bit >DB: SQL Server 2008 R2 64bit > > >1. I have some SVTs that are set to disabled and then deleted from SLM >console, but they keep attaching to new incidents. they were imported >previously and had index problems when trying to modify them in any way >at all (classic 302 error). These SVTs were imported and have caused all >manor of problems every since. I would love to Kill them with a >control+D in the SLM tables, but I know that will cause hell in the >hpd:helpdesk form for incidents that reference them, so how can I force >them out of the system when they can not be built due to index and unique >identifier errors? > >2. have a milestone with action to fire an email when incident is >logged. it fires when the incident is logged, but then it fires again >every one hour.... also, every time it fires twice :-~. The milestone >is very simple. I only have email engine running on one server in the >server group. Any thoughts on this? It runs literally every hour. I >have not tried any other actions yet, so I am not sure if it just fires >every time a breach escalation fires (i.e. 25%, 50% which happen to run >very hour as it is a 4 hour fi SVT) > >3. I have a problem that there is a known defect for). When you add a >new > >Cheers >Dan > >__________________________________________________________________________ >_____ >UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
