Installation Instructions for iLeave and ISS

These instructions explain how to install Apex's software products. They are written for system administrators. To skip these instructions and install everything on one computer, click here to complete a typical single-user installation.

These instructions do not explain how to set up communication between Apex Software and biometric\proximity terminals. Click here to read the setup instructions for the S900 biometric terminal. Click here to read the setup instructions for the S680 proximity terminal.

If you have any questions then call (317) 225-4415 or e-mail tsupport@iHRsoftware.com.

Table of Contents

1. Planning Installation
2. Database Server Installation
3. Client Installation
4. Configuring File Attachments and Portraits
5. Security Configuration
6. Configuring Apex Task E-mailer Service
7. Installing Instant Self Serve
8. Notes regarding Setup.exe and Uninstallation

1. Planning Installation

The software contains two core components: a SQL Server Database and a client, and the software contains three optional components: a Web add-on (ISS), a file share that holds attachments, and a service that e-mails reminders and tasks (e-mailer service). In a typical single-user installation, the Database and client are installed on the same computer. In a typical client/server installation, the Database, file share, e-mailer service, and Web add-on are installed on one server, and the client is installed on each end-user's workstation. In use cases involving more than 500 users, Apex recommends that you reserve a dedicated database server as shown in Table 3 below.

Apex strongly recommends that you avoid installing ISS on a domain controller or a server that runs Microsoft Small Business Server. If that recommendation is not followed then Apex reserves the right to deny security-related support for ISS.

Table 1 lists the system requirements for the server and client components. You may install all of the server components on one computer, or you may install them separately. The client uses an auto-update function that is similar to Windows Updates. For auto-updates to work, each user needs write permissions on their local folder, c:\Program Files\Apex\iHR, and firewalls must allow SOAP messages over HTTP port 80 to/from 206.221.237.115. Apex recommends that all of the workstations, users, and server(s) are joined to the same Windows AD domain. Apex provides an alternative update package for network administrators who prefer to disable the auto-updates and control the installation of software revisions. See http://iHRsoftware.com/updateHistory.aspx for more information.

Table 1. System Requirements
Component Prerequisites Client/Server Permissions Additional Memory (MB) Additional Hard Drive Space (MB)
Apex Client Windows 98, 2000, XP, Vista, 7, 2003 or 2008
.NET Framework 1.0 or better

Apex Client is not needed for general users. Only needed for admin users.
Client
  • Users require read/write on registry key, HKEY_CURRENT_USER
  • Updates require full permissions on Apex program installation folder
  • Auto-updates require SOAP messages over HTTP port 80 to/from 206.221.237.115
64 10
Database Windows 2000, XP, Vista, 7, 2003 or 2008
SQL Server: SQL 2005 Express, 2005, SQL Express 2008, or 2008
Express requires .NET Framework 2.0 or better
Server Default SQL Server installation permissions 256 500
Share for File Attachments Windows 98, 2000, XP, Vista, 7, 2003 or 2008

All Apex thick clients must be able to use a UNC path to access this share. Web clients do not require access.
Server
  • Typically, HR has full permissions over the share
  • HR assistants need read/write/create
  • Managers may need read on folders for individual employees
0 4000
Task E-mailer Service Windows 2000, XP, Vista, 7, 2003 or 2008
Relay Access to SMTP Server
.NET Framework 1.0 or better
Server Service must run under an account that can read apexTaskEmailer.xml in the program installation folder 10 10
Instant Self Serve Windows 2000, XP, 2003, Vista
Internet Information Services
.NET Framework 1.0 or better
Server Depends on SQL Authentication or Windows Authentication. See ISS, section 7. 128 10

Table 2 lists server configurations for a typical client/server installation with less than 500 active users. In the recommended configuration, performance is balanced with cost. The recommended configuration uses two IDE drives: one drive holds system files and the SQL Server transaction log. The other hard drive holds the database and the network share for the file attachments. Note that Apex provides software builds for both 32bit and 64bit architectures.

