Since the whole database grew from a very simple approach to something bigger, Servers migrated to Servers and Equipment. The idea and thought behind it is rather simple – you can make a huge database application that divides everything in specific tables and input forms, likely resulting in multiple search forms or at least complicated data searches or you keep it simple.

What do most businesses have – a IT helpdesk, Sys-Admin level and Management level. While the helpdesk will deal with workstations, the sys-admins deal with all the server and network equipment while the management oversees those tasks. This might be simplified but is true for the most part.

So Sys-Admins would work in the Servers and Equipment module for the most part. This made it just logical to abuse this module for more then just servers.

Enough about on how this emerged, lets dive in.

You can chose a Type like virtual server, physical server from one of the many pre-configured entries, give the entry a hostname and define information like deployment status, department, location, etc.. basic information about software and hardware.

Further is there a relation to VMware vCenter servers, datacenters and clusters.

Information on if the system is backed up – what will expect a weekly review entry in the backup-module and information about the warranty that might cause it to show up in the main menu when the warranty is due soon.

You can add MAC addresses and see assigned IP addresses.

Any local harddrive / SSD / RAID / partition and volume information can be added in a simple flat table.

The system will show you related databases and what it might know about backup reviews – if you use those.

Software can be related to server and incidents be reviewed.

If you need additional field, you can simply adjust the tables and server-views and add them to the form.

Additionally you can TAG servers to group them and relate them to the bigger picture as well as add additional notes to them as needed to document special settings etc.

Data field and reference overview

  • type
    • a sub table with types like switches, physical server, virtual server, firewall, etc.
  • Deployment Status
  • Hostname, AssetTag
  • Powered-on
  • Description / function and Status Notes
  • department
  • location
  • OS / AntiVirus
  • vCenter / vCenter DataCenter / vCenter Cluster
  • Domain
  • CPU Model / Speed / amount and cores
  • RAM
  • JDE relevant (might not be useful – but a nice indicator – you could rename it to SAP etc.)
  • WSUS (is this system updated by WSUS)
  • backed up / backup status last reviewed / back notes – why is this system not backed up e.g.
  • deployed date / ticket
  • make and model as well as SN respective ServiceTag and ExpressCode
  • purchase date, ticket and PO reference (if the PO matches a PO in Purchases it will be auto-linked)
  • Warranty Company (none would remove it from the warranty expires list on the main form)
  • Warranty EndDate and WarrantyPartsTime respective the type of warranty e.g. 24/7/4 or 8/5/NBD etc.
  • Archived To Tape
    • a TAPE number / description where this system was archived to before it was eventually retired
    • those tapes are normally stored forever or long time off site in case the system needs to be recover
    • this helps to identify and quickly find the right tape
  • retired date and reference
  • finance reference – should be a reference number to this asset from your finance department in case they get audited in order to quickly relate this asset with their numbers or indicators
  • confirm device exists
    • an ongoing inventory – this helps to determine when the system was last seen
  • MAC addresses, IP address references and hard drive respective raid drive documentation
  • relations to
  • data from the automated backup reviews
  • notes and checklists
  • previously assigned IP addresses
    • this helps especially if the system was retired to find out what IP was once assigned to it in case you need to bring it back