|1Introduction| |0Welcome!| |^ WASD is outlined in the |link%|../features/##Introduction| and |link%|../features/##Package Overview| sections of the |link%|../features/##|WASD Features| document. |^ Installation and update of the package is covered by |link%|../install/##|WASD Installation||. |^ This document provides detailed configuration instructions of the WASD Web Services package. |^ Following installation the package should require only minor further configuration for basic serving. |^ WASD configuration is performed using the contents of five files located using logical names |table| |~ |. WASD_CONFIG_AUTH |. request authorization control |~ |. WASD_CONFIG_GLOBAL |. global server configuration |~ |. WASD_CONFIG_MAP |. request processing control |~ |. WASD_CONFIG_MSG |. provides server messages |~ |. WASD_CONFIG_SERVICE |. specifies services (virtual servers) |!table| |^ along with server CLI parameters commonly provide by startup DCL procedures. |^ |*Initially| two files may require alteration. |number| |item| The startup file, possibly to set the local WASD_CONFIG_GMT logical (for systems not supporting DTSS (e.g. DECnet-Plus)). Consider using the STARTUP_LOCAL.COM file for other site-specific requirements (|link%|../install/##Account Support Files++in++WASD Installation||). |item| The only configuration that should require immediate attention will be the mapping rules (|link|Request Processing Configuration||). |!number| |^ |*More generally| server runtime configuration involves the considerations discussed in |link|Site Organisation| along with the following aspects: |bullet| |item| Configuring the HTTP server run-time characteristics (|link|Configuration Considerations||). |item| Mapping request paths to the VMS file system, and to other things such as scripts (|link|Request Processing Configuration||). |item| Customizing some or all messages (|link|Message Configuration||). |item| Establishing an authentication and authorization environment (|link|Authorization Configuration (Basics)||). |!bullet| |0Keep site-specific resources and server installation separate and distinct.| |2Troubleshooting?| |^ When initially installing or configuring WASD, and sometimes later where something breaks spectacularly, it is most useful to be able to gain insight into what the server is up to. |^ The |/go-to| tool is\  |"WATCH||\  (yes, all capitals, and for no other reason than it makes it stand out). |^ WATCH is described in detail in |link%|../features/##WATCH Facility++of the++WASD Features and Facilities|| document. |^ For most circumstances WATCH can be made available for troubleshooting even if the configuration is significantly broken. This is done by using a skeleton-key to authorise special access into the server. |^ The skeleton-key is described in detail in |link%|../features/##Skeleton-Key Authentication++of the++WASD Features and Facilities|| document. |^ |*TL;DR| |^ Enable at the command-line with the username anything beginning with an underscore and at least 8 characters, same for the password length. |code| $ HTTPD /DO=AUTH=SKELKEY=_|/username||:|/password|| |!code| |^ Then using a browser access any available service, entering the above username (including underscore) and password when prompted. |block| |link%|/httpd/-/admin/report/WATCH|https://\the.host.name:port\\ /httpd/-/admin/report/WATCH| |!block| |^ The service administration facilities (of which WATCH is one) are also available and useful. |block| |link%|/httpd/-/admin/|https://\the.host.name:port\\ /httpd/-/admin/| |!block|