Table 2. Single Server Configurations for Less than 500 Active Users
Component Minimum Recommended Best Performance
MicroprocessorP3Dual CoreQuad Core (Phenom II X4\Xeon\Itanium)
RDMSSQL Server 2005 ExpressSQL Server 2005 ExpressSQL Server 2008
OSWindows 2000Windows 7 Pro or Windows 2003 ServerWindows 2008 Server
RAM1G2G4G
Hard DriveIDE 40+ GIDE 2x40+ GRAID SCSI/SAS 4x20+ G

Table 3 lists server configurations for installations with 500 to 10,000 active users. In these configurations, a database server that is dedicated to running the Apex database communicates with a Web server that optionally hosts other low-traffic Web applications. Note that Integrated Windows Authentication will not work in a two-server configuration. SQL Authentication or Basic Authentication must be used. (Basic Authentication uses the same Windows login\password as Integrated Windows Authentication.)

Table 3. Two-Server Configurations for 500 to 10,000 Active Users
Server Component Minimum Recommended Best Performance
Server 1, Dedicated Database ServerMicroprocessorDual CoreQuad Core Quad Core (Phenom II X4\Xeon\Itanium)
RDMSSQL Server 2005SQL Server 2008SQL Server 2008
OSWindows 2003 ServerWindows 2008 ServerWindows 2008 Server
RAM16G16G32G
Hard DriveIDE 2x40+ GIDE 2x40+ GRAID SCSI/SAS 4x20+ G
Server 2, Web ServerMicroprocessorP4Dual CoreQuad Core
May be shared with low-traffic sitesOSWindows 7 ProWindows 2003 ServerWindows 2008 Server
RAM4G8G16G
Hard DriveIDE 40+ GIDE 40+ GRAID SCSI/SAS

2. Database Server Installation

The database server requires Windows 2000 or better. If you use a Windows domain then the server should be a member of the domain. The procedure for server installation depends on whether or not you are attaching the database to an existing SQL Server 200x.

2.1. Attaching the Database to an Existing SQL Server

If your server already runs SQL Server 2005 or 2008 then log on to your SQL Server as an administrator. Confirm that the collation on the server is set to the US default, SQL_Latin1_General_CP1_CI_AS. You can look up collation in the general tab/node on the server's properties. If you see a different collation setting then you should install a separate SQL Server instance. Download the compressed database backup file...

http://iHRsoftware.com/FTP/iLeaveDb.zip (3M)

Extract the file and use SQL Management Studio to restore it as a database named iHR. During the restore, you may want to change the locations of the mdf and ldf files. Also, the iHR database must have an owner. After restoring the database, set the owner by opening the database properties. Alternatively, run the script below.

EXEC sp_changedbowner 'sa'

2.2. "No SQL Server" Installation

If SQL Server 200x is unavailable then log on to the server as an administrator. Download and run the self extracting executable...

http://iHRsoftware.com/FTP/iLeaveSetup.exe (16M)

The installer will open. Click Server Installation.

IMPORTANT! With the No SQL Server installation, SQL Server Express is installed as an instance named iHR. When you open the client and the system prompts you for the name of the database server, append \IHR to the server's name. If your server were named MyServer then you would enter MyServer\IHR

3. Client Installation

Client installation depends on whether or not the target workstation has .NET Framework 1.0 or better installed.

3.1. .NET Framework 1.0 or Better Is Already Installed

For every workstation with .NET Framework 1.0 or better, log on with an account that has local administrative permissions. Download and execute the file...

http://iHRsoftware.com/FTP/ApexSetup.msi (8M)

The installer will open. Click Next until it finishes. After the installer finishes, the client will open. When prompted, enter the name of the database server and choose Windows Authentication. After you log in, the software may prompt you to enter the key code from your e-mailed sales receipt. Enter your key code if prompted and close the software. You can open the software later by clicking Start > Programs > Apex.

3.2. .NET Framework 1.0 or Better Is Not Installed

For every workstation without .NET Framework 1.0 or better, log on with an account that has local administrative permissions. Either use Windows Update to install the latest .NET framework and then follow the instructions from the last section, 2.1, or download and execute the file...

http://iHRsoftware.com/FTP/iLeaveSetup.exe (16M)

The installer will open. Click Additional Client Installation. When prompted, click Next until the installer finishes. After the installer finishes, the client will open. When prompted, enter the name of the database server and choose Windows Authentication. After you log in, the software may prompt you to enter the key code from your e-mailed sales receipt. Enter your key code if prompted and close the software. You can open the software later by clicking Start > Programs > Apex.

