Adolsign generates correct, on-brand Outlook signatures for every user straight from your directory — Active Directory, plain LDAP, or Microsoft Entra ID (Azure AD) — instead of relying on users to hand-edit a template or IT to update mailboxes one at a time.

1. Write a template. An .htm, .rtf or .txt file with scan codes dropped in, e.g. field_fullname, field_title.
2. Define the rules. In adolsign.config, map templates to AD groups or field values, mark defaults, attach extra files.

3. Run it — from a login script, your software distribution tool, or by hand:

   adolsign --configfile adolsign.config --default

4. It's already on every desktop. Outlook's signature files and default-signature registry keys are updated silently, with nothing for the user to click.

Adolsign ships as a single self-contained executable — there's nothing to install on the client, and no runtime dependency to manage across a fleet.

Building an offline installer package with --makepackage additionally requires NSIS's makensis.exe to be reachable (next to adolsign.exe or on PATH).

1. Copy adolsign.exe and your adolsign.config to a location every target machine can reach — typically a NETLOGON share or a folder pushed out by your software distribution system.
2. Put your signature templates (.htm, .rtf, .txt) alongside adolsign.config, or point at them with full paths in the config.
3. Call adolsign.exe from a login script, a Group Policy startup/logon script, or your distribution tool's per-user run step.
4. For remote or offline users who never hit the login script, build a one-click installer instead with --makepackage and send that.

A minimal login-script invocation:

adolsign.exe --configfile \\server\netlogon\adolsign\adolsign.config

Before rolling out to a whole domain, proof a template safely with --noldap (see the testing FAQ below) and check the output with --verbose.

A template is an ordinary .htm, .rtf or .txt file with scan codes dropped in wherever a directory value should be substituted. Provide whichever variants you need — Adolsign renders every one that exists for a given signature name.

<b>field_fullname</b><br />
field_title, field_department<br />
field_telephone<br />
field_email

Built-in scan codes:

field_login, field_fullname, field_firstname, field_lastname, field_initials, field_othername, field_title, field_company, field_department, field_office, field_telephone, field_homephone, field_mobilephone, field_fax, field_email, field_street, field_pobox, field_city, field_state, field_postal, field_country, field_description, field_division, field_employeeid, field_homepage

Any of these can be redirected to a different directory attribute in the [field mappings] section of adolsign.config, and a scan code with no value for a given user is simply replaced with an empty string. Note that not every field has a Microsoft Graph equivalent — field_initials, field_othername, field_division, and field_homepage are left blank when looked up via --admethod graph.

Wrap a scan code in its own name to attach options: field_xxx(--option value ...)field_xxx. For example:

field_telephone(--prefix "Tel: " --default "on request")field_telephone

renders as Tel: +47 22 00 00 00 when the field has a value, or Tel: on request when it's empty.

A lookup table example, defined elsewhere in the same config file:

field_office(--lookup offices --prefix "Office: ")field_office

[offices]
OSL = Oslo
BGO = Bergen
TRD = Trondheim

One adolsign.config file drives which signatures apply to whom. Each [Signature <name>] section maps to a template file <name>.htm/.rtf/.txt, and a user qualifies for it if either:

• they belong to one of its Group entries (repeatable — any match qualifies), or
• any of its field_xxx entries is a regular expression that matches that user's looked-up value for that field (also repeatable).

[field mappings]
; override the default AD attribute a scan code maps to, if your schema differs
field_title = Title

[Signature default]
NewDefault = 1
ReplyDefault = 1

[Signature sales]
Group = Sales EMEA
Vcard = 1
AddFile = logo.png

[Signature executives]
field_title = ^(Director|VP|Chief)
NewDefault = 1
ReplyDefault = 1

Other keys inside a [Signature <name>] section: Vcard (generate and attach a vCard), NewDefault / ReplyDefault / Default (make this signature the default; Default = 1 sets both), and AddFile (extra file or directory to bundle, repeatable).

Run it without --signature and every matching rule in the config is processed for the current user in one pass:

adolsign.exe --configfile adolsign.config --verbose

Pass --newdefault and/or --replydefault on the command line (or set NewDefault/ReplyDefault in a [Signature] config section) to make that signature the default for new messages and/or replies/forwards. --default is shorthand for both:

adolsign.exe --signature default --default --verbose

To stop users changing the default signature themselves, add --readonly — this greys out the default-signature setting in Outlook's UI on newer Office versions.

