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]] 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.
