## TL;DR
Point the automation at the group as it actually exists, by distinguished name, not by an assumed name and OU. Search the directory for the group across OUs, correct the provisioning configuration to the real location or create the group in the agreed OU, confirm the service account can see and modify it, and re-run the membership add for the affected hires.

```text
AD group membership provisioning failed: group not found error in target OU
```

## Use this when
- Membership adds fail naming a group and OU while user account creation succeeds.
- The group was moved, renamed, or created in a different OU than the runbook states.
- Other groups in the same job resolve and update correctly.

## Not for this skill when
- The group exists and adds work in AD tools. Suspect replication timing instead of location.
- The failure is access denied rather than not found. Fix service account rights separately.

## Steps
1. Open the provisioning log and Active Directory Users and Computers search for the affected hire and capture the full error detail, the operation that failed, and the identifiers involved, rather than working from the summary banner alone. Keep one hire as the test case for every change so cause and effect stay clear. Verify: the full error detail and one test hire are recorded
2. Search the whole domain for the group by name and by partial name, recording its real distinguished name, group scope, and type, and compare them with the path and scope the provisioning job is configured to use. Verify: the real group location and the configured location are both documented
3. Decide the canonical home with the directory owner: either move the group to the agreed OU if it drifted, or update the provisioning configuration to the real distinguished name if the group legitimately lives elsewhere. Keep security and distribution group types straight, since a type mismatch also surfaces as a failed lookup in some tools. Verify: configuration and directory agree on one canonical group path
4. Apply the correction in Active Directory and save it, then re-run provisioning for the single test hire only and read the fresh log entry end to end. If it still fails, treat the new detail as the current cause and do not stack further changes on top. Verify: the test hire provisions successfully or a new specific detail replaces the old one
5. Confirm the provisioning service account can read the target OU and modify the group membership attribute, testing a manual membership add with that account context if the tooling allows, because restricted visibility can present as not found. Verify: the service account successfully views and modifies the group in a test
6. Re-run membership provisioning for the affected hires and confirm each user now appears in the group member list, then check a dependent access item the group grants so the business effect is proven, not just the directory write. Verify: the hire downstream access is verified in its own system

## Why it happens
Provisioning jobs usually reference groups by a configured path built when the integration was designed. Directories evolve: administrators reorganize OUs, rename teams, and recreate groups, and each change silently invalidates the stored path while the job keeps reporting a plain not found. Because users and other groups still work, the failure looks narrow and mysterious. Searching the live directory for the group as it exists today, then aligning configuration and directory on one canonical location, resolves it and the hygiene check keeps the reference honest as the directory keeps changing.

## Variants and edge cases
### Group exists in another domain or forest
Cross-domain groups need the job pointed at the correct domain controller and trust path. Configure the domain explicitly for that group set.

### Group is dynamic or query-based
Membership of dynamic groups is computed, not written. Provision users into the attribute the query keys on instead of the group itself.

### Recently moved group still fails
Directory caches and replication can lag a move. Wait one replication cycle and confirm the change on the controller the job uses.

Compatibility: Applies to on-premises Active Directory group provisioning from identity platforms and scripts. Requires directory admin tools.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TxD5sVFRf0i0Jq_D2CZS-g