1

webNetwork Pre-Installation Configuration Checklist

Stoneware, Inc.

Date: Oct 3rd 2012

Product: webNetwork version 6.0 sp9 and 6.1

Document revision: 10-3-2012

2

Introduction

This document is intended to provide information that will assist in webNetwork architecture design, server hardware

selection, OS choice, firewall configuration, directory services configuration, and DNS configuration prior to a webNetwork

production installation engagement. During the pre-installation kickoff meeting, a Stoneware consultant will work with

you to answer any questions and help you make appropriate choices based on your individual needs.

The installation procedure will require a technical contact within the organization that will provide access to network

resources. It is highly recommended that this technical contact be actively involved in the installation process for the

purpose of knowledge transfer. The format will be a learn-as-you-go and will not include any formal training process.

Executive Goals

In order to deliver the most effective webNetwork solution, organizational goals need to be established and priorities set -

within the scope of the PID (Project Initiation Document.) It is important that the organizational goals of the IT Executive

are communicated to the Stoneware consultant, as well as the customer IT technical resource. Executive goals will be

discussed during the pre-installation kickoff meeting.

webNetwork Architecture Determination

webNetwork is designed with a two-tiered architecture consisting of a webNetwork Server and webRelay. Both the

webNetwork Server and webRelay can run concurrently on a single (physical or virtual) server, or the webNetwork Server

and webRelay can be implemented independently on separate servers. The decision to implement a single server or multi-

server configuration will have an effect on the hardware configuration, operating system choice, and firewall configuration.

A Stoneware consultant will help you determine the appropriate webNetwork architecture based on your needs and

capabilities.

Example of typical ‘true’ dual firewall DMZ architecture with one combined internal webNetwork Server/webRelay, and one

dedicated public webRelay:

3

Example of typical simple firewall architecture with one combined internal webNetwork Server/webRelay:

4

a) Size of deployment

1. Stoneware webNetwork implementations can range from as few as ten concurrent users to thousands of

concurrent users. For increased performance and security, especially in larger implementations, a two-tier

configuration (dedicated webRelay and combined webNetwork Server/webRelay) is highly recommended.

2. For smaller organizations (25 concurrent users and less), where it is impractical to deploy a multi-server

configuration due to the additional hardware expense, a basic single server installation running both the

webNetwork Server and webRelay (on the same host server) can be utilized. As the webNetwork System

grows, it can be reconfigured into a two-tiered configuration without additional licensing expense.

b) Firewall Capabilities and Configuration

1. The two-tiered nature of Stoneware’s webNetwork allows it to be easily deployed within a ‘true’ dual

firewall DMZ architecture providing additional security and flexibility. Stoneware suggests a two-tiered

(multiple server) implementation where maximum security is a priority. A basic single server

implementation can be utilized if the organization does not have a DMZ implemented and the deployment

is supporting less than 25 concurrent users.

c) Common webNetwork Server / webRelay Configurations

1. One combined internal webNetwork Server/webRelay (one physical/virtual server - basic budget

configuration)

2. One combined internal webNetwork Server/webRelay, and one dedicated public webRelay (two

physical/virtual servers - recommended minimum configuration – more secure two tiered configuration)

3. One combined internal webNetwork Server/webRelay, and two dedicated public webRelays (three

physical/virtual servers - useful for load balancing between DMZ webRelays – a hardware load balancer* to

balance the load between the webRelays is recommended (not required) for maximum flexibility and

performance)

4. Two combined internal webNetwork Server/webRelays, and two dedicated public webRelays (four

physical/virtual servers - useful for load balancing for both Internal and DMZ webRelays - hardware load

balancers*, to balance the load between the internal and public webRelays, are recommended (not

required) for maximum flexibility and performance)

5. Two dedicated internal webNetwork Servers, two dedicated internal webRelays, and two dedicated public

webRelays (six physical/virtual servers – fully-meshed clustered servers and independent redundant internal

and DMZ Relays - hardware load balancers*, to balance the load between the internal and public Relays, are

recommended (not required) for maximum flexibility and performance)

5

Please see the webNetwork Server Progression document for visual representations of these common webNetwork Server /

