Skip to content

Releases: heyvaldemar/disable-inactive-users-active-directory

Release list

v1.1.0

Choose a tag to compare

@heyvaldemar heyvaldemar released this 26 Sep 14:52

Added

  • Tests of what the script does, and proof that they can fail. A Pester suite runs the script for real and asserts its behaviour; tests/plant-violations.py breaks it 7 ways on a copy and requires the suite to notice each. Both run in CI on every push.

Fixed

  • A dry run writes the report it says it wrote. Under -WhatIf the script printed "N dormant account(s) written to " and wrote nothing: New-Item and Export-Csv inherited the dry-run preference along with the account changes. The report is now written in every mode, and the account changes still honour -WhatIf. Found by the new test on the first run.

v1.0.0

Choose a tag to compare

@heyvaldemar heyvaldemar released this 03 Sep 23:24

Fixed

  • Accounts were disabled with dsmod, a Windows Server 2003 tool that is
    not present on current servers and fails quietly inside a loop: the account
    was then moved to the disabled OU while still enabled. Disable-ADAccount
    from the same ActiveDirectory module already in use does the job and reports
    failure.
  • The search filter was a script block. In that form the comparison values
    are not always expanded, and the query silently matches nothing, which reads
    as "no dormant accounts" rather than as an error. The filter is now a string.
  • Already-disabled accounts are excluded, so a rerun no longer rewrites the
    description of accounts it disabled on an earlier pass.

Added

  • -WhatIf support, and the CSV report is always written before any change,
    so the intended change can be reviewed before it is made.
  • Parameters instead of edit-the-file variables: -SearchBase,
    -InactiveUserOU, -Days and -LogFolder. The two organizational units are
    mandatory, so the script cannot run against the wrong directory by inheriting
    someone else's defaults.
  • Comment-based help with the replication caveat stated up front:
    lastLogonTimestamp replicates lazily, so a threshold under 30 days produces
    false positives.
  • CI that parses the script and runs PSScriptAnalyzer at Error and Warning
    severity on every push and weekly.

Upgrading

Take the new script. Both the parameters and the defaults are documented in the README, and the first run should use -WhatIf (PowerShell) or the test suite (Python) before anything is scheduled.

Full history in CHANGELOG.md.