Correct. Orchestrator integration pack. We are currently using Orchestrator to process all alerts and open/close incident.
Cesar A On Mar 19, 2015 3:34 PM, "Henrik Andersen" <[email protected]> wrote: > Ups! Slight misunderstanding, I think Cesar meant SCORCH Integration > Pack, not Server IP address. > > > > Is SCORCH an good idea? I think it depends a lot on the alert rate and if > you depend your alert enrichment on a fairly complex animal(scorch) > > > > I have uses an custum coded C# windows service to populate the custom > fields with information fetched from a CMDB (both on 2007 and 2012). > > > > If you don’t wanna follow that path, there have been posted a couple of > solutions > > > http://blogs.technet.com/b/kevinholman/archive/2012/09/29/opsmgr-public-release-of-the-alert-update-connector.aspx > > > > http://stefanroth.net/2012/04/17/scom-2012-using-alert-customfields/ > (based on powershell) > > > > > http://blogs.msdn.com/b/steverac/archive/2010/08/17/updating-custom-alert-fields-using-subscriptions-and-powershell.aspx > > > > Oh btw, it’s my experience that for some kind of alerts, you do have to do > some coding to get the related server. > > > > Happy alert enrichment > > > > Henrik > > > > *Fra:* [email protected] [mailto: > [email protected]] *På vegne af *Orlebeck, Geoffrey > *Sendt:* 19. marts 2015 21:22 > *Til:* '[email protected]' > *Emne:* RE: [msmom] Adding URL To Server Properties: > > > > I haven’t gone down the SCORCH path (have a test VM stood up, but no > Runbooks yet). > > > > Unfortunately, the SCOM IP would not be sufficient, although the hostname > would be. Some additional details that may clarify the picture. > > > > Support site (example): http://techsupport.domain.com > > Server specific URL (example): http://techsupport.domain.com/search.asp?e= > 1234 ßThe ‘1234’ is a unique number assigned to each server in our prod > environment. > > > > Now, this is all just theory, but if I could statically set the “ > http://techsupport.domain.com/search.asp?e=” and append the URL with the > $Variable for the unique ID then that $Variable value could be populated > from wherever I can pull it—a registry key, a table in SQL, etc. I don’t > care where that value lives, so long as I can add it and it will remain > with the server for its lifecycle in SCOM/SCORCH. > > > > We could potentially use the hostname of the server, however we have to > drop the domain portion as that won’t match in our system. All servers are > entered as “Server01” , “Server02”, etc. If we enter “Server01.domain.com” > it will fail. So if there already exists an entry for the hostname (without > it being the FQDN), we could leverage that as well. > > > Not sure if that’s entirely clear, but hopefully it is. If not we can > discuss further as we are trying to get our Helpdesk into a workflow of > self-sufficiency when it comes to deciding on who gets what calls relevant > to a raised alert. Right now they call supervisors because the supervisors > have the working knowledge of what admins support what servers. If we can > input this URL so they can have a one-click experience that tells them who > the primary admin is, that will go a long way to ease some of the workflow > burdens we are facing. > > > > Thanks, > > Geoff > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *elsalvoz > *Sent:* Thursday, March 19, 2015 12:59 PM > *To:* SCOM List > *Subject:* Re: [msmom] Adding URL To Server Properties: > > > > You can accomplish this by using orchestrator quite easy with scom IP if > that's an option. > > Cesar A > > On Mar 19, 2015 12:08 PM, "Orlebeck, Geoffrey" < > [email protected]> wrote: > > We have an in-house website that contains information about all servers > and any special support instructions (who to contact, special login, etc.). > Each server has an individual URL unique to itself in our website. I am > trying to figure out a way to populate that URL into an alert when it is > generated from a server object. I’m not even sure where to start as I see > custom fields within specific monitors, but this is at the server object > level. So, in theory, if a service is running on Server1 and it stops, > raise an alert and within the body of the email have the URL we specify > somewhere in SCOM for Server1 to be included. > > > > Is this really possible? Or is it going to have to be a scenario of > creating a Management Pack and using registry values or some other way to > uniquely identify the information? And if we go down that path, can we > create a variable, akin to “$Data[Default='Not > Present']/Context/DataItem/AlertName$” that can be populated inside the > E-Mail channel? > > > > I’ve read a few different blogs about extending classes and such, just > wasn’t sure if I **had** to do that for this sort of functionality. > > > > Thanks. > > > > -Geoff > > Confidentiality Notice: This is a transmission from Community Hospital of > the Monterey Peninsula. This message and any attached documents may be > confidential and contain information protected by state and federal medical > privacy statutes. They are intended only for the use of the addressee. If > you are not the intended recipient, any disclosure, copying, or > distribution of this information is strictly prohibited. If you received > this transmission in error, please accept our apologies and notify the > sender. Thank you. > > > > > > Confidentiality Notice: This is a transmission from Community Hospital of > the Monterey Peninsula. This message and any attached documents may be > confidential and contain information protected by state and federal medical > privacy statutes. They are intended only for the use of the addressee. If > you are not the intended recipient, any disclosure, copying, or > distribution of this information is strictly prohibited. If you received > this transmission in error, please accept our apologies and notify the > sender. Thank you. > > > >
