About This ArticleThis article was generated using an AI-assisted automated workflow. We verified the official Microsoft Learn specifications for Compare-Object and organized a practice procedure for comparing lists before and after changes using only fictional device names.

Verification Status: 📘 Official Specifications Verified / PowerShell Execution Not Tested on Actual Hardware

Comparing Before and After Lists Using PowerShell's Compare-Object: Understanding Arrow Meanings and Prevention of Oversight

Want to quickly know what was added and what was removed after a change

When comparing lists before and after an operation, looking only at the row count does not reveal the nature of the changes. For example, even if the managed devices remain at three, one of them might have been swapped. Visually comparing lists side by side in Excel can lead to oversights due to row sorting or similar names.

PowerShell's Compare-Object is a standard command for extracting differences between two lists. The key point is that the arrows do not necessarily represent "before" and "after" in themselves. Values that exist only in the reference list specified on the left appear with <=, while values that exist only in the comparison list on the right appear with =>. If you reverse the reference and comparison specifications, the direction of the arrows will be reversed even for the same data.

This difference can be verified using fictional device names without touching actual files or servers. In practical operations, this can be applied to inventory checks, verification of targets after modification work, and reconciliation of distribution lists. However, the absence of differences in the lists is not the same as device configurations and operational states being identical.

Supported Environment and Preparation

First, execute the commands one by one and cross-reference the displayed arrows with the source data. The code to be pasted into the terminal does not include instructions to terminate the interactive shell. Since the target is a simple string list, no additional modules or network connections are required.

Get it running first: replace only one out of three units

In the following example, let the pre-change list be $before, and the post-change list be $after. The configuration assumes Terminal A and Terminal B remain, Terminal C is removed, and Terminal D is added. Here, arrays are merely created in memory, and actual terminals are neither searched nor modified.

$before = @('PC-A', 'PC-B', 'PC-C')
$after  = @('PC-A', 'PC-B', 'PC-D')
Compare-Object -ReferenceObject $before -DifferenceObject $after

The expected display contains PC-C's <= and PC-D's =>. The display order is not essential. What should be read is the combination of the values in the InputObject column and the arrows in the SideIndicator column. Both arrays have three items, but the difference consists of two rows. The finding of this small experiment is that one cannot conclude "no changes because the count is the same".

-ReferenceObject is the set serving as the comparison baseline,-DifferenceObject represents the comparison target set. Even if names are similar, the order in which arguments are specified determines the interpretation of the results. If you establish a convention of using the pre-change state as the baseline,<= can be read as removal candidates, and=> as addition candidates. However, this is an operational convention within the team and does not mean the command itself recognizes dates.

Understanding with diagrams: Left and right inputs and arrows

The following diagram illustrates the flow where the same terminal name is passed into two inputs, outputting only values present on one side. The arrows indicate which side the value exists on, not the direction of data movement.

flowchart TD
    A["変更前 Reference: A B C"] --> C["Compare-Object"]
    B["変更後 Difference: A B D"] --> C
    C --> D["共通 A B: 既定では非表示"]
    C --> E["C: 左側のみ <="]
    C --> F["D: 右側のみ =>"]

C, which exists only on the left side of the diagram, and D, which exists only on the right side, are output, while A and B, which exist on both sides, are not displayed by default. Therefore, an empty result means "no differences were detected under the specified comparison conditions." It does not rule out missed collection of comparison targets or insufficient permissions.

Changing one condition: Also displaying common values

When looking only at differences, it can sometimes be difficult to see which terminals remain. In such cases, add-IncludeEqual. The key to the experiment is to change only the display conditions without altering the baseline and comparison arrays.

Compare-Object -ReferenceObject $before -DifferenceObject $after -IncludeEqual

In the expected results,PC-A andPC-B will have== attached, and the two differences from earlier are also displayed. Here,== indicates that the same values matched under the comparison conditions. It is not a mark guaranteeing the configuration values of terminals that did not change. For example, if the terminal names are the same but the IP addresses have changed, this cannot be detected by a comparison of this string alone.

If you are only collating lists of terminal names before and after changes, displaying only differences is easier to read. On the other hand, when retaining the collation status of all targets as an audit trail, displaying common items is meaningful. It is important to select the output conditions according to your purpose.

Another comparison: Are uppercase and lowercase letters the same?

Next, change the comparison data to check for name notation inconsistencies. By default, PowerShell string comparisons are case-insensitive. Therefore,PC-A andpc-a are treated as the same in standard comparisons. When you want to distinguish them strictly, specify-CaseSensitive.

$x = @('PC-A')
$y = @('pc-a')
Compare-Object $x $y
Compare-Object $x $y -CaseSensitive

The first call is expected to show no differences, while the second call is expected to show the left and right values as differences. This is not about whether the displayed strings look identical, but rather the difference in comparison rules. Because systems differ in whether case sensitivity matters for identifiers, please check the business data specifications before making your choice.

