What are administration settings?

The Administration settings are high-level preferences intended for network administrators, IT support departments, or operators with administrator-level permissions; in other words, they're advanced settings used to configure your main Data Station once and then be forgotten.

While every operator with the proper security permissions can access the Administration module, it contains settings that most operators won't be able to configure without help. An operator's access to these settings is governed by Alexandria's security preferences. Your library's administrator can manage these settings in Tools > Preferences > Security.

Actions Menu

• Send Data to COMPanion. If a Customer Support Representative needs your library data for troubleshooting you can easily send it to us by selecting this option and entering the Authorization Code you are provided.
  
  

• Log Out. This button will log you out of Alexandria, despite if you have multiple windows open. 
  
  

• Quit Alexandria. This option will stop the Data Station from running and log out any active operators.

Navigation Bar

What does the status interface do?

Database Maintenance 

You have the ability to preserve and maintain your library catalog data by utilizing the following options through the status interface.

• Restore From Archive. Use this option to replace your current data folder with a previously created archive. This is useful if you need to undo a completed process such as imports or utilities. 

  Steps to restore from an archive.

  1. Click Restore From Archive, this will trigger a roll-down menu.

  2. From the list of Available Archives, select the archive date/time you would like to restore to; dates/times are listed as yyyy/mm/dd 24:00

  3. Click the Restore button to proceed. If you no longer want to restore simply click Cancel to abort the process. By clicking Restore your current data will be replaced by that contained in the selected archive folder. 
  4. Check the Delete the archived data after restoring box to remove the selected archive from your archive directory upon successful restoration. (optional) 
• Archive. Selecting this button performs an immediate, manual archive of your database. During an archive, all information in the data station's data folder is copied into the archive directory you've configured. While the archive is running all services on the data station are temporarily disabled. We recommend running an archive before making any large-scale changes to your database, such as imports, updates, utilities, or machine upgrades.
  
  
• Restart. Selecting this button will restart the data station remotely. During the restart duration, Alexandria services and modules will be unavailable to all operators.
  
  
• Database Maintenance. Selecting this button will examine your database files and perform patron, item, and circulation verification routines. If database damage is detected, it's automatically fixed. While maintenance is being performed the data station will be inaccessible. This process can also be scheduled to perform regularly. 

Send your patrons email notifications

To send email reminders, such as the Overdue Items Notice, you will need to configure how Alexandria communicates with your library's email server. Alexandria's email system is designed to potentially cope with hundreds of emails being sent (or resent) over many machines at the same time.

If a send fails, the next resend time is generated by adding a random value between 3 and 9 minutes, spreading out the resend times so all the undelivered email still in the “short range” period isn't sent at the same time. If a send hasn't succeeded by the end of the “short range” period, the program will generate new send times using random values between 60 and 90 minutes. If a send still hasn't succeeded after 100 hours the email is discarded and a “return-to-sender” email will be sent.

Email Settings 

The Server 1 and Server 2 sections are used for out-bound email. Server 1 is the primary server and Server 2 can function as a back up server should server 1 fail. You do not need to have two SMTP servers to use the email functionality; for networks with one SMTP server simply configure the setting in the Server 1 section. 

SMTP Server 1 and 2. This is the TCP/IP or DNS address of your library's mail server. Typically, this will be “ mail.” followed by your domain name. 

Port. Enter the port number that your email server uses.

Allow Non-Secure Connections. Alexandria uses Transport Layer Security (TLS) for secure web communications, when this setting is enabled checked the system will use non-TLS connections if it cannot make an TLS connection.

Log In. Enter the login for your email server. 

Password. Enter the password for your email server.

Test Server. Test the SMTP Server settings by sending a test email. This email is sent to the email address listed in the Sites module. 

Last Tested On. This field displays the last date/time that the server test was performed.

Last Test Results. This field displays whether the test was successful or not.

Setting Up Your SMTP Server 

Before setting up your SMTP server you will need to enter a valid email address in the Site management settings of Alexandria. 

1. Click on Tools to the left of your Circulation window. 
2. Click on Sites under the Management header. 
3. Enter the name of your site contact (typically this will be the District or Library Administrator of Alexandria), their title, their email and their phone/fax numbers.
4. Click Save in the upper right corner.

Once you have saved this information you are ready to set up the SMTP server.

1. Access Tools > Administration.
2. Click Email on the left.
3. Enter your SMTP server address and port in the available fields. 
4. Check the box if you want to allow non-secure connections. (optional)
5. Enter the login and password for your SMTP server. 
6. Click Save in the upper-right corner of the window.
7. Repeat steps 1-6 if you want to configure a back up server for Server 2.
   
   

Using Gmail as your SMTP Server

A Gmail account can be used as a portable SMTP server if your library's network does not already have one. Before you configure Alexandria to use Gmail, you will need to set your Gmail preferences to Allow Less Secure Apps. 

1. Access Tools > Administration.
2. Click Email on the left.
3. Enter smtp.gmail.com as the SMTP Server Address.
4. Enter 587 as the port. 
5. Check the box if you want to allow non-secure connections. (optional)
6. Enter the login and password for your Gmail account. 
7. Click Save in the upper-right corner of the window.
8. Click Test Server to ensure the Gmail account is acting as a server. 
9. Repeat steps 1-8 if you want to configure a back up server for Server 2. 

