TextServer
Company Structured Text Software Solutions Customers Support
Demonstrations Documentation Downloads Publications Acknowledgements



Deploying Textserver

Reasons for Deploying TextServer

TextServer should operate as an OLE/DB COM component under both Windows NT 4.0, Windows 2000 and Windows XP, using either Workstation or server software configurations. TextServer has not been tested for Windows 95/98, and there are known limitations of these systems which might well prove to be problematic for TextServer.

TextServer is not intended to function as a stand-alone program but instead to be tightly integrated with end user applications. These applications fall into the following broad categories:

  • Applications which wish to present the results of queries that retrieve fragments of structured text to viewers via a web browser interface.
  • Applications which perform data intensive processing by using OLE/DB interfaces to one or more OLE/DB service providers. Typically such applications wish to represent results as large tabular tables.
  • Applications which wish to construct new texts from old, and wish to do this by having some form of programmatic interface to the information contained within the text indexes themselves.

Required software

When presenting information to viewers of web browsers, IIS needs to be installed and functioning correctly. In this environment TextServer will typically be access via ADO (which wraps OLE/DB system calls to TextServer beneath objects callable from ASP, and provided by Microsoft).

Software that needs to communicate with TextServer directly needs to implement the necessary client request to OLE/DB to cause dynamic linking and invocation of TextServer. Sample source code for a simple client called call_oledb which may be found in the source directory serves as a useful template for future software development in this area.

Those who wish to interface directly with the text indices may do so by using low level functions provided as extensions to the SQL2 language which map selected information about texts obtained from the relevant text index into apppropriate data values. If considered desirable low level libraries could be developed which allowed generic access to the indexed information about texts, without the needless overhead of having to parse SQL2 in order to recover this information.

Installing Server 2000

While TextServer can be evaluated under ASP by using NT Option Pack 4 it is recommended that those serious about deploying TextServer within Web applications deploy NT Server 2000.

Installing NT Server 2000, is relatively straight forward provided that DHCP is not configured to operate within any router. If it is then NT Server 2000 erroneously concludes that it is not the only server on your network. If you are unable to alter this configuration of your router, the entire NT Server 2000 installation must be done manually.

Recommended texts to assist in deploying Internet Information Services (IIS) include:

  1. Microsoft Internet Information Services 5.0 Documentation
  2. Microsoft Windows 2000 Server Administrator's Companion
  3. Professional JavaScript - Nigel McFarlane
  4. Learning VBScript - Paul Lomax
  5. Java in a Nutshell - David Flanagan
  6. Professional ADO 2.5 Programming - David Sussman et. al.
  7. ASP 2.0 Programmers Reference - Alex Fedorov et. al.
  8. Using Active Server Pages - Scot Johnson
  9. Developing ASP components - Shelley Powers
  10. OLE DB 2.0 Programmer's Reference and Data Access SDK - Microsoft
  11. ODBC 2.0 Programmer's Reference and SDK Guide - Microsoft
  12. Instant HTML 4.0 Programmers Reference - Alex Hommer et. al.

Installation of Server 2000 is straightforward, but personal experience suggests that getting permissions correctly configured to allow restricted but controlled access to IIS from the World Wide Web is/can be far from straight forward.

Avoid deploying any software which might effectively block messages from the Internet from being delivered cleanly to server software running on your Server machine. A partial checklist of possible issues, conflicts or concerns follow. Consider:

  • The protocol used within your LAN for intra-machine communication. TCP/IP is the recommended protocol. There is a risk that you might attempt to talk to the router using a protocol unknown to the router.
  • Be aware that you may quite legitimately be unable to see a router connected to your intranet, from your server.
  • Avoid using IPSEC unless you are certain that the router supports this.
  • Make sure that IP addresses, gateways, DNS addresses, etc are correctly specified.
  • Consider what impact Active Directory authetication mechanisms will have on your router. In particular recognise that installation of Active Directory will reset permissions to defaults, potentially revoking permissions by IIS to see necessary TextServer files.
  • Consider what the impact will be of placing your Server machine within a domain that your router is not a member of.
  • Consider what impact running kerberos may have on a router which is unfamiliar with the kerboros protocols.
  • Avoid initially deploying any software which might compound the difficulty of explaining and correcting denial of service.
  • If possible deploy NT Server after rather than before the router is configured to avoid any possible confusion arising because both NT Server and a router colliding on common services such as DNS,and DHCP, or whatever. [Before connecting a router I was able to configure my server as the sole server on my network. However when reinstalling my server software, after installing a router, I was told that I could not configure my server as the sole server because other servers existed on the network.]
  • Do not deploy NT Server's software router if you are employing a hardware router.
  • Avoid if possible configuring your server as a primary domain controller. Texts suggest that the need to constantly support authorisation functions as a primary domain controller, will degrade server performance.
  • Be aware that security may more easily be compromised if your primary domain controller is directly connected to the net, since any breach of your firewalls will leave invaders on the machine containing your companies most sensitive security information.
  • Be aware that Microsoft considers the security of a primary domain controller so important that texts suggest that Microsoft when installing a server designated as a primary domain controller, may disable rather than enable anonymous connections to the server by external users.

