Overview | Installing and Configuring the System Manager | Starting and Stopping the System Manager | Checking Expiration Dates and Auto Expiring Users | Item Cleanup with the System Manager | Obtaining the Client Installer Files | Sending Email with the System Manager
Overview
The System Manager functions as an Email Manager service for Aeon. You send an email, check email status, and resend the email from within the Aeon Desktop Client. You can also send emails from the User Information page in the Aeon Web Client. All email processes are handled by the System Manager. The Aeon System Manager will send emails through whichever SMTP server is configured with Aeon. All emails originate from the Aeon server, enabling you to restrict SMTP access to a single IP address.
In addition, the System Manager can be set to check for expired user accounts and change the value of those accounts to a pre-determined status. System Manager can also be configured to automatically clean up electronic delivery files at after a specified number of days. Reference request emails are also sent to the Aeon Desktop Client via the System Manager. The System Manager runs its checks 1 minute after the service is started and every 12 hours thereafter.
Installing and Configuring the System Manager
The System Manager is installed by default for all Aeon installations. Configuring the System Manager to send email and monitor expired user accounts is explained below.
Starting and Stopping the System Manager
You can start and stop the System Manager, if needed, by going to the Services application on the Aeon server and clicking on Aeon System Manager. Click the Stop, Restart or Start commands as necessary.
Checking Expiration Dates and Auto Expiring Users
The System Manager routinely monitors the expiration date of cleared user accounts. You can set keys to prompt the System Manager to auto-expire cleared users who have reached their expiration date and to change the user's Cleared status to a status of your choosing.
Configuring the Expired Users Keys
The System Manager can be configured to use the following keys to check for expired users and update their status. The keys are found in the System:System section of the Aeon Customization Manager.
Which customization keys are used?
|
Key |
Description |
|---|---|
|
AutoExpireUsers |
Determines if the System Manager should automatically expire users who have reached their expiration date. The system will update the cleared value of expired users to the value specified by the AutoExpiredUsersClearedValue key. Key values are Yes or No. |
|
AutoExpireUsersClearedValue |
Determines the new cleared value that the System Manager will set for expired users. This value is not used if the AutoExpiredUsers key is set to No. |
|
RenewedUsersClearedValue |
If the AutoExpireUsersClearedValue key is set to EXP, the cleared status for expired users is set to Yes after they review and update their user information. This value is not used if the AutoExpiredUsers key is set to No. The only accepted values for this key are "Yes" and "No". |
Setting Cleared Values
Value options for the AutoExpireUsersClearedValue key:
- Yes: Changes the user's cleared value back to Cleared.
- No: Changes the user's cleared value to Not Cleared. The user must go through the clearance process again.
- New: Prompts the DLL to display the New Auth Information form so the user can update their account information. If the NewAuthRegistration.html is not available the system will use ChangeUserInformation.html. Once they've updated their information their cleared value will be set back to No to go through the clearance process again. (This value is intended for installations using Remote Authentication.)
- EXP: Prompts the DLL to display the Change User Information form so the user can update their account information. A custom ExpiredUsers.html page can also be used. Once the expired user has updated their information the cleared status is changed to the value set in the RenewedUsersClearedValue key (default value is Yes).
The Disavowed value should not be used for this key because the actual disavow process will not be automatically performed.
The expiration date for user accounts is set in the Customization Manager using the UserExpiration key.
Item Cleanup with the System Manager
The system manager employs an Item Cleanup tool that automatically removes all electronic files from the web server after a specified amount of time so that files do not have to be removed manually. When the system manager runs, it deletes electronic files found in the default location on the web server specified by the WebDeliveryPath customization key. If the WebDeliveryPath key value is blank, the system manager will attempt to use the WebPath key value appended with \pdf.
To determine if a file should be removed, the system manager looks at the PhotoduplicationDate and the PhotoduplicationStatus fields of the request associated with the file. If PhotoduplicationDate is older than the number of days defined by the DaysBeforeElectronicDeliveryCleanup key and if the PhotoduplicationStatus is one with an ItemDelivered state code, the file is removed and the Photoduplication status of the request is updated to Order Finished.
This process will also clean up all the files with a last modified date older than the days represented by DaysBeforeElectronicFileCleanup key, if the transaction record contains a non-null photoduplication status and the username exists in the username table. In this part of the cleanup, those transactions which also have a Photoduplication Status with an Item Delivered state code will be routed to Order Finished.
Deleting electronic files affects only the Photoduplication status of the request. It does not affect the transaction status of the request.
In the user's web account, the request will remain in the Outstanding Requests table until the transaction status is changed to Request Finished. At that time, the request will move to the list of finished requests and can be viewed in the user's request history.
Obtaining the Desktop Client Installer Files
The System Manager stores the installer files and other necessary information in the AeonUpdates folder located within the Aeon web directory (default location C:\Program Files (x86)\Aeon\Web\AeonUpdates). This folder contains a file named ClientUpdates.xml that details the latest available desktop client version and the path to retrieve the desktop client installer file. The System Manager will check the Atlas servers for new desktop client releases 10 seconds after startup, after which it will resume the behavior of only checking once every 15 minutes.
There are two types of installers:
- The installer ("AeonClientSetup") that is used for new installations and major updates (updates than involve a major version number change, for example updating from 4.0 to 5.0)
- The updater ("AeonClientUpdate") that is used for updating existing desktop clients within a major version, for example, 5.0.2 to 5.0.3.
The System Manager will only keep the latest version of the setup and update installers. Older versions are overwritten.
The System Manager runs the following process to obtain the desktop client installer files:
- Checks the value of the VersionClient customization key to see what version of the Aeon Desktop Client is currently running.
- Retrieves the ClientUpdates.xml file from Atlas. This file provides the latest desktop client version and the location of the setup and updater installers for each major release (e.g. 4.0, 5.0, 5.1).
- Compares its VersionClient customization key against the latest version available from Atlas.
- If a newer version is available, or if the versions match but System Manager does not currently have its AeonUpdates directory and files set up, it will update its hosted files.
- Special case: If for some reason System Manager has a later version of the desktop client than Atlas has made available, it will not download the latest Atlas versions even if its AeonUpdates directory has not yet been created.
- Updating its hosted files involves:
- Downloading the two latest desktop client installers for the release and copying them into a subdirectory of AeonUpdates named Client. As of Aeon 5.2:
- The setup installer file will be located in the Client\Install subfolder
- The updater installer file will be located in the Client\Update subfolder
- Building its own ClientUpdates.xml file for its Aeon Desktop Clients to read, which will be hosted in AeonUpdates and will point to the installer files in AeonUpdates/Client.
- Downloading the two latest desktop client installers for the release and copying them into a subdirectory of AeonUpdates named Client. As of Aeon 5.2:
- Updating its VersionClient customization key to the version number of the newest desktop clients it has made available.
Sending Email with the System Manager
Configuring the SMTP Keys
The System Manager uses the following SMTP keys for sending an email. The keys are found in the System:Email section of the Aeon Customization Manager. If you are hosted with Atlas, these keys can be set to send either via your internal SMTP server or one supplied by Atlas for your site.
Which customization keys are used?
|
Key |
Description |
|---|---|
|
EMailSMTPServer |
The SMTP server used for sending emails from System Manager service on the server. |
|
EMailSMTPPort |
Port used for sending emails from System Manager service on the server. Defaults to port 25. |
|
SMTPUserID |
The user ID used for sending emails from System Manager service on the server. |
|
SMTPPassword |
The password used for sending emails from the System Manager service on the server. |
Reviewing Sent, Pending, and Failed Email
You can view the status of all emails that have been sent for a transaction on the Request form on the E-Mail Pane of the History tab. Emails that fail to send can be resent, cancelled (removed from the Aeon database table and not sent), resent as a batch, or resent individually. Resending an email gives staff the option to edit parameters such as an incorrect address or to change the wording in the email template body. Failed emails display an explanation of the failure in the Note column of the grid (e.g.,if there was an error from the mail server).
SMTP.config Customization
The SMTP configuration file (SMTP.config) should be used only in specific situations where your SMTP server requires additional settings that cannot be set using the standard customization keys.
The SMTP.config file must be in the same location as the System Manager in order to function properly. When placed with the System Manager, the SMTP.config will complement the settings from the Customization Manager. Note that each setting is optional. Options that are not required by your SMTP server can be removed from the configuration file.
A Sample SMTP.config File:
<p><?xml version="1.0"?><br /> <MailSettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<br /> xmlns:xsd="http://www.w3.org/2001/XMLSchema"><br /> <AllowExtensions>true</AllowExtensions><br /> <FirewallHost>127.0.0.1</FirewallHost><br /> <FirewallPassword>firewall_password</FirewallPassword><br /> <FirewallPort>0</FirewallPort><br /> <FirewallType>fwNone</FirewallType><br /> <OtherHeaders></OtherHeaders><br /> <SslAcceptServerCert></SslAcceptServerCert><br /> <SslCertEncoded></SslCertEncoded><br /> <SslCertStore>MY</SslCertStore><br /> <SslCertStorePassword></SslCertStorePassword><br /> <SslCertStoreType>sstMachine</SslCertStoreType><br /> <SslCertSubject></SslCertSubject><br /> <SslStartMode>sslAutomatic</SslStartMode><br /> <Timeout>120</Timeout><br /> <FullyQualifiedDomainName>mydomain.com</FullyQualifiedDomainName><br /> </MailSettings></p>Use this example if you need only to configure your fully qualified domain name:
<p><?xml version="1.0"?><br /> <MailSettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<br /> xmlns:xsd="http://www.w3.org/2001/XMLSchema"><br /> <FullyQualifiedDomainName>mydomain.com</FullyQualifiedDomainName><br /> </MailSettings></p>Optional Settings and Explanations
AllowExtensions
If AllowExtensions is true, the component will first send the EHLO greeting to the server; if that fails, the standard HELO command will be sent. True by default but may be disabled if it is known in advance that the MailServer doesn't support SMTP extensions.
FirewallHost
Name or IP address of firewall. If a FirewallHost is given, requested connections will be authenticated through the specified firewall when connecting.
FirewallPassword
The password property if authentication is to be used when connecting through the firewall. If FirewallHost is specified, the FirewallUser and FirewallPassword properties are used to connect and authenticate to the given firewall. If the authentication fails, a trappable error is fired.
FirewallPort
The TCP port for the FirewallHost. See the description of the FirewallHost property for details. Note that the FirewallPort is set automatically when FirewallType is set to a valid value. See the description of the FirewallType property for details.
FirewallUser
The user name property if authentication is to be used when connecting through a firewall. If FirewallHost is specified, the FirewallUser and FirewallPassword properties are used to connect and authenticate to the given firewall. If the authentication fails, a trappable error is fired.
FirewallType
Determines the type of firewall to connect through. The options are listed below.
fwNone (0) No firewall (default setting).
fwTunnel (1) Connect through a tunneling proxy. FirewallPort is set to 80.
fwSOCKS4 (2) Connect througha SOCKS4 Proxy. FirewallPort is set to 1080.
fwSOCKS5 (3) Connect througha SOCKS5 Proxy. FirewallPort is set to 1080.
The OtherHeaders Property
The OtherHeaders Property is an RFC 822 compliant string consisting of extra headers to be appended to the message headers created from other properties like SendTo, Subject, etc. The headers must of the format "header: value" as specified in RFC 822. Header lines should be separated by CRLF ("\r\ n"). The OtherHeaders property is useful for extending the functionality of the component. A good example is delivery of MIME encoded messages. SPECIAL CASE: If OtherHeaders starts with an empty line (CRLF), then the value of OtherHeaders is used instead of the normally computed message headers.
Use this property with caution. If OtherHeaders contains invalid headers, message delivery might not be successful.
SSLAcceptServerCert
Instructs the component to unconditionally accept the server certificate that matches the supplied certificate. If it finds any issues with the certificate presented by the server, the component will normally terminate the connection with an error.
You may override this behavior by supplying a value for SSLAcceptServerCert. If the certificate supplied in SSLAcceptServerCert is the same as the certificate presented by the server, then the server certificate is accepted unconditionally, and the connection will continue normally.
Please note that this functionality is provided only for cases where you otherwise know that you are communicating with the right server. If used improperly, this property will create a security breach. Use it at your own risk.
SslCertEncoded
The SSL certificate (PEM/base64 encoded). This property is used to assign a specific certificate for SSL client authentication (SSL server authentication in the case of the IPDaemonS component). The SSLCertStore and SSLCertSubject properties may also be used to specify a certificate.
When SSLCertEncoded is set, a search is initiated in the current SSLCertStore for the private key of the certificate. If the key is found, SSLCertSubject is updated to reflect the full subject of the selected certificate, otherwise SSLCertSubject is set to empty string.
SslCertStore
The name of the certificate store for the client certificate. The SSLCertStoreType property specifies the type of the certificate store specified by SSLCertStore. If the store is password protected, specify the password in SSLCertStorePassword. SSLCertStore is used in conjunction with the SSLCertSubject property in order to specify client certificates. If SSLCertStore has a value, and SSLCertSubject or SSLCertEncoded is set, a search for a certificate is initiated. Please refer to the SSLCertSubject property for details. Designations of certificate stores are platform-dependent.
The following are designations of the most common User and Machine certificate stores in Windows:
MY A certificate store holding personal certificates with their associated private keys.
CA Certifying authority certificates.
ROOT Root certificates.
SPC Software publisher certificates. When the certificate store type is PFXFile, this property must be set to the name of the file. When the type is PFXBlob, the property must be set to the binary contents of a PFX file (i.e., PKCS12 certificate store). If the provider is OpenSSL, the certificate store is a file containing a certificate and a private key. This property must be set to the name of the file.
SSLCertStorePassword
The password for the certificate store (if any). If the certificate store is of a type that requires a password, the value of this property is used to open the certificate store.
SSLCertStoreType
The type of certificate store for the client certificate.
0 (sstUser - default) For Windows, this specifies that the certificate store is a certificate store owned by the current user. For Java, this specifies that the certificate store is the name of a JKS (Java Key Store) file. If the provider is OpenSSL, this specifies that the certificate store is a file that contains PEM encoded certificate and private key.
1 (sstMachine) The certificate store is a machine store (not available in Java and when provider is OpenSSL).
2 (sstPFXFile) The certificate store is the name of a PFX (PKCS12) file containing certificates. If the provider is OpenSSL, the file may contain only one certificate and private key.
3 (sstPFXBlob) The certificate store is a string (binary or base64 encoded) representing a certificate store in PFX (PKCS12) format. This setting is currently not supported when the provider is OpenSSL.
4 (sstPEMKey) The certificate store is a string or filename that contains a PEM encoded certificate and private key. This store type is currently not supported in Java.
SSLCertSubject
The subject of the certificate used for client authentication. When this property is set, a search is performed in the current certificate store certificate with matching subject. If an exact match is not found, the store is searched for subjects containing the value of the property. When setting the property to a partial subject, CN= should be omitted. If a match is not found, the property is set to an empty string, and no certificate is selected. The special value "*" picks a random certificate in the certificate store. If a matching certificate is found, the SSLCertSubject property is set to the full subject of the matching certificate.
SSLStartMode
Determines how the component starts the SSL negotiation.
0 (sslAutomatic - default) If the remote port is set to the standard plaintext port of the protocol (where applicable), the component will behave the same as if SSLStartMode is set to sslExplicit. In all other cases, SSL negotiation will be implicit (sslImplicit).
1 (sslImplicit) The SSL negotiation will start immediately after the connection is established.
2 (sslExplicit) The component will first connect in plaintext, and then explicitly start SSL negotiation through a protocol command such as STARTTLS.
3 (sslNone) No SSL negotiation, no SSL security. All communication will be in plaintext mode.
Timeout
A timeout for the SMTP connection in seconds. If the Timeout property is set to 0, all operations will run uninterrupted until successful completion or until an error condition is encountered.
If Timeout is set to a positive value, the component will wait for the operation to complete before timing out. Please note that by default, all timeouts are inactivity timeouts, i.e., the timeout period is extended by Timeout seconds when data is successfully sent or received. The default value for the Timeout is 60 (seconds).
FullyQualifiedDomainName
A domain name that is used when sending the initial HELLO message to an SMTP server.