Organizational implementation approach

🔗Implementation Blueprint: Organizational Strategy for Complex Environments

This document serves as a strategic blueprint from a customer's perspective, specifically designed to layer onto the foundational Quickstart guide for highly regulated and high-security environments. While the Quickstart guide provides the core deployment path, complex organizations require this additional framework to layer on formal processes, absolute traceability, and strict governance without sacrificing velocity.

The strategies detailed here are derived from actual corporate experience in deploying solutions across multi-tenant environments containing tens of thousands of mailboxes. This document is intended for internal IT teams, CISOs, and business departments who must ensure that email signature management meets rigorous compliance standards.

The blueprint covers the entire organizational lifecycle:

• Consultation & Planning: Aligning technical capabilities with legal and marketing requirements.
• Testing & Pilot Phases: Ensuring stability in complex, multi-forest AD and M365 landscapes.
• Rollout & Operations: Integrating with existing security structures like AppLocker and signed script policies.
• Governance & Training: Establishing clear ownership between IT and Corporate Communications.

Note: This is a high-level organizational overview focusing on governance and process. For technical configuration details and script parameters, please refer to the detailed documentation.

🔗Task

As a multinational corporation, we are required to find a flexible solution for the automatic management of signatures. The requirements for this come from several areas:

• The marketing department wants to ensure that corporate identity and corporate design are also maintained in emails. Signatures should be able to be updated quickly by the marketing department itself so that campaigns can be started and ended at short notice. This should not require any technical knowledge.
• The legal department insists on implementing the requirement for an imprint in emails in the form of a signature, which is applicable in many countries.
• Management at all levels supports the wishes of the other departments as long as this does not lead to additional work for their employees, but rather relieves them where possible and gives them more time for their tasks.
• CISOs want to ensure that all data protection and information security regulations are complied with and that data remains in its original systems as far as possible.
• IT managers do not want to have to worry about the content of signatures and updating them. Nor should any new dependencies on our email system be created, as these inevitably increase the complexity of the overall system and operating costs.

There are also various other factors to consider:

• The solution must offer clear added value from a financial perspective. A purchase will only be considered if the cost-benefit analysis is positive.

• As a group, we are subject to a certain dynamic. Some subsidiaries are very closely linked to the group in organizational and technical terms, while others are very loosely connected. In all constellations, there can be intensive cooperation. In the context of mergers and acquisitions, it must be possible to quickly integrate individual companies or groups of companies or remove them from the group.

• Accordingly, the technical implementation is very diverse: multiple independent Exchange environments in on-premises, hybrid, and cloud-only configurations, multiple AD forests in different trust configurations, multiple M365/Entra ID tenants with and without connections to each other.

This document aims to clarify whether the desired requirements regarding signatures can be met and what a practical implementation might look like.

The word "signature” in this document always refers to a textual signature and should not be confused with a digital signature, which is used to encrypt emails and authenticate the sender.

🔗Options for Signature Maintenance

🔗Manual Signature Maintenance

With manual maintenance, a template for the textual signature is provided to the user, e.g., via the intranet. Only this template is centrally maintained; there is no further automation.

Each user sets up their own signature. Depending on the technical configuration of the client, signatures may migrate when switching computers or need to be reconfigured.

If the mailbox is not in the cloud or "roaming signatures" have been disabled, the user must also maintain their signature in Outlook for the web.

Without third-party software, signatures must also be manually maintained separately on Android, iOS, and macOS.

🔗Automatic Signature Maintenance

With automatic signature maintenance, no actions are required from the end user. All specifications are defined centrally, and signatures update automatically across all devices and systems.

🔗Server-Based Solutions

The biggest advantage of a server-based solution is that every email is processed based on a defined set of rules, regardless of the application or device used to send it.

Since the signature is appended on the server, the user does not see which signature is used while composing the email.

Defining the rules quickly becomes complex, and users have virtually no influence over the signature used.

After the signature is appended on the server, the modified email must be re-downloaded by the client to be correctly displayed in the "Sent Items" folder. This generates additional network traffic.

