TABLE OF CONTENTS

• Introduction
• Use Cases
  • End-Users Surveys
  • Test Sign-Offs
  • Deployment Units
  • Event Notifications
  • Account Administration
  • Proactive Support
  • Direct Emails
• Configuration
  • Email Options
    • Traditional SMTP
    • Azure Email (User/Pass)
  • Default Sender Details
• Tracking Email
  • Email Queue
• Further Support

Introduction

Email is a core requirement within many IT transformation programmes because it provides a reliable, familiar, and scalable way to raise awareness and drive engagement users. In practice, successful adoption of new platforms depends on timely notifications, clear messaging, and consistent engagement with end-users - areas where email continues to perform well. It is also a critical channel for notifying suppliers, partners, and other stakeholders who require operational alerts and workflow notifications. 

This article outlines the supported email use cases within ManagementStudio and discusses how email is implemented at a technical level to ensure dependable delivery, security, and traceability.

Use Cases

End-Users Surveys

ManagementStudio allows end-users to view or input data directly into ManagementStudio via a dedicated web page.  Administrators are able to create landing pages, otherwise known as Portal Forms, for a variety of scenarios.  For example: to capture satisfaction feedback after a hardware upgrade, validate information held about a user, or to review application owner and licensing information. 

Portal Forms are supported in the following modules:

• Applications
• User Migrations
• Devices
• Mailboxes
• Bespoke
• Deployment Units
• Defects
• Tasks
• Contacts

ManagementStudio automatically creates three types of email with a new Portal Form:

• Request Email: This is often a user's first touch point with the Portal Form and is used to introduce the survey to the recipient, and provide a unique link to the Portal Form hosted by ManagementStudio.
• Reminder Email: If the recipient hasn't completed the survey after a period of time, a gentle reminder will be sent by ManagementStudio.
• Complete (Confirmation) Email:  Upon completion of the survey, ManagementStudio will send an email to acknowledge receipt. The confirmation email could be extended to include useful links or provide next steps.

The subject, content, reminder threshold, and conditional email rules can be viewed/changed in Administration > Portal Settings > Portal Forms > [Portal Form] > Email Options.

Further Reading:

• Portal Forms (Surveys) - Form Setup
• How to Setup Conditional Emails

Test Sign-Offs

ManagementStudio allows project administrators to define and manage tests for a variety of scenarios. These are referred to as Test Sign-Offs. Typical applications include User Acceptance Testing (UAT), Quality Assurance (QA), and Compatibility Testing.  By configuring Test Sign-Offs, administrators can:

• Create a set of questions tailored to specific scenarios (such as application testing on physical or virtual desktops)
• Notify designated testers via email when a test is ready
• Collect test responses from end-users
• Report on the test outcomes

Test Sign-Offs are supported in the following modules:

• Applications
• User Migrations
• Devices
• Mailboxes
• Bespoke
• Deployment Units
• Defects

Email is used to provide testing information to testers, as well as providers reminders, updates, and completion notification.  The email subject and content templates for the following email types can be defined:

• Request Email: This is typically sent after the test has been generated in ManagemenStudio and contains the URL to access the Test Sign-Off, RDP file to access test machines (if specified), and a calendar file for the duration of the test window.
• Reminder Email: A reminder is sent to all testers that haven't completed the test within a set period of time (default to 14 days).
• Complete (thank you) Email: If enabled, ManagementStudio will automatically send notification to the tester upon submission of the test.
• Updated Test Email: Any changes to the test, such as testing window or test machine, are captured in the 'Updated Test Email'.  Unlike the 'Request Email', this is not subject to reminders.
• Cancelled Test Email: If the test is cancelled, the tester will receive notification by email.

The subject, content template, and reminder threshold can be viewed/changed in Administration > Portal Settings > Test Sign-Offs > [Test Sign-Off] > Email Options or Settings respectively.

Further Reading:

• Test Sign-Off

Deployment Units

Deployment Units (DU) provide a way to simplify the organisation and planning of the project delivery phase by grouping users (or devices) into logical groups, typically based on business unit or location.  Users are allocated to slots in the DU where work (upgrades, rebuild, hardware handover, account migration, etc) is set to occur.

Email is an essential communication tool for deployment teams to help drive activity with colleagues, maximise engineering time, and reduce no-shows:

• Invite a colleague to choose their migration slot.
• Remind a colleague to choose their migration slot.
• Confirm the migration slot booking.
• Notify of updates or changes to a colleague's migration slot.
• Notify of cancelled migration slots. 

Further Reading:

• Deployment Units

Event Notifications

ManagementStudio console users have the ability to define alerts that are specific to their role or interests.  The alerts are displayed in the UI and by email, and will only be displayed to that user.

Alerts triggers are defined against modules and can be scoped to all events, only those that impact that user, or match a process/Blueprint filter.  For example:

• Notify me when a device is assigned to me
• Notify me when a defect is created
• Notify me when a contact is flagged for deletion
• Notify me when an attachment is added to an application record
• Notify me when a user is moved in to the 'Ready to Migrate' process

The ability to change the content of system emails (including event notifications) is provisionally targeted for v16.

Further Reading:

• How to Setup Notifications

Account Administration

To lower the risk of leaks and misuse, local ManagementStudio user account passwords are set/reset by the named user - not the ManagementStudio administrator.  This concept is employed in two scenarios:

• New user account
• Password reset

In both cases, ManagementStudio sends a time-limited link to the named user to ensure they are responsible for setting/resetting the password.  Email is essential to this functionality; without it, there is no other way to set passwords for local accounts.

