Page #91 (Chapter 13 - Deploying WebClass Applications)

	Chapter 13 - Deploying WebClass Applications
	Visual Basic Developers Guide to ASP and IIS
	A. Russell Jones

Copyright 1999 SYBEX Inc.

---

	Dealing with Permissions Issues

	It's been my experience, unfortunately, that permissions issues arise for almost every IIS application deployment, with both WebClass and ASP applications. Some of these problems you can solve in advance; the rest you'll need to solve during deployment. There's little chance that everything will run perfectly. If you trap the errors properly, practice the installation, and document the settings from your test server, you may have only a few problems. If you haven't done those things, I hope you're a lucky person.

	Most permissions errors won't appear on the browser screen or in any log files generated by your application even if you trap them properly. The on-screen or in-log errors typically say something like Access denied, which is unhelpful. A better description of most permissions errors appears in the Event log. You need to check both the System log and the Application log if your application isn't running properly.

	You don't have to allow anonymous access to your Web server. You can set up IIS so that it requires users to sign on. Internet Explorer users sign on with NT Challenge/Response, which is transparent. Netscape users must manually enter their network sign-on and password (sent via plain text) to gain access to the application. If your server does not allow anonymous access, you can substitute your user's group or account names wherever you see IUSR_MachineName or IWAM_MachineName throughout this book. Most IIS application permissions errors occur when the IUSR_MachineName or IWAM_MachineName account requests access or launch permission to a class, component, or file. In some cases, the system or subsystem writes these errors to the System or Application logs; in other cases, they don't. When your error-trapping and the system error-trapping don't provide enough information, you can use NT's auditing feature to help find the problem.

	You need to be an administrator to enable auditing for a computer. Document what you do—you'll want to turn it off later, and there's no easy way to turn off auditing without disabling all auditing. To enable auditing, start User Manager for Domains and click the Policies menu, then select the Audit entry. You'll see the System Audit Policy dialog, from which you can select the types of events you wish to audit. You can audit several types of events, but usually you need to audit only File and Object access to debug IIS applications (see Figure 13.3).

	Click the Audit These Events radio button, then check the File and Object Access Failure check box. Click OK to save the changes and close the dialog.

	Setting the system audit policy doesn't turn on auditing—it only enables auditing. After setting the audit policy for the server, you turn auditing on and off for individual directories and files by using Windows Explorer. Navigate to a file or directory, then right-click it and select Properties. Click the Security tab and then click the Auditing button. You will see the File Auditing dialog (see Figure 13.4).

	Windows NT audits events for specific sign-ons or groups. Add the IUSR_ MachineName and IWAM_MachineName accounts to the list by using the Add button, then click the features you want to audit. The entries in this list don't match the system audit policy list. If you're reasonably sure where the error occurs, audit Execute Failure. If the error occurs during file access, audit Read, Write, or Delete. If you're not sure where the error occurs, auditing successes can help as well, since a success entry can help you eliminate error candidates.

	Keep a careful list of the items you audit. When you solve the problem, be sure to turn off auditing. Don't just turn it off using the System Policy Editor—go back to the individual items and disable the auditing by using Windows Explorer. Auditing is a major performance drain because it requires a disk write for every audited action. If another administrator later turns on auditing for another reason, and you leave directory or file auditing turned on, your application may suffer.

	Despite all these warnings and error-trapping resources, your application may still have problems. Microsoft's MSDN site and the newsgroups can sometimes provide expert advice. The other books in this Sybex series of VB Developer's Guides also provide expert information on MTS/COM+, ASP, NT, and IIS:

	•		Visual Basic Developer's Guide to COM and COM+ by Wayne Freeze

	•		Visual Basic Developer's Guide to ADO by Mike Gunderloy

	•		Visual Basic Developer's Guide to Win32 API by Steve Brown

	Maybe Microsoft will provide more power and features in the next version. I can assure you that Windows 2000 will alleviate some of the installation problems you face today—but it will probably introduce others.