Long standing customers often benefit from a review of new standard settings and features.
As part of annual maintenance, Sassafras customers can benefit from a configuration review session. 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 your leisure rather than scheduling an interactive session with our team if you prefer. Otherwise, please contact Sassafras Support if you'd like to schedule a review session with one of our technicians.
We often find older implementations have not enabled new features that are on by default in new installations. The KeyConfigure -> Config -> General Settings are our starting point for this. The following defaults are recommended:
By default all 3 options on this tab 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 Sassafras can become aware of them, and potentially enhance the catalogue. You should ensure that the Last Update has a green check and shows the current day, indicating these checks are working.
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 Products window, as well as accurate Audit Reports. Further details are in our documentation, and we're happy to answer any questions.
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 3000 clients or less can usually set this to daily without concern. Larger sites may need to consider network and server resource impact. More frequent audit cycles ensure that your Audit reports are up to date. Note the default for safety is 2 weeks. 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 have to wait at least 2 weeks if that is your audit cycle. If this is daily however, you can get much quicker results.
The two checkboxes at the bottom 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.
A lot of features of the platform depend on being able to send email. In KeyConfigure -> Config -> Alerts and Status -> Email, or in the Web UI -> Settings -> Mail, ensure you have the mail server configured so email can be sent. It's also recommended that you enable the daily status messages and set an address to send these and other critical alerts to. This can be one person or an address that is a list. By having email configured, you can then also leverage Scheduled Reports and Purchase expiration notices.
Before going further, it is important to talk about an extremely important fundamental setting, the Computer ID Types. This sets the precedence of how Computer records are uniquely identified in the database. In years 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 or Computer Name to be the preferred choices. Serial allows for a unique identifier for lifecycle management. Name allows for easy rollover of labs where names are reused, but while Maps don't have to be updated if systems replace each other, you lose the lifecycle management. That is, Serial is more of a logical asset tracking, while Name is more of a functional asset identification. Custom hardware may not have an OEM Serial, and Name is subject to typo and renaming creating additional records that consume a seat.
Sassafras Support is happy to discuss these choices in details 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.
For long term customers, good housekeeping of Computer records becomes increasingly important. This is a topic which spills over into related items further on.
Some sites may still be manually organizing Computers into Divisions. If you have a well organized Active Directory, it may be you'd like to simply have KeyServer replicate that folder structure. This can be done using Client Authentication. If that does not fit the need, there are also Rules that can be made in KeyConfigure to automatically organize computers based on naming convention for example.
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 state. This allows you to retain the Usage data and report on it, 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. 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 computers (new in 7.8) 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.
As you're likely aware, the color of the icon in the Computer window indicates the type of computer. Orange records are virtual computers, and green records are thin client sessions. When managing virtual systems you usually want to create Rules that set them to Do Not Audit. This is especially true of thin sessions given they really are all the same computer serving those sessions, but it's also 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. Additionally, you usually want thin sessions to be set to Leased instead of Dedicated. The combination of no audits and leased timer allows those records to go Dormant in only 4 hours. Thick VDI can also be set to Leased, but they will have a one week timer if any Policy is accessed during the session. This is still less than the one month if Audits were in place. These settings allow you to run virtual environments with lower license counts than you might need with physical hardware.
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. 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.
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 7.8.x to 7.9.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 move 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 wether or not it contains all the data you are looking for. Other than this rebuild period, there are no other concerns with starting fresh with the audit data, and it can be a good way to optimize performance.
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 Sassafras to ensure we are creating the new version definition. If you make your own, it will cause conflicts when we put out ours.
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 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.
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 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.
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 fine grain detail.
With the release of 7.6 we fully deployed the use of Family Products. While it may seem like this should be mentioned in the Products section above, their primary use is with Policies. 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 say the Creative Cloud Policy to see ALL Adobe use of any app of any version, or report on the Products to see 2020 vs 2021 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 KeyServers 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.
An important reminder about Policies, especially in context of our newer features. While we have the Automatic Policy Wizard that prompts if you want to Observe any Family Products not currently in a Policy, 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 on 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 softare 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.
The follow up to this of course is reviewing your policies for things you are tracking already that perhaps you can stop. If for example you're tracking the Adobe suite but your organization as a site license that is not going anywhere, you're gathering a lot of data that you'll never report on. In that case, you can disable or delete the policy in question.
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.
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.
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.
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!
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.
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.
We hope the information in this article has been useful in guiding some general review and cleanup of your Sassafras 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.