webRelay design options:http://www.stone-ware.com/support/techdocs/ServerProgression/index.htm

* Stoneware will NOT be responsible to provide, configure, or maintain any load balancing devices. The load balancer

vendor should be consulted for appropriate configuration changes. The alternate method of Round-robin DNS is supported,

but is not recommended as it does not provide true load balancing or fault tolerance.

Hardware Configuration

Stoneware recommends (not required) server class hardware for all webNetwork Servers and webRelays. Stoneware

webNetwork will take full advantage of multiple CPU/core processors and available RAM – dependent on host operating

system limitations. The following specifications are a basic guide to assist in choosing an appropriate hardware platform.

a) Hardware Recommendations

1. Processor

Minimum: 1.2 Ghz processor (less than 25 concurrent users)

Recommended: 2+ Ghz dual (dual-core, multiple-CPU, etc.) processor or greater (more than 25 concurrent users)

2. Memory

Minimum: 1GB RAM (less than 25 concurrent users)

Recommended: 4GB RAM or greater (webNetwork can only utilize 1GB of RAM on a 32bit operating system due to OS limitations, 64bit OS memory addressing capability is virtually limitless)

3. Networking

100mb or gigabit network interface

4. Disk

Minimum: 1GB available disk space

Recommended: 4GB available disk space

A redundant disk subsystem is recommended on all servers for increased availability and reliability, but is not required. webNetwork is not a read/write disk intensive application.

b) Which component of webNetwork should run on the faster server in an environment with multiple physical

servers of different specifications?

This depends on the webNetwork services being implemented. In an environment where many core services will be used

(e.g. Report Services, Community Services, File Services, Pipeline Services, teamPages, webPages, etc.) it is advantageous

to utilize the more powerful hardware for the webNetwork Server. If few services will be implemented it may make sense

to utilize the more powerful hardware on the webRelay. A Stoneware consultant can work with you to help decide how to

efficiently provision hardware based on individual webNetwork implementations.

6

Operating System

a) Choosing an operating system - Stoneware webNetwork is platform independent and can run on most current

server operating systems. It is recommended to choose your operating system based on the following criteria:

1. Security - Ability to secure or “harden” the operating system from malicious attacks. Operating system

manufacturers should be consulted for information related to securing the OS based on the environment in

which it will be deployed. Documentation is available for most operating systems that will provide

instructions for securing the OS based on the intended use.

2. Skill – General comfort and ability to support the operating system from a technical standpoint

b) Supported Operating Systems - http://www.stone-ware.com/webnetwork/specifications

c) Install, Configure, and Patch Operating System - It is recommended to install Stoneware webNetwork on a

‘clean’ operating system, without any services that could interfere with webNetwork functionality. A web server

is included as part of the webRelay; therefore other web servers should not be installed on the same server as

webNetwork. All operating systems should be updated with the latest patches prior to webNetwork installation.

d) Assign static IP address to all systems and document IP addresses

e) Disable anti-virus and firewall software – Anti-virus and firewall software should be disabled on servers prior to

(and during) installation of webNetwork – these services may be re-enabled after installation.

Browser Support

Stoneware's webNetwork requires a browser with JavaScript support. Some features require Java (1.6 or higher) on local

workstation to work. Clients will need to meet the minimal requirements of a browser and Internet/network connection for

full functionality. The list below outlines a list of suggested browsers that have been tested and are currently in use by our

customers.

a) Recommended Browsers - http://www.stone-ware.com/webnetwork/specifications

7

Firewall Configuration

The webNetwork Installation and Configuration Guide, included in the full webNetwork online documentation, provides a

complete description of the configuration necessary in a DMZ/Firewall setting. This section provides the basic port

configuration information needed to install the webRelay and webNetwork Server in a production environment.

a) Web browser communication with webRelay - Open ports 80 and 443 bi-directionally between the public

Internet and the webRelay(s)

b) webRelay communication with webNetwork Server (separate Relay/Server installation) – Open ports 1099, 4500,

4501, and 24000 bi-directionally for TCP traffic between the webRelay and webNetwork Server when

configured on separate boxes.

