webnetwrk Pre-Installatin Cnfiguratin Checklist Stneware, Inc. Prduct: webnetwrk versin 6.2 and higher Dcument revisin: 2-10-2015 1
Intrductin This dcument is intended t prvide infrmatin that will assist in webnetwrk architecture design, server hardware selectin, OS chice, firewall cnfiguratin, directry services cnfiguratin, and DNS cnfiguratin prir t a webnetwrk prductin installatin engagement. During the pre-installatin kickff meeting, a Stneware cnsultant will wrk with yu t answer any questins and help yu make apprpriate chices based n yur individual needs. The installatin prcedure will require a technical cntact within the rganizatin that will prvide access t netwrk resurces. It is highly recmmended that this technical cntact be actively invlved in the installatin prcess fr the purpse f knwledge transfer. The frmat will be a learn-as-yu-g and will nt include any frmal training prcess. Executive Gals In rder t deliver the mst effective webnetwrk slutin, rganizatinal gals need t be established and pririties set - within the scpe f the PID (Prject Initiatin Dcument.) It is imprtant that the rganizatinal gals f the IT Executive are cmmunicated t the Stneware cnsultant, as well as the custmer IT technical resurce. Executive gals will be discussed during the pre-installatin kickff meeting. webnetwrk Architecture Determinatin webnetwrk is designed with a tw-tiered architecture cnsisting f a webnetwrk Server and webrelay. Bth the webnetwrk Server and webrelay can run cncurrently n a single (physical r virtual*) server, r the webnetwrk Server and webrelay can be implemented independently n separate servers. The decisin t implement a single server r multiserver cnfiguratin will have an effect n the hardware cnfiguratin, perating system chice, and firewall cnfiguratin. A Stneware cnsultant will help yu determine the apprpriate webnetwrk architecture based n yur needs and capabilities. a) Size f deplyment 1. Stneware webnetwrk implementatins can range frm as few as ten cncurrent users t thusands f cncurrent users. Fr increased perfrmance and security, especially in larger implementatins, a tw-tier cnfiguratin (dedicated webrelay and cmbined webnetwrk Server/webRelay) is highly recmmended. 2. Fr smaller rganizatins (25 cncurrent users and less), where it is impractical t deply a multi-server cnfiguratin due t the additinal hardware expense, a basic single server installatin running bth the webnetwrk Server and webrelay (n the same hst server) can be utilized. As the webnetwrk System grws, it can be recnfigured int a tw-tiered cnfiguratin withut additinal licensing expense. 2
b) Firewall Capabilities and Cnfiguratin 1. The tw-tiered nature f Stneware s webnetwrk allws it t be easily deplyed within a true dual firewall DMZ architecture prviding additinal security and flexibility. Stneware suggests a tw-tiered (multiple server) implementatin where maximum security is a pririty. A basic single server implementatin can be utilized if the rganizatin des nt have a DMZ implemented and the deplyment is supprting less than 25 cncurrent users. c) Cmmn webnetwrk Server / webrelay Cnfiguratins 1. One cmbined internal webnetwrk Server/webRelay (ne physical/virtual server - basic budget cnfiguratin) 2. One cmbined internal webnetwrk Server/webRelay, and ne dedicated public webrelay (tw physical/virtual servers - recmmended minimum cnfiguratin mre secure tw tiered cnfiguratin) 3. One cmbined internal webnetwrk Server/webRelay, and tw dedicated public webrelays (three physical/virtual servers - useful fr lad balancing between DMZ webrelays a hardware lad balancer** t balance the lad between the webrelays is recmmended (nt required) fr maximum flexibility and perfrmance) 4. Tw cmbined internal webnetwrk Server/webRelays, and tw dedicated public webrelays (fur physical/virtual servers - useful fr lad balancing fr bth Internal and DMZ webrelays - hardware lad balancers**, t balance the lad between the internal and public webrelays, are recmmended (nt required) fr maximum flexibility and perfrmance) 5. Tw dedicated internal webnetwrk Servers, tw dedicated internal webrelays, and tw dedicated public webrelays (six physical/virtual servers fully-meshed clustered servers and independent redundant internal and DMZ Relays - hardware lad balancers**, t balance the lad between the internal and public Relays, are recmmended (nt required) fr maximum flexibility and perfrmance) Please see the webnetwrk Server Prgressin dcument fr visual representatins f these cmmn webnetwrk Server / webrelay design ptins:http://swdl.stne-ware.cm/supprt/techdcs/serverprgressin/index.htm * webnetwrk runs well n physical r virtual servers; hwever, the sftware is nt designed t take advantage f tls such as VMWare Vmtin that mve live systems frm ne hst t anther. It is recmmended that the webnetwrk servers and relays be n separate hsts s that they are redundant. Example: Server1 and Relay1 n ne hst and Server2 and Relay2 n anther hst, etc. ** If there are tw r mre relay servers and a lad balancer is present in the prductin netwrk, r will be added at a later time, it is required that an additinal relay server be added and cnfigured in rder t perfrm testing and trubleshting. The additinal relay server will nt be in the prductin envirnment and can be n very limited hardware. Nte: If the lad balancer is handling SSL authenticatin, it is critical that a test relay server be available fr testing and trubleshting. ** Stneware will NOT be respnsible t prvide, cnfigure, r maintain any lad balancing devices. The lad balancer vendr shuld be cnsulted fr apprpriate cnfiguratin changes. The alternate methd f Rund-rbin DNS is supprted, but is nt recmmended as it des nt prvide true lad balancing r fault tlerance. 3
Tw-Server Cnfiguratin Characteristics f this implementatin: One cmbined internal webnetwrk Server/webRelay One dedicated public/dmz webrelay The tw servers can either be physical, virtual, r a mixture This implementatin prvides a mre secure tw-tiered cnfiguratin by directing external users t the DMZ relay Recmmended fr envirnments with up t 3,500-4,000 cncurrent users NOTE: LanSchl Cnnectin Server is nly required if yu use LanSchl and want t integrate the tw prducts. 4
Fur-Server Cnfiguratin Characteristics f this implementatin: Tw cmbined internal webnetwrk Server/webRelays Tw dedicated public webrelays The fur servers can either be physical, virtual, r a mixture This implementatin prvides a mre secure tw-tiered cnfiguratin by directing external users t the DMZ relays Recmmended fr envirnments with up t 7,000-8,000 cncurrent users NOTE: LanSchl Cnnectin Server is nly required if yu use LanSchl and want t integrate the tw prducts. 5
Six-Server Cnfiguratin Characteristics f this implementatin: Tw dedicated internal webnetwrk Servers Tw dedicated internal webrelays Tw dedicated public/dmz webrelays The six servers can either be physical, virtual, r a mixture This implementatin prvides fully-meshed clustered servers and independent redundant internal and external (public/dmz) Relays * Nte: The clustering service is prvided by webnetwrk it is built int the prduct * Hardware lad balancers, t balance the lad between the internal and public Relays, are recmmended (nt required) Recmmended fr envirnments with up t 15,000 cncurrent users NOTE: LanSchl Cnnectin Server is nly required if yu use LanSchl and want t integrate the tw prducts. 6
Hardware Cnfiguratin Stneware recmmends (nt required) server class hardware fr all webnetwrk Servers and webrelays. Stneware webnetwrk will take full advantage f multiple CPU/cre prcessrs and available RAM dependent n hst perating system limitatins. The fllwing specificatins are a basic guide t assist in chsing an apprpriate hardware platfrm. Type / User Cunt webnetwrk Server / webrelay webrelay Ntes Evaluatin 25 users and under Servers: 1 64-bit prcessr 4 GB RAM 5 GB hard disk space 32-bit / 64-bit OS N/A N/A Prductin 10,000 users and under Prductin 10,000 20,000 users Prductin 20,000 50,000 users Servers: 1 64-bit, fur-cre, 2.5 GHz minimum per cre 8 GB RAM 20 GB hard disk partitin 64-bit OS Servers: 2 64-bit, fur-cre, 2.5 GHz minimum per cre 10 GB RAM 20 GB hard disk partitin 64-bit OS Servers: 2 64-bit, fur-cre, 2.5 GHz minimum per cre 16 GB RAM 20 GB hard disk partitin 64-bit OS Servers: 1 64-bit, fur-cre, 2.5 GHz minimum per cre 8 GB RAM 20 GB hard disk partitin 64-bit OS Servers: 2 64-bit, fur-cre, 2.5 GHz minimum per cre 8 GB RAM 20 GB hard disk partitin 64-bit OS Servers: 4 64-bit, fur-cre, 2.5 GHz minimum per cre 8 GB RAM 20 GB hard disk partitin 64-bit OS Here are sme additinal resurces t take int accunt: SQL server fr lgging, cmmunity and teampages features Existing SQL server may be used instead f a new server MySQL and MS SQL supprted Wildcard SSL certificate (*.cmpany.cm) Lad balancer fr envirnments with mre than 2 servers Remte Desktp Services fr Windws based applicatins Nte: A redundant disk subsystem is recmmended n all servers fr increased availability and reliability, but is nt required. webnetwrk is nt a read/write disk intensive applicatin. Which cmpnent f webnetwrk shuld run n the faster server in an envirnment with multiple physical servers f different specificatins? This depends n the webnetwrk services being implemented. In an envirnment where many cre services will be used (e.g. Reprt Services, Cmmunity Services, File Services, Pipeline Services, teampages, etc.) it is advantageus t utilize the mre pwerful hardware fr the webnetwrk Server. If few services will be implemented it may make sense t utilize the mre pwerful hardware n the webrelay. A Stneware cnsultant can wrk with yu t help decide hw t efficiently prvisin hardware based n individual webnetwrk implementatins. 7
Operating System a) Chsing an perating system - Stneware webnetwrk is platfrm independent and can run n mst current server perating systems. It is recmmended t chse yur perating system based n the fllwing criteria: 1. Security - Ability t secure r harden the perating system frm malicius attacks. Operating system manufacturers shuld be cnsulted fr infrmatin related t securing the OS based n the envirnment in which it will be deplyed. Dcumentatin is available fr mst perating systems that will prvide instructins fr securing the OS based n the intended use. 2. Skill General cmfrt and ability t supprt the perating system frm a technical standpint b) Supprted Operating Systems - http://www.stne-ware.cm/web-netwrk/specs#blue_webnetwrk c) Install, Cnfigure, and Patch Operating System - It is recmmended t install Stneware webnetwrk n a clean perating system, withut any services that culd interfere with webnetwrk functinality. A web server is included as part f the webrelay; therefre ther web servers shuld nt be installed n the same server as webnetwrk. All perating systems shuld be updated with the latest patches prir t webnetwrk installatin. d) Assign static IP address t all systems and dcument IP addresses e) Disable anti-virus and firewall sftware Anti-virus and firewall sftware shuld be disabled n servers prir t (and during) installatin f webnetwrk these services may be re-enabled after installatin. Brwser Supprt Stneware's webnetwrk requires a brwser with JavaScript and HTML5 supprt. Sme features require Java (1.6 r higher) n lcal wrkstatin t wrk. Clients will need t meet the minimal requirements f a brwser and Internet/netwrk cnnectin fr full functinality. The list belw utlines a list f suggested brwsers that have been tested and are currently in use by ur custmers. a) Recmmended Brwsers - http://www.stne-ware.cm/web-netwrk/specs#blue_webnetwrk Firewall & Prxy Cnfiguratins The webnetwrk Installatin and Cnfiguratin Guide, included in the full webnetwrk nline dcumentatin, prvides a cmplete descriptin f the cnfiguratin necessary in a DMZ/Firewall setting. This sectin prvides the basic prt cnfiguratin infrmatin needed t install the webrelay and webnetwrk Server in a prductin envirnment. a) Web brwser cmmunicatin with webrelay - Open prts 80 and 443 bi-directinally between the public Internet and the webrelay(s) 8
b) webrelay cmmunicatin with webnetwrk Server (separate Relay/Server installatin) Open prts 1099, 4500, 4501, and 24000 bi-directinally fr TCP traffic between the webrelay and webnetwrk Server when cnfigured n separate bxes. 1. Prts 1099 and 4500 are used fr RMI (remte methd invcatin) 2. Prt 4501 is used fr Pipeline Services 3. Prt 24000 is used fr Relay Central c) Stneware will NOT be respnsible t prvide, cnfigure, r maintain any prxy device r service. If yu utilize such a device r service, yu are required t exclude all webnetwrk servers frm the prxy device r service. Directry Services Preparatin Stneware s webnetwrk utilizes directry services as its primary cnfiguratin and user accunt stre. Directry health must be verified and varius directry features must be enabled, befre webnetwrk can be installed int a prductin netwrk envirnment. Cmplete the fllwing checklist items fr the relevant directry in the prductin envirnment. Micrsft Active Directry (2000, 2003, and 2008) a) Run Stneware Envirnment Check utility - T dwnlad the utility, visit ur Stneware Supprt Utilities page and dwnlad and install the Env Check utility. Fr instructins n hw t run the utility, visit ur Running Env Check page. IMPORTANT exprt the utilities Detailed utput and email t yur Stneware Cnsultant when cmpleted fr verificatin. Nte: See sectin C belw fr the accunt t use when running the utility. b) Enable SSL access t LDAP if nt already enabled T enable full functinality webnetwrk needs t cnnect t LDAP via a secure SSL (prt 636) cnnectin. Micrsft Certificate Server (Enterprise rt CA r Enterprise subrdinate CA) must be installed n an AD member server t enable LDAP ver SSL. DO NOT install this n the Stneware webnetwrk Server(s). If yu cannt run the swenvcheck utility with SSL enabled, please see Enable SSL ver LDAP n hw t set up the Micrsft Certificate Server with default settings. c) Dmain administratr accunt needed fr installatin - webnetwrk Server requires an accunt that is a member f bth Dmain Admins and Schema Admins. The Active Directry schema will be extended during installatin. Nrmal peratin des nt require Schema Admins, but des require the ability t add/edit/delete bjects and attributes (Dmain Admins). A separate service accunt is highly recmmended. d) Verify administratr accunt has schema-admin rights, the dmain cntrller used fr LDAP is the schema master, and allw schema updates is enabled G t Stneware Supprt Utilities and click Schema Diag t dwnlad the AD Schema Diagnse applicatin. This applicatin will verify that the administratr accunt has schema-admin rights, which server is the schema master, and if allw schema updates is enabled. The applicatin must be run frm a Windws cmputer that is part f the Active Directry dmain (e.g. desktp lgged int dmain, Dmain Cntrller server, etc.), and is lgged in with the admin accunt that will be used fr the prductin installatin. Please click the Save buttn in the Schema Diag utility, save the results t a file, 9
and email the file t yur Stneware Cnsultant. The Active Directry server must have Allw Schema Updates ptin enabled t extend the schema and install webnetwrk. If Allw Schema Updates is nt enabled, please see http://supprt.micrsft.cm/kb/285172 fr mre infrmatin n hw t enable schema updates (n Windws Server 2003 and abve yu will nt be able t enable Schema Updates via the Schema Management Cnsle yu will have t enable Schema Updates by means f the Windws Registry.) e) Run Micrsft utilities dcdiag and DNSLint t check Active Directry health DNSLint will make sure there are n replicatins issues. Please see http://supprt.micrsft.cm/kb/321046 fr mre infrmatin n DNSLint. Dcdiag will analyze the dmain cntrller s state and reprt any issues. See http://technet.micrsft.cm/enus/library/cc773199.aspx fr detailed infrmatin n the dcdiag.exe utility. Cnsult Micrsft dcumentatin fr any errr messages fund using these utilities. f) Verify Dmain Cntrller DNS Reslutin frm webnetwrk Server - T verify prper reslutin f the DNS Name / IP Number, bring up a cmmand prmpt n the machine t be used as the webnetwrk Server, and then d a ping -a xxx.xxx.xxx.xxx f the DNS Name / IP Number f the dmain cntrller. This shuld reslve t the REAL name f the dmain cntrller - if the dmain cntrller is named DC1 then the address shuld reslve t dc1.rganizatin.cm. If the DC des nt reslve crrectly the issue needs t be reslved r a manual entry will need t be made in the hsts file n the webnetwrk Server machine t prperly reslve the dmain cntrller. If manual mdificatin f the hsts file is necessary re-d the ping -a xxx.xxx.xxx.xxx test after mdifying the file t make sure it nw reslves prperly. C:\>ping -a 192.168.1.128 Pinging 3-win2k3.swstney3.rg [192.168.1.128] with 32 bytes f data: Reply frm 192.168.1.128: bytes=32 time<1ms TTL=128 g) Verify Dmain Tree Rt Reslutin If, fr example, the AD dmain is dc=rganizatin,dc=cm, then at a cmmand prmpt n the webnetwrk Server machine type the fllwing: ping rganizatin.cm - and verify that the IP number is the same IP number frm the Verify Dmain Cntrller DNS Reslutin frm webnetwrk Server checklist item abve. If ping rganizatin.cm des nt reslve t the dmain cntrller IP number then the hsts file f the webnetwrk Server needs t be manually edited t add the entry. This entry must be the LAST entry in the hsts file. After making the change and saving the hsts file verify the hsts file manual entry using the same ping cmpany.cm cmmand as befre. C:\>ping swstney3.rg Pinging swstney3.rg [192.168.1.128] with 32 bytes f data: Reply frm 192.168.1.128: bytes=32 time<1ms TTL=128 Nvell edirectry (8.5 and newer) a) Verify edirectry versin is 8.5 r newer webnetwrk requires Nvell edirectry versin 8.5 r newer t run. b) Perfrm an edirectry Health-check See http://www.nvell.cm/supprt/kb/dc.php?id=3564075 fr infrmatin n hw t perfrm an edirectry health check. 10
c) Timesync Timesync must be accurate thrughut the entire edirectry tree and all servers that are part f the tree must be up and running t avid causing replicatin issues. d) Determine LDAP server with lcal cpy f directry - Fr best perfrmance, Stneware recmmends directing the webnetwrk Server t the IP address f an LDAP server that is als a lcal cpy f the directry. e) Cnfigure LDAP access t edirectry - webnetwrk Server requires LDAP access n prt 389 (nn-secure) r 636 (secure). In a nn-secure (prt 389) cnfiguratin, ALLOW CLEAR TEXT PASSWORDS must be enabled n the LDAP directry bject. f) edirectry tree administratr accunt needed fr installatin - The webnetwrk Server needs t use the REAL tree admin accunt t access the directry and extend the schema during installatin. Once the schema has been extended, and installatin is cmplete, a separate (e.g. swadmin) accunt can be created with reduced access privileges limited t users/grups/cntainers accessed by webnetwrk Server. g) Test LDAP cnnectin via SSL - Verify LDAP cnnectivity t the edirectry LDAP server using the REAL admin username / pass. An LDAP tl like LDAP Brwser r JXplrer can be used t test the LDAP cnnectin t edirectry. Bth f these utilities can be dwnladed frm http://www.stne-ware.cm/supprt-learning/utilities. Click the Supprt Utilities tab. The tls are listed in the 3rd Party Utilities sectin. OpenLDAP a) Request the Stneware.schema file frm yur Stneware cnsultant and uplad the file n yur OpenLDAP server(s). Verify schema has upladed successfully by running Env Check utility in Part b. b) Run Stneware Envirnment Check utility - T dwnlad the utility, visit ur Stneware Supprt Utilities page and dwnlad and install the Env Check utility. Fr instructins n hw t run the utility, visit ur Running Env Check page. Fr OpenLDAP, just chse edirectry as the Test Type under File. IMPORTANT exprt the utilities Detailed utput and email t yur Stneware Cnsultant when cmpleted fr verificatin. c) Verify admin user can read/write/mdify bjects in the tree. Run an LDAP Brwser tl and cnnect with same user as abve and try t create a Stneware bject. Send screensht r ther prf f verificatin t cnsultant. DNS Cnfiguratin Stneware s webnetwrk technlgy utilizes DNS t prvide virtual access t internal web servers and applicatins. The use f DNS allws webnetwrk t create secure web applicatin cnnectins withut implementing client-side sftware. a) webrelay(s) DNS Names the webrelay requires a unique DNS entry t be addressed by name instead f IP address. This DNS name (e.g. prtal.rganizatin.cm) shuld reslve t the static IP address f the webrelay server. Public DNS servers must reslve the DNS name t the public IP address f the Relay, and the private DNS server must reslve the same DNS name t the private IP address f the webrelay. T simplify cnfiguratin 11
bth the public and private DNS names shuld be identical even thugh they will reslve t different IP addresses based n whether they are reslved frm a public r private DNS. A simple example wuld be prtal.rganizatin.cm reslves t 10.1.1.101 (which will be an IP address f a webrelay) frm inside the private netwrk, and prtal.rganizatin.cm reslves t 68.1.1.147 (als a webrelay) frm the public Internet. The DNS name that reslves t Relays and webnetwrk Web Applicatins must be a sub-dmain (must cntain tw dts) f the primary dmain fr example prtal.rganizatin.cm is valid, rganizatin.cm is nt. It is pssible, but will require additinal cnfiguratin and add cmplexity, t use different internal and external dmain names. b) Web Applicatin Virtual DNS Names each web-based applicatin (e.g. Outlk WebAccess, GrupWise WebAccess, PwerSchl, etc.) that will be accessible thrugh the webnetwrk System will need a new unique Virtual DNS Name exclusively fr use by the webrelay(s). This name shuld be unique and nt be in use by any ther system (e.g. swutlk.rganizatin.cm, swgrupwise. rganizatin.cm, swpwerschl. rganizatin.cm.) End users will nt need t knw these Virtual DNS Names as they are used exclusively by webnetwrk. All unique Virtual DNS Names need t be cnfigured t reslve t the static IP address (private and public) f the webrelay(s), nt the IP address f the actual web applicatin web server. Every Virtual DNS Name that reslves t a webnetwrk Web Applicatin must be a sub-dmain (must cntain tw dts) f the primary dmain fr example swwebmail.rganizatin.cm is valid; rganizatin.cm and rganizatin2.cm are nt valid. Applicatins, Databases, SSL Certificate, and File Systems Checklist The fcus f many installatins is t integrate and secure the internal applicatins thrugh the webnetwrk prduct. T speed implementatin rganizatins shuld have the fllwing infrmatin fr each applicatin, file system, and database that is t be integrated int the webnetwrk system: Applicatins (web, Windws, Terminal Services, Citrix, etc.): a) Stneware webnetwrk des nt natively hst Windws applicatins, but there are several ways t deliver Windws applicatins seamlessly thrugh webnetwrk. The methd f delivery shuld be chsen based n existing r planned Windws applicatin hsting architecture and specific applicatin requirements. Windws Terminal Server Citrix VDI Applicatin Virtualizatin (e.g. ThinApp) Lcal Windws Applicatins (installed n client PC) RDP r VNC access t individual desktp PC b) Applicatin name c) IP address and Prt Number fr applicatin server 12
If a Citrix r Windws Terminal Server applicatin please prvide applicatin PATH and WORKING DIRECTORY d) Lgin URL fr the applicatin (web applicatins) e) Valid User ID and Passwrd t test the applicatin f) The applicatin administratr shuld be available during webnetwrk applicatin cnfiguratin t assist with technical details as needed g) Web-apps cntaining Adbe Flash as part f the lgin page may have issues with Single Sign-On please cnsult the applicatin develpers fr an alternate lgin page r supprted Single Sign-On methd h) Integrating Micrsft SharePint int webnetwrk can be challenging because n tw implementatins f SharePint are the same. It des nt behave like integrating Outlk Web Access (OWA) r ther cmmn webbased applicatins. The integratin will nt be implemented during the initial installatin f webnetwrk. Once the implementatin f webnetwrk is cmpleted, ur cnsultants and supprt engineers will wrk with the custmer n the SharePint integratin until it is cmpleted. Stneware recmmends purchasing additinal hurs t be used fr the integratin 8 hurs minimum, r hurs frm Supprt Cntracts may be used. Databases: a) Fur Stneware applicatin databases (teampages, Relay Lgging, Auditing, and Cmmunities) default t the included Hypersnic database fr testing and dem purpses nly. Stneware recmmends MySQL 4.x r higher, and Micrsft SQL Server 2000 r higher fr prductin implementatins. An external database (nt the included Hypersnic) is required fr all Stneware Cluster implementatins. b) Database name c) IP address and Prt Number fr database server d) Current supprted JDBC database driver e) Valid User ID and Passwrd t the database / table f) The database administratr shuld be available during webnetwrk database cnfiguratin t assist with technical details as needed g) Stneware Reprts Services supprts mst current database servers with a current JDBC/ODBC driver. 13
SSL Certificate: a) A valid wildcard SSL certificate (*.cmpany.cm) is recmmended b) Chse the preferred Certificate Authrity (CA) fr the rganizatin c) Create accunt and purchase the certificate frm CA d) Certificate Request (CSR) will be generated at time f installatin File System: a) File System Name b) IP address r UNC f the file system c) Supprted file system type (e.g. Windws share/cifs, FTP, etc.) d) Valid User ID and Passwrd t the file system e) The file system administratr shuld be available during webnetwrk file system cnfiguratin t assist with technical details as needed 14
webnetwrk Pre-Installatin Checklist Summary Hardware Cnfiguratin and Operating System Checklists Hardware meets expectatins OS cnfigured and patched N firewall/anti-virus/webnetwrk Server.. Firewall Cnfiguratin Checklist External and DMZ firewall cnfigured Directry Services Preparatin Checklist All Directry tests cmpleted DNS Cnfiguratin Checklist DNS recrds created Applicatins, Databases, SSL Certificate, and File Systems Checklist Applicatin servers cnfigured SQL Database installed SSL certificate chsen/purchased File System cnfigured 15