Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent. Join the Challenge.
The challenge with using serial numbers as asset tags is that there is not agreement across manufacturers on format or standards. You may end up with more than one asset with the same serial number.
Hi, yes, SAM has the concept of user and device entitlements. However it is worth noting that in "new SAM" we use an 'allocation' to indicate that a right to use software has been granted. So the meaning of entitlement is different in "old SAM" and "new SAM".
If an asset is already defined, what happens if someone or process enters the same unique identifying information? Does this asset system prevent this entry or duplication of record?
Hi Mike, I would suggest you or your admin would set the Unique dictionary property of the asset tag field if you want to ensure that you don't end up with duplicate asset tags.
As a CMDB person, I would disagree with having ITAM personnel deciding to make a laptop asset both a Computer and a Linux Server at initial entry of the asset. Instead, stick with the "base" that you absolutely know (in this case Computer). If the laptop computer is used as a Linux Server, rely on Discovery to extend the CI record from Computer > Server > Linux Server.
Hi, Unique is an existing boolean dictionary attribute, so no need to create it. It applies on a field by field basis. I will show you how to find this attribute in the next lab if you like. Personally I was surprised it was not set to to 'true' in the baseline instance.
Also, when we look at Import Sets we will see that you can coalesce on > 1 field (coming up in the next Module).
https://community.servicenow.com/community?id=community_question&sys_id=9dda4b6ddb5cdbc01dcaf3231f961963&view_source=searchResult (specifically the link off that article)
Good point; the main thing is that the organization has an agreed upon process so that all teams interacting with CIs and Assets know where the data belongs. Having this "agreed to standard" make take some time up-front but should lead to a better building of "trust worthy data".
RFID tags are a good idea. Just be aware that the tag could be laying on a floor, so the asset still may not be where you think it is or where it is reporting.
Even with RFID tags you need to have a periodic physical inventory review to cross-validate the info you have.
Hi Betsy, I would agree - the Asset procurement process creates the Asset, which (in accordance with the Model Category) would create the relevant 'bare bones' CI, which Disco would then update with the detail (software installations, disk space, mac address etc...)
I absolutely agree that standardization and cooperation is key. In addition, it is important to determine "authoritative data sources": Where is the best information of a particular type housed (and in what source)? If the information is presented from multiple sources (SN Discovery, Legacy AM systems, SAP, SCCM, etc.), what source takes precedence?
p.s. One of the many reasons I am sensitive to people guessing about machine types was a feed that insisted a SunFire server was a "Super Computer"?!???!!!
Our CMDB person actually does this where he defined location based on IP Address. This of course is a challenge if your network admins reuse an IP range for a new location, and don't tell you.
One general word of caution about state modifications. While both States and substates can be modified, keep in mind that ServiceNow does have under-the-covers logic which does depend on certain states. While it is generally "less risky" to modify sub-states; please keep this in mind before deciding to modifying states (or sub-states).
There are many ways to do this; but mostly I'd say it comes back to process. If you have a "re-usable" consumable then one way would be to have a process that says to "put it in the cords box in stock room 1". Another way would be to not treat it as a consumable and track it as a normal asset (based on some criteria such as cost).
What is best practice for virtual servers or virtual resources. I believe when virtual resource is connected to network will be discovered and CI will be created. Will asset hardware created as well? If not, what's the best practice? Do we need to created hardware assets for virtual servers? If we create hardware asset how we are going to sync with CI. Thank you
In our environment, we setup SN Discovery to discover the physical hosts as well as the VMs (once the Discovery MID servers were enabled to access the management interfaces of the VM hosts).
This triggered asset and CI creation for the hardware assets that provide our VM solution. Worked like this across all three of our virtualization platforms - VMWare, HyperV and Xen.
Hi Turben, in my experience Consumables by definition do not get re-used, so I would say to treat reusable assets as 'ordinary' assets rather than Consumables.
Earlier, we discussed that when similar assets are combined in a stockroom, the financials of the 2 items are collapsed (such as price per unit). (See Page 78) If a transfer order is completed after an asset has combined in a stockroom - does the item use the original financials? Or the financial info that was created prior to the combination?
Example:
From stockroom A, 8 logitech mouse @ cost of $60 are combined with 7 mouse @ 35 - this now gives individual mouse cost of 6.34 ($95/15 mice)
is that new cost per item store somewhere separately from the original cost? or is the original cost per item retained?
Hi Dave, you are correct that by treating an asset an a Consumable you are deciding to track in bulk at the aggregate level, and conversely you are losing some of the detail that would otherwise be available. However if the same asset consumes >1 item of the same model you can click on the 'consumed' record (in the related list at the foot of the asset form) to see more about how the total consumption figure is made up.
Hi Julio, #me too! I was also surprised by this but I think given that you generally purchase Consumables in bulk it would perhaps not be a good assumption. I agree though it is a potential gotcha.
Regarding HW Assets for VMs: You are right in that a device with the properly enabled credentials will be discovered and CIs reflecting physical and virtual systems will be created. In my experience, HAM people created an asset record for a VM not because they were tracking the VM as an asset, but because their SAM system required that licensed software showed some type of association to an actual device/asset name for purposes of license tracking. Depending on how your Asset Management environment is structured, that will likely drive your decision.
From a CMDB perspective, if you have discovery enabled in your environment, work with your Asset Management counterparts to try and reach some agreement about your shared data requirements. From a "data trustworthiness" perspective, a manually entered VM "asset" with incorrect and/or blank serial numbers is problematic, particularly if you are sharing that information with the CMDB.
Thank you! Just tried this, and I can see how to get to the data. Really, I guess, is that consumables are tracked at total spend which makes sense. If you need line by line details, best to not use a consumable category.
Me three! But I also think that if they were ordered via Procurement...you'd have line item financial data...although that's a guess until I dig into that module a bit more
This is not handled OOB as the process can be quite different based on organization. That said, you could create a workflow that "waits for" each state and then creates corresponding tasks for each.
Hi Sandy, I don't believe there is an OOTB workflow relating to the progress transfer orders (from memory - I don't have an instance in front of me) but SN workflow would be ideally suited to adding approvals/tasks as the transfer proceeds. Just create a workflow against the alm_transfer_order table and set an appropriate condition.
Out of the box, you'll get a duplicate record. You would need a reconciliation process to reconcile the duplicates. There are queries and reports you can run to help with this.
You could also define a unique attribute on the table, such as Asset Tag, which prevents assets with duplicate asset tags from being added to the system. We have done with with success.
Hi Mary, re 2) I can confirm that Bundles are an optional feature. We will be looking at these later in the course. They are great for including related peripherals along with a main asset.
Hi Mary, re 2) & 3) ..we will see that Bundles automatically fill in the parent field so that if you assign the main asset to a user then the child bundled assets automatically follow the parent (unlike real children!) and are also assigned to that user.