1. Ports 1099 and 4500 are used for RMI (remote method invocation)

2. Port 4501 is used for Pipeline Services

3. Port 24000 is used for Relay Central

Directory Services Preparation

Stoneware’s webNetwork utilizes directory services as its primary configuration and user account store. Directory health

must be verified and various directory features must be enabled, before webNetwork can be installed into a production

network environment. Complete the following checklist items for the relevant directory in the production environment.

Microsoft Active Directory (2000, 2003, and 2008)

a) Run Stoneware Environment Check utility - To download the utility, visit our Stoneware Support Utilities page

and download and install the Env Check utility. For instructions on how to run the utility, visit our Running Env

Check page. IMPORTANT – export the utilities output and email to your Stoneware Consultant when completed

for verification.

b) Enable SSL access to LDAP if not already enabled – To enable full functionality webNetwork needs to connect

to LDAP via a secure SSL (port 636) connection. Microsoft Certificate Server (Enterprise root CA or Enterprise

subordinate CA) must be installed on an AD member server to enable LDAP over SSL. DO NOT install this on the

Stoneware webNetwork Server(s). If you cannot run the swEnvCheck utility with SSL enabled, please see Enable

SSL over LDAP on how to set up the Microsoft Certificate Server with default settings.

c) Domain administrator account needed for installation - webNetwork Server requires the ‘real’ domain

administrator account to extend the Active Directory schema during installation. Once the schema is extended,

8

and installation is complete, a different (e.g. swadministrator) account can be created with reduced access

privileges limited to users/groups/containers accessed by webNetwork Server.

d) Verify administrator account has schema-admin rights, the domain controller used for LDAP is the “schema

master”, and “allow schema updates” is enabled – Go to Stoneware Support Utilities and click Schema Diag to

download the AD Schema Diagnose application. This application will verify that the administrator account has

schema-admin rights, which server is the schema master, and if allow schema updates is enabled. The

application must be run from a Windows computer that is part of the Active Directory domain (e.g. desktop

logged into domain, Domain Controller server, etc.), and is logged in with the admin account that will be used for

the production installation. Please click the Save button in the Schema Diag utility, save the results to a file,

and email the file to your Stoneware Consultant. The Active Directory server must have “Allow Schema

Updates” option enabled to extend the schema and install webNetwork. If Allow Schema Updates is not enabled,

please see http://support.microsoft.com/kb/285172 for more information on how to enable schema updates (on

Windows Server 2003 and above you will not be able to enable Schema Updates via the Schema Management

Console – you will have to enable Schema Updates by means of the Windows Registry.)

e) Run Microsoft utilities dcdiag and DNSLint to check Active Directory health –DNSLint will make sure there are

no replications issues. Please see http://support.microsoft.com/kb/321046 for more information on DNSLint.

Dcdiag will analyze the domain controller’s state and report any issues. See http://technet.microsoft.com/en-

us/library/cc773199.aspx for detailed information on the dcdiag.exe utility. Consult Microsoft documentation for

any error messages found using these utilities.

f) Verify Domain Controller DNS Resolution from webNetwork Server - To verify proper resolution of the DNS

Name / IP Number, bring up a command prompt on the machine to be used as the webNetwork Server, and then

do a ping -a xxx.xxx.xxx.xxx of the DNS Name / IP Number of the domain controller. This should resolve to the

REAL name of the domain controller - if the domain controller is named DC1 then the address should resolve to

dc1.organization.com. If the DC does not resolve correctly the issue needs to be resolved or a manual entry will

need to be made in the ‘hosts’ file on the webNetwork Server machine to properly resolve the domain controller.

If manual modification of the ‘hosts’ file is necessary re-do the ping -a xxx.xxx.xxx.xxx test after modifying the

file to make sure it now resolves properly.

C:\>ping -a 192.168.1.128

Pinging 3-win2k3.swstoney3.org [192.168.1.128] with 32 bytes of data:

Reply from 192.168.1.128: bytes=32 time<1ms TTL=128

g) Verify Domain Tree Root Resolution – If, for example, the AD domain is dc=organization,dc=com, then at a

