Discovery Schedule Attributes

[doug_schulze]

All, first and foremost all recognition, accolades and any potential tomato slinging should be directed at @aleck_lin . He is the author, creator and brilliant mind behind this great enhancement to our discovery product. I am just your humble messenger.

I can say that I was the genesis of this idea some 13'ish years ago when we were just getting discovery rolling I went to Tom and Aleck about the use of the Location attribute we can add to our discovery schedules.  As I'm sure most are aware that we can add this attribute to the Discovery Schedule and any thing discovered in that schedule would be tagged with that same attribute so you can "see" where your devices are within your enterprise.

I quickly recognized in my deployments that folks were using multiple ranges/range sets in the same where they were all part of a different location. Imagine a Schedule for California location but each range set might be in a different office around the state.  We really could have used an extension to set location on those sub ranges so that when we ran the California Schedule each range set could have its own specific location value. Well unfortunately in the startup world there were bigger priorities and it just kinda went by the wayside...Until today!

Aleck went and made that one idea into a really incredible useful way to add nested attributes from the schedule down to the range set and range item. And its not just Location, its really any attribute, text value, related item that are available in the existing CMDB that can be added to the discovered items.

Imagine being able to not only set location but managed by, tag values, support group, cost centers, text fields.. And not only that they are nested and take higher precedence the lower you go in your custom attribute. Imagine my case scenario. My schedule has the overall California location but my Range Sets each have their own city location and their own support groups for local contacts. You name it this update set helps provide for all that to help manage CIs. You will have to expose the new related lists in the discovery schedule, range sets and items...

Again, ALL props and recognition goes to my very good friend Aleck Lin, no one has been doing discovery longer in these parts then the two of us and great to see there are always new and exiting things we can bring to our Discovery Family out there..

And of course, enjoy yet test , test , test.. this is not supported so you cant call our tech support for assistance, its community driven and you are responsible...But it is pretty straight forward, nothing too magical about it other than Alecks brilliance.

[Noelene Dwyer1]

Great idea!  Makes managing large IP Address networks across multiple locations and subsidiaries much cleaner. 

[Sharon Hobart]

@doug_schulze I've up-voted it!

[pratiksha5]

This needs to be implemented!!! I am going to try some use cases for sure. Thank you for sharing it. 

[ZK1]

@doug_schulze can you please send discovery custom attributes file in pdf? Thank you

[Henrik Jutterst]

Hi all. I remember up-voting an idea about this while ago, but recently I saw a post in Community that basically did what I was asking for in terms of custom attributes to fields.

Idea: Idea: Discovery Schedule/Range item custom attributes 

But this looks really interesting and even more intuative to what I was looking for in the first place!
Awesome info!

Here is the "old" way on how I used to set this.
Discovery - Populate custom attribute based on discovery schedule

/Henrik

[MrSmitty]

I'm curious what size networks people are using that would require them to do this.  I create discovery schedules by location.  I'm dealing with reconfiguring what was previously setup before me and it was all just /16 networks with no relation to location records at all.  I've been working at converting these to networks that are more like what is actually configured in the network devices themselves, and tying the schedules to location records.  

[Henrik Jutterst]

Question:
Are there more here than me that get these errors when doing preview to XML-file? Did you all just accept it and committed it?

ping: @doug_schulze 

Running this version:
Build name: Washingtondc
Build date: 07-12-2024_0853
Build tag: glide-washingtondc-12-20-2023__patch4-hotfix1a-07-01-2024

Or are there other ways to add this functionality to ServiceNow?

[Bobin]

This is perfect @doug_schulze and just the thing many of us are looking out for. Trying this out now.  

[Henrik Jutterst]

Let me know if you encounter any of the issues that I faced from my screen shot @Bobin 

I didn't follow through and was hoping for some user feedback, if it was just my instance or what people did with issues.

Kind regards

[doug_schulze]

Henrik, yes those errors are expected, you can accept the changes. Or better yet, its coming out of box very shorty through a store app so keep an eye out for that so its fully supported