These are personal for all of us, and trade secrets that help us be the awesome engineers that everyone hates... but I'll go first and share some critical ones that I use for every place I implement... and at the same time, ignore the fact that integrating/autopopulating them isn't supported and thus I know if I bork the database, it's all on me and not supported.
Custom1 = Environment (Production, Test, QA, Dev, POC, Lab, etc) - gotta be able to know whats what in your environments. For me, its custom1 first choice.
Custom2 = Application (Veeam One, Utility SQL Server, Corepoint Engine, Outsystems Front-End, Varonis Archive). No-brainer, gotta know what stuff is being used for. It's generally one or to things for larger businesses. This is for servers really.
Custom3 = Application Family (Veeam Backup, Utility, Corepoint, Outsystems, Varonis). Guess what? now we can find all Production Veeam Servers (Backup and Replication, VeeamONE, whatever they call the ones that process the backups..) Varonis servers (archive, scanning servers, etc)... or all Test Corepoint Servers (database, front-end servers). Boom.
Custom4 = Application Contact(s): (what group or person to contact about the application or application family - the administrators or experts) If this is maintained in an ITSM or something, I pull that information from that app and populate this field. If it isn't, well, I ask around, import from spreadsheets, or (yuck) manually put the stuff in. You gotta do what you gotta do. Automating means that if the folks update their ITSM application, it will update Lansweeper accordingly. If you want to maintain it in Lansweeper, most ITSM products allow for imports so then you can have ITSM updated accordingly via automated fashion.
Custom5 = Application Support Group (what group is front-line support if there's a problem). Same as number 4. See where I'm going? ITSM becomes accurate and actionable.
Custom6 = Criticality (1 - Critical, 2 - High Importance, etc.) This is for a ton of reasons. Know what HAS to be backed up, and frequency.. what HAS to have redundancy or a Disaster Recovery plan for, what gets escalated IMMEDIATELY in alerts/ITSM/etc... what has to be white-gloved for upgrades/updates/maintenance.... what needs the best hardware/resources to ensure uptime and performance, again also making ITSM more functional.
Custom7 = Backup Status (I populate from backup systems via API/PowerShell/SQL/whatever.. could be a Yes/No kinda thing, if you can import last success/fail and a date, you can assume the Yes/No and save a field). If you don't feel like parsing and converting string to datetime for reporting, you can use a custom field for the last success date for easier reporting. Yes, its all stored in Veeam or Cohesity or whatever but who wants to check that all the time or trust the backup folks to be looking at their reports and fixing stuff - as an Admin I am responsible to make sure my stuff is compliant. Want to help the backup admin? Make a report that emails them and make the CRITICAL PRODUCTION send stuff to them daily and bug the heck out of them. If you're the backup admin, now you know what stuff to focus on first. Since it's in Lansweeper, everyone can see it so you're shamed into fixing it! Again, ITSM becomes more actionable.
Custom8 = Monitored (automated from the monitoring system via API or a respective Powershell Module) Could be a simple Yes/No (if it aint in the data returned, it aint monitored). Use in cunjunction with other fields and report on PRODUCTION CRITICAL STUFF that's not being monitored! Again, shame is involved and you now know what to remediate first. Bonus points, I use the reporting to then pass to the monitoring system and add the suckers to monitoring. Since you have two-way communcation now, it falls off the report, and again you're awesome and your stuff is monitored, and most importantly you can shame whomever brought a production server or SD-WAN device online and forgot to add it to monitoring.
Custom9 = DR Status. (grab it via automated fashion where you can... manually input where you can't) Now you can find production critical stuff that doesn't have a DR plan set up.
These are the must-haves when I implement Lansweeper in a medium to large environment.
Custom fields are super easy to report on (most all the reports have tblassetcustom already in them already)... and easy to make actionable items - servers missing the details (no environment defined, no application defined, no or failed backups, etc.) - make dashboards, make email reports to appropriate groups/people... the use cases go on and on - knowing what is important and less important also allows you to free up valuable infrastructure resources such as SAN/NAS high-tier storage, server CPU/RAM resources, etc... saving a ton of money.
OK - I dare you to share some of yours.
I'll give it a go too with some of my most important on-prem custom fields 🙂
Custom03: OT Vendor (eg. Honeywell, Schneider, Siemens, AspenTech, ...). This is different from the actual (scanned) PC (or other device) manufacturer.
Custom04: System Responsible (who to address if something happens with the group of devices)
Custom 05: System Administrator (who to address if something happens with this particular device)
Custom 06: Network Administrator (who to address if something happens with the subnet/switch/network this device is connected to)
Custom08: System Type (eg. Distributed Control System, Lab Automation, Logistics, MES, Mobile, Building Automation, Camera, Security system, ...)
Custom10: Plant Name (as we use Lansweeper in a production environment with approximately 40 plants.
Custom13: Max Downtime (how long may the device/network be down before emergency measures must be taken in case of planned or unplanned changes)
Custom14: Outage result (what to expect when the device is unexpectedly down, which measures must be taken)
Custom18: Purdue Level (as we're talking about OT systems, Level 1, 2, 2.5, 3, 4 or 5)
Custom19: Maintenance Window (shows me when the PC will go down for updates, for this to accomplish I created custom assets for each Maintenance Window containing the time and period of the Security Update window).
These custom fields make it very easy to do enhanced reporting in PowerBI (via XLSX import) with Row Level Security (eg. System Coordinators only have access to the assets where they are responsible for).
2) System ID: - Manufacture's serial number if different the the auto-populated one.
3) My Serial #: - Used for my internal tracking (yymm##) ## being build/install number.
4) KB Link: - link to KB article if warranted. Useful for linking to our robots, manuals and the such.