Looking at this example, it would be premature to assume that you should simply add -CaseSensitive to every comparison. In practice, the same terminal might be detected as a duplicate simply due to variations in uppercase and lowercase letters. Define input-side normalization rules and design the comparison results so that they match operational identity.

In practice, look at multiple attributes rather than just the "name"

When auditing terminals, relying solely on the terminal name is sometimes insufficient. The following example compares hypothetical objects that have both a terminal name and a department.-PropertyBecause you can specify the columns you want to compare in , this serves as practice for detecting when the department has changed even if the terminal name remains the same.

$old = @(
    [pscustomobject]@{ Name='PC-A'; Team='Sales' }
    [pscustomobject]@{ Name='PC-B'; Team='Support' }
)
$new = @(
    [pscustomobject]@{ Name='PC-A'; Team='Sales' }
    [pscustomobject]@{ Name='PC-B'; Team='Ops' }
)
Compare-Object -ReferenceObject $old -DifferenceObject $new -Property Name,Team

The expected result is that PC-B / Support is on the left side only and PC-B / Ops is on the right side only. Rather than returning a dedicated "department change" event, the command displays that the old combination of attributes has disappeared and a new combination has been added. Therefore, making a final determination on the type of change requires additional processing to correlate rows with the same terminal name.

While adding more attributes allows you to detect finer changes, including timestamps or values that change every time will increase noise. Select only the necessary items, such as the terminal ID if the comparison purpose is "adding or deleting target terminals," or the terminal ID and department if the purpose is "discovering departmental changes." A difference whose comparison purpose you cannot explain has weak value as a basis for operational decisions.

Isolating common failure points

First, do not immediately jump to the conclusion that success has been achieved simply because the result is empty. Verify whether the original two arrays were successfully retrieved, whether the record counts match expectations, and whether empty strings or spaces are mixed in. If a data collection process fails and both sets are empty, an indication that there are no differences will fail to reveal the anomaly. Practically speaking, it is best to record the input counts and retrieval timestamps before running the comparison.

Second, distinguish between order differences and value differences. Even if terminal names are in the same set and only the sort order changes, a standard set-based comparison does not function as an inspection for order changes. When comparing configuration files where line numbers or sequence matter, a different comparison method must be chosen. Conversely, if you do not care about row order during an inventory audit, being able to ignore differences in order is an advantage.

Additionally, pay attention to how duplicate rows are handled. For lists where the same name appears multiple times, consider count reconciliation and set reconciliation separately.Compare-ObjectTreating the output of as a simple one-to-one change history can lead to misunderstandings depending on duplication and sorting conditions. It is safer to determine a business primary key and place duplicate detection in a separate step.

When loading from a CSV, discrepancies in column names, character encodings, leading and trailing spaces, full-width and half-width characters, and missing values will affect the results. For example, PC-A and PC-A differ in their trailing spaces. Inspect the input format before comparing, and normalize the copy if necessary. Directly editing the original file to check for differences risks destroying the very evidence you are investigating.

Furthermore, -PassThru alters the format of the output objects. Normally, InputObject and SideIndicator are handled, but -PassThru preserves the original object while adding indicators. When designing subsequent CSV output or property referencing, separately verify the format in which the expected columns will be obtained. It is important not to infer the structure usable for subsequent processing solely from the strings displayed on the screen.

For professional use: Record both before and after comparison

When using it for change management, first safely retrieve and store the pre-change list, and collect the post-change list using the same method, same permissions, and same extraction conditions. If the retrieval conditions differ, the differences may reflect variations in the collection method rather than actual changes. Including the number of target items, extraction timestamp, data source, and presence or absence of errors makes it easier for a third party to interpret the results later.

Building on that, fix the left and right sides of Compare-Object and review each difference row as a "deletion candidate" or "addition candidate." They are called candidates here because the same arrows can appear due to terminal name changes, ledger errors, or incomplete extractions. To confirm actual deletions or additions, cross-reference them with records from the target system or confirmation from the person in charge.

For example, you can compare before and after changes in a distribution target list to check whether addition candidates correspond to approved requests. Conversely, if a disappearing candidate is an unexpected terminal, it can prompt an investigation into the cause before proceeding with distribution processing. It is safe to use it for read-only verification first, rather than performing automatic deletions or redistribution simply by running the comparison command.

The key is to treat the display of differences as an entry point for investigation, not as a final conclusion. Swaps can occur even if the item counts are the same, attributes can change even if names are common, and the direction of the arrows is determined by the input specification. Understanding these three points transforms post-work verification from visual intuition into a verifiable procedure.

References

• Microsoft Learn: Compare-Object (PowerShell 7.6)

• Microsoft Learn: Compare-Object (Windows PowerShell 5.1)

Official documentation check date: November 5, 2026. Code display examples represent expected values based on specifications; actual device tests on Windows PowerShell 5.1 and PowerShell 7, as well as WordPress display verification, have not been performed.