LDAP supports user-authentication for open or active directories

Lightweight Directory Access Protocol (i.e. LDAP) is an application protocol for querying and modifying directory services running over TCP/IP. At this time, Alexandria supports user-authentication using existing log-on credentials maintained on a separate directory server.

With this capability enabled, administrators can manage user log-on credentials (username and password) on a central server and allow the user access to their account within Alexandria using these same credentials. While a permanent record must exist locally in the Alexandria database for all patrons and operators that use the system, their log-on credentials do not have to be separately updated within these systems when they change. Instead, our software can authenticate the user on the LDAP server and then look them up locally by unique information returned from that server when the authentication is successful.

Our software’s LDAP capabilities are designed to be utilized in an environment where security is required for operators and patrons to gain access to the software, or log into their accounts to view personal information or place holds or reservations on items.

In many environments, administrators choose to maintain user account credentials directly within Alexandria. With LDAP, administrators can now choose to manage these credentials on a central LDAP server instead as these credentials may change frequently and often need to be standardized across many different systems.

Please note that operator and patron records can not be created or entirely managed by LDAP at this time; they must exist as unique records locally within the Alexandria database.

LDAP authentication is accomplished in the following manner:

The COMPanion software will send the credentials the user enters in any log-in dialog to the specified LDAP server in the form of a BIND. If the BIND is successful, the software will...Locate the user's record within the local database—looking it up using the information returned in the specified Local ID field from the LDAP server. Once the record is located, the user will be logged in. If this fails, Alexandria will also test the credentials against the local data base as a fallback.

TLS Communications

It is highly recommended that you secure communications with the LDAP server by requiring TLS. TLS configuration is performed at the system level. There are no additional settings within the application required. When the system is correctly configured for secure communications with your LDAP server, Alexandria will also be able to communicate with the LDAP server securely. If, for example, in a Macintosh / Open Directory environment, the client (or machine running the Data Station) has Directory Services or the OpenLDAP client configured for TLS, Alexandria will also be able to talk to the server via TLS.

Configure LDAP settings 

LDAP Settings

Enable LDAP—When checked, the system will attempt to use the provided values to perform user authentication via LDAP. If the authentication is successful, the value returned from the field defined as Local ID will be used to identify the person to Alexandria. If unable to authenticate using LDAP, the system will use the previous authentication method as a fallback.

LDAP Domain— This is the Domain of the LDAP server, as in “yourdomain.com”. This is used in conjunction with sAMAccountName to produce a complete userPrincipalName.

LDAP Server—This is the full name of the LDAP server, as in “ldap.yourdomain.com”. This is the host address of the LDAP server used for network communication.

Allow Non-Secure Connections—When checked, the system will use non-TLS connections if it cannot make an TLS connection. For the best security, don't check this.

Base DN for all LDAP users—This is a DN that matches all the users, as in “cn=users,dc=ldap,dc=yourdomain,dc=com”, so that any search using the User ID field specifies a unique user. Multiple Base DNs can be specified if separated by semicolons: “cn=staff,ou=COMPanion,dc=demo,dc=goalexandria,dc=com;cn=student,ou=COMPanion,dc=demo,dc=goalexandria,dc=com”.

User ID—This is the name of the LDAP database attribute whose value is the LDAP login name (e.g. “uid=yourlogin" in the context of the Base DN). For an Open Directory, this is typically uid. For an Active Directory this is typically cn, sAMAccountName, or userPrincipalName.

Local ID—This is the name of the LDAP database attribute whose value contains the Patron Username or Patron Barcode in Alexandria. This MUST be one of the users' LDAP attributes. Common attribute names include uid, uidNumber, givenName, cn, and others.

Note: In a Centralized Catalog, these settings will apply to all sites.

Test your LDAP settings before saving. Attempting to connect to an invalid server (and other invalid settings), can cause the test to take several minutes before failing.

Test Login—Enter the test login.

Test Password—Enter the password for the test login.

Test—Clicking on this button initiates a test, which attempts to log into the LDAP server using the settings and credentials provided above.

More on Testing LDAP

If configured correctly, your users should be able to log into Alexandria using the same login credentials as configured on the directory server for their account. However, sometimes difficulty arises. In these cases, verify your preferences settings and test whether the Base DN and other information you have specified is accurate to your configuration.

We have found that Active Directory configurations seem to prefer binds using the user's CN while OSXs Open Directory prefers the uid (i.e. user identification).

The use of ldapsearch tool is suggested.

For example:ldapsearch -x -v -H ldap://LDAP.yourdomain.com -b"cn=users, dc=LDAP, dc=yourdomain, dc=com" -D"cn=testing user id, cn=users, dc=LDAP, dc=yourdomain, dc=com" -w the users password -ZZ

- NOTE -
	The -ZZ parameter requires successful connection utilizing StartTLS over port 389. If you have selected to Allow Non-Secure Connections, omit this in your testing with ldapsearch as well.

Alternately, ldp.exe can be utilized for testing in a Windows environment.