Manage orphaned knowledge objects
When a knowledge object owner leaves a department or company and their Splunk account is deactivated, the knowledge objects that they owned remain in the system. These are orphaned knowledge objects. Knowledge objects without valid owners can cause problems. For example, searches that refer to orphaned lookup definitions may not work.
Orphaned scheduled reports can be a particular problem. The search scheduler cannot run a scheduled report on behalf of a nonexistent owner. This happens because the scheduled report is no longer associated with a role. Without that role association, the search scheduler has no way of knowing what search quotas and concurrent search configurations the report is limited by. As a result, it will not run the scheduled report on its schedule at all. This can result in broken dashboards and embedded searches, data collection gaps in summary indexes, and more.
The Splunk software provides several methods of detecting orphaned knowledge objects. Once you have found orphaned knowledge objects, you have several options for resolving their orphaned status.
Find orphaned knowledge objects
There are several ways that you can find out whether or not you have orphaned knowledge objects in your Splunk implementation. Most of these detection methods specialize in orphaned scheduled reports, because they tend to cause the most problems for users.
The Reassign Knowledge Objects page in Settings is the only orphaned knowledge object detection method that can find all orphaned knowledge object types. It can only find orphaned knowledge objects that have been shared at the app or global levels.
These detection methods have no way of knowing when people are removed using a third-party user authentication system.
Review orphaned scheduled search notifications
By default your Splunk implementation runs a search to find orphaned scheduled reports on a daily schedule. When it finds orphaned scheduled reports it creates a notification message. If you open that message you can click a link to see a list of the orphaned reports in the Orphaned Scheduled Searches, Reports, and Alerts dashboard.
Steps
- Click Messages when the UI indicates there are messages there.
- If you find a message indicating that the Splunk software has found orphaned scheduled searches, click the message link to run a search that displays the orphaned scheduled searches.
Look at the Orphaned Scheduled Searches, Reports, and Alerts dashboard and report
The Orphaned Scheduled Searches, Reports, and Alerts dashboard is delivered with your Splunk platform deployment in the Search & Reporting app. The dashboard loads with the results of the Orphaned Searches, Reports and Alerts report, which is designed to return the names of any orphaned scheduled reports in your system.
You can run the Orphaned Searches, Reports And Alerts report directly from the Reports listing page to get the same results.
Run the Monitoring Console health check in Splunk Enterprise
If you have the Monitoring Console configured for your Splunk Enterprise instance, you can use its health check feature to detect orphaned scheduled searches, reports, and alerts. It will tell you how many of these knowledge objects exist in your system. You have to run a drilldown search to see a list that identifies the orphaned searches by name.
Prerequisites
- Access and customize health check in the Admin Manual.
Steps
- Open the Monitoring Console by selecting Settings > Monitoring Console.
- Select the Health Check tab.
- Click the Start button in the upper right corner to run the health check. By default, the health check will search for orphaned scheduled searches, reports, and alerts. If the health check finds orphaned searches, the Monitoring Console marks the Orphaned Scheduled Searches row with an Error notification moves it to the top of the health check list, alongside other rows with Error notifications.
- Click the Orphaned Scheduled Searches row to launch a drill down search. This search displays the names of the orphaned scheduled searches.
Use the Reassign Knowledge Objects page in Settings
The Reassign Knowledge Objects page in Settings is the only orphaned knowledge object detection method that detects all knowledge objects (not just searches, reports, and alerts). However, it can only find knowledge objects that have been shared to the app or global levels.
Steps
- Select Settings > All configurations.
- Click Reassign Knowledge Objects.
- Click Orphaned to filter out non-orphaned objects from the list.
At this point, the list should only contain orphaned objects that have been shared. Now you can determine what you want to do with the items in that list.
Use the Reassign Knowledge Objects page in Settings to reassign a knowledge object to a new owner. The Reassign Knowledge Objects page can reassign both owned and orphaned knowledge objects. It is designed to work with all Splunk deployments, including those that use search head clustering (SHC).
The Reassign Knowledge Objects page cannot reassign knowledge objects that are both orphaned and privately shared. See Reassign private orphaned knowledge objects.
Knowledge object ownership changes can have side effects such as giving saved searches access to previously inaccessible data or making previously available knowledge objects unavailable. Review your knowledge objects before you reassign them.
Only users with the Admin role can reassign knowledge objects to new owners.
Find the knowledge object or objects you want to reassign
First, you need to use the filtering options on the Reassign Knowledge Objects page to help you find the knowledge object or objects that you want to reassign.
Steps
- Select Settings > All configurations.
- Click Reassign Knowledge Objects.
- Find the object or objects that you want to reassign.
Objects to find Step to follow Objects belonging to an owner with an active account. Click Filter by Owner and select the owner name from the dropdown. All shared, orphaned objects. Click Orphaned. Objects belonging to a specific knowledge object type. Make a selection from the Object type dropdown. Objects belonging to a specific app. Make a selection from the App dropdown. You can optionally switch All Objects to Objects created in the app to filter out objects created in apps other than the app you have selected. Objects that include a particular text string. Enter the string into the filter field and click Return.
Your next steps depend on how many knowledge objects you want to reassign to a different owner.
Reassign a single knowledge object to another owner
If you are using the Reassign Knowledge Objects page to reassign an individual object to another owner, follow these steps.
Prerequisites
Find the knowledge object you want to reassign before starting this task.
Steps
- For the knowledge object that you want to reassign, click Reassign in the Action column.
- Click Select an owner and select the name of the person that you want to reassign the knowledge object to.
- Click Save to save your changes.
Bulk-reassign multiple knowledge objects to another owner
If you are using the Reassign Knowledge Objects page to reassign multiple objects to another owner, follow these steps.
Prerequisites
Find the knowledge objects you want to reassign before starting this task.
Steps
- Select the checkboxes next to the objects that you want to reassign. If you want to reassign all objects in the list to the same owner, click the checkbox at the top of the checkbox column.
You can reassign up to 100 objects in one bulk reassignment action. - Click Edit Selected Knowledge Objects and select Reassign.
- (Optional) Remove knowledge objects that you have accidentally selected by clicking the X symbols next to their names.
- Click Select an owner and select the name of the person that you want to bulk-reassign the selected knowledge objects to.
- Click Save to save your changes.
If you want to reassign orphaned knowledge objects that had a Private sharing status when they were orphaned, you cannot reassign them through the UI. There are two ways to reassign unshared (private), orphaned knowledge objects. You can temporarily recreate the invalid owner, or you can copy and paste the knowledge object stanza between the configuration files of the invalid and valid owners.
Temporarily recreate the invalid owner
The easiest solution for this is to temporarily recreate the invalid owner account, reassign the knowledge object, and then deactivate the invalid owner account.
Prerequisites
See About users and roles in the Admin Manual to learn how to add and remove users from your Splunk implementation.
Steps
- Add the invalid knowledge object owner as a new user in your Splunk deployment.
- Use the Reassign Knowledge Objects page to assign the knowledge object to a different active owner.
- Deactivate the invalid owner account.
Perform a knowledge object stanza copy and paste operation between two .conf files
If you cannot reactivate invalid owner accounts, you can transfer ownership of unshared and orphaned knowledge objects by performing a .conf file stanza cut and paste operation. You cut the knowledge object stanza out of a .conf
file belonging to the invalid owner and paste it into the corresponding .conf
file of a valid owner.
Prerequisites
To use this method you must meet the following requirements:
- You must be using Splunk Enterprise.
- You must have filesystem access.
- You cannot be running SHC on your Splunk deployment.
- You must be able to restart your Splunk deployment.
Steps
- In the filesystem of your Splunk deployment, open the the
.conf
file for the invalid owner atetc/users/<name_of_invalid_user>/search/local/<name_of_conf_file>
. - Locate the stanza for the orphaned knowledge object and cut it out.
- Save your changes to the file and close it.
- Open the the corresponding
.conf
file for the new owner atetc/users/<name_of_valid_user>/search/local/<name_of_conf_file>
. - Copy the knowledge object stanza that you just cut to the
.conf
file for the valid owner. - Save your changes to the file and close it.
- Restart your Splunk deployment so the changes take effect.
About resolving orphaned scheduled searches
The action you take to resolve an orphaned scheduled search, report, or alert depends on what you want it to do going forward.
Objective | Step to follow |
---|---|
Keep the search running on its schedule | Reassign the search to a new owner. |
Let the search run on an ad-hoc basis. | Remove the schedule for the search from its definition in Settings > Searches, reports, and alerts. If the search has been shared with other users of an app, users of that app can run it. This can be important if it is used in a dashboard, for example. However, you may need to ensure that other users do not schedule it again. You can do this by limiting the number of roles that have edit access to the search. Alternatively, you can reassign it to a new owner as an unscheduled search. |
Keep the search from running again under any circumstances. | Disable the search, or delete it. |
Turn off notifications of orphaned searches
By default, Splunk software notifies you about orphaned searches. If you would rather not receive these notifications, open limits.conf
, look for the [system_checks]
stanza, and set orphan_searches
to disabled
.
Manage knowledge object permissions | Disable or delete knowledge objects |
This documentation applies to the following versions of Splunk® Enterprise: 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 7.3.9, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.0.9, 8.0.10, 8.1.1, 8.1.2, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.1.9, 8.1.13, 8.1.14, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7, 8.2.8, 8.2.9, 8.2.10, 8.2.11, 8.2.12, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.0.7, 9.0.8, 9.0.9, 9.0.10, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.3.0, 9.3.1, 8.1.0, 8.1.10, 8.1.11, 8.1.12
Feedback submitted, thanks!