command prompt on the webNetwork Server machine type the following: ping organization.com - and verify

that the IP number is the same IP number from the Verify Domain Controller DNS Resolution from webNetwork

Server checklist item above. If ping organization.com does not resolve to the domain controller IP number then

the ‘hosts’ file of the webNetwork Server needs to be manually edited to add the entry. This entry must be the

LAST entry in the ‘hosts’ file. After making the change and saving the ‘hosts’ file verify the hosts file manual

entry using the same ping company.com command as before.

C:\>ping swstoney3.org

9

Pinging swstoney3.org [192.168.1.128] with 32 bytes of data:

Reply from 192.168.1.128: bytes=32 time<1ms TTL=128

Novell eDirectory (8.5 and newer)

a) Verify eDirectory version is 8.5 or newer – webNetwork requires Novell eDirectory version 8.5 or newer to run.

b) Perform an eDirectory “Health-check” - See http://support.novell.com/docs/Tids/Solutions/10060600.html for

information on how to perform an eDirectory health check.

c) Timesync – Timesync must be accurate throughout the entire eDirectory tree and all servers that are part of the

tree must be up and running to avoid causing replication issues.

d) Determine LDAP server with local copy of directory - For best performance, Stoneware recommends directing

the webNetwork Server to the IP address of an LDAP server that is also a local copy of the directory.

e) Configure LDAP access to eDirectory - webNetwork Server requires LDAP access on port 389 (non-secure) or

636 (secure). In a non-secure (port 389) configuration, ALLOW CLEAR TEXT PASSWORDS must be enabled on

the LDAP directory object.

f) eDirectory tree administrator account needed for installation - The webNetwork Server needs to use the REAL

tree admin account to access the directory and extend the schema during installation. Once the schema has

been extended, and installation is complete, a separate (e.g. swadmin) account can be created with reduced

access privileges limited to users/groups/containers accessed by webNetwork Server.

g) Test LDAP connection via SSL - Verify LDAP connectivity to the eDirectory LDAP server using the REAL admin

username / pass. An LDAP tool like LDAP Browser or JXplorer can be used to test the LDAP connection to

eDirectory. Both of these utilities can be downloaded from http://www.stone-

ware.com/cloud/downloads/utilities.html

DNS Configuration

Stoneware’s webNetwork technology utilizes DNS to provide virtual access to internal web servers and applications. The

use of DNS allows webNetwork to create secure web application connections without implementing client-side software.

a) webRelay(s) DNS Names – the webRelay requires a unique DNS entry to be addressed by name instead of IP

address. This DNS name (e.g. – portal.organization.com) should resolve to the static IP address of the webRelay

server. Public DNS servers must resolve the DNS name to the public IP address of the Relay, and the private DNS

server must resolve the same DNS name to the private IP address of the webRelay. To simplify configuration

both the public and private DNS names should be identical even though they will resolve to different IP addresses

based on whether they are resolved from a public or private DNS. A simple example would be

portal.organization.com resolves to 10.1.1.101 (which will be an IP address of a webRelay) from inside the private

network, and portal.organization.com resolves to 68.1.1.147 (also a webRelay) from the public Internet. The DNS

10

name that resolves to Relays and webNetwork Web Applications must be a sub-domain (must contain two dots)

of the primary domain – for example portal.organization.com is valid, organization.com is not. It is possible, but

will require additional configuration and add complexity, to use different internal and external domain names.

b) Reverse DNS – as of Java 6 Update 22, a reverse DNS look-up of the IP address must also resolve to the chosen

name (portal.organization.com). This must resolve correctly on private DNS and public DNS servers. To test if

reverse DNS resolves correctly, use nslookup from a command prompt. First type in the DNS name (example

shows portal.organization.com) then hit Enter. Next type in the IP address from the first entry (192.168.1.7) and

make sure it resolves to the DNS (portal.organization.com).

c:\>nslookup

Default Server: dns.organization.com

Address: 192.168.1.5

> portal.organization.com

Server: dns.organization.com

Address: 192.168.1.5

Name: portal.organization.com

Address: 192.168.1.7

> 192.168.1.7

Server: dns.organization.com

