Controlling site-wide parameters involves creative use of data tables for both efficiency and ease of maintenance.
Setting up a site that can effectively control its membership and site-wide options without the need for costly custom coding for labor intensive data entry is a key success factor in any Active Server application.
Mail messages and custom site postings should provide efficient and low-cost methods for delivering information to your membership community.
With extended administrative features and increased membership reliance on your Active Server site, ensuring high availability and effective security is a priority.
In the overall database design, the AdminParameters table does not directly relate to any one table except that it provides the values that can be used to populate drop-down boxes. In fact, the entire purpose of the AdminParameters table is to provide site administrators the capabilities to vary the values in drop-down boxes throughout the system without having to alter HTML or Active Server Pages. Figure D.1 illustrates the tables used by the Introduction Service and shows how they relate to each other.
This shows an overview of Introduction Service table design and relationships.
The AdminParameters table provides a method for enabling one table to act as a container for many categories of small lists such as religious choices and ethnic options. Table D.1 illustrates the fields in this table such as text descriptions and unique IDs. In addition to storing categories of values, the table also enables you to specify a collating order and a default value within a given category of values. This method proves invaluable for enabling site administrators to rapidly make changes to their sites without involving a programmer in the process. A specific example of a category of values that might be included in this table is ethnic backgrounds, which includes Caucasian, Hispanic, Asian, and others that can be changed and added over time.
Table D.1 Administrative Parameters for Use Throughout the System
| Field Name | Data Type | Size | Description |
| SysParamID | Number (Long) | 4 | Primary Key |
| SysTypeParam | Number (Long) | 4 | Category of parameter |
| ParamValue | Text | 150 | Actual text display value |
| ColatingOrder | Number (Integer) | 2 | Value for sorting within category |
| Default | Yes/No | 1 | Default value within category |
Managing a site often requires several levels of security, allowing site administrators various levels of information access and update capabilities. At this time, the Introduction Service has only one level of security, allowing users access to a series of query and update features for information throughout the site. The areas of management fall into two primary categories. The first category of management is the editing of specific members' information as well as site-wide parameters like the AdminParameters table values. This first category makes up the majority of features included in the Introduction Service. The second category represents money related or accounting related areas of the Server and includes all administration related to accounting, billing and fee collection. Whereas we cover money issues in great detail in Appendix E, "Implementing Billing and Payment Mechanisms," at this time we focus on the functionality surrounding administration of membership account information and site-wide information parameters.
Unlike the screens used by the members to manage their own information, for the Site Administrator, managing user information involves finding the user or member he intends to modify and then starting a process to edit information on that user's record. We will focus on the administrative access to the user account, based solely on member ID (though search facilities also exist on the site to find a member by first and last name). This initial member screen illustrated in Figure D.2 does a lookup on the member ID entered and returns a page partially filled with read-only display information and partially filled with form fields that are defaulted to current member values and are ready for editing.
The Membership editing screen enables site administrators to update user profiles.
The resulting display page or adminsearch.asp page (see Listing D.1) provides an editing environment in which site administrators can edit specific administrative flags on the account, including expiration date, password, availability of graphics, gender settings, and more. The Active Server Page involves a very straightforward lookup and display. And because Windows NT Server security has been enforced to isolate the secure directory from normal members and guest users, no validation pages are required.
Listing D.1 ADMINSEARCH.ASP-Lookup and Display Page for Administering a User's Account
<%
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open("firstsite")
If request.querystring("memberid") = "" then
memberid = 0
Else
memberid = request.querystring("memberid")
end if
sql = "SELECT * FROM Members WHERE Members.MemberID=" & memberid & ";"
Set rs = Conn.Execute(sql)
If rs.EOF then
newpage = "index.htm"
response.redirect newpage
End If
%>
<html><head><title>Admin - Update User Profile</title></head>
<body bgcolor="#FFFFFF">
<form action="adminprofileupdate.asp" method="POST">
...
Once any and all changes have been made, the administrators can update the member account by executing the adminsearch.asp file . The Update Page or adminprofileupdate.asp completes all the validations and testing necessary to build and execute the update SQL statement on behalf of the administrative user as illustrated in Listing D.2.
Listing D.2 ADMINPROFILEUPDATE.ASP-Administrative Routine for Updating Member Account Information
<%
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open("firstsite")
'Testing Uncertain Values
'--------------------------
admexpdate = request.form("admexpdate")
admonlinedate = request.form("admonlinedate")
If admexpdate = "" then admexpdate = "01/01/96"
If admonlinedate = "" then admonlinedate = "01/01/96"
sql = "UPDATE Members SET"
sql = sql & " Members.admexpdate =#" & admexpdate & "#,"
sql = sql & " Members.admonlinedate =#" & admonlinedate & "#,"
if request.form("pass") <> "" then
sql = sql & " Members.pass ='" & request.form("pass") & "',"
end if
sql = sql & " Members.admstatus =" & request.form("admstatus") & ","
sql = sql & " Members.admpublic =" & request.form("admpublic") & ","
sql = sql & " Members.admingraphics =" & request.form("admingraphics") & ","
sql = sql & " Members.profsex =" & request.form("profsex") & ","
sql = sql & " Members.download = 1 ,"
sql = sql & " Members.AdmModDate = #" & Date() & "#,"
sql = sql & " Members.profprefid =" & request.form("profprefid")
sql = sql & " WHERE Members.memberID=" & request.form("memberid") & ";"
Set rs = Server.CreateObject("ADO.Recordset")
rs.Open sql,Conn,3
if request.form("admstatus") = 0 then
sql2 = "UPDATE Selections SET"
sql2 = sql2 & " Selections.SelectStatus = 4,"
sql2 = sql2 & " Selections.SelectFinalDate = #" & Date() & "#"
sql2 = sql2 & " WHERE (Selections.SelectedMemberID=" & clng(request.form("memberid")) & ") AND (Selections.SelectStatus <> 7);"
Set rs2 = Conn.Execute(sql2)
end if
%>
<html><head><title>Confirm Admin Update</title></head>
<body bgcolor="#FFFFFF">
<h3><center>Your update has been processed</center></h3>
<p><a href="http://www.1st-site.com/secure/index.htm">
Return to Admin Homepage</a></p></html>
Site-wide parameters stored in the AdminParameters table offer the administrative user (non-programmer) a mechanism for updating the site without knowing Active Server syntax and without the risk of adding new code, which could damage to the overall functioning of the site. Determining what information should be hardcoded into the pages and what information to set up as lookups in a table like the AdminParameters table, requires careful consideration and should be a focus of your work in the design phase of any site development project. Overuse of administrative parameters can unnecessarily slow down the site and can cause extra traffic on the database. The balance point must be set on a case-by-case basis. On the Introduction Service, we chose to implement parameters for many of the choices that members made while building their profiles. The importance of these choices stemmed from the search engine features and how those features relied on profile information during the search process. Figure D.3 shows the categories that can be controlled on the Introduction Service.
Administrators can edit a variety of profile parameters.
Once an administrator selects a given category, the parameter lookup page or adminparamHead.asp executes a search for all values in the AdminParameters table, based on that category. To prevent removing values that a user currently has selected in her profile, the administrative user can update or add but can not delete records. A series of four .asp files provides all functionality for the lookup, add, and update of administrative parameters:
The adminparamhead.asp provides a simple lookup and list of the values, based on category ID. In addition, a link is created to the adminparamadd.asp for a new entry and a hyperlink to the adminparamdetail.asp for editing an entry. The code generating this page is illustrated in Listing D.3.
Listing D.3 ADMINPARAMHEAD.ASP-Simple Display of Category- Based Information in the AdminParameters Table
<%
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open("firstsite")
sql = "SELECT * FROM AdminParameters WHERE systypeparam = " & request.querystring("Type") & " ORDER BY ColatingOrder;"
Set rs = Conn.Execute(sql)
%>
<html><head><title>Administration - Parameter List</title></head>
<body bgcolor="#FFFFFF">
<h1><center>Administration - Admin Parameters</center></h1>
<%'------------------------
'Add Feature
'------------------------%>
<p><a href="http://www.1st-site.com/secure/adminparamadd.asp?Type=<%=rs("systypeparam")%>">[Add Value for this Parameter]</a></p>
<%'------------------------
'Editing Feature
'------------------------
Do While Not rs.EOF%>
<p><a href="http://www.1st-site.com/secure/adminparamdetail.asp?Type=<%=rs("systypeparam")%>&value2=<%=rs("sysparamid")%>"><%=rs("paramvalue")%></a></p>
<%rs.MoveNext
Loop%>
<center><p><a href="http://www.1st-site.com/secure/index.htm">Return to Admin Homepage</a></p></center>
</body></html>
Whether the hyperlink for editing a specific item is selected, invoking the adminparamdetail.asp, or the link enabling the adding of a new item is selected, invoking the adminparamadd.asp, the resulting page displayed to the Site Administrator is virtually identical. Only two differences exist between the adminparamdetail.asp and adminparamadd.asp options. The first difference is a flag set identifying whether to add a new record or edit an existing record. The second difference is that when an existing record is selected, the values in the HTML form fields are populated based on the currently set values in the database. Figure D.4 illustrates the adminparamdetail.asp display, which shows an existing record with values populated from the database. Listing D.4 illustrates the code used to generate the page.
adminparamdetail.asp display for editing of the Admin Parameters.
Listing D.4 ADMINPARAMDETAIL.ASP-Detail Display of Individual Record from the AdminParamaters Table for Editing
<%
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open("firstsite")
sql = "SELECT * FROM AdminParameters WHERE sysparamid =" & request("value2")
Set rs = Conn.Execute(sql)
%>
<html><head><title>Edit Admin Parameters</title></head>
<body bgcolor="#FFFFFF">
<form action="adminparamupdate.asp" method="POST">
<h1><center>Edit - Admin Parameter</center></h1>
<table>
<tr><td width=20%><b>Parameter Value:</b></td><td>
<input type=text size=60 maxlength=150 name="paramvalue" [ic:ccc]value="<%=rs("paramvalue")%>"></tr></td>
<tr><td width=20%><b>Sort Order:</b></td><td>
<input type=text size=3 maxlength=3 name="colatingorder" [ic:ccc]value="<%=rs("colatingorder")%>"></tr></td>
<% If rs("Default") = -1 then %>
<tr><td width=20%><b>Default:</b></td><td>
<input type=radio name="default" checked value=-1>
Yes<input type=radio name="default" value=0>
No</tr></td>
<% Else %>
<tr><td width=20%><b>Default:</b></td><td>
<input type=radio name="default" value=-1>
Yes<input type=radio name="default" checked value=0>
No</tr></td>
<% End If %>
</table>
<p><center><input type=submit name="btn" value="Update"></center>
<INPUT NAME="value" VALUE=<%=request.querystring("value2")%> TYPE=HIDDEN>
</form></html>
The final step in the administrative area for maintaining a value in the AdminParameters table involves the Active Server Page for executing the insert or update of the value. This Active Server Page or adminparamupdate.asp file provides a simple conditional evaluation to determine whether to update or insert and then uses the request variables passed in from the form to execute the SQL statement as illustrated in Listing D.5.
Listing D.5 ADMINPARAMUPDATE.ASP-Insert or Update of Value in the AdminParamenters Table
<%
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open("firstsite")
colatingorder = request.form("colatingorder")
if colatingorder = "" then colatingorder = 0
'------------------------
'Update Feature
'------------------------
if request.form("btn")="Update" then
sql = "UPDATE AdminParameters SET"
sql = sql & " AdminParameters.paramvalue ='" & request.form("paramvalue") & "',"
sql = sql & " AdminParameters.default =" & request.form("default") & ","
sql = sql & " AdminParameters.colatingorder =" & colatingorder
sql = sql & " WHERE AdminParameters.sysparamID=" & request.form("value") & ";"
Set rs = Server.CreateObject("ADO.Recordset")
rs.Open sql,Conn,3
'------------------------
'Add Feature
'------------------------
else
set rsInsert = Server.CreateObject("ADO.RecordSet")
Conn.BeginTrans
rsInsert.Open "AdminParameters", Conn, 3, 3
rsInsert.AddNew
rsInsert("systypeparam") = request.form("systypeparam")
rsInsert("paramvalue") = request.form("paramvalue")
rsInsert("colatingorder") = request.form("colatingorder")
rsInsert("default") = request.form("default")
rsInsert.Update
Conn.CommitTrans
rsInsert.Close
end if
'------------------------
%>
<html><head><title>Confirm Admin Update</title></head>
<body bgcolor="#FFFFFF">
<h3><center>Your update has been processed</center></h3>
<p><a href="http://www.1st-site.com/secure/index.htm">
Return to Admin Homepage</a></p></html>
The series of four Active Server Pages and one table, which provides the site parameters features, can be invaluable to all site development efforts and can be easily plugged into different sites.
In a Web-based environment driven by Active Server Pages, the challenge of maintaining active communication with the membership can appear at first to be difficult. In the same way that members no longer having to communicate directly with customer service or other types of support personnel has lowered the cost of delivering an interactive service, the amount of direct contact the service provider has with the membership also has been limited. However, with the effective use of dynamic page-generation capabilities and the integration of Mail services, the service provider can also creatively deliver information to the member in a very convenient, consistent, and unobtrusive manner.
The primary methods of communication utilized in the Introduction Service include the capability to provide custom information on the Start Page as a user logs into the system and batch Mail to the community through database-driven Mail delivery.
Unlike a bulletin board or banner at the front of a physical location, the custom-generated Start Page empowers the service provider to deliver specific messages to a particular user. For example, because the system knows the birthday of every member, when a member logs in whose birthday equals the current date, a custom system birthday greeting or promotion can be provided. This type of custom message delivery, which can be driven by any information stored about the member, provides a flexible method of communicating with a membership. In fact, its flexibility actually leads to a design problem as you try to limit the site to a set of features that can be set as parameters for the site.
The specific components necessary to implement a rule-based approach to delivering this type of custom messaging includes setting up a database table like the one illustrated in Table D.2, followed by logic to generate the message display and administrative pages to edit the messages and rules.
Table D.2 SysMessage Table for Storing and Administering Messages
| Field Name | Data Type | Size | Description |
| SysMessageID | Number (Long) | 4 | Primary Key |
| MemberFieldName | Text | 75 | Name of field in member table to evaluate |
| SysOperator | Number (Long) | 4 | Value to represent =,>,< for evaluating rule |
| MatchingValue | Text | 150 | Value to compare to value in members field specified based on operator selected |
| SysMessage | Memo | - | Actual text display value or message |
| SysActive | Yes/No | 1 | Value to assign whether this rule-based message is currently active |
A birthday message would be a specific example of a rule that could be set up in the data table illustrated in Table D.2. This would include a data record such as the one illustrated as follows.
| MemberFieldName | SysOperator | MatchingValue | SysMessage |
| memdob | = | Date() | <b>Happy Birthday <b> |
The information included would be the name of the Date of Birth field in the member table, a matching operator like the equal sign (=), a matching value like a function providing the current date (date()), and finally a message that can be used for display. Once you set the table structure for assigning the rule-based evaluation and add the necessary values to the table, the two remaining components to implement include:
The administrative environment will closely follow what has already been illustrated with administrative parameters in the section "Managing Site-Wide Parameters." Listing D.6 provides a sample of how you integrate the rule-based messaging template into your Start Page as a Server-Side Include.
Listing D.6 TEST_MESAGE.ASP-Custom Message Delivery Mechanism for Providing Users with Start Page Greetings and Other Communication
<%
'Assume Member information is available under in rs recordset
'------------------------------------------------------------
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open("firstsite")
sql = "SELECT * FROM SysMessage WHERE SysActive = -1"
Set rsMessage = Conn.Execute(sql)
Do While Not rsMessage.EOF
'Evaluate logical operator with select case
Select Case rsMessage.sysoperator
Case 1
if rs(rsMessage.memberfieldname) = rsMessage.matchingvalue then
response.write rsmessage.sysmessage
end if
Case 2
if rs(rsMessage.memberfieldname) > rsMessage.matchingvalue then
response.write rsmessage.sysmessage
end if
Case 3
if rs(rsMessage.memberfieldname) < rsMessage.matchingvalue then
response.write rsmessage.sysmessage
end if
End Select
rsMessage.MoveNext
Loop
rsMessage.close
%>
Similar in principle to the custom messages delivered to the Start Page for your membership, Mail can provide a mechanism for delivering a custom message to a subset of your membership community. The Mail functionality provides an important complement to the Start Page bulletin board-type posting, much like a company mailing complements a flyer in the break room.
With the batch Mail delivery, the focus returns again to the administrative pages provided to a site administrator, who is responsible for membership communication. Although maintaining an Mail distribution list for sending broadcasts to a membership community hardly appears as something new, the value added by combining a Microsoft SQL Server delivery engine with Active Server Pages is in the capability to target the messages based on membership information stored in the database.
The Mail capability described in "Batch Mail Delivery to Membership" requires Microsoft's SQL Server product. Currently, this site primarily operates based on Microsoft Access, which does not currently have the SendMail extended stored procedure capability.
The primary components to delivering this type of content do not include an additional data table as in the Start Page message delivery, because message creation and delivery will be based on an administrator actively using Active Server Pages. Instead, the primary modules needed for this communication include only Active Server Pages in the administrative area, which provides search criteria to build a list for distribution and then a message area for typing in the appropriate message.
As an additional approach or feature, a new table could be created to set up rules for delivering system-generated Mail messages, based on a scheduled stored procedure in Microsoft SQL Server.
The first administrative page involves defining the group of members to receive the Mail message. This involves implementing a search process similar to that used in the members search process described in Appendix C. Figure D.5 illustrates this first administrative page.
This is a search screen for building a list of the Introduction Service's membership for custom Mail message delivery.
Once the query has been run, a summary report should be provided that enables the site administrator to ensure they have properly run the search criteria that they wanted. At this point a simple subject line and text area for delivering the message must be provided.
Be careful if your messages exceeds 255 characters because this may cause a problem with the standard SendMail extended stored procedure provided with Microsoft SQL Server
As with any site, security and performance monitoring play important roles in the overall success or failure of a site. Based on the NT Server platform, a series of tools and features can be implemented to ensure a secure and robust site. The specific focus of this section is to provide an overview of the steps taken in the rollout of the http://www.1st-site.com Introduction Service, based entirely on Active Server Pages. The key points for discussion include ensuring:
We need to preface this discussion by saying that we are engaging upon a big topic, and an entire book can easily be dedicated to the issues surrounding security on the Internet/intranet. We will not attempt to provide that type of treatment here but will instead only share the steps that were taken with respect to the Introduction Service. Along the way, however, we will highlight red flags that you should pursue. Whether the areas highlighted as red flags fall under your direct responsibility or not, you should be armed to ask questions. Don't let a network administrator ignore your inquiries because the chances are good that they also are trying to understand all of these risks. With that said, here is a quick tour of the procedure we took in bringing up Love @ 1st Site.
For the Introduction Service, security fell into two areas: the ability of an outsider to penetrate our network or one or more of our servers (we run Microsoft SQL Server, Microsoft Exchange Server, and Microsoft IIS 3.0 on three different machines), and the risk of someone intercepting a transmission across the Internet that might include credit card numbers, passwords, or other sensitive information.
Information in Transit on the Net
The issue of information in transit impacted the use of both the Web Server and the FTP Server. Both of these products are combined in IIS 3.0, but they provide different levels of security in the way they move information.
With respect to the FTP server, basically we were out of luck. All FTP information is transmitted as plain text that includes NT Server usernames and passwords. Somehow we had to enable administrators to move member pictures into the Web server directories, but by compromising the FTP logon, any hacker could immediately log into our administrative pages. We considered creating limited, separate, FTP-only accounts but still faced the risk of unauthorized access to our art work. This would have been the solution if a working version of Microsoft's Point to Point Tunneling Protocol (PPTP) had not become available in the commercial release of Windows NT Server. Though it required an NT machine at both ends (because NT provides the only current client platform), PPTP enabled us to map drives across the Internet with Windows NT's fully enabled authentication model, including encrypted authentication.
Point to Point Tunneling Protocol (PPTP) The complete specification can be found at the Microsoft home page, currently http://www.microsoft.com/ntserver/communications/pptp.htm. One of the features enabled by the PPTP standard is the ability to access file sharing services on a Windows NT Server, which has enabled PPTP filtering in the Network Control Panel.
OK, so what about the Web server? The traditional response in this area is Secure Sockets Layer (SSL). By using an SSL certificate provided through Verisign (http://www.verisign.com), we were able to provide encryption of data moved between the two locations.
Secure Sockets Layer (SSL) The SSL standard provides a method for encrypting communication between a Web server and Web browser. For additional information on SSL, visit http://www.versign.com, a leading provider of signed SSL keys for use by Web servers.
We will discuss SSL in more detail in Appendix E on billing and payment issues
But at this point, we have achieved only an acceptable level of confidence with respect to information in transit from one place to another. The far greater threat involves direct penetration of our network and servers.
Network Security and "The Firewall"
Any self-respecting network today should be insulated from the outside world by some form of Firewall. This word is used quite loosely and actually reflects a series of services, including proxy servers and packet filtering. Microsoft's Proxy Server, now in final release, provides the capability to hide your computer IP address from the outside world by establishing a group of IP addresses for the outside world and a separate set of IP addresses for your internal network that the Proxy Server maps to enable internal computers to talk with external computers. Another important feature that we evaluated, packet filtering, limits the type of traffic that can make it through your Firewall onto the internal network.
While implementing these features seems like an obvious precaution, at the time of this book's release, we were still determining the Firewall-related features we would implement (have mercy on our defenseless network). We have been involved in many bad implementations in which, by default, too much network security was implemented and applications appeared to be down to the outside world. We hope to have this up and running before street date to ensure that no one out their decides to teach us a lesson. The key message here is DO IT-add these features-just be careful not to bring down your application in the process.
Server Security: "The NT Myth"
Everyone that we talk to seems to think that out-of-the-box, NT Server provides that oft talked about C2 government security level. Actually, out-of-the-box, NT has a lot of holes. If you are responsible for network security, you need to understand the risks inherent in NT. Check out the October 1996 issue of Windows NT Magazine for more information.
I won't go ad nauseum through all of the steps we have had to take to secure the Introduction Service, but here are some cautions you should heed:
While being careful not to burden your system with excessive monitoring, you will need some monitoring and logging to provide useful information for determining when you need to add RAM and CPU resources. The performance monitor and your Web server statistics can provide this type of valuable information. Take some time to figure out how you can take the hundreds of thousands of records accumulated by these monitoring tools and turn them into meaningful information. Your Web administrator should be exploring commercial products and creative uses of database queries to help in this process. From a development perspective, you may also want to integrate a custom logging feature into your Active Server Pages, i.e. set up insert statements to create log records in a table, based on different types of key activity.
Most people limit the monitoring of their systems to a passive role. However, you also should consider carefully how to use the Alert mode of the performance monitor to launch different types of notification programs. In addition to the performance monitor, you should assess the other types of NT services running in your environment and determine how they can help. For example, Microsoft Exchange Server can monitor any of your running services and generate Mail notifications. SQL Server can also provide monitoring capabilities that result in running stored procedures that send Mail or execute command line programs.
For our Introduction Service, we focused on the alerting capabilities of the Performance Monitor to launch batch programs that work in conjunction with a product called WinBeep. This provided an effective method of generating pages. We also are using our nationwide PageNet service, which accepts Mail messages and routes them automatically to electronic paging devices. This has been a very cost-effective notification strategy that has only one major limitation. If you go off of the net or if your Mail server is down, you will never know it. This limitation highlights the need for redundancy in your notification strategy.
We have already begun to discuss the need for monitoring to ensure your site remains live, but now we take a slightly more structured look at the areas you should focus on to ensure that your site is up. Nothing is worse than clients or customers who can barely turn on a computer calling to let you know that your site is down. Specific focus areas include:
Internal Monitoring of Your Server Services
Finding a stable product to monitor your internal services may be the single most important step we took to ensure that our site has the highest possible amount of up time. The product from IPSwitch (http://www.ipswitch.com), called WhatsUP and illustrated in Figure D.6, provides a highly reliable method for, not only monitoring, but also for providing flexible notification services.
This illustrates a standard network grid view within IPSwitch's WhatsUP network monitoring product.
The services that can be monitored and the types of notifications available are partially illustrated in Figure D.7. They include Mail, pager, and beeper notifications, based on failures of any service monitored. We have been very pleased with the flexibility and stability of these low-cost methods of monitoring a site.
The illustration displays the administrative screens of WhatsUP network monitoring product.
In addition to monitoring with notifications, we have taken it one step further with our use of the Performance Monitor to actually restart services when they stop or when the thread count for the service drops below one. This type of active monitoring has proven invaluable, especially during the early Beta stages, as Active Server Pages evolved from a DBWeb product into Denali into ActiveX Server and then finally into IIS 3.0's Active Server Pages. The Performance Monitoring alert illustrated in Figure D.8 launches a batch file when the thread count of the InetInfo.exe or IIS drops below one.
Windows NT Server Thread Count In order for a program to be running, it has to have had at least one thread running. When a thread count drops from some number greater than 0 to 0, it is analogous to the program terminating.
This is a view of the Performance Monitoring settings to kick-off the batch file necessary to restart the Web server.
The batch file is not complicated; just be careful in the Performance Monitor setup. The complete content of the batch file took the form of:
net stop "world wide web publishing service" net stop "ftp publishing service" net start "world wide web publishing service" net start "ftp publishing service"
Batch File A Batch file in Windows NT Server, similar to Batch files in Dos, is just a simple text file with a .bat file extension which contains commands executable at the command prompt.
Internal Monitoring of the Outside World
The WhatsUp described previously provides the capability to ping high up-time sites on the Internet such as http://www.microsoft.com and the http://rs.internic.net.
Although the practice of systematically querying other sites on the Internet is discouraged due to its tendency to create unnecessary Internet traffic, Pinging other Internet sites can provide invaluable warnings to a Site Administrator. By pinging another Internet location, you can provide a high level of confidence that your site can be reached by other locations on the Internet as well. When another site does not respond to a ping or other query, it provides a good indication that your site may be having problems reaching the Internet.
An External Third-Party Monitoring of Your Key Services
Many companies, like RedAlert, now offer the service of pinging your server from an outside source periodically and generating a page, Mail message, or other type of notification in the event of several failures. These services are often fairly inexpensive and can help detect DNS or other problems that may not be obvious from inside your internal network.
Don't throw the panic button if you miss one check with your ping; this often results from a time-out due to ordinary traffic or load issues.
At this point, we have thoroughly reviewed the processes of building a membership community and of providing members with an interactive environment. We have also finished reviewing some important administrative issues involved in monitoring and securing your site, as well as providing an effective, efficient, and low-cost maintenance infrastructure.
As you move into the final appendix of the case study, your attention turns to the bottom line. The process of charging fees and effectively tracking and collecting those fees in a secure and efficient manner requires careful planning. From on-line authorizations to the implementation of an accounting system, creating a business based on Active Server technologies requires the ability to manage the money.
© 1997, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.