3.3. Enabling Auto-Updates

For auto-updates to work, each user needs write permissions on their local folder, c:\Program Files\Apex\iHR, and firewalls must allow SOAP messages over HTTP port 80 to/from 206.221.237.115. Auto-update failures are logged to the user's Application event log. If you use Microsoft's ISA or a similar firewall then copy the pinhole for Microsoft updates and change it to 206.221.237.115.

4. Configuring File Attachments and Portraits

iLeave can associate files like portraits, resumes, and MS Office documents with an employee. If you choose to take advantage of this feature then use Windows Explorer and/or Computer Management to create a network share that will hold the documents. Set appropriate security on the share, and enter the share's UNC path into the software.

To enter the UNC path, log on as an administrator and open the client. Click Company > Settings. Click the File Associations tab. Enter the UNC path. On that same tab, you can also edit the subfolders that will be created for each employee. Note that iLeave does not automatically manage the security on any of those folders.

5. Configuring Security

Before you configure security, decide whether users will use Windows Authentication or SQL Authentication. Windows is preferred because, after the initial setup, it allows you to use Active Directory to control accces. Unlike Windows Authentication, SQL Authentication requires that you create a new SQL login for each user. Note that Windows Authentication requires that all of the users are enrolled in the same domain as the computer that hosts the SQL Server. To set up typical security for Windows Authentication, read Section 5.1. To set up typical security for SQL Authentication, read Section 5.2. For additional security information refer to the help manual at http://iHRsoftware.com/ftp/help.doc.

5.1. Setting up Security for Windows Authentication

Typical security setup for Windows Authentication requires that you create an AD group, join it to the db_owners role, confirm the permissions on the public role, and then associate Windows Accounts with Apex employee records. If you will install Instant Self Serve then you must also grant database access to the staff by clicking Company > Security and adding the Domain Users role.

5.1.1. AD Group for HR Administrators

Create an AD group that holds all of the users who need full access to the database. To create it, open Active Directory and create a group named something like "HR Admin" and join the necessary users. Then, in Apex, click Company > Security and open the security window. Click Add Windows User or Group. Enter the name of the AD group in the format domain\group. Save it. Then click the tab named Membership and click the checkbox named db_owner. Save your changes.

5.1.2. Public Role for Managers and Their Staff

The public role defines the permissions for managers and their staff. To check the permissions on public, double-click it and then click the tab named Permissions. In the select box named Scope, select "User Viewing Self". These permissions define what a user can see about himself. Now select "User Viewing Subordinates". These permissions define what a user can see about his subordinates. (The software identifies the user's subordinates based on the Manager select box that is found on each person's General tab.)

5.1.3. Associating Windows Accounts with Apex Employee Records

For each user, associate his Windows Account with his employee record so that Apex can correctly match "self" and "subordinate" permissions. You can manually enter the Windows Accounts by opening each person and entering their domain\account in the Security Account field on theirGeneral tab. Or you can click Company > Employees > Custom Tabular Reports > Names, Locations, Departments and Accounts and enter the Windows Accounts for everyone on one screen (click Apply often). Or you can copy and run the script below in either SQL Management Studio or the window that opens when you click Company > Execute SQL.

-- Adds access for windows accounts: john doe --> YOURDOMAIN\jdoe
-- Sets work e-mail address based on account name
-- Associates each user account with the correct Apex employee record
USE IHR
DECLARE @username varchar(50), @person_id int, @wdomain varchar(50), @edomain varchar(50)
SET @wdomain='CHANGE_ME_TO_YOUR_WINDOWS_DOMAIN'
SET @edomain='CHANGE_ME_TO_YOUR_EMAIL_DOMAIN'
DECLARE p_cursor CURSOR FOR SELECT LOWER(SUBSTRING([First Name], 1, 1) + [Last Name]), PersonID FROM Person
OPEN p_cursor