Setting up IIS

  1. Make sure that a suitable home page is placed in the c:\inetpub\wwwroot directory. Device and location may vary depending on installation parameters.
  2. Set up a virtual directory for your own web pages, rather than directly store user constructed pages in the wwwroot directory. This makes them easier to manage, move and administer. To set up a virtual directory navigate through: Start, Programs, Adminstrative Tools,INternet Service Manager, machine, highlight Default Web Site, then select from the menu Action, New, Virtual Directory.
  3. Change IE5 to have http://localhost as its default home page, if you wish to test your web pages internally.
  4. Change this to the designated domain name for your web pages when you wish to test how the pages appear externally.
  5. Install Service Pack 1 and any later announced Service Packs.
  6. Install 128bit encription software available from Microsoft, if authorised to do so.
  7. Set internet permissions by navigating through: Start, Programs, Adminstrative Tools, Internet Service Manager, machine, highlighting Default Web Site, and then selecting Action from the menu, All tasks, Permissions Wizard, Select new security settings from a template, public and then follow the instructions. N.B. Do not choose the default if you wish permissions for a public web site, and this is not the default.
  8. Verify that IUSR_machinename is identified as a valid user, and that this reserved user name under which IIS operates has permissions to access, all necessary files. N.B. This user id, must also have permission to execute the DDL's provided with this release. If you are unable to connect to TextServer through ADO, check permissions leading to the TextServer/Debug and TextServer/Release directories.
  9. Check internet permissions by navigating through: Start, Programs, Adminstrative Tools, INternet Service Manager, machine, highlight Default Web Site, right clicking, selecting properties, and carefully review the Directory Security Tab, and other relevant information.
  10. TextServer returns extended error messages according to the standard proposed in OLE/DB. However, these extended error messages will not be recoverable by any client application unless msdaer.dll is registered (using regsvr32 if necessary). This dll can be found in \WINNT\ServicePackFiles\i386\msdaer.dll.
  11. TextServer will almost certainly be accessed via ADO through ASP. Therefore ensure that \WINNT\ServicePackFiles\i386\msado15.dll is registered (if necessary) by using regsvr32.
  12. TO gain the convenience of being able to use ADO symbols by name rather than by value, add a file named global.asa to you previously defined virtual directory. This file should contain a single line having as its value <!-- METADATA TYPE="TypeLib" FILE="\WINNT\ServicePackFiles\i386\msado15.dll" --> and instructs ASP to load into its own internal memory space the contents of the ADO type library.
  13. Consider setting up a password protected user account capable of logging in to the machine supporting IIS which is initially created as a copy of IUSR_machinename. This will allow you to test the basic TextServer functionality, resolve IUSR_machinename permissions problems, etc. using call_oledb.exe. It is very much easier to trouble TextServer by invoking it directly, than by executing TextServer under layers of software that at best provide only rudimentary error reporting capabilities.
  14. If desired, set ASP debugging by navigating through: Start, Programs, Adminstrative Tools, INternet Service Manager, machine, Default Web Site, Desired Virtual directory, selecting properties, Virtual directory, Application Configuration, App Debugging. This feature is highly recommended if you ASP pages are not yet stable.
  15. Carefully evaluate Active Directory before considering deploying it. Active directory adds potentially needless complexity to your server, may potentially degrade performance (this is not at all clear), and may well leave systems administrators familiar with NT4.0 questioning why if it wasn't broke, Microsoft saw fit to do such an extensive job of fixing it.
  16. Be aware that a server configured as a domain controller, may be configured by Microsoft to default to immediately write to disk all disk updates received by the NT kernel, in an effort to improve the reliability of the domain coordinator. This may have some negative impact on Web sites which perform considerable database update.

Further observations

The above list is far from exhaustive. Please send mail to webmaster@textserver.com if you have suggestions as to how these instructions derived from experience with System 2000 might be improved.
Maintainer
webmaster@textserver.com
Back