Address: 192.168.1.5

Name: portal.organization.com

Address: 192.168.1.7

c) Web Application Virtual DNS Names – each web-based application (e.g. Outlook WebAccess, GroupWise

WebAccess, PowerSchool, etc.) that will be accessible through the webNetwork System will need a new unique

Virtual DNS Name exclusively for use by the webRelay(s). This name should be unique and not be in use by any

other system (e.g. swoutlook.organization.com, swgroupwise. organization.com, swpowerschool.

organization.com.) End users will not need to know these Virtual DNS Names as they are used exclusively by

webNetwork. All unique Virtual DNS Names need to be configured to resolve to the static IP address (private and

public) of the webRelay(s), not the IP address of the actual web application web server. Every Virtual DNS Name

that resolves to a webNetwork Web Application must be a sub-domain (must contain two dots) of the primary

domain – for example swwebmail.organization.com is valid; organization.com and organization2.com are not

valid.

11

Applications, Databases, SSL Certificate, and File Systems Checklist

The focus of many installations is to integrate and secure the internal applications through the webNetwork product. To

speed implementation organizations should have the following information for each application, file system, and database

that is to be integrated into the webNetwork system:

Applications (web, Windows, Terminal Services, Citrix, etc.):

a) Stoneware webNetwork does not natively host Windows applications, but there are several ways to deliver

Windows applications seamlessly through webNetwork. The method of delivery should be chosen based on

existing or planned Windows application hosting architecture and specific application requirements.

o Windows Terminal Server

o Citrix

o VDI

o Application Virtualization (e.g. ThinApp)

o Local Windows Applications (installed on client PC)

o RDP or VNC access to individual desktop PC

b) Application name

c) IP address and Port Number for application server

o If a Citrix or Windows Terminal Server application please provide application PATH and WORKING

DIRECTORY

d) Login URL for the application (web applications)

e) Valid User ID and Password to test the application

f) The application administrator should be available during webNetwork application configuration to assist with

technical details as needed

g) Web-apps containing Adobe Flash as part of the login page may have issues with Single Sign-On – please consult

the application developers for an alternate login page or supported Single Sign-On method

12

Databases:

a) Four Stoneware application databases (teamPages, webPages, Relay Logging, and Communities) default to the

included Hypersonic database for testing and demo purposes only. Stoneware recommends MySQL 4.x or

higher, and Microsoft SQL Server 2000 or higher for production implementations. An external database (not

the included Hypersonic) is required for all Stoneware Cluster implementations.

b) Database name

c) IP address and Port Number for database server

d) Current supported JDBC database driver

e) Valid User ID and Password to the database / table

f) The database administrator should be available during webNetwork database configuration to assist with

technical details as needed

g) Stoneware Reports Services supports most current database servers with a current JDBC/ODBC driver.

SSL Certificate:

a) A valid wildcard SSL certificate (*.company.com) is recommended

b) Choose the preferred Certificate Authority (CA) for the organization

c) Create account and purchase the certificate from CA

d) Certificate Request (CSR) will be generated at time of installation

File System:

a) File System Name

b) IP address or UNC of the file system

c) Supported file system type (e.g. Windows share/CIFS, FTP, etc.)

d) Valid User ID and Password to the file system

e) The file system administrator should be available during webNetwork file system configuration to assist with

technical details as needed

13

webNetwork Pre-Installation Checklist Summary

Hardware Configuration and Operating System Checklists

o Hardware meets expectations………………………………………………………………………………………

o OS configured and patched……………………………………………………………………………………………

o No firewall/anti-virus/webNetwork Server……………………………………………………..……

Firewall Configuration Checklist

o External and DMZ firewall configured………………………………………………………………………

Directory Services Preparation Checklist

o All Directory tests completed…………………………………………………………………………………………

DNS Configuration Checklist

o DNS records created……………………………………………………………………………………………………………

Applications, Databases, SSL Certificate, and File Systems Checklist

o Application servers configured………………………………………………………………………………………

o SQL Database installed………………………………………………………………………………………………………

o SSL certificate chosen/purchased………………………………………………………………………………

o File System configured………………………………………………………………………………………………………