If a message is digitally signed or encrypted during creation, the textual signature cannot be added server-side without breaking the digital signature and encryption. Alternatively, the message is modified so that the content consists only of the textual signature, and the original unchanged message is sent as an attachment.

This creates a new dependency of the mail system on the signature solution, and there are hardly any suitable solutions available for on-premises Exchange operations.

Cloud-based solutions require that all internal and external emails, as well as data from Entra ID, be redirected to a third-party data center for rule analysis and signature application.

We therefore advise against server-based solutions.

🔗Client-Based Signatures

With client-based solutions, the definition of templates and optionally their distribution is done centrally, while the signature is added to the email on the client side.

The biggest disadvantage of client-based solutions compared to server-based ones is their dependency on specific email clients. In practice, this is of little relevance, as Microsoft Outlook is usually used for reasons of maintainability and consistency. Outlook is available for Android, iOS, macOS, and Windows, and additionally as a web application on virtually all other platforms.

The user sees the signature while composing the email and can help decide which signature is used.

Encryption and digital signing of messages pose no problems on either the client or server side.

Unlike server-based solutions, there are alternatives here that do not require the transmission of emails and data from Entra ID to third-party data centers.

We therefore recommend using a client-based solution.

🔗Required Feature Set

Based on the previously mentioned conditions and discussions with all involved parties, the following catalog of required features has been derived:

Signatures and out-of-office messages should:

• Be creatable from templates in common formats such as DOCX or HTML.
• Be customizable using variables from directory services (e.g., Active Directory, Entra ID) and other data sources, including photos and images.
• Support variables for the current user, mailbox, and manager.
• Be designed to be accessible, e.g., with alternative text for links and images.
• Be flexibly assignable: to all mailboxes, groups, alias addresses, based on attributes.
• Be reusable: one template for many mailboxes, with individual signature names.
• Be usable on a scheduled basis (valid during specific time periods).
• Be set as the default signature for new emails or replies.
• Be usable as the default out-of-office message for internal and external recipients.
• Be synchronized in Outlook for the web and as roaming signatures.
• Be centrally managed, but also allow parallel user signatures.
• Be automatically inserted into new emails, replies, forwards, and calendar events.
• Be made available for other email clients besides Outlook. If not automatically, then at least for manual integration (e.g., Apple Mail).

Deployment and execution should:

• Be possible on Windows, Linux, and macOS clients, including terminal servers or shared devices.
• Work without installation on servers or clients.
• Be executable via central shares and standard mechanisms such as login scripts, scheduled tasks, or manual execution.
• Optionally be available directly for web users without client deployment.
• Function in hybrid, cloud, and on-premises environments.
• Be suitable for large and complex environments (e.g., multiple AD domains, trusts, multi-tenant setups).
• Allow multiple instances through separate configurations.

Security and data protection:

• No telemetry or external data transmission.
• No changes to DNS or email traffic required.
• Data remains within the existing infrastructure.

Additional requirements:

• Documented best practices for implementation and operation.
• Preference for open-source options or transparent licensing terms.

🔗Architecture and Security Requirements

This section defines the architectural and security requirements for a solution that supports centralized management of email signatures and out-of-office messages in complex enterprise environments.

It is intended to support evaluation, design decisions, and security reviews.
The requirements reflect the principles of data sovereignty, minimal dependencies, and transparent, auditable operation.

🔗Architectural Requirements

A suitable solution must implement a separation of concerns between:

1. Generation of signatures and messages
2. Provisioning and usage within email clients

This separation enables flexible deployment models, scalability, and independence from specific client or server configurations.

🔗Generation Requirements

The solution must support one or more of the following execution models:

• Client-side execution
  • Runs in the context of the logged-on user
  • Uses local computing resources
  • Allows frequent execution (e.g., logon, scheduled tasks)
• Centralized execution
  • Runs on controlled systems within the organization
  • Uses clearly defined service identities where required
  • Supports users without managed client devices

The architecture must allow combining these models depending on organizational requirements.

🔗Provisioning Requirements

The solution must provide signatures through one or more of the following mechanisms:

