Create and Delete the DL in On Prem AD via ServiceNow Automation
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
The requirement is to Create and Delete the DL in On Prem AD via ServiceNow Automation. Whenever the user comes and submit the request for DL creation or deletion, once after the approvals the DL has to create in the ON prem Active active directory. Need help on this as what are the things that we can do from SNOW side and what are the that has to be done from AD side.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Hi sai9845,
This is a standard Integration Hub + MID Server pattern. In ServiceNow a "DL" in on-prem AD is an AD group of type Distribution (mail-enabled, if you also use on-prem Exchange). The work splits like this:
ServiceNow side
1. MID Server: install/validate a MID Server on a machine inside your network that can reach a domain controller. All AD actions run from the MID (PowerShell), the instance never talks to AD directly.
2. Integration Hub + Microsoft AD spoke (needs an Integration Hub subscription): install the Microsoft Active Directory spoke, and create the Connection & Credential alias for AD using a Windows credential for the AD service account. Test the connection from Flow Designer before building anything on top.
3. Catalog item: one request form for "Create DL" / "Delete DL" with the variables the automation needs — DL name, description, owner/managed-by, target OU, initial members (for create), and for delete a reference to the existing DL (ideally populated from an AD group table you import via LDAP, so requesters pick rather than type). Your approvals run first, as you planned — the automation flow should only start after approval.
4. Flow (Flow Designer, triggered on the requested item/catalog task after approval):
- Create: use the AD spoke's group create action with Group Type = Distribution, name/sAMAccountName, description, managed-by and the OU/DN, then the spoke's membership action to add the requested members. Check for an existing group with the same name first and fail gracefully into a manual task if found.
- Delete: use the spoke's group delete/remove action against the group DN; build in a confirmation/approval step because deletion is irreversible — many teams disable the group or empty it in a first step and delete after an agreed wait period, but that is a process choice to agree with the AD team.
- Handle errors: on spoke failure, don't close the request as complete — write the error into the task, reopen it for manual handling, and surface the Flow execution details to the fulfiller.
5. Keep the correlation: store the created group's DN/name and the request details somewhere durable (task variables are not enough for a later delete request). The LDAP import of AD groups into ServiceNow also gives you reporting on which DLs exist.
AD side (for your AD/Exchange team)
1. A dedicated service account for ServiceNow, with rights delegated ONLY on the target OU(s): create/delete group objects, write the group attributes you set (description, managed-by, mail attributes) and modify membership. Use Delegation of Control — do not ask for Domain Admins.
2. Network path from the MID Server host to the DCs (PowerShell/WinRM and LDAP as required by the spoke), and the target OU structure agreed in advance.
3. Decide the mail question explicitly: if these DLs must be mail-enabled in on-prem Exchange, creating the AD group alone is not the whole job — either the group is created mail-enabled (mail attributes set as part of the flow) or the Exchange team provides an Exchange PowerShell step (e.g. Enable-DistributionGroup/New-DistributionGroup) that you run from the MID via a custom PowerShell action. Agree which side owns this before you build.
4. Agree the conventions up front: naming standard, which OUs automation may touch, and the creation/deletion rules for similarly named existing groups.
Build order that works well: MID + service account delegation → spoke connection test in a test OU → create flow → membership → delete flow → then wire the catalog item and approvals on top.
Hope that gives you the split you need for planning with the AD team.