FETCH p_cursor INTO @username, @person_id
WHILE @@FETCH_STATUS = 0
BEGIN
  UPDATE Employee SET [SID] = SUSER_SID(@wdomain + '\' + @username) WHERE EmployeeID = @person_id
  UPDATE Person SET [Work E-mail] = @username + '@' + @edomain WHERE PersonID = @person_id
  FETCH p_cursor INTO @username, @person_id
END

CLOSE p_cursor
DEALLOCATE p_cursor

5.2. Setting up Security for SQL Authentication

Typical security setup for SQL Authentication requires that you create a SQL login for each administrative user, join the logins to the db_owners role, confirm the permissions on the public role, create a SQL login for each user, and then associate the SQL logins with Apex employee records.

5.2.1. Creating SQL Logins

Click Company > Security. Click Add SQL Login. Enter the login and password. Click Save. If this login should have full permissions then click the tab named Membership and click the checkbox named db_owner. Save your changes and repeat these steps for each user.

5.2.2. Public Role for Managers and Their Staff

The public role defines the permissions for managers and their staff. To check the permissions on public, double-click it and then click the tab named Permissions. In the select box named Scope, select "User Viewing Self". These permissions define what a user can see about herself. Now select "User Viewing Subordinates". These permissions define what a user can see about her subordinates. (The software identifies the user's subordinates based on the Manager select box that is found on each person's General tab.)

5.2.3. Associating SQL Logins with Apex Employee Records

For each user, associate his login with his employee record so that Apex can correctly match "self" and "subordinate" permissions. You can manually enter the logins by opening each person and entering their SQL login in the Security Account field on their General tab. Or you can click Company > Employees > Custom Tabular Reports > Names, Locations, Departments and Accounts and enter the SQL login for everyone on one screen (click Apply often). Or you can copy and run the script below in either SQL Management Studio or the window that opens when you click Company > Execute SQL.

-- Creates SQL Logins with SSN as the password for each employee: john doe --> jdoe
-- Sets work e-mail address based on login
-- Associates each login with the correct Apex employee record
-- Make sure you delete old SQL logins before running
USE IHR
DECLARE @login varchar(50), @person_id int, @edomain varchar(50), @ssn varchar(50)
SET @edomain='CHANGE_ME_TO_YOUR_EMAIL_DOMAIN'
DECLARE p_cursor CURSOR FOR SELECT LOWER(SUBSTRING([First Name], 1, 1) + [Last Name]), P.PersonID, X.SSN FROM Person P
INNER JOIN PersonX X ON P.PersonID = X.PersonID
OPEN p_cursor

FETCH p_cursor INTO @login, @person_id, @ssn
WHILE @@FETCH_STATUS = 0
BEGIN
  PRINT @login
  EXEC sp_addlogin @loginame=@login, @passwd=@ssn, @defdb='iHR'
  EXEC sp_grantdbaccess @login
  UPDATE Employee SET [SID] = SUSER_SID(@login) WHERE EmployeeID = @person_id
  UPDATE Person SET [Work E-mail] = @login + '@' + @edomain WHERE PersonID = @person_id
  FETCH p_cursor INTO @login, @person_id, @ssn
END

CLOSE p_cursor
DEALLOCATE p_cursor

6. Installing the Apex Task E-mailer Service

To enable automatic e-mails, insure that your Windows Account is a member of Domain Admins and follow the steps below.
  1. Choose the server that will host the service. The server needs network access to the Apex database and an SMTP server. Apex recommends that you install the e-mailer service on an existing SMTP server that does not require SMTP authentication.
    If the server that you choose is not an SMTP server then the service will need to use a remote SMTP server. The remote SMTP server must grant relay permissions to your chosen\local server. Also, the e-mailer service cannot pass SMTP credentials. If authentication and relaying create problems then work around them by installing the SMTP service on your chosen server from your Windows Server CD-ROM.
  2. Log on to the target server. Download and run http://iHRsoftware.com/ftp/ApexTaskEmailer.msi (6M).
  3. If the service and the database are on different servers then create a Window's Account for the service and grant the account permissions. Create a domain account and grant the account read permissions on C:\Program Files\Apex\Apex Task Emailer\apexTaskEmailer.xml . Grant the account full permissions on the database (In Apex Software, click Company > Security, add the account, and join it to the db_owner group).
  4. Assign the account to the service. Open Service Manager, edit the service properties, and enter the new account in the "run as" text box. If the service and the database are on the same computer then set the service to use the Local System account.
    Some versions of SQL Server block local system from accessing the database so you may need to either create a new account as explained in the previous step or explictly grant database access to NT AUTHORITY\SYSTEM or BUILTIN\Administrators.
  5. Point the service to the database. Open C:\Program Files\Apex\Apex Task Emailer\apexTaskEmailer.xml . Edit the file (right-click it and open with Notepad) and change the connectionString and SMTP elements to point to your database and SMTP server.
    In the connectionString element, decide whether to use Windows Authentication (recommended) or SQL Authentication. With Windows Authentication, database permissions will be determined by the Windows Account in which the service runs. Example connection strings are listed below. If you do not know the value of the Data Source attribute then open Apex Software and click Company > Reconnect to Database. Use the text in the Server textbox.

    -- Connect to the local server on the default instance. Use the service's Windows credentials to log in.
    <connectionString value="Data Source=.;Trusted_Connection=Yes;Database=iHR" />

    -- Connect to the local server on the SQLExpress instance. Use the service's Windows credentials to log in.
    <connectionString value="Data Source=.\SQLExpress;Trusted_Connection=Yes;Database=iHR" />

    -- Connect to a remote server on the default instance. Use the SQL login "daemon" to log in.
    <connectionString value="Data Source=Server1;Database=iHR;User ID=daemon;Password=colts2008" />

    -- Connect to a remote server on the IHR instance. Use the service's Windows credentials to log in.
    <connectionString value="Data Source=Server1\IHR;Trusted_Connection=Yes;Database=iHR" />

  6. Start the service. Open the computer's list of services, find Apex Task E-mailer Service, right-click it and start it.
  7. Verify it worked. Review your application event log to confirm that the service started successfully. If the event log shows success then you can review the log of outgoing e-mails by opening Apex Software and clicking Reports > Tasks > Log of E-mailed Reminders.
  8. Troubleshoot errors in the event log.
    Connection errors are usually caused by one of the following problems.
    • Wrong type of slash before the instance name (use Server1\iHR, do not use Server1/iHR)
    • Using Windows Authentication to connect to a remote databaase when the task e-mailer service is running under a local account. To fix this problem, change the service's "run as" account to a domain account or use SQL authentication in the connection string. The domain account should have administrative database access (member of db_owner). The account needs read permissions on the local apexTaskEmailer.xml file.
    • Running the service as LocalSystem (the default account) and using Windows Authentication to connect to a local SQL Server that is not set to run as LocalSystem. To fix this problem, check the account name that the MS SQL Server service is using. If the account is NOT named NetworkService then use that account to run the service. If it is named NetworkService then create a Windows account and assign it to the service as explained in step 3.

    E-mail errors are usually caused by one of the following problems.
    • Failing to grant relay permissions on the remote SMTP server.
    • Setting a blank or invalid "send from" e-mail address in the Apex Software client (Company > Settings, Reminders tab).

7. Installing Instant Self Serve

Instant Self Serve is an Internet Information Services (IIS) Web application. To install it, open IIS manager. Decide whether Instant Self Serve will be (1) the default Website, (2) an application within the default Website, or (3) a new Website.

  1. Default Website. No special action is required.
  2. Application. Installing Instant Self Serve as an application will let users access the site using an URN like http://yoursite.com/hr . To create a new application, right-click the default Website.
  3. New Website. New websites require that you either assign a different IP address than the default Website or a non-standard port (resulting in an URN like http://yoursite.com:8080 ). To install Instant Self Serve as a new site, right-click the sites node.
Decide whether Instant Self serve will use (1) HTTP or (2) HTTPS.
  1. HTTP. Login handshaking over HTTP is insecure and should only be used when the site is inaccessible outside of your network. HTTP is the IIS default and requires no special action.
  2. HTTPS is secure but requires an SSL certificate. If you do not already have a certificate then you have two options: self-sign or buy a certificate from a third party like GoDaddy. In general, self-signing will create a bad first impression for your users because they will see "untrusted" warnings when they visit the site. Set the site to support https over port 443 by clicking the site. Click the bindings link. Verify that https over port 443 is listed. If it is not listed then add it. Set the site to requite SSL by clicking the site. Click SSL Settings. Check the "Require SSL" checkbox . Verify that the "Client Certificates" setting is set to ignore.

Download and run the Instant Self Serve self-extracting executable. When prompted, verify that the target folder matches the IIS folder from the previously completed steps.

Decide whether you will use SQL Authentication or Windows Authentication. Windows Authentication allows users to use their Windows login and password to log into the site, but it requires that all users have Windows AD accounts.
  1. SQL Authentication over HTTP is the default and requires no special changes to the web.config file. Verify that site authentication is set to anonymous by clicking the site. Click the authentication icon. Verify that every authentication option is disabled except for anonymous.
  2. SQL Authentication over HTTPS. Delete the web.config file and rename web.sqlAuthenticationHttps.config to web.config . Verify that site authentication is set to anonymous by clicking the site. Click the authentication icon. Verify that every authentication option is disabled except for anonymous.
  3. Windows Authentication over HTTP.
    Verify that basic authentication is an option by clicking the site. Click the authentication icon. If basic authentication is not an option then go to Server Manager > Roles > Web Server > Add Role Services. In the role services treeview, add Internet Information Services > World Wide Web Services > Security > Basic Authentication.
    Delete the web.config file and rename web.windowsAuthenticationHttp.config to web.config . Verify that site authentication is set to basic by clicking the site. Click the authentication icon. Verify that every authentication option is disabled except for basic. Right-click basic and click edit. Enter your AD domain (the domain prefix in domain\username).
  4. Windows Authentication over HTTPS.
    Verify that basic authentication is an option by clicking the site. Click the authentication icon. If basic authentication is not an option then go to Server Manager > Roles > Web Server > Add Role Services. In the role services treeview, add Internet Information Services > World Wide Web Services > Security > Basic Authentication.
    Delete the web.config file and rename web.windowsAuthenticationHttps.config to web.config . Verify that site authentication is set to basic by clicking the site. Click the authentication icon. Verify that every authentication option is disabled except for basic. Right-click basic and click edit. Enter your AD domain (the domain prefix in domain\username).

Change the configuration file to point the application to your database and e-mail server. Open web.config in notepad. Confirm the ConnectionString setting. By default, it points to the IHR instance on the local server. Change the SMTPServer setting to point to your e-mail server. If your e-mail server is local then insure that the Web server has permission to relay through your e-mail server. (In Exchange, that access is controlled by a receive connector.) If your e-mail server is remote then add your public IP address to your host's list of authorized servers. (In Gmail, that access is controlled by the Authorized Servers list in main Gmail settings.) Scroll through the rest of the elements in appSettings and change them to meet your needs.

After you install ISS, insure that you followed Section 5 so that users can access their ISS accounts.

8. Notes regarding Setup.exe and Uninstallation

Setup.exe is designed to be a no-hassle installer for a typical single-user installation. It wraps the client MSI, ApexSetup.msi. After the user selects the type of installation, setup may download .NET framework 2.0 (dotnetfx.exe) or SQL Server Express SP1 (sqlexpr.exe). Setup updates the registry, scheduling itself to run again after your machine reboots. This action is necessary because the installers for .NET and SQL Server may force a reboot before setup can complete. After setup completes, it removes itself from your registry. It may leave a folder named c:\Temp\iHRsoftware. You can safely delete that iHRsoftware folder.

While Setup.exe is a complete installation package, it leaves a footprint and it triggers warnings from anti-virus software because it downloads installers from Microsoft's website and writes to your registry. For client/server installations where SQL Server is already installed, Apex recommends that you avoid setup.exe. Instead, use Enterprise Manager or SQL Management Studio to attach the database (iHR.bak) and then install ApexSetup.msi on individual workstations. Sections 2 and 3 explain this procedure in detail.

To completely uninstall a typical single-user installation, open Add/Remove programs. Remove Apex Software and Microsft SQL Server 2005 (IHR instance). Delete the c:\Temp\iHRsoftware folder, and delete all of the unused subfolders in c:\Program Files\Microsoft\SQL Server and c:\Program Files\Apex. Additionally, run regedit and delete the key, HKEY_CURRENT_USER\Software\Apex.

http://ihrsoftware.com