• Local email client signature storage
• Mailbox-based configuration (e.g., Outlook for the web or roaming features)
• Application-based integration (e.g., add-ins)
• Optional export to file systems or other accessible locations

The chosen approach must ensure consistent availability across:

• Desktop clients
• Web clients
• Mobile devices

🔗Security Model Requirements

The solution must enforce a security model based on the following principles:

• Least Privilege
• Need to Know
• Separation of Duties

🔗Execution Contexts

The solution must clearly define and isolate execution contexts, including:

• Execution in the context of the logged-on user
• Execution using dedicated service identities where required
• Execution within application sandboxes (e.g., add-in environments)

Each context must be restricted to the minimum permissions required.

🔗Identity and Access Management

The solution must integrate with existing identity systems (e.g., Active Directory, Entra ID) and:

• Prefer delegated permissions over broad application permissions
• Use application permissions only where technically necessary
• Apply fine-grained and minimal API scopes
• Require administrative consent only during initial setup, not during normal operation

🔗Data Protection Requirements

A suitable solution must ensure that all data processing remains within the organization’s controlled environment:

• No routing of emails through third-party systems
• No transfer of directory or mailbox data to external services
• No dependency on vendor-operated processing components
• No telemetry or usage tracking outside the organization

All processing must occur within:

• Client devices
• Customer-controlled infrastructure
• Existing messaging and directory systems

🔗Threat and Risk Requirements

The architecture must minimize exposure to common risks by:

• Avoiding manipulation of mail flow (no re-routing or rewriting via external systems)
• Ensuring directory and mailbox data remain within trusted boundaries
• Avoiding introduction of additional internet-facing processing components
• Preventing dependency on externally operated runtime services

🔗Software Integrity and Supply Chain Requirements

The solution must provide mechanisms to ensure integrity and transparency of the software supply chain:

• All executable components must be digitally signed
• Release artifacts must support integrity verification (e.g., hashes)
• Dependencies must be:
  • Clearly identifiable
  • Version-pinned
  • Reviewed prior to release
• Releases must be:
  • Versioned
  • Documented
  • Tested before production deployment

Customers must be able to control update timing and validate software before use.

🔗Application Integration Requirements

If application-based extensions (e.g., add-ins) are used, the solution must ensure:

• Execution within the security model of the host application
• Customer-controlled deployment and versioning
• Self-hosting capability without mandatory middleware or proxy services
• Direct interaction with customer-controlled systems (e.g., mailbox storage)

🔗Separation of Concerns and Trust Boundaries

The solution must respect and maintain clear trust boundaries between:

• Client devices (execution and user interaction)
• Directory services (identity and attribute data)
• Messaging systems (mailbox and configuration data)
• Template storage (business-managed content)

No new critical dependencies or trust boundaries should be introduced.

🔗Summary of Requirements

A suitable solution must:

• Operate within existing trusted environments
• Avoid external data processing and dependencies
• Enforce strict least-privilege access control
• Provide transparent and verifiable software delivery
• Support flexible deployment models for complex environments
• Meet regulatory and organizational security requirements

🔗Comparison of Different Solutions

🔗Pricing Benchmark

Also consider the total cost of ownership (TCO) over several years. Some competitors include automatic annual price increases of 8% or more in the fine print.

🔗Detailed Comparison Benchmark

🔗Recommendation: Set-OutlookSignatures

After gathering customer requirements and testing several server- and client-based products, we recommend using the free open-source software Set-OutlookSignatures with the paid "Benefactor Circle" extension.

🔗Alignment with Architecture and Security Requirements

The requirements defined in the section Architecture and Security Requirements provide a neutral baseline for evaluating suitable solutions.

Set-OutlookSignatures fulfills these requirements as follows:

• Architectural separation of concerns
  Implements a clear distinction between signature generation and provisioning, enabling flexible deployment and scalable operation.

• Flexible execution models
  Supports both client-side and centralized execution models, which can be combined depending on endpoint management and operational requirements.

• Standards-based provisioning mechanisms
  Uses native client capabilities, mailbox-based configuration, and optional add-in integration to ensure consistent availability across platforms.