Local deployment writes the default to the registry; cloud deployment (see below) records the intended default in the manifest instead, since there are no local registry writes to make.

Add --vcard on the command line, or Vcard = 1 inside a [Signature <name>] config section:

adolsign.exe --signature default --vcard --verbose

This generates a .vcf file alongside the signature, populated from the same directory fields, and — for local deployment only — registers it as the signature's attached vCard in Outlook.

Choose a lookup backend with --admethod:

• ads (default) — ADSI/ADODB via COM automation against on-premises Active Directory. No extra configuration needed.
• ldap — a plain LDAP bind, configured in the [ldap] section of adolsign.config. See the LDAP FAQ below.
• graph — Microsoft Graph against Entra ID, for environments with no on-premises directory reachable. Requires --graphconfig. See the Graph FAQ below.

An explicit Active Directory base DN can be supplied with --namingcontext if it can't be auto-discovered from the domain's rootDSE.

Add an [ldap] section to adolsign.config:

[ldap]
server = dc1.example.com
; binddn/bindpw optional — omit for an anonymous bind
binddn = CN=svc-adolsign,OU=Service Accounts,DC=example,DC=com
bindpw = ********
; base optional — auto-discovered from rootDSE if omitted
base = DC=example,DC=com

Then run with --admethod ldap:

adolsign.exe --signature default --admethod ldap --verbose

Create an Entra ID app registration with the User.Read.All application permission (admin-consented), then point --graphconfig at an ini file:

[graph]
tenant_id = <your tenant id>
client_id = <app registration client id>
client_secret = <client secret value>

adolsign.exe --signature default --admethod graph --graphconfig graph.ini --verbose

With --admethod graph, pass a full user principal name to --username (e.g. jdoe@yourtenant.onmicrosoft.com), not a bare account name — that's what Graph's /users/{id} endpoint expects.

Local (default) writes signature files to Outlook's local signature folder and sets new-mail/reply registry defaults — it works across Office 2000 through Microsoft 365 desktop, deployed by login script with no user interaction.

Cloud (--deployment cloud, or the --cloud shorthand) renders the same templates and config but writes a cloud-manifest.json file to --targetpath (or the current directory) instead — no local registry writes at all, which is what makes it safe on shared or virtual desktops:

adolsign.exe --signature default --cloud --admethod graph --graphconfig graph.ini

The manifest holds the rendered HTML/RTF/TXT content for every processed signature and which one(s) should be the new/reply default. Pushing that manifest into Exchange Online or Outlook on the web (e.g. via Exchange Online PowerShell's Set-MailboxMessageConfiguration, or your own Graph-based rollout tool) is a separate step on your end — Microsoft doesn't currently expose a supported API for setting a mailbox's default signature directly, so Adolsign can't automate that last hop.

For machines that never run the login script — remote workers, laptops that are frequently offline — build a one-click installer with --makepackage:

adolsign.exe --signature default --makepackage --verbose

This requires NSIS's makensis.exe to be reachable (next to adolsign.exe or on PATH), and produces <exe dir>\<username>_signature.exe by default — override the path with --packagename. Send that installer to the user (or run it via your distribution tool) and it installs the signature files into their local Outlook profile.

Add --noldap to skip the directory lookup entirely and fill the template with placeholder values ("First", "Last", "Title", http://itefix.net) — useful for proofing a new template's layout before pointing it at real users:

adolsign.exe --signature default --noldap --verbose

--verbose is worth leaving on throughout testing — it prints which signature folder/profile/naming-context was resolved and which rules matched, so a wrong result is easy to trace.

To write output to a scratch folder instead of Outlook's real signature folder while testing, add --targetpath:

adolsign.exe --signature default --targetpath C:\temp\sigtest --verbose

To see which template encodings are available (default is iso-8859-1), run --encoding with no value:

adolsign.exe --encoding

Adolsign is licensed in packs of 20 users at $129 per pack — a one-time purchase, not a subscription — and includes your first year of updates and support. A free trial is available for evaluation against a real AD group in your own environment.

Volume discounts apply automatically from your 6th pack, graduated like a tax bracket — each pack is priced at the rate for its own band, not your whole order jumping to one rate:

Need more than 50 packs, or want a quote? Reach us via our contact form.

For a free trial or a licensing quote, use our contact form. For technical support with an existing deployment — template issues, directory lookup problems, or deployment questions — open a ticket at the support portal with the command you ran and its --verbose output; that's usually enough to diagnose the issue quickly.