Long standing customers often benefit from a review of new standard settings and features, as well as configuration best practices. This Health Check is a service offering that includes a full review, analysis, and advice on your ITAM instance. The goal of this session is to review the system settings and customer utilization of primary features, in an effort to identify any potential optimizations. This document endeavors to walk through the major points covered in such a session. You may use this at a high level to self evaluate your instance without consulting with one of our profesionals.
User Interface
Long standing customers may be most familiar with the KeyConfigure desktop application. This has largely been replaced in daily operation by the web interface. While there are still some under the hood functions only in KeyConfigure, all new features added in recent years are only in the web. If you are not using the web interface you are missing out on the majority of the new features. Some highlights include:
- Extras
- Hardware Replacement
- Loaner Checkout
- User Assets
- Windows Upgrade
- Actions
- Forms
- Dashboards
- Graphical Histogram reports
- Advanced list navigation tools
- Advanced Filter builder
- Modern interface
Settings
We often find older implementations have not enabled new features that are on by default in new installations. These are all listed as Topics under the main Settings page in the web interface.
PRS
By default all 3 options on this page should be enabled. This allows automatic daily checking of PRS for new Product definitions and their automatic addition to your server. It also allows any manually created Product definitions to be sent anonymously to PRS so that we can become aware of them, and potentially enhance the catalogue. You should ensure that the Last Update has a check and shows the current day, indicating these checks are working on the enabled daily schedule.
Audits
All items on this tab other than the Throttle setting should typically be enabled. These settings allow for the server Audit to follow the PRS check resulting in Install counts in your Software page, as well as accurate Audit Reports and software on Maps.
Reschedule Audit Every sets the cycle that clients report new audit (hardware and software inventory) data to the server. Very broadly speaking, any site with 10000 clients or less can usually set this to daily without concern. Larger sites may need to consider network and server resource impact, although hosted customers need not worry about this. More frequent audit cycles ensure that your Audit reports are up to date. A common example is if you push out software updates by SCCM or similar systems and want to check if it worked on all systems, you can get much quicker results with a daily update schedule.
Miscellaneous
The two toggles at the top of this tab should generally be enabled to allow for gathering more accurate status information and more granular Login report information. Tracking startup and shutdown allows you to accurately show if computers are Available or Off in Availability Maps. Tracking idle events (default 15 minute idle timer, set as desired) allows you to see in Login reports the difference between logged in time vs active and idle time.
Email
A lot of features of the platform depend on being able to send email. If you are an on prem customer, ensure you have the mail server settings configured so email can be sent. These settings are not shown for hosted customers as we handle the SMTP service. It's highly recommended that you enable the daily status messages and status/warning messages and set an address to send these to. This can be one person or an address that is a list in larger organizations. By having email configured, you can then also leverage Scheduled Reports and Purchase expiration notices in the platform.
Computer ID Types
Before going further, it is important to talk about an extremely important fundamental setting, the Computer ID Types. This sets the order of what Computer records use to generate their unique identifier in the database. In decades past, MAC was a popular choice as it was reliable and unique. However for years this has become problematic because there are laptops and tablets that do not have a built in NIC. Instead, you find things like docks and dongles being used which can move around. You may image a number of systems in a workroom on the same dock, resulting in all the systems sharing the same record and replacing each other. Computers may fail over to a second MAC, or ultimately another ID type when MAC shows to be unreliable, resulting in multiple records for one computer, which also consumes license seats.
The result of this shift in technology is most customers find either Serial to be the preferred choice. Serial allows for a unique identifier for lifecycle management. Using Name as a fallback after Serial then accounts for Virtual computers. Custom hardware may not have an OEM Serial, so Name also catches those.
We are happy to discuss these choices in detail and advise on how to change your ID type order. DO NOT CHANGE THE ORDER WITHOUT CONSULTING WITH SUPPORT. There is a process for modifying cleanly and updating all the linked records in the database using an offline utility. Simply changing the order in the UI can result in loss of reporting ability and more duplicate records.
Backups
In the distant past, servers were physical systems with limited backup capabilities. The Backups settings allowed you to have copies of the database made to an internal folder on a daily or weekly basis. This has long been supplanted by virtual hosts that have infrastructure snapshots, and much more robust data integrity and robust database repair tool. If you still have Backups enabled, you are most likely just wasting drive space and backup space in a structure where this redundancy is of no use.
Account Setup
If you are still using Internal accounts in an organization where more than a couple people have privileged access to the platform, you should consider leveraging your organizational authentication mechanism. Using Azure auth offers not only consistent accounts but also SSO in browser. Automatic provisioning of accounts based on domain group membership to control permissions allocation is also a great benefit.
Updates
The platform has now long had the ability to have clients silently update themselves. You have only to Accept each new release for this to occur. This allows you to still vet the release in your environment, but not have to bother with using another deployment system like InTune to update the clients.
Computers
For long term customers, good housekeeping of Computer records becomes increasingly important. This is a topic which spills over into related items further on.
Divisions
Some sites may still be manually organizing Computers into Divisions. For on prem customers with a well organized Active Directory, it may be you'd like to simply have ITAM replicate that folder structure. This can be done using Client Authentication. Other methods of automatically organizing computers include:
- Using Rules to sort computers based on Name or other attributes
- Using Actions to sort computers based on Name or other attributes, including the ability to leverage regular expressions and lookup tables
- Using boot time scripts to populate registry keys with meta data that can then be leveraged by the above when read in by the agent
- Using an InTune attribute to populate the Division
Login States
Some customers make the mistake of deleting Computer records when machines are retired from service. There are a couple reasons this is not advised. Deleting the computer record only deletes that record in that database. All the Audit and Usage records, which are the much larger chunks of data, remain in their respective databases. You also lose the ability to cleanly report on the historic Usage data of that computer because the pointer has been removed. This can further result in different reports seeming to show conflicting data, because in some reports the pointer is not relevant so the usage is still counted.
Generally speaking it is advised to move retired Computers into the Dormant login type. This allows you to retain the Usage data and report on that history, but removes the computer from Audit results and makes it not take a license seat. Further, if a Dormant computer were to connect to the server, it moves to Leased. This means the presence of any computer in Leased is a red flag to check why a system has returned from the scrap pile. You can also use the Excluded state to prevent a system from returning to use and showing up in Leased. This is typically for a "stolen" computer situation. You can further leverage the Lifecycle Stage options in the Asset Pane of computers to mark if something was Salvaged, Disposed, Missing, or is simply Stocked in a dormant state awaiting possible redeploy. Imported records don't need to be moved because they don't use license seats. In fact they can not be moved to Dormant, but they can be moved to Excluded if you want to use this as a "retirement" indicator.
Virtual Records
When managing virtual systems you usually want to create Rules that set them to Do Not Audit and Leased. This is especially true of thin sessions given they really are all the same computer serving those sessions, but it can also be true of VDI pools where the systems are wiped and cloned between users. If you had persistent virtual machines, you may want to audit those as they could have other software added just like a physical machine. The combination of no audits and leased timer allows those records to go Dormant in only 4 hours when Thin, and 1 week if "thick". These settings allow you to run virtual environments with lower license counts than you might need with physical hardware, and without having software inventory that is not relevant.
Note that it's not recommended for many environments to put physical computers in the Leased state by default. Remember a Leased machine that goes Dormant does not appear in your Audits. If a machine is off the grid for over a month and vanishes from your reports, your data is incomplete. Once that system comes back, the sudden appearance of old inventory can be confusing. You may be tempted to run all computers in a Leased state to optimize seat use in a concurrency model. However as mentioned the implications of this choice on your Audits (software inventory) need to be carefully considered, along with the lack of any flags when something wanders off unexpectedly. Right sizing and allocating your license count for your environment while accurately taking advantage of our features is important. Again, we are happy to discuss your use case to ensure the best choices.
Audit Data
As mentioned above, while moving a computer to Dormant (or deleting it) will remove it from Audit reports, the audit data is still present. This means over years of cycling out hardware, you may have a large amount of stale data that no longer serves a purpose. This extra data takes up space and slows down reporting. Fortunately there is an easy mechanism to clean house. When you perform a Major Upgrade (e.g. from 8.0.x to 8.1.x), the ksdbconsist utility (on Mac or Windows) will have an extra option in the window when it pops up during the upgrade. This option allows you to not migrate the Audit Data in the upgrade. Effectively this means all the software inventory is wiped clean and you have a fresh start.
The impact of this choice should be carefully considered. All clients when they report in to the server will on the standard cycle (also discussed above) submit a new Audit. You can also request a new audit immediately from one or more computers from the context menu. This repopulates your Audit database with only relevant information for active computers. Keep in mind that until every Dedicated (and Leased) computer returns a new audit, they will not have any audit data. As such an Audit Report should be considered carefully as to whether or not it contains all the data you are looking for. Other than this rebuild period, the only other consideration is the niche Audit Delta report. If you truly wanted to report on any software changes from deployment to present, you would of course lose that in the purge and it starts over from the fresh audit.
Products
Assuming the above General PRS settings are in place, the majority of common software should be automatically recognized by our normalization. While it's possible there is software not in our catalogue, this used to be more common. Keep in mind that if you see a new version is missing from your Products, it's usually best to contact us to ensure we are creating the new version definition. If you make your own, it will cause conflicts when we put out ours.
Manual Duplicates and Cleanup
Long time customers will likely have an array of old manual products created. Most of these should be cleaned out so you start using our PRS definitions instead. Manual products are easily spotted in the Products window of KeyConfigure by their lighter colored icon. You can also use the Filter for Created Manually by Admin to see them all at once. Ensure there is a PRS definition and then simply delete the old manual product. A useful tool is the Product Suggestions (PROD) report under Miscellaneous. This compares manual products to PRS products and shows you duplicates and the suggested equivalent to assist cleanup/conversion.
NOTE: this does mean that a Product level Usage report will NOT show the usage gathered under the old manual product if it's deleted. You can still report at the Policy and Program level however, and it will be cleaner moving forward. The final decision on this cleanup is of course up to the individual.
Manual products with no Installs count are likely very safe to delete without consideration for old data, but one must consider possible historic information they may want to report on. Also pay close attention to the icon. If there is no little black gear at the top of the icon, then the Product is actually empty of any Program and serves no purpose.
Ignored
An often overlooked and underused feature is the Ignored category of Products. Some products are ignored by default from PRS for a variety of reason. While this is our "advice", it is not mandatory in any way. Sites that want a full inventory of all installs will likely not want to leave these items in Ignored as that prevents collating install counts. Review the Ignored items and anything you'd like to have tracked in your Audits should be moved to Related. In the next Product Audit any items that have installs will be moved to Discovered and those install counts totaled.
In the other direction, it is sometimes useful to ignore Discovered items to make your installs accurately reflect your Purchases. The most common example of this is the Adobe suite. In the event you deploy the CC client and allow users to self install the applications they use, it's possible a user only installs Photoshop and nothing else. In that event, we determine Photoshop is the installed Product. However, the actual license is for Creative Cloud, something we can't know automatically. So, if you do not buy stand alone Photoshop seats, simply move the Photoshop Products that show Installs to Ignored. In the next Product Audit cycle those installs will instead be attributed to the Creative Cloud product. Repeat as needed for anything else in the suite, or other suites like Microsoft or AutoDesk. Be careful not to ignore anything that does not appear in another Product if you wish to have it audited. You can open a Product to see the Programs it contains, then open those Programs to ensure they are contained in other Products before ignoring one.
Note that managing Ignored or Related status can be done in the Mange page in the Web UI as well as the Products window in KeyConfigure.
Also note in some educational use cases, because you have an Adobe Site license you may not care about Creative Cloud as a suite for license tracking, but rather the individual apps for visibility on Maps. In that case reverse the above and ignore Creative Cloud to force the installs to be broken out into things like Photoshop and InDesign installs.
Policies
Where your Audit reports will show you the Installs of Products, including when an item was last used, you have to have Policies for anything further. In order to know who used what when where and for how long, you need a Policy to at least Observe that Usage. You can also Manage software if needed with a variety of options and fine grain detail.
Families and Observing
Family Products have been in the platform for many years now and combined with Observer policies make tracking Usage very easy. In fact, in the web interface this has been distilled down to a single click option for each Product. A Family product has a 4 square icon and is a "wrapper" for all the Editions of that Product. By tracking the family in a policy, you track every Program of every Variant in every Product contained therein. This means you can then report on the Creative Cloud Policy for example to see ALL Adobe use of any app of any version, or report on the Products to see 2023 vs 2024 etc, or report at the Program level to see Photoshop 21 vs InDesign 19 etc. It also means when a new version of the Product is put out, you are proactively tracking it because it will become a member of the family.
Many older on prem instances will still have more granular Policies by Edition, as well as those Policies being Manage instead of Observe. If you have not yet "upgraded" your old Policies, please see our knowledge base article on the topic.
Make Good Choices
An important reminder about Policies, especially in context of current features, is to make good choices on what to track. While it's easy to just click all those green dots, you likely don't want to just observe everything. If all you need is to know what software of what version is installed where, you have that with the Audit data. Usage data is generally to inform how much use you get from software that has been purchased. Tracking usage of free applications is unlikely to inform decisions, so that data is simply "clutter" that slows down reporting of the useful data. It's also generally not advised to track usage of system utilities like antivirus, because that's not user based usage that would again inform any manner of purchasing. Lastly, any software that runs at login (e.g. utilities like Box) is not useful as usage would be 100%. Within these contexts, make sure that when you choose to observe a Product in a Policy that it's a good choice. Also consider if there is any use in tracking things like site licenses. If you have an entitlement for Office or Creative Cloud for all members of the organization, and that's not going to change, then that's a lot of data that is not informing any cost savings.
This is also not a one time decision. It's recommended that you review your Policies on an annual basis to verify if continued tracking is still useful. If for example you were tracking Adobe apps to see if you can downside and determined you can't, is it still worth gathering more data moving forward?
Unused
Another housekeeping item we see on older servers is cleanup of unused Policies. If a piece of software has not been used for a couple years and you have no Installs of the Product, one questions if the policy is still relevant. If reporting on the historic use of that Policy is unlikely (remember you'll always have Program level report data if nothing else, regardless of deleting old Policies and Products), then you can declutter your Policies window by deleting these old items. You can always run a Chart or Usage report on Policies for say the trailing year to find things with zero use. While they don't cause harm, they are perhaps an eyesore. Also, you may determine that a clean up of old Usage data is prudent. This leads us to archiving and purging.
Archive
We mentioned above the ksdbconsist option to not migrate Audit data in a major upgrade. Any time you run ksdbconsist (which is automatic in any upgrade, major or minor) you can choose the option to Archive Usage prior to a certain date. This takes all data in the Usage database prior to that date and moves it to the Usage Archive database. There are two impacts from this. The first is that the service can run more efficiently because the active database is smaller. It also means that any Usage reports that are of that date and newer run faster as there is less data to parse. The second impact is that if you chose to remove that old data permanently, you can simply delete that archive database on the server. Note if you run a report that goes back far enough, the archive will be called for so you can still report on that old data, it will just take longer.
Hosted customers should contact support to discuss this kind of historic cleanup.
On Prem Files
While we're in the file system of the server, there are a couple other items you can purge to clean up space. Again, be very careful when deleting files from the server!
Legacy Logs
In the Log Files folder of the KeyServer Data Folder you'll find all our legacy logs. Modern logging actually goes into the diagnostic.log file in the main data folder. It is very rare the legacy logs are needed, and we have seen some cases of 10 years or more of log files built up. You can safely delete all the files in this folder, leaving the most recent one if you wish.
Old Folders
When you upgrade the KeyServer (and KeyConfigure presuming you have that on the server as well), you'll find a server old (and/or admin old) folder in the Sassafras K2 install location. You can always delete the admin old folder, though it's rather small. The server old folder can be quite large as it's the entire old major version of the server. In some cases you may have multiple date stamped old folders from several past upgrades. Assuming you have been running the current version for some time without issues, it's safe to say you don't need the full version rollback data any more and can delete these folders.
Backups
In years past some customers would use our internal file backup feature. This simply copies all the database files into a backup folder inside the KeyServer Data Folder on the schedule configured. This is largely an outdated and unneeded mechanism these days. Most servers are run in a virtual environment that have nightly snapshot/backup schedules. In such an environment, if you were doing a daily internal file backup and then a daily server backup, you have a full week of backups updated every day. This is obviously a huge redundancy and can waste tens of gigs of space in the infrastructure.
Check if you have such a backup configured in KeyConfigure - Config - Backups and disable as needed. You can then go into the Backup Folder in the KeyServer Data Folder on the server and delete all the sub folders with day names. Be extremely careful with this so you do not delete critical data!
While you're in that backups folder, check the timestamped folders in it. These are created when ksdbconsist fixes any issues. If you have folders that are older than a few weeks, one can safely assume the server is running fine and the old backup is no longer needed. On older servers there may be several of these dbconsist folders that can be removed, and if they contain Usage and/or Audit data they can be rather large. Again, the contents of the Backup Folder are generally considered safe to delete, but always be careful about what you are deleting on the server.
Closing
We hope the information in this article has been useful in guiding some general review and cleanup of your TDX ITAM Server. Remember our support team is here to assist with any questions, and we're happy to schedule a session to walk through this process with you.