• Least-privilege security model
  Operates primarily in the security context of the logged-on user, with clearly defined and limited use of service accounts where required.

• Controlled identity and API access
  Integrates with existing identity systems using delegated permissions and minimal required API scopes, avoiding excessive privileges.

• Data sovereignty by design
  Ensures that all processing remains within the organization’s infrastructure, with no routing of emails or directory data through external systems.

• Reduced attack surface
  Avoids mail flow manipulation and eliminates the need for external processing components, thereby minimizing security exposure.

• Software integrity and transparency
  Provides signed releases, verifiable artifacts, and a controlled, versioned release process, enabling independent validation before deployment.

• Application integration without additional trust boundaries
  The Outlook add-in operates within the host application’s security model and does not introduce intermediary services or external processing layers.

• Compatibility with complex enterprise environments
  Supports hybrid, multi-tenant, and multi-forest scenarios while respecting existing trust boundaries and operational models.

This alignment demonstrates that Set-OutlookSignatures not only meets the defined requirements but does so using approaches consistent with enterprise architecture and security best practices.

🔗Supporting Technical Documentation

For detailed technical architecture, security model, and audit-relevant information, refer to:

• Architecture considerations
• Security considerations
• Security questionnaire (audit & compliance)
• https://set-outlooksignatures.com/outlookaddin#configuration-and-deployment

🔗General Description

Set-OutlookSignatures is a free open-source product with a paid add-on for advanced enterprise features.

It supports all variants of Outlook and Exchange as target platforms: Windows, macOS, Android, iOS, Linux, and Web. Both classic and new Outlook. On-premises, hybrid, and cloud-only. By optionally storing signatures in the mailbox, they are also available in other email clients.

Signature management is centralized and can be fully or partially delegated, e.g. to marketing, on a per-template basis. Only Microsoft Word is required for management; HTML knowledge is optional.

Signature generation and distribution can be done in three combinable ways:

• Locally on clients: This is the preferred method, as most unused computing power is available on clients (Windows, Linux, macOS).
• On one or more servers: Signatures are pre-generated centrally and written into users' mailboxes. This method requires high central computing power and cannot account for client-side settings. It is the preferred method for users who only use Outlook for the web, iOS, Android, or other email clients.
• Via the Outlook add-in: This allows access to signatures created by the other methods, and also enables independent signature creation and insertion. This mode supports granular rules based on many properties of the current item (e.g., recipients, sender, subject, and more).

All three methods support all types of email encryption, and integration into clients secured with AppLocker and other mechanisms (e.g., Microsoft Purview Information Protection) is technically and organizationally straightforward using established practices such as digitally signed PowerShell scripts.

The architecture ensures that no data leaves existing system, there is no transmission to external providers.

Any number of independent instances can be operated, which is beneficial for phased rollouts or for companies loosely affiliated with a corporate group.

🔗Licensing Model and Cost-Benefit Analysis

The free part of the software is licensed under the "European Union Public License (EUPL) 1.2", which is recognized by international organizations as a full open-source license and is compatible with many other comparable licenses.

The Benefactor Circle add-on is licensed based on the number of mailboxes intended to use it. There is no need to name mailboxes individually.

By avoiding tiered pricing and discounts, the cost-benefit ratio is already favorable even for a small number of mailboxes.

🔗Support from the IT Service Provider

As an IT service provider, we not only recommend Set-OutlookSignatures, but also offer comprehensive support to our clients.

We share our experience gained during the definition of requirements for a signature solution, the evaluation and comparison of different products, and the implementation of Set-OutlookSignatures and the Benefactor Circle add-on.

For companies within the group that wish to implement the solution independently, we recommend starting with the Quickstart guide. Thanks to the extensive documentation, clients can usually implement Set-OutlookSignatures and the Benefactor Circle add-on on their own in a short amount of time.

We offer support to all group companies in the form of workshops and training sessions. The following list represents the maximum scope, both in terms of content and time, within a full preparation and implementation project. Complete implementation support in a "train the trainer" format rarely takes more than half a day.

