Page #90 (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.

---

	Configuring the Target Server

	In this section, I'll show you what you need to do in addition to creating an installation package. For all IIS applications, you have to change the server configuration somewhat. For the simplest applications, you only need to create a virtual directory; for others, you need to create accounts, assign permissions, create DSNs, and install packages into MTS.

	Capture the Server Configuration Settings

	As soon as you create and test the installation package, capture the current settings for IIS and for MTS from your test server. Screen captures work best, but you can write down all the settings as well. Be sure to capture them all.

	If you're using an installer other than the PDW, one that can create virtual Web directories and perform MTS installations, you'll need to know the settings to create your package. Otherwise, you or some other server administrator need to know them to configure the target server. There are too many settings to remember, and you won't remember them long-term, so write them down. Put the settings, graphics and all, in the .htm file that accompanies the application and keep a copy for yourself.

	Run the Installation

	To configure the server, you'll need to perform some of the following steps, but probably not all of them. Consider this list as a resource only, not as a procedure; I don't know what your applications require, what the server situation is, or whether you're delivering in-house or commercial applications. In general, unless you "own" the server, try to be polite—don't break existing applications just to get your application running.

	I've assumed that you're performing the installation, or at least that you are present during the installation. If not, you need to assemble all the documentation and deliver it to the person doing the installation. If you can't be present, have someone else practice the installation by using your documentation on the test server before delivering the application. Follow these steps for installation:

	1.		Consult with the server administrator before beginning your installation. If you plan to install any system DLLs, make sure the administrator knows the files and versions in advance. Such files usually require a reboot. Therefore, you must often schedule the installation in advance; administrators often must schedule installations that require a reboot during low usage hours. Remember that removing most upgrades is much harder than installing them. Many upgrades aren't perfectly compatible with previous versions. Most servers run multiple applications. You don't want to be responsible for breaking someone else's program.

	2.		Set up your virtual directory first, using the Internet Service Manager application. Set the directory and applications permissions to the same settings as those from the tested beta version. If you captured those settings as screen shots, this step will be straightforward.

	3.		Run your installation package to install the files.

	4.		Create any other required directories—for example, log directories—and set the necessary directory and/or file permissions.

	5.		Edit the global.asa or your external reference file and change the entries so they match the requirements of the server. Such entries include DSNs, file paths, global variables, company names, etc.

	6.		If your application uses a database, make sure the database has been properly set up. In some cases, that may be as simple as using a Wizard to move the database to a production database server. In others, it's an involved process fully as complex as setting up and creating your IIS application. Database setup is beyond the scope of this book. Just be aware that the database needs to be online and ready, with appropriate permissions set, by this stage of deployment.

	7.		Check the database connection(s), sign-on(s), and password(s). Many IIS installations break down at this stage because the IUSR_MachineName or IWAM_MachineName sign-ons don't have permission to access the database server. Test several representative procedures, including procedures with updates, inserts, and deletes to ensure that your application has sufficient permissions. I usually use ASP files to do these kinds of checks because you can alter them quickly based on the immediate needs, conditions, and problems involved. The test ASP files run inside your virtual directory, but more importantly, they run with exactly the same permissions as your application, which can help debug problems.

	8.		Set up the appropriate packages and import components into MTS. You can do this step manually if you prefer. MTS also provides an export facility that creates an MTS package (.pak) file. The .pak file stores all component names, IDs, and settings. MTS also exports the DLLs themselves. Keep the .pak file and the DLLs together. Don't substitute a later version of a DLL for the version exported by the .pak file or your installation may not work. To re-create the package on another system, right-click the Packages Installed item and select New Package to import the .pak file. Click the Install Pre-Built Packages button and browse to the .pak file for your package.

	9.		When you create an MTS .pak file, you have the option to include role names and include the NT UserIDs associated with those roles. If you're delivering internal applications, including that information can be useful, but you should not include it if you're delivering to another company or to a location that is not part of your NT network. Make sure that you set up any required roles and users. Bear in mind that you may need to re-create these roles exactly as they appeared on the test server if any program code checks a user's role assignment.

	10.		Check the DCOM default access and launch permissions. Make sure they include the IUSR_MachineName and IWAM_MachineName accounts if you're delivering an application that uses anonymous access. See Chapter 12, "IIS Applications and Microsoft Transaction Server," for directions on setting permissions for a specific object. Setting the default access and launch permissions is similar; just click the Default Security tab first. You can find detailed directions for changing DCOM permissions in Chapter 12 as well.

	11.		If you call remote objects, you'll need to repeat the permissions-setting checks on the remote machine also. You may need to set up a trust relationship between your server and the remote computer and add the IUSR_MachineName and IWAM_MachineName accounts to the remote computer's user account list. Alternately (and this is preferable), you can switch the Web server's anonymous account to a network account with sufficient permissions to run the application on both computers.