Docstoc

Stoneware webNetwork Pre-Installation Configuration Checklist

Document Sample
Stoneware webNetwork Pre-Installation Configuration Checklist Powered By Docstoc
					                    Stoneware webNetwork

     Pre-Installation Configuration Checklist




(c) 2011 Stoneware, Inc.

www.stone-ware.com

Pre-Installation Configuration Checklist

Version: April 7, 2011
1. 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.


A checklist of items that need to be addressed prior to installation is included in each section of this
document. To eliminate common environmental configuration issues, all checklists contained in this
document should be completed prior to working with a Stoneware consultant to install webNetwork
in a production environment.



2. 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.




3. webNetwork Architecture Determination



webNetwork is designed with a two-tiered architecture consisting of a webNetwork Server and
webNetwork Relay. Both the webNetwork Server and webNetwork Relay can run concurrently on a
single (physical or virtual) server, or the Server and Relay 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.




                                                   1
Example of typical „true‟ dual firewall DMZ architecture with one combined internal webNetwork
Server/Relay, and one dedicated public webNetwork Relay:




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




                                                3
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 webNetwork
            Relay and combined webNetwork Server/Relay) 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 webNetwork Relay
            (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 / webNetwork Relay Configurations

       1.   One combined internal Server/Relay (one physical/virtual server - basic budget
            configuration)

       2.   One combined internal Server/Relay, and one dedicated public Relay (two
            physical/virtual servers - recommended minimum configuration – more secure two
            tiered configuration)

       3.   One combined internal Server/Relay, and two dedicated public Relays (three
            physical/virtual servers - useful for load balancing between DMZ relays – a hardware
            load balancer to balance the load between the Relays is recommended (not required)
            for maximum flexibility and performance)

       4.   Two combined internal Server/Relays, and two dedicated public Relays (four
            physical/virtual servers - useful for load balancing for both 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.   Two dedicated internal Servers, two dedicated internal Relays, and two dedicated public
            Relays (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)




                                                   4
Please see the webNetwork Server Progression document for visual representations of these
common webNetwork Server / webNetwork Relay design options:

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




                                           5
4. Hardware Configuration Checklist

   Stoneware recommends (not required) server class hardware for all webNetwork Servers and
   webNetwork Relays. 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 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?

           1.   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
                webNetwork Relay. A Stoneware consultant can work with you to help decide how
                to efficiently provision hardware based on individual webNetwork implementations.




                                                6
5. Operating System Checklist



   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 - The following are supported operating systems for both
      the webNetwork Server and Relay. In multiple-server configurations, the webNetwork
      Server and Relay can be installed on different operating systems if desired.


          1.   Windows 2000, 2003, and 2008 Server (32-bit and 64-bit)

          2.   Red Hat Enterprise Linux 4 and 5 (32-bit and 64-bit)

          3.   SUSE Linux 9 and 10 (32-bit and 64-bit)

          4.   Mac OS X 10.4, and 10.5 (with JAVA 1.5 or higher, Intel and PowerPC CPU)

          5.   Other operating systems that can support a Sun JVM may be capable of running
               webNetwork – check with your Stoneware Consultant for information on operating
               systems not listed above.


   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
      webNetwork Relay; 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.




                                                7
6. Firewall Configuration Checklist



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
webNetwork Relay and Server in a production environment.

    a) Web browser communication with webNetwork Relay - Open ports 80 and 443 bi-
        directionally between the public Internet and the webNetwork Relay(s)

    b) webNetwork Relay communication with webNetwork Server (separate Relay/Server
        installation) – Open ports 1099, 4500, 4501, and 24000 bi-directionally for TCP traffic
        between the webNetwork Relay and 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




                                                  8
7. Directory Services Preparation Checklist



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 Utilities page and download and install the swEnvCheck. For instructions on how
        to run the utility, visit our Running swEnvCheck 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. 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, 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 3rd Party Utilites 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



                                                  9
     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
     Microsoft dcdiag.exe utility.


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

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

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




                                                   10
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




                                                11
8. DNS Configuration Checklist



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) webNetwork Relay(s) DNS Names – the webNetwork Relay 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 webNetwork Relay
        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 Relay. 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
        webNetwork Relay) from inside the private network, and portal.organization.com resolves
        to 68.1.1.147 (also a webNetwork Relay) from the public Internet. The DNS 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




                                                       12
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
   webNetwork Relay(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 webNetwork Relay(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.




                                            13
9. Applications, Databases, 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

    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


                                                 14
   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.

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




                                             15
10.Stoneware webNetwork Pre-installation Checklist Summary



  a) Supported operating system installed on recommended hardware per Hardware
     Configuration and Operating System Checklists

  b) Firewall ports properly configured per Firewall Configuration Checklist


  c) Directory services configured and tested per Directory Services Preparation Checklist

  d) DNS entries created per DNS Configuration Checklist


  e) Applications, Databases, and File Systems determined per Applications, Databases, and
     File Systems Checklist




                                            16

				
DOCUMENT INFO