🔗Consulting and Imp/lementation Phase

🔗Initial Alignment on Textual Signatures

Participants

• Client: Corporate Communications, Marketing, Client Management, Project Coordinator
• IT Service Provider: Mail Product Management, Mail Operations, or Mail Architecture

Content and Objectives

• Client: Presentation of desired features for textual signatures
• IT Service Provider: Brief overview of general possibilities for textual signatures, pros and cons of different approaches, rationale for the recommended product
• Alignment of client requirements with technical and organizational capabilities
• Live demonstration of the product considering client requirements
• Definition of next steps

Duration

• 2 hours

🔗Template Manager Training

Participants

• Client: Template Managers (Corporate Communications, Marketing), optionally Client Management, Project Coordinator
• IT Service Provider: Mail Product Management, Mail Operations, or Mail Architecture

Content and Objectives

• Summary of the previous "Initial Alignment" session, focusing on desired and feasible features
• Introduction to the structure of the template directories, focusing on:
  • Naming conventions
  • Application order (general, group-specific, mailbox-specific, alphabetically within each group)
• Definition of default signatures for new emails and for replies/forwards
• Definition of out-of-office messages for internal and external recipients
• Definition of template validity periods
• Use of variables and user photos in templates
• Differences between DOCX and HTML formats
• Options for including disclaimers
• Collaborative creation of initial templates based on existing templates and client requirements
• Live demonstration on a standard client with a test user and test mailboxes (see prerequisites)

Duration

• 2 hours

Prerequisites

• Standard client with Outlook and Word available
• Screen content must be projectable via beamer or displayed on a sufficiently large monitor
• Client provides a test user who must:
  • Be allowed to download files from the internet (github.com) once (alternatively, a BitLocker-encrypted USB stick can be used)
  • Be allowed to execute signed PowerShell scripts in Full Language Mode
  • Have a mail mailbox
  • Have full access to various test mailboxes (personal or group mailboxes), ideally members of various groups or distribution lists. Access can be granted via permissions or by providing credentials.

🔗IT Team Training

Participants

• Client: IT, optionally an Active Directory administrator, optionally a File Server and/or SharePoint administrator, optionally Corporate Communications and Marketing, Project Coordinator
• IT Service Provider: Mail Product Management, Mail Operations, or Mail Architecture, optionally a representative from the client team

Content and Objectives

• Summary of the previous "Initial Alignment" session, focusing on desired and feasible features
• Overview of software operation
• Client system requirements (Office, PowerShell, AppLocker, digital signature of software, network ports)
• Server system requirements (template storage)
• Integration options (logon script, scheduled task, desktop shortcut)
• Software parameterization, including:
  • Template folder paths
  • Consider Outlook for the web?
  • Consider out-of-office messages?
  • Which trusts to include?
  • How to define additional variables?
  • Allow user-created signatures?
  • Store signatures in an additional path?
• Joint testing based on previously created templates and client requirements
• Definition of next steps

Duration

• 2 hours

Prerequisites

• Client provides a standard client with Outlook and Word
• Screen content must be projectable via beamer or displayed on a sufficiently large monitor
• Client provides a test user who must:
  • Be allowed to download files from the internet (github.com) once (alternatively, a BitLocker-encrypted USB stick can be used)
  • Be allowed to execute signed PowerShell scripts in Full Language Mode
  • Have a mail mailbox
  • Have full access to various test mailboxes (personal or group mailboxes), ideally members of various groups or distribution lists. Access can be granted via permissions or by providing credentials
• Client provides at least one central SMB share or SharePoint document library for template storage
• Client provides a central SMB file share for storing the software and its components

🔗Testing, Pilot Operation, Rollout

Planning and coordination of testing, pilot operation, and rollout is handled by the client's project lead.

The actual technical implementation is carried out by the client. If the client's IT service provider also manages the client systems, the client team supports integration of the software (logon script, scheduled task, desktop shortcut).

In case of fundamental technical issues, the mail product management team assists with root cause analysis, develops solution proposals, and, if necessary, establishes contact with the software vendor.

