This appendix covers some basic scenarios you might encounter when working with Microsoft Proxy Server. Keep in mind that it is impossible to write troubleshooting instructions for every conceivable system design. For the most part, Microsoft Proxy Server is a very smooth running service, requiring very little if any administrator intervention once the service is installed and properly configured.
For my tastes, I can usually find all the information I need by asking fellow network administrators for help on the Microsoft Proxy Server newsgroup. This is a private newsgroup supported only by Microsoft and can be found by linking to their newsgroup server at msnews.microsoft.com. The name of the Microsoft Proxy Server newsgroup is microsoft.public.proxy. Microsoft operates a private newsgroup server that does not share its newsgroup feed to the rest of the Internet on a global basis. However, the public is free to access their newsgroup server and you will find over 200 newsgroups dedicated to various Microsoft software topics.
Both the Web proxy and the WinSock Proxy will generate different kinds of errors. The Web Proxy is able to communicate more easily with the client through return HTTP documents when an error is encountered. When an error is encountered by the WinSock proxy, it is often impossible to determine the exact cause of the error because the WinSock Proxy has no direct way of communicating with the client.
The errors listed for the Web Proxy will be found displayed in a client's browser window unless otherwise noted. The errors listed for the WinSock Proxy can also be seen in the display area of client browsers if the browser is not set to perform CERN proxy communication and must rely on the WinSock Proxy for its Internet connection. Errors may also be logged through the Event Viewer on the NT server running Microsoft Proxy Server.
Not all possible error messages are listed in this chapter. I have chosen the ones that you are most likely to encounter. If you would like to view a complete list of error messages for Microsoft Proxy Server, you can do so through the online HTML documentation in Appendix I and J (of the online documentation).
Most error messages are given as a verbose string and a numeric error code. The error code will be listed at the end of the verbose string. Obviously, most network administrators prefer reading a verbose string rather than a cryptic error code.
Table A.1 is a short list of common error messages you might see as pop-up dialogs
displayed on the NT server running Microsoft Proxy Server. These are server-based
messages, not user-based messages.
| Table A.1. Common Error Messages displayed on NT server. | |
| Error Message | Definition |
| The server was unable to load ODBC32.DLL for SQL logging due to the following error: number. The data is the error code. | Most likely ODBC is not properly installed an the NT server running Microsoft Proxy Server. Reinstall a valid ODBC32 driver into the system or check to ensure that ODBC32.DLL is present in the c:\winnt\system32 directory. |
| The server was unable to log on the Windows NT account accountname due to the following error: number. The data is the error code. | This error occurs when a client is attempting to pass a username to Microsoft Proxy Server that is not present in the NT user database or is present, but the password is incorrect. This is a standard logon error message. Double check to make sure that the client has submitted the correct credentials. |
| The server was unable to open ODBC Data Source sourcename, Table: tablename, under User Name username. The ODBC Error is: number. The data is the error code. | This error occurs when one or both of the proxy servers is configured to log active information to a database, and Microsoft Proxy Server cannot find the correct DSN entry for the given database. Double check the ODBC Control Applet in the system Control Panel to make sure that the DSN name has been correctly configured. |
| W3PCache corrected a corrupted or old format URL cache by removing all or part of the cache's contents. | If a disk error occurs on your NT service, you may see this error message. It indicates that at least some portion of the cache has become corrupt. It is unlikely that an old format URL will be present because the Web Proxy qualifies all cache data as valid before it stores it in the cache. Scan the system hard disk for physical errors that holds the cache directory. |
| W3PCache failed to initialize the URL Cache on disk. | This message indicates that the Web Proxy cache has become extremely corrupt. Because the Web proxy stores cache items in a coded format, corruption of the reference file may result in the entire contents of the cache being wasted. Delete the cache directory or attempt to reset the cache defaults from within the Web Proxy properties. The Web Proxy server will not start when the cache is corrupt. You will need to restart the NT server after correcting the problem, or manually start the Web Proxy server on its own. |
| W3PCache initialization failed due to incorrect configuration. Please use the administration utility or manually edit the registry to correct the error and restart the service. | It's unlikely that the NT registry will become corrupt (NT protects the registry pretty darned well). If this error occurs, examine the registry settings involved with Microsoft Proxy Server and see if they look OK. It's often difficult to tell correct registry settings from bad ones. Refer to the Registry Entries section later in this chapter for details on registry entries that might help. |
Table A.2 is a list of error messages the user might see when attempting to connect
to the Web proxy server. These messages will be shown in the display area of the
browser the user is using.
| Table A.2. Error messages when connecting to the proxy server. | |
| Error Message | Definition |
| A connection with the server could not be established. |
If clients are receiving this message, it means that the proxy server could not be contacted. Check to see if the Web Proxy service is running and/or if the workstation can see any other server resource or service. If no other server service can be seen, check the actual network cabling or setup. |
| Access is denied | This message is by far one of the most common error messages. This message indicates that the client is requesting access to a site or protocol which he does not have access to (as defined in the permissions list of the Web Proxy). Alter the permissions list or explain the security restricts to the user. This is also referred to as HTTP error 5. |
| The access code is invalid | This error usually means that there is an error in the LAT file. Copy the server version of the LAT down to the workstation having trouble, and see if that takes care of the problem. Try using another browser and see if the same error occurs. If it does not, reinstall the first browser that was having trouble. If the error does occur, check to make sure the network connection between the workstation and server is stable. |
| The connection with the server was reset. | This error means that the client lost connection with the proxy server and then regained the connection. The server may have rebooted or the service was shut down and restarted. |
| The connection with the server was terminated abnormally. | This error means the clients connection with the proxy server has died and has not been regained. This does not mean that the connection with the outside Internet host has been terminated. Check to see if there is an operational problem with the NT server or the Web Proxy server. |
| The login request was denied. | This error means that a client workstation was trying to present logon credentials to the Web Proxy and the credentials were not accepted. This will only occur when authentication is required. Check the NT user account to make sure the workstation is presenting the correct information. Check to make sure the account is not disabled. |
| The operation timed out. | The most common user error encountered. It means the target Internet site did not respond to the Web Proxy server's access request. The target name was resolved to an IP, but the IP did not initially respond, or has stopped responding. This error could mean that the Web Proxy's connection to the Internet has been suddenly disconnected after an initial contact to the target site has been made. This error will not be received if the connection to the Internet is down before initial contact because the target name will not have yet been resolved into an IP address. Check the Web Proxy server's connection to the Internet or try contacting the site directly from the NT server running Microsoft Proxy Server. It is unlikely that there is a problem with the Web Proxy server. |
| The server name or resolved. | This error means that the client is referencing Web address could not be Proxy server by a name that cannot be found in the name resolution server's database. If you want clients to reference the Web Proxy server by a name, there must exist some form of name resolution on the network (see Chapter 9, "Concepts and Realities of Name Resolution with Proxy Server"). If name resolution services are available on the network, check to see if the workstation's TCP/IP settings are correct. |
| The URL is invalid. | The URL entered by the client is not formatted correctly. Resubmit the request in the correct manner. |
By far, the previously listed client errors will be the ones most commonly received by clients. Most of the time, errors will be related to a down Internet connection. Keep in mind that ISP's lose their Internet connections too. Just because your NT server is connected to the ISP does not mean you still have a valid connection to the rest of the Internet. If workstations cannot connect to target sites, yet the NT server is connected to an ISP, check with the ISP to inquire about their situation.
The following is a list of server-based WinSock Proxy error messages. These messages
will be displayed as pop-up dialogs on the server itself, or can be found through
the Event Viewer. These are not user-based messages.
| Error Messages |
Definition |
| Incorrect network configuration. None of server's addresses is internal. | This error means that the LAT file is not constructed properly. The WinSock Proxy cannot determine which addresses are local and which are remote. Reconstruct the LAT manually or by letting the WinSock Proxy (of Web Proxy) do it automatically. This is done via the Edit LAT Table button on the General tab of either proxy property sheets. |
| User username at host hostname has timed-out after number seconds of inactivity. | This error means that the client did not respond to the WinSock Proxy within the time out period defined through the RAS connection settings. RAS connections can have inactivity periods defined for them on the NT side, If clients do not keep the connection active for the required period, RAS will close the Internet connection. To fix this error, extend or disable the time out value for the RAS connection to the Internet. |
| WinSock Proxy Server failed to determine network addresses. | This error generally means that the workstation copy of the LAT does not match the server copy of the LAT. Makes sure both LAT files match. |
| WinSock Proxy Server failed to initialize. The data (if any) is the error. | This is one of the most irritating error messages. It means almost anything could be wrong. The WinSock server needs to be reinstalled to ensure that all necessary data and application files are present on the server. |
| WinSock Proxy Server failed to initialize because of badregistry. The data is the error. | The registry entries for the WinSock Proxy are incorrect. Have you been messing with them? Feel free to edit the registry but always export the branch you are working on to a saved file before making any changes. If you can't remember has to reset the registry settings for the WinSock Proxy to the correct values, you will need to reinstall the WinSock Proxy. |
| WinSock Proxy Server failed to initialize the network. The data is the error. | Something is wrong with the network on the NT server running the WinSock Proxy. Reset the server or try stopping all network services and restarting them through the Service Manager. Many times the NT server will come back to life after a bum service is restarted. Make sure you know what order to stop and restart services in though. |
| WinSock Proxy Server failed to load security DLL. | In order for the WinSock Proxy to be able to communicate with the NT security layer, the file security.dll must be present in the c:\winnt\system32 directory. Without this file, the WinSock Proxy cannot submit logon credentials to NT. Make sure this file is present. If not, reinstall the WinSock Proxy. |
Table A.3 shows some possible WinSock Proxy errors users may see. These error
messages may be displayed as pop-up dialog boxes generated by the WinSock Proxy client
software or the user's Internet client application(s) may report the numeric version
of a given error. For example, if a client cannot connect to a target Internet site,
it may simply report error 10060.
| Table A.3. Possible WinSock Proxy errors users might encounter. | |
| Error Message | Definition |
| Connection refused | This is a common error encountered by many Internet clients, typically FTP clients more than others. It usually means that the target site has no available connections, and the user will have to retry the connection later. |
| Connection timed out | This error means that there is a DNS entry for the site name the user is trying to connect to, but it is not responding the access request. The target site could be down, or the Internet connection between your network and the target site is severed. This is error 10060 in standard Internet parlance. It is unlikely the error is with the WinSock Proxy. Wait and try the connection in a little while. |
| Current version is not supported | This is a WinSock Proxy client software generated error, and it means that the workstation Internet client application has made a WinSock call that does not fall in the 1.1 WinSock standards. Find a client application that is WinSock 1.1 compliant if you want to use the current version of Microsoft Proxy Server. |
| Host was not found | This error means that a workstation client has submitted a DNS request that could not be resolved by any known DNS servers. Check the address and try again. |
| Permission denied | This error indicates that the workstation client does not have permission to access the requested protocol. Check the WinSock Proxy permissions list to ensure that the affected user has permission to use the protocol desired. |
| System is not ready | This error means that the workstation client has attempted to contact the WinSock Proxy during startup or shutdown. If the NT server running Microsoft Proxy Server was just restarted, retry the operation in a few minutes. This error will not be reported |
Since the WinSock Proxy client software runs as a service on workstations, it can also report errors related to normal network operation. If things seem flakey between the workstation and the WinSock Proxy, check to see if the workstation's network settings are correct.
Located in the c:\mspclnt directory created by the WinSock Proxy client software installation routine is a small program for testing the WinSock Proxy connection between the workstation and the WinSock Proxy server. This application is chkwsp32.exe. Run this application through a DOS shell, not by using the Run command on the start menu. You will need to see the results it displays.
Run chkwsp32.exe with the -f parameter to see a detailed report about the status of the WinSock Client software and the server status. The following is an example of the results of using the chkwsp32.exe application:
******************************************************************
**** Winsock Proxy Diagnostic Information ****
******************************************************************
WAIT...
CONFIGURATION:
Winsock Proxy Service - Configuration Location: C:\mspclnt\
Proxy Name (IP Addr):
Addr1: 220.200.200.1 ( pandyloc.com )
Proxy IPX Addr:
Addr1: 02020202-00400526bfe8
IP: Installed
IPX: Installed
WAIT...
16-bit RWS CLIENT:
Winsock Name: C:\WINDOWS\winsock.dll
Version: 1.0.193.3
Description: Microsoft Remote Windows Socket 16-Bit DLL
32-bit WSP CLIENT:
Winsock Name: C:\WINDOWS\SYSTEM\wsock32.dll
Version: 1.0.193.3
Description: Microsoft Remote Windows Socket 32-Bit DLL
Version Type: FREE
Client version of control protocol: 9
WSP SERVER:
Testing against server: 220.200.200.1 ( pandyloc.com )
Version: 1.0.193.3
Version Type: FREE
Server version of control protocol: 9
Windows version: 4.0
Windows build number: 1381
-------------------------------------------
Client control protocol version MATCHES the server control protocol
As you can see, the chkwsp32.exe utility displays quite a bit of information about the current WinSock Client version, the WinSock Proxy Server version, and the status of the current connection. Keep in mind that the WinSock Proxy client software must match the WinSock Proxy server version running on the NT machine. If you upgrade Microsoft Proxy Server, all network workstations using the WinSock Proxy client software will need to be updated accordingly.
The chkwsp32.exe utility will tell you if the WinSock Proxy server is able to be contacted and/or if the WinSock Proxy client files are installed correctly.
A little bit of personal advice here. I have found that changing almost any Network settings on workstations when the WinSock client is installed will make it so the WinSock Proxy server cannot be contacted, even if every configuration setting is correct. I don't know what to attribute this to. After altering Network settings for such things as protocols, and network clients, the WinSock Proxy client software just seems to die. I have been unable to get it to come back from the grave without doing a full reinstallation of Windows 95. My advice to you, if you have to alter workstation network settings, is to first uninstall the WinSock Proxy client software, make the necessary network changes, and then reinstall the WinSock Proxy client software. I have messed up three of my home machines in testing. I might be the only one who has had this problem, but I felt obligated to mention it here.
As with any piece of software, installation errors can occur. Most errors are minor, but some will prevent you from installing Microsoft Proxy Server and the WinSock Proxy client software. The following sections detail some of the errors you might encounter.
One of the most common errors you may encounter when installing Microsoft Proxy Server is the presence of two or more of the same DLL files in the \WINNT and \WINNT\SYSTEM directories, or along the system search path. This will affect both Windows NT and Windows 95 client workstations. If the system finds a DLL in more than one place in the system, you will experience buggy performance and possible corruption of data. Many TCP/IP applications these days want to do things their own way. Applications such as The America Online client for Windows 95 and the CompuServe client for Windows 95 might decide to add their own directories to the search path and add their own winsock.dll and wsock32.dll files into the Windows system area. This could cause more problems than I can count. You should have a clear understanding of what any Internet application will install before you actually begin installing. Yes, this may mean a little RTFM action, but it'll save you some headaches down the road.
Another common problem encountered when installing Microsoft Proxy Server is the need of having Administrator privileges on the NT server you want to install the software on. In order to correctly install Microsoft Proxy Server you must be logged on with a user account that has Administrator Privileges.
Locked file is another common problem. Sometimes it is impossible to install the server software because another application has locked open the system files Microsoft Proxy Server needs to overwrite. When installing the server software, make sure all extraneous software is shut down. Default Windows NT service applications should not cause any files to be locked open.
If you have an NT 4.0 server installation that came right out of the box, you may need to contact Microsoft (via their Web sitewww.microsoft.com) to get the latest service pack for NT 4.0. Almost immediately after NT 4.0 was released, a service pack was released that is required before Microsoft Proxy Server will install. This service pack fixes several bugs directly related to Microsoft Proxy Server. Microsoft Proxy Server's installation routine will check to ensure the service pack has been applied and will not continue unless it has been.
Client workstations will normally install the WinSock Proxy client software by connecting to the shared resource name MSPCLNT on the server running Microsoft Proxy Server. This shared resource is created and shared by default and should be used for all client installations.
Personally, I have had lot of problems getting the WinSock Proxy client setup to run correctly over the network. I have encountered errors related to the setup routine being unable to open the necessary files. I have had to go so far as to copy the entire contents of the MSPCLNT share and all sub-directories down to a temp directory on the local workstation and running the WinSock Proxy client setup from that temp directory. This will not cause any setup problems with mis-pointed file locations or anything of that nature.
If you find you are having similar problems, your only alternative may be to copy the setup files to the local workstations and run the setup routing from there. In theory, you should be able to run the WinSock Proxy client setup routine directly from the Network Neighborhood without even having to map a drive letter to the shared resource. If the in theory approach doesn't work for you, try mapping a drive letter to the resource, and then running the setup routine from the mapped drive. If that still fails, your only alternative may be to copy down to the local workstation.
As already mentioned, making changes to workstation network settings while the WinSock Proxy client software is installed may render the WinSock Proxy client unusable. If you find your workstations are suffering from this apparent bug, follow the uninstall routine for the WinSock Proxy client, reboot, and then make any necessary network setting adjustments.
If you have set the WinSock Proxy client setup routine to automatically set workstations for Web Proxy interface, you should already have Internet Explorer 3.0 or higher installed on all target workstations. Remember that the Internet Control Applet is not present in the Windows 95 Control Panel until Internet Explorer 3.0 or higher is installed. In order to reduce the amount of setup work you may have to do to workstations later on, it is best to have the Internet Control Applet present in Windows 95 for the WinSock Proxy client setup routine to adjust. The WinSock Proxy client setup routine will also make automatic proxy changes to stand alone clients like Netscape (all versions) and Internet Explorer 1.x and 2.x.
If the NT server running Microsoft Proxy Server has a space in its name like mine does (Controller 4.0), you might find that the WinSock Proxy client installation routine does not correctly set up Web Proxy clients if you have indicated clients should reference the Web Proxy server by name, rather than IP address. Clients may only reference the first or last part of the server name. To try and remedy this, edit the MSPCLNT.INI file in the \MSP\CLIENTS directory on the NT server, and enclose any server name references in double quotes (as in Controller 4.0 or \\Controller 4.0\MSPCLNT). This should take care of this problem. If it does not, create a static mapping in the WINS server database (for examplePROXY) to reference Microsoft Proxy Server Web Proxy by and then edit the MSPCLNT.INI file on the server to reference this static mapping name (edit only the WWW-Proxy= line to reference the Web Proxy server name; do not alter any NetBios names (names starting with \\)). This is often the best approach because you can segregate the name used to reference Microsoft Proxy Server Web Proxy completely from any specific server name. This WINS database entry can then be easily adjusted, should the location on Microsoft Proxy Server Web Proxy change.
When the WinSock Proxy client software is installed, you should understand how DNS is affected. Any TCP/IP traffic that originates from a workstation will automatically be routed to the WinSock Proxy server should it be destined for the outside world. This generally means that DNS resolution will take place on the NT server running the WinSock Proxy. I have seen some funky workstation behavior concerning DNS name resolution when the WinSock Proxy client software is installed. In Chapter 9, I talk about how to use DNS and WINS together to resolve all possible network names. I also talk about how to create a zone in the DNS server (for example pandy.com) and then use DNS to reference the WINS server for specific name resolutions (for example, ftp.pandy.com).
This is done by simply creating a static entry in the WINS database for the host name of FTP. Normally, when DNS receives a request for a name such as ftp.pandy.com, if it does not find the host FTP listed in the zone for pandy.com it will pass the host name (FTP) along to the WINS server that should be referenced in the pandy.com zone. WINS would just receive the resolution request for FTP, and it would respond to the DNS server with the IP. Then the DNS server would respond to the client with the IP address it was given by the WINS server.
This doesn't always seem to work. It appears that sometimes the DNS server does not pass host resolution requests to the WINS server. I can't tell if this is a workstation-related issue or a server-related issue. In either case, you may need to set up DNS host entries in the zone for your network for most resolution requests. This is a pain (IMHO) because the WINS server is a much more powerful name resolution service in a Windows-based environment.
LAT file errors can cause parts of the Internet to become inaccessible. All addresses found in the LAT file will be referenced as though they were part of the local network. This means that should your network IP subnet not be one of the reserved subnets set aside by the InterNic, you may be unable to contact the sites on the Internet that validly have IP addresses used by your own private network. To ensure this does not happen, read chapter 4 carefully.
It's unlikely you will have to edit registry settings for Microsoft Proxy Server yourself, but just in case, I'll cover some of the important ones.
On Windows NT there are two registry editing utilities. One looks like the Windows 95 registry editor, and the other is native to Windows NT. Figure A.1 shows the Windows 95 version of the registry editor, and Figure A.2 shows the Windows NT native version of the registry editor.
The Windows 95 version of the registry editor is started by running REGEDIT.EXE and the native Windows NT version is started by running REGEDT32.EXE. In my opinion, the Windows 95 registry editor is the easier one to use, but the native Windows NT version has all of the features necessary to change some advanced registry keys. This next section will covers using only the native Windows NT version of the registry editor.
Most of the Microsoft Proxy Server registry settings can be found off of the following registry branches:
WinSock Proxy Settings
HKEY_LOCAL_MACHINE SYSTEM \CurrentControlSet \Services \WSPsrv
Web Proxy Settings
HKEY_LOCAL_MACHINE SYSTEM \CurrentControlSet \Services \W3Proxy
Web Proxy Cache Settings
HKEY_LOCAL_MACHINE SYSTEM \CurrentControlSet \Services \W3PCache
WWW Service Settings
HKEY_LOCAL_MACHINE SYSTEM \CurrentControlSet \Services \W3Svc
When making changes to the registry through the registry editor, keep in mind that the changes you make might not take affect immediately. You should always stop and restart any service after making changes to its registry settings. Changes made through the Internet Server Manager however will be immediately effective.
And, as always, edit the registry at your own risk. Making changes to the wrong settings could make it impossible to start Windows NT and only a reinstallation will remedy the situation. However, none of the setting dealing with Microsoft Proxy Server should affect how NT itself starts up. The wrong settings may cause the service to not start, but not NT itself.
Keep in mind also that most of the key values are set by hexadecimal notation, which is base 16 notation. If you are not familiar with hex notation, it's a pretty simple thing to grasp. For example, hexadecimal 20 equals 32 in standard notation (2 x 16 = 32). The hexadecimal value of 14 equals 20 in standard notation (16 + 4 = 20). And you didn't think all that fancy calculus you took in college would come in handy.
Most of the registry settings are simply the configuration settings you set on the property sheets of both the Web Proxy and the WinSock Proxy. Site filtering settings are common between both the Web Proxy and the WinSock Proxy. These settings are held in the registry branch:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Proxy\Parameters\DoFilter
Table A.4 shows a list of useful keys in this branch:
| Table A.4. Useful keys in the registry branch. | |
| Key | Definition |
| FilterType | 0 = No site filtering enabled 1 = General site deny policy set 2 = General site grant policy set |
| NumDenySites | Can be set to any number When set to a non zero value, Microsoft Proxy Server will deny access to the first x number of sites listed in the DenySites key (not created by default). Sites will be separated by a space. |
| NumGrantSites | Can be set to any number when set to a non zero value, Microsoft Proxy Server will grant access to the first x number of sites listed in the GrantSites key (not created by default). Sites will be separated by a space.) |
| DenySites | Can be set to any string value, for example, www.pandy.com ftp.xyz.com *.netscape.com The sites listed here will be excepted from the general site grant policy and access to them will be prohibited through Microsoft Proxy Server. |
| GrantSites | Can be set to any string value, for example, www.pandy.com ftp.xyz.com *.netscape.com The sites listed here will be excepted from the general site deny policy and access to them will be granted through Microsoft Proxy Server. |
A short list of important Web Proxy registry keys is shown in Table A.5. These
keys are found in the Parameters folder off of the main Web Proxy branch (see above).
| Table A.5. Important Web Proxy registry keys. | |
| Key | Definition |
| DnsCacheSize | Can be set to any hex number in the range of 12c-7530. The default is bb8. This refers to the cache size in bytes. This key sets how large the DNS cache size will be for Microsoft Proxy Server. When client access the outside Internet, Microsoft Proxy Server stores the most recently accessed IP addresses. Increasing this value on busy networks may speed up name resolution somewhat. |
| DnsTTLInSecs | Can be set to any hex number in the range of e10-8ca0. This refers to the Time to Live in seconds. The default is 5460 (24 hours). This sets the time to live value for DNS cache entries. When their time to live expires, cached DNS entries will be flushed. |
| MaxFtpThreadsFactor | Can be set to any hex number in the range of 8-24. The default is 8. This refers to the number of processor threads Microsoft Proxy Server will start for FTP sessions. Once the thread limit has been reached, Microsoft Proxy Server will begin sharing threads for FTP sessions. |
| RequestTimeoutSecs | Can be set to any hex in the range of 10-1000. This value is in seconds. The default is 3c. Determines what the time out factor is when Microsoft Proxy Server is attempting to contact an Internet site. |
Table A.6 shows a list of important registry key values that affect Web Proxy
caching. These keys are found in the Parameters folder of the Web proxy Cache primary
branch (see above).
| Table A.6. Important registry key values affecting Proxy caching. | |
| Key | Definition |
| CleanupFactor | Can be set to any hex number in the range of 0-64. The default is 19. This number represents the cleanup percentage. When a cache clean up is performed, this key determines what percentage of the cache is cleaned up. By default, only the oldest 25 percent of the cache is cleaned. |
| CleanupInterval | Can be set to any hex number in the range of 0-93a40. The default is 15180. This number represents number of seconds. This determines how often the cache is cleaned. By default, it is set to 86,400 seconds, or once every 24 hours. |
| CleanupTime | Can be set to any number in the range of 0-23. This number indicates the hour of the day. By default it is set to 0 (12 am). This key determines when cleanup occurs (by default at midnight). |
| Persistent | Can be set to 0 or 1. By default it is set to 1. Determines whether or not the cache is cleared when the Web proxy service is stopped. A 0 value indicates the cache will be completely cleared every time the Web Proxy Service stops (which will happen when NT shuts down to reboot). |
Some important registry keys which control how the WinSock Proxy server operates
are shown in Table A.7. They are found in the Parameters branch off of the main WinSock
Proxy Server branch.
| Table A.7. Registry keys controlling the operation of WinSock Proxy server. | |
| Key | Definition |
| Authentication | Can be set to 0 or 1. By default set to 1 (authentication enabled). If this key is set to 0, the WinSock Proxy will not demand NT Challenge/Response Authentication from workstations, which will in essence grant access to everyone. |
| TcpBufferSize | Can be set to any hex number 600 or higher. By default it is set to 800. This number refers to number of bytes. By default, this key defines the number of buffer bytes allocated to each TCP/IP connection. |
| UdpBufferSize | Can be set to any hex number in the range of 600-ffff. By default it is set to 1000. This number refers to number of bytes. This key controls what the largest UDP packet size is that will be passed through the WinSock Proxy server. UDP packets that exceed this size will not be passed from client to server and vice versa. |
| Obviously, there are many other keys involved with each element of Microsoft Proxy Server; however, these other keys are more easily set through the property sheets of both proxy servers. Remember to stop and start the proxy servers after making changes to their registry settings. | |
When trying to figure out a problem that seems to involve Microsoft Proxy Server, try to first determine if it is a general network problem or a problem that is specific only to clients trying to access Microsoft Proxy Server. For what it does, Microsoft Proxy Server is a very simplistic service.
If clients are having trouble connecting to Microsoft Proxy Server, check to see if the TCP/IP protocol is loaded correctly. Many times workstations are set to receive their IP setup from a DHCP server, but sometimes they can't contact the DHCP server on startup. If workstations have disabled the DHCP server error message, they may never know they do not have an IP address. To test to see if this is the case, try pinging the name localhost. If TCP/IP is loaded correctly, Windows 95 will respond to the local ping request. If TCP/IP to not loaded correctly, the ping command will display an error message.
If workstations are set to use DHCP for their startup IP configuration, but they are not getting it and you are certain their are no physical errors with the network or the DHCP server itself, try deleting the following folder out of the Windows 95 registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP
When Windows 95 workstation first contacts a DHCP server, they log its location for future reference. Sometimes Windows 95 seems to get confused about where the DHCP server can be found and no longer broadcasts a DHCP location request. This will prevent it from obtaining an IP address even after it has booted many times and successfully contacted a DHCP server. Deleting the folder mentioned will force Windows 95 to rebroadcast a DHCP location request on the next boot up. This folder will be recreated once a new (or possibly the same) DHCP server is located (or relocated as the case may be).
If you are using IPX as your exclusive network protocol, the Web proxy server will not be used at all. Only the WinSock Proxy client and server can communicate over an IPX connection. If workstations are having trouble contacting the WinSock Proxy over an IPX link, make sure that the frame type defined for IPX on both the NT server and workstation(s) match. Do not trust Windows 95 to automatically determine the frame type used by a network. I have found that this rarely works and you'll save yourself a lot of headaches by manually indicating which frame type to use.
PING can be used on workstations to attempt to ping a server on the Internet through the WinSock Proxy server. Only the first half of the ping command will work though. Ping should be able to get as far as resolving the host name to an IP address; however, the ping negotiation after that point takes place using ICMP, which is not supported through the WinSock Proxy. Ping can therefore be used to simply test to see if workstations are getting proper name resolution through the WinSock Proxy server.
If you are using RAS to make the Internet connection from your NT machine running Microsoft Proxy Server to an ISP, but the connection keeps timing out, you might need to find a utility that can run on the NT machine to simulate network activity through the RAS connection to the ISP. Most ISPs will disconnect after so many minutes of non-activity. There are several shareware programs, such as Ponger and Rascal, that are designed to help keep a connection to the Internet open. Search your favorite Internet file depository for such a utility if you would like to ensure that your Internet connection remains open as long as possible. Rascal (which can be found on www.windows95.com) is very nice because it will actually re-dial an ISP should the connection be broken.
Hopefully you won't have too many problems with Microsoft Proxy Server. It's a pretty stable package and should not cause you too much grief. Before installing, make sure your network is running properly and you have considered as many eventualities as possible. This will save you some work down the road. With more and more companies turning to proxy servers to control employee access to the Internet from the office, applications such as Microsoft Proxy Server will become more common. Hopefully this chapter gives you the mental tools necessary to track down most of the common problems you may encounter.