title: Running Bulk Operations category: Bulk Operations tags: bulk, execution, preview, rollback, progress priority: Normal
Running Bulk Operations
This guide walks you through the complete process of running a bulk operation, from initiating a scan to reviewing results and rolling back changes if needed.
Prerequisites
Before running bulk operations, ensure that:
- You have Administrator or Bulk Operations role permissions
- At least one directory connection has been synchronized recently
- You have reviewed the Bulk Operations Overview to understand issue categories
Step-by-Step Execution
Step 1: Navigate to the Bulk Operations Center
Go to Admin > Bulk Operations (/admin/bulk-operations). The main page displays a summary of your most recent scan results and any outstanding issues from previous sessions.
Step 2: Select the Scan Scope
Choose what to scan:
| Option | Description | When to Use |
|---|---|---|
| Full Scan | Scans all issue categories across all objects | Monthly hygiene reviews |
| Stale Accounts | Only detect stale users and computers | Post-termination cleanup |
| Duplicate Accounts | Only detect potential duplicates | After a directory merger or migration |
| Orphaned Accounts | Only detect accounts without valid owners | After organizational restructuring |
| Misconfigured Accounts | Only detect attribute and membership issues | Before a compliance audit |
| Security Risks | Only detect privilege and password issues | Security posture assessment |
You can also scope the scan to a specific directory connection or organizational unit if you want to focus on a subset of your environment.
Step 3: Review Detected Issues
After the scan completes, the results panel displays each detected issue with the following information:
| Field | Description |
|---|---|
| Affected Object | The user, computer, group, or other object with the issue |
| Issue Type | Category (Stale, Duplicate, Orphaned, Misconfigured, Security Risk) |
| Description | Human-readable explanation of what is wrong |
| Recommended Action | What the system suggests to fix the issue |
| Impact Score | AI-generated score (1-100) indicating the potential impact of the issue |
| Severity | Critical, High, Medium, or Low |
Use the column headers to sort by any field. The severity column is sorted by default so that critical issues appear first.
Tip: Click on any affected object name to open its detail page in the Directory Browser without leaving the bulk operations workflow.
Step 4: Preview Changes
Before executing any remediation, click Preview Changes to see exactly what will happen for each selected issue. The preview displays:
Preview: Stale Account Remediation
──────────────────────────────────
Object: jsmith (John Smith)
Action: Disable account
Current State: Enabled, Last Login: 2025-07-15
New State: Disabled, Description updated with disable reason
Object: old-pc-lab04 (LAB-PC-04)
Action: Disable computer account
Current State: Enabled, Last Login: 2025-03-20
New State: Disabled, moved to Disabled Computers OU
Each entry shows the object, the action that will be taken, the current state, and the resulting state after the change. Review this carefully before proceeding.
Step 5: Select Issues to Remediate
You have three selection options:
| Option | Description |
|---|---|
| Select All | Apply the recommended action to every detected issue |
| Select by Severity | Apply only to issues at a specific severity level (e.g., Critical and High only) |
| Individual Selection | Use checkboxes to pick specific issues to remediate |
Best Practice: For your first time running bulk operations, select a small batch (10-20 items) to verify the results before scaling up to the full population.
Step 6: Execute the Operation
Click Execute to begin the remediation. You will be prompted to confirm:
- The number of objects that will be modified
- The types of changes that will be applied
- Whether rollback snapshots should be created (recommended: always yes)
Once confirmed, the operation begins and a new BulkOperationSession is created to track it.
Step 7: Monitor Real-Time Progress
During execution, the progress tracker provides live updates via SignalR:
Bulk Operation Progress
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 67%
Processing: 134 / 200 items
Succeeded: 128
Failed: 4
Skipped: 2
Remaining: 66
Current: Disabling account 'mgarcia' ...
Elapsed: 2m 34s | Estimated remaining: 1m 15s
The progress view updates in real time without requiring a page refresh. You can see:
- Overall completion percentage
- Counts of succeeded, failed, and skipped items
- The specific object currently being processed
- Elapsed and estimated remaining time
Step 8: Review Results
When the operation completes, the results summary shows:
| Metric | Value |
|---|---|
| Total Processed | Number of items attempted |
| Succeeded | Items successfully remediated |
| Failed | Items that could not be remediated (with error details) |
| Skipped | Items skipped due to conflicts or exceptions |
| Duration | Total time for the operation |
For each failed item, the system provides the specific error message (e.g., "Insufficient permissions to modify object" or "Object was modified by another process during execution"). Click any failed item to investigate.
Rollback Capability
If a bulk operation produces unintended results, the BulkRollbackService can reverse the changes.
How Rollback Works
- Before each change, the BulkIssueSnapshotRepository stores the complete before-state of the object
- After the change, it stores the after-state
- To rollback, the service restores each object to its before-state
Initiating a Rollback
- Navigate to the session you want to rollback (via Bulk Operations > History)
- Click Rollback Session
- Choose to rollback all changes or select specific items
- Preview the rollback actions (just like previewing the original operation)
- Confirm and execute the rollback
Important: Rollback is only available for sessions where snapshots were enabled. If an object has been modified by another process since the bulk operation, the rollback will flag it as a conflict for manual resolution.
Rollback Limitations
| Scenario | Rollback Behavior |
|---|---|
| Account disabled by bulk op | Re-enables the account |
| Attribute changed | Restores previous value |
| Group membership removed | Re-adds the membership |
| Object moved to different OU | Moves back to original OU |
| Object deleted | Cannot be rolled back -- use AD Recycle Bin |
Best Practices
- Always enable snapshots -- The small storage overhead is worth the safety of rollback capability
- Preview before every execution -- Never skip the preview step, even for routine operations
- Start small -- Run your first operation on 10-20 items, review the results, then scale up
- Verify after execution -- Spot-check a few remediated objects in the Directory Browser to confirm correctness
- Schedule during off-hours -- Large operations (500+ items) should run during maintenance windows to minimize impact
- Keep a rollback plan -- Know how to initiate a rollback before you execute, not after something goes wrong
- Document your decisions -- Add notes to sessions explaining why certain items were selected or excluded
Troubleshooting
| Issue | Cause | Resolution |
|---|---|---|
| Scan returns zero results | Directory data may be stale | Run a synchronization first, then re-scan |
| Many items fail during execution | Insufficient AD permissions | Verify the service account has write access to target OUs |
| Progress tracker stops updating | SignalR connection dropped | Refresh the page; the operation continues in the background |
| Rollback shows conflicts | Objects were modified after the bulk operation | Resolve conflicts manually via the Directory Browser |
Next Steps
- Bulk Operations Analytics -- Review history and measure impact
- Bulk Operations Overview -- Revisit issue categories and architecture
- Object Write-Back -- Understand how changes are written back to Active Directory
- Policies Overview -- Configure policies that feed into bulk detection
- Intelligence Hub Overview -- Learn how AI analysis powers issue detection
- Security Hardening -- Ensure your service account permissions are properly scoped