Creating and maintaining templates is the responsibility of the client.

🔗System Requirements

Client

• Outlook and Word (when using DOCX templates and/or RTF-format signatures), version 2010 or newer
• The software must run in the security context of the currently logged-in user
• The software must be executed in "Full Language Mode"; "Constrained Language Mode" is not supported
• If AppLocker or similar solutions are used, the software is already digitally signed
• Network access requirements:
  • Ports 389 (LDAP) and 3268 (Global Catalog), both TCP and UDP, must be open between the client and all domain controllers. If not, signature-related information and variables cannot be retrieved. The software checks access on each run
  • For access to the SMB file share containing software components, the following ports are required: 137 UDP, 138 UDP, 139 TCP, 445 TCP (see this Microsoft article for details).
  • For access to Microsoft SharePoint document libraries, port 443 TCP is required. Firewalls and proxies must not block WebDAV HTTP extensions

Server

• An SMB file share where the software and its components are stored. All users must have read access to this share and its contents
• One or more SMB file shares or SharePoint document libraries where templates for signatures and out-of-office messages are stored and managed

If templates use variables (e.g., first name, last name, phone number), the corresponding values must exist in Active Directory. In the case of linked mailboxes, attributes of the current user and the mailbox (which may reside in different AD forests) can be distinguished.

As described in the system requirements, the software and its components must be stored on an SMB file share. Alternatively, it can be distributed to clients via any mechanism and executed locally.

All users need read access to the software and its components.

As long as these requirements are met, any SMB file share can be used, for example:

• The NETLOGON share of Active Directory
• A share on a Windows server (single server or cluster, classic share or DFS in any variation)
• A share on a Windows client
• A share on any non-Windows system, e.g., via SAMBA

As long as all clients use the same version of the software and configure it only via parameters, a central storage location for the software components is sufficient.

For maximum performance and flexibility, we recommend that each client stores the software in its own SMB file share and replicates it across locations if needed.

Unlike templates and configurations, storing the software itself on SharePoint Online is not supported.

Template Storage
As described in the system requirements, templates for signatures and out-of-office messages can be stored on SMB file shares or SharePoint document libraries, similar to the software itself.

SharePoint document libraries offer the advantage of optional file versioning, allowing template managers to quickly restore a previous version in case of errors.

We recommend at least one share per client, with separate subdirectories for signature and out-of-office templates.

Users need read access to all templates.

By simply assigning write permissions to the entire template folder or individual files, the creation and management of signature and out-of-office templates can be delegated to a defined group of people. Typically, templates are defined, created, and maintained by Corporate Communications and Marketing departments.

For maximum performance and flexibility, we recommend that each client stores the software in their own SMB file share and replicates it across locations if needed.

Templates and configuration files can also be stored on SharePoint Online.

Template Management and Delegation
By assigning write permissions to the template folder or individual files, the creation and management of signature and out-of-office templates can be delegated to a defined group of people. Typically, templates are defined, created, and maintained by Corporate Communications and Marketing departments.

The software can process templates in DOCX or HTML format. For initial use, DOCX format is recommended. The reasons for this recommendation and the pros and cons of each format are described in the software's FAQ.

The online documentation of the software provides an overview of how templates should be managed so that they:

• Apply only to specific groups or mailboxes
• Are set as default signatures for new emails or replies and forwards
• Are used as internal or external out-of-office messages
• And much more

The online documentation of the software and sample templates also describe:

• Replaceable variables
• Extension with custom variables
• Handling of photos from Active Directory

The included sample file "Test all signature replacement variables.docx" contains all standard variables. Additional custom variables can be defined as needed.

Executing the Software
The software can be executed using any mechanism, for example:

• At user login, as part of the logon script or as a standalone script
• Via Task Scheduler at fixed times or triggered by specific events
• Manually by the user, e.g., via a desktop shortcut
• Through a client management tool

Since Set-OutlookSignatures is primarily a PowerShell script, it is executed like any other script of this type:

