One warning – be careful about using custom alert fields. If you extend this process to annotate alerts from certain management packs (notably Exchange 2010 MP) that use custom fields for alert correlation, your process might overwrite the Management Pack’s data or vice-versa.
Brandon Ryan ClearPointe From: [email protected] [mailto:[email protected]] On Behalf Of Henrik Andersen Sent: Thursday, March 19, 2015 5:34 PM To: [email protected] Subject: SV: [msmom] Adding URL To Server Properties: 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]> [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]> [mailto:[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]<mailto:[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.