The subject, content, recipient, and sender details can be changed in Administration > PS Scripts, Emails, Buttons > Email Templates > [Project Name]:

• New Account Email
• Reset Password Email

Note: This does not apply to user accounts that are configured for single sign-on (SSO).

Further Reading:

• User Accounts

Proactive Support

ManagementStudio ships with the ability to notify the development team of excessive errors or timeouts recorded within a rolling two-week window.  Many environmental or infrastructure related issues that culminate in a loss of service can often be prevented when we have the ability to proactively work with you to resolve any issues before they become a major problem.

This feature is managed in Administration > Global Settings > Troubleshooting > Email Core Logs (Weekly on Thursdays).

Direct Emails

To enable administrators to use email for ad hoc or project-specific tasks, ManagementStudio also enables email to be manually triggered directly from the main grid, or through an automation plan using the Evergreen Servicing Engine (ESM).  For example:

• Manually: A collection of colleagues form a small pilot group and require instructions on how to test their applications stack.  Since this is a one-time activity, the email is sent manually.
• Automatically: As colleagues moves through the hardware refresh programme, they will receive email at different times to ensure the communication is timely and relevant to the stage that they're at.  E.g. when a user is selected for migration, they would receive a welcome email or invitation to book their migration slot.

The ability to send email manually is controlled by Role Group permissions and is granular across each module. For example, an administrator might have permission to send emails to User Migrations but not to the primary user of a computer tracked in the Devices module.

Configuration

The core email service is typically configured in Administration under Global Settings, with project-specific variations handled in Project Settings.  Support is provided for traditional SMTP-based services and Microsoft Azure Email.

Email Options

Found in Administration > Global Settings > Email Settings:

• Globally Enable Email: Controls ManagementStudio's ability to send email.  When unticked, ManagementStudio will be unable to send email, regardless of the project or activity.
• Per Minute Send Limit: Limits the number of emails that can be sent per minute to accommodate throttling by mail providers, such as Microsoft Office 365.
• Retry Limit: Defines how many times ManagementStudio should try to send the same email if transmission fails during to a network or other infrastructure issue.
• Email Server:
  • Traditional SMTP
  • Azure Email (User/Pass)
  • Azure Email (Client Secret)
  • Azure Email (Certificate)

Traditional SMTP

• SMTP Server Address: The DNS name of the SMTP server.  For Office 365, using smtp.office365.com is recommended.
• Email Server Port: Typically 465 or 587; custom ports are supported.
• SSL Options:
  • None
  • Auto: The mail service will determine which SSL or TLS options to use
  • SslOnConnect: The connection uses SSL or TLS immediate
  • StartTls: Elevates the connection to use TLS encryption immediately after reading the greeting and capabilities of the email server. If the server does not support the STARTTLS extension, the connection will fail.
  • StartTlsWhenAvailable: Elevates the connection to use TLS encryption immediately after reading the greeting and capabilities of the server, but only if the server supports the STARTTLS extension.
• Trusted Connection: Use if the ManagementStudio server is whitelisted by the SMTP relay and does not require credentials (only recommended for internal lab use).
• Email Account Username: Specify the username to be used if username/password authentication with the SMTP relay is required.
• Email Account Password: Specify the password to be used if username/password authentication with the SMTP relay is required.

Azure Email (User/Pass)

ManagementStudio supports send email through the Microsoft Graph API or Exchange Online SMTP (Office 365) in scenarios where OAuth authentication is desirable.

Both methods rely on an Azure Enterprise Application for authentication using one of the following mechanisms:

• Username/Password (limited functionality and cannot be used with MFA)
• Client Secret
• Certificate

Configuring Azure Email will require the following information:

• Tenant ID
• Client ID (Application ID)
• Client Secret or Certificate details (if applicable)
• Sender email address
• SMTP server and port (for traditional SMTP)
• Any other relevant connection details

Further Reading:

• OAuth 2.0 Authentication

Default Sender Details

Emails are sent from the default sender details for the project, defined in Administration > Project Settings > Email & Keywords:

• Email From Address
• Email From Display Name

Alternative sender details are specified by changing the From Name and From Address directly on the email template:

• Administration > PS Scripts, Emails, Buttons > Email Templates > [Module], or
• Administration > [Module] > Email Templates

The From Name and From Address fields are hidden by default; use the Column Picker in the toolbar to enable these fields for the grid.

Further Reading:

• Email Templates

Tracking Email

Email Queue

The Email Queue within ManagementStudio provides key information about emails that are waiting to be processed and those that have already been sent:

• Sent: True/False.
• Try Count: Default to 3 attempts, configured in Administration > Global Settings > Email Settings.
• Sent At (Server Time): The date/time that an email was successfully sent.
• Schedule At (Server Time): The date/time an email is scheduled to be sent.
• Email Template: The internal email template used for the message.
• To Address: The recipient's email address; typically the 'Email' field.
• Subject: The subject of the appear as it appears in the recipient's email client.
• Module Name: The module that the email was sent from.  E.g. User Migrations.
• InstanceId: The recipient's ManagementStudio ID, where appropriate.
• Last Opened: The date/time when the email was last opened.
• Open Count: The number of times the email was opened or displayed in the email client preview pane.
• Error Message: Any errors that have been encountered whilst sending email.

These statistics are also exposed to Datamining Reports, Portal Forms, and Test Sign-Offs to enhance reporting and visibility of email engagement.

Further Reading:

• Email Templates
• Datamining Tiers - Reporting Tiers
• Email Errors
• Project Settings (Section: Email Template Wrapper)

Further Support

For further assistance, visit the ManagementStudio Service Desk to search the knowledge base or create a new support ticket.