powershell.exe <PowerShell-Parameter> -File "<Pfad zu Set-OutlookSignatures.ps1>" <Script-Parameter>  

Parameterization
The behavior of the software can be controlled via parameters. Particularly relevant are SignatureTemplatePath and OOFTemplatePath, which specify the path to the signature and out-of-office templates.

Below is an example where the signature templates are located on an SMB file share and the out-of-office templates in a SharePoint document library:

powershell.exe -File "\\example.com\netlogon\set-outlooksignatures\set-outlooksignatures.ps1" -SignatureTemplatePath "\\example.com\DFS-Share\Common\Templates\Signatures Outlook" -OOFTemplatePath "https://sharepoint.example.com/CorporateCommunications/Templates/Out-of-office templates"

At the time of writing this document, additional parameters were available. Below is a brief overview of the options; for details, refer to the online documentation of the software:

• SignatureTemplatePath: Path to the signature templates. Can be an SMB share or a SharePoint document library.
• ReplacementVariableConfigFile: Path to the file where custom variables deviating from the default are defined. Can be an SMB share or a SharePoint document library.
• TrustsToCheckForGroups: By default, all trusts are queried for mailbox information. This parameter allows specific domains to be excluded and non-trusted domains to be added.
• DeleteUserCreatedSignatures: Should user-created signatures be deleted? By default, this does not happen.
• SetCurrentUserOutlookWebSignature: By default, a signature is set in Outlook for the web for the logged-in user. This can be disabled with this parameter.
• SetCurrentUserOOFMessage: By default, the text of the out-of-office messages is set. This behavior can be changed with this parameter.
• OOFTemplatePath: Path to the out-of-office templates. Can be an SMB share or a SharePoint document library.
• AdditionalSignaturePath: Path to an additional share where all signatures should be copied, e.g., for access from a mobile device and to simplify configuration of clients not supported by the software. Can be an SMB share or a SharePoint document library.
• UseHtmTemplates: By default, templates in DOCX format are processed. This switch allows switching to HTML (.htm).

The online documentation of the software contains additional parameters.

Runtime and visibility of the software
The software is designed for fast execution and minimal network load, but its runtime still depends on many parameters:

• general performance of the client (CPU, RAM, HDD)
• number of mailboxes configured in Outlook
• number of trusted domains
• response time of domain controllers and file servers
• response time of Exchange servers (setting signatures in Outlook for the web, out-of-office messages)
• number of templates and complexity of variables (e.g., photos)

Under the following conditions, a reproducible runtime of approximately 30 seconds was measured:

• standard client
• connected to the corporate network via VPN
• 4 mailboxes
• querying all AD domains connected via trust
• 9 signature templates to process, all with variables and graphics (but without user photos), some restricted to groups and mail addresses
• 8 out-of-office templates to process, all with variables and graphics (but without user photos), some restricted to groups and mail addresses
• setting the signature in Outlook for the web on-prem
• no copying of signatures to an additional network path

Since the software requires no user interaction, it can be executed minimized or hidden using standard mechanisms. This makes the runtime practically irrelevant.

Use of Outlook and Word during runtime
The software does not start Outlook; all queries and configurations are performed via the file system and registry.

Outlook can be started, used, or closed at any time during the software's execution.

All changes to signatures and out-of-office messages are immediately visible and usable by the user, with one exception: if the name of the default signature for new emails or for replies and forwards changes, this change only takes effect after restarting Outlook. If only the content changes but not the name of a default signature, the change is immediately available.

Word can also be started, used, or closed at any time during the software's execution.

The software uses Word to replace variables in DOCX templates and to convert DOCX and HTML to RTF. Word is started as a separate invisible process. This process is practically unaffected by the user and does not interfere with Word processes started by the user.

🔗Ongoing Operations

As an IT service provider, we also support our group companies in the ongoing operation of Set-OutlookSignatures with our full expertise. This includes, for example, questions about:

• Creating and maintaining templates
• Creating and maintaining storage shares for templates and software components
• Setting and maintaining AD attributes or attributes in other data sources
• Configuration adjustments
• General questions regarding day-to-day operations