Review NIM logs
Configuration guide
Use NIM logs to find when an operation ran, which component produced a message, and what happened before and after a failure.
At a glanceDirect link to At a glance
Open Configuration > Log in NIM Studio. The screen has four tabs:
| Tab | Use it for |
|---|---|
| General log | Current NIM Service activity, including PowerShell messages now written to the general log or the relevant operation context. Start here for most investigations. |
| PowerShell log | Historical entries only. NIM displays a notice that this tab is being removed and no new data is written to it. |
| Script logs | Find a particular script execution, then inspect the messages associated with that run. |
| Options | Highlight log messages by level, matching message text, and formatting. |
For a failed job or scheduled task, begin with its execution result, then use the time and context to locate related log messages. The logs provide detail; the result identifies which workflow or operation needs attention.
Find log files on diskDirect link to Find log files on disk
On the NIM server, log files are stored in C:\ProgramData\Tools4ever\NIM\sysdata\log. These files help when NIM Studio is unavailable or when you need service startup, installation, update, or connector details. The exact files present depend on which components and connectors have run.
| File | What it records | Start here when |
|---|---|---|
nim.log | Main NIM Service log. Timestamped, structured entries include a level, context, and message for service activity, API requests, jobs, and connector operations. | You need the broad sequence around a failure or want to correlate an event with the General log in Studio. |
nim.err.log | Standard error output from the NIM process, including runtime exceptions and Node.js warnings. | The service fails during startup or produces an exception that needs its stack trace. |
nim.out.log | Standard output from the NIM process, such as the service version, configuration load, logger initialization, and graceful shutdown. | You need to confirm that the process started, initialized logging, or shut down. |
nim.wrapper.log | Windows service wrapper activity, including launching the NIM process, process IDs, stops, and service exit status. | The Windows service will not start, stops unexpectedly, or restarts. |
nim_installer.log | Windows Installer actions and results for an install, upgrade, or repair. | Installation or upgrade setup fails, or you need to confirm its final result. |
nim_update.log | NIM update-related service activity, such as version checks and snapshot or backup steps. | You need to inspect what NIM recorded while checking for or preparing an update. |
nim_updater.log | The updater's own activity, including download progress and the handoff to installation. Older segments may appear as nim_updater.1.log, nim_updater.2.log, and so on. | An update download or installer launch fails. |
ps2nim-<connector>.log | A separate log for a PowerShell connector instance. Entries can show connector loading, Idm-* function calls, requests, and messages from that connector. | A specific PowerShell connector fails or you need its detailed execution history. |
Use the incident time to compare files. For an update problem, read nim_update.log and nim_updater.log first, then nim_installer.log if installation began. For a startup problem, compare nim.wrapper.log, nim.out.log, and nim.err.log before searching nim.log. The installer file may be UTF-16 encoded; use an editor that detects its encoding.
Read the General logDirect link to Read the General log
The General log lists Level, Time, Context, and Message. Use the timestamp to locate the incident, the context to identify its source, and the message to follow the sequence of activity. Informational service and API requests can appear alongside warnings and errors, so narrow the view before interpreting one message in isolation.
Narrow the time period and messagesDirect link to Narrow the time period and messages
- Under Period, choose Recent and enter a number and unit in Show logs of last to inspect a recent window. Choose Begin-end when you need a specific time range.
- Select Apply after changing the period. Start with the shortest range that includes the incident.
- Use Filter to search the displayed entries. The colored level controls beside it let you include or exclude log levels.
- Turn on Real-time update when you are reproducing a problem and want new messages to appear. Auto scroll follows incoming entries; turn it off when you need to keep an earlier message in view.
- Compare the relevant entries with the job or task result. Look for the first meaningful warning or error and the messages immediately around it.
The available time units include minutes, hours, days, weeks, and months. A broad range can produce many routine entries; narrow it or use the message filter when an error is hard to find.
Understand log levelsDirect link to Understand log levels
| Level | What to look for |
|---|---|
| Error | A failed action or condition that needs investigation. |
| Warning | A condition that may need attention even if processing continues. |
| Info | Routine activity and progress messages. |
| Verbose | More detailed execution information. |
| Debug | Low-level diagnostic detail useful during a focused investigation. |
The level controls change what is visible in the log view. They do not change the severity of an existing message. Use Options when you want matching rows to stand out visually.
Find one execution in Script logsDirect link to Find one execution in Script logs
The Script logs tab has an execution list above a Log pane. Each row identifies a run by ID, Date-time, Script, Function, and Name. The Actions column provides a control to open that execution's messages.
- Search the execution list by script, function, or run name, or use its filter control to narrow the rows.
- Match the run's date and time to the incident. Select the row's log action to inspect that execution in the lower Log pane.
- In the Log pane, filter messages and inspect warnings or errors. Read the surrounding informational messages to understand the sequence, inputs, and outcome.
- Select Refresh to retrieve recent executions. Use Resize when a truncated column or message needs more room.
For example, if an App action calls a script function, the upper list helps locate that particular function run. Its lower log shows the messages associated with the selected execution. See Scripts for writing and debugging script functions.
Messages can contain identifiers, request details, source and target data, and connector parameters. PowerShell connector logs may include token fields. Remove credentials and personal or session information before sharing excerpts outside your operations team.
The OWASP Logging Cheat Sheet explains why investigation logs need useful context while sensitive values and log integrity need protection. Apply your organization's access and retention rules to NIM log files and exported excerpts.
Use the PowerShell log only for historical entriesDirect link to Use the PowerShell log only for historical entries
The PowerShell log tab displays a notice that it is being removed. No new data is written to that tab. For current PowerShell activity, search the General log and the log context for the connector operation, mapping, job, or task involved. On the server, also inspect ps2nim-<connector>.log for that connector's detailed messages. An empty PowerShell tab does not establish that the connector did nothing.
If you are investigating a PowerShell connector, start with its system collection or job result, then search the General log around that time. See PowerShell connectors for connector logging details.
Highlight messages with formatting rulesDirect link to Highlight messages with formatting rules
The Options tab contains Formatting rules. A rule can match a log level and text in the Message column, then change how matching entries appear. This changes their display; it does not change the logged message or its level.
- Select Add in Options.
- Choose a Log level. Enter Matching text when the rule should apply to a particular message. Matching text is checked against the Message column, not the time or context columns, and matching is case-insensitive.
- Choose Bold, Italic, Text color, or Background color as needed. Use a combination that remains readable in light and dark mode.
- Select Save. Return to a log tab to check the result. Use the row's actions to copy or remove a rule when maintaining the list.
For example, a rule for the error level can make errors bold with red text. Add matching text when you want to emphasize one recurring error rather than every error. If multiple rules have the same level and matching text, NIM applies the first matching rule; place the preferred rule first.
A practical investigation sequenceDirect link to A practical investigation sequence
- Record the affected workflow, approximate time, and expected result.
- Review the job or scheduled-task outcome to identify the failing stage.
- Narrow the General log to that time and search for the relevant context or message. If a script ran, open its execution in Script logs. For startup, update, or connector problems, compare the relevant files on disk.
- Correct the underlying connection, data, permission, or configuration issue. Use Validation when a configuration dependency may be broken.
- Retry one safe record or operation and confirm the expected result and new log entries before resuming broad automation.
For common failure paths, see NIM troubleshooting and provisioning troubleshooting.