Command-Line Example: Setting Up a Staging Environment | Microsoft Application Center 2000 Resource Kit 2001

In this section we'll use the command-line tool to work with the clusters and servers that were described in Chapter 8, "Creating Clusters and Deploying Applications." You'll see how this tool, used in one-off situations, or in batch files, can assist you with various cluster administration tasks. Let's use this scenario for illustrating how the command-line tool works:

Create a staging cluster.
Create a new Application Center application.
Deploy the new application to a Web cluster.

Because we're going to use the environment from Chapter 8 for our scenario, we have to do some cleanup work on the existing environment. This consists of:

Disbanding the staging cluster.
Removing the Preflight Check application from the Web cluster.

Preparation

Let's start our preparation by disbanding the staging cluster, which as you may recall is named RKStager and consists of a single member, ACDW822AS.

Log on to the system as the administrator, and then run the following command to disband the cluster:
```
AC CLUSTER /DELETE
```
After pressing ENTER, you'll get the following prompt:

"Are you sure (Y/N)?"
Press Y, and then press ENTER.
NOTE
Because the existing staging cluster was a cluster of one, consisting of a single member, we don't have to worry about removing individual members first. By the same token, because NLB wasn't enabled, we don't have to worry about retaining IP addresses on the network adapter.

The next steps involve removing the Preflight Check application, ACPFApp, from the Web cluster (RKWebCluster).

After logging onto the controller (ACDW516AS) with administrative privileges, we obtained a list of the current applications by entering the following command at the command prompt:

AC APPLICATION /LIST

The results of this command are displayed next.

Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. D:\Documents and Settings\rktest>ac application /list AC Command Line Utility V1.0 (c) 2000 Microsoft Corporation Applications on ACDW516AS Name                                       ID ACPFApp                                    {586676A0-8A57-4B2B-B194-D3D304817D2A} Administration Web Site                    {030BABE5-DE57-4411-9DCE-4FDE6227225A} AllSites                                   {2E3D9AEB-26BD-4F33-8EC4-D6907F0F152D} Application Center 2000 Administrative S   {AA6209B3-A402-4967-9AFD-58F7E1F0DD33} Default Web Site                           {95354A7E-F7FD-4F3A-9A7A-F2A8DC4B107B}

To delete the Preflight Check application from the controller, enter
```
AC APPLICATION /DELETE /NAME:ACPFApp
```
NOTE
Remember, when you delete the application you are only deleting a named resource manifest that exists in the Application Center user interface. The installed COM+ components, source directories, and Web site virtual directories are not removed from the system.

As a final cleanup step, you could force synchronization on the Web cluster, but it's not really required because removing the application triggers synchronization. (In our case, we also removed the COM+ components and ACPF directory on the Web cluster controller to ensure that we had a completely clean target for the test.)

Create the Staging Cluster and Preflight Check Application

Now we'll create a cluster named RKStager on the server that was used as a stager. First, we'll log on to the server with an account that has administrative privileges.

To create the staging cluster, we'll use the following command:
```
AC CLUSTER /CREATE /NAME:RKSTAGER /TYPE:WEB /LOADBALANCING:NONE 
```
This command uses the appropriate parameters to create the staging cluster. In this case, because we're logged on the system with administrative privileges and the command-line defaults to localhost, we didn't have to provide either authentication information or the machine name to create the cluster.

Before creating the Preflight application on the stager, verify that the application components that were installed for the Chapter 8 scenarios exist on the server. The server should have:
- The ACPF source directory
- The two COM+ applications (AC_PF_VB, AC_PF_VC)
- The virtual directory (ACPFWeb) defined in the default Web site's root
  NOTE
  If any of the preceding elements are missing, you can install them by using the instructions provided in the "Automated setup" sidebar in Chapter 8.
Now we'll create the ACPFApp, and then identify its resources.
Create the application by entering the following command:
```
AC APPLICATION /CREATE /NAME:ACPFApp
```

Identify the application's virtual directory resource by entering the following command:

 AC APPLICATION /ADDRESOURCE /NAME:ACPFApp /RESOURCETYPE:IIS /RESOURCEPATH:/LM/W3SVC/1/root/ACPFWeb

Identify the application's source directory by entering the following command:

 AC APPLICATION /ADDRESOURCE /NAME:ACPFApp /RESOURCETYPE:FileSystem /RESOURCEPATH:C:\ACPF

Identify the two COM+ applications by entering the following commands:

 AC APPLICATION /ADDRESOURCE /NAME:ACPFApp /RESOURCETYPE:COMPlusApp /RESOURCEPATH:AC_PF_VB AC APPLICATION /ADDRESOURCE /NAME:ACPFApp /RESOURCETYPE:COMPlusApp /RESOURCEPATH:AC_PF_VC

TIP
Validate the preceding steps by using the following command:

AC APPLICATION /LISTRESOURCES /NAME:ACPFApp

Deploy the Preflight Check Application

At this stage we can deploy the ACPFApp application to the Web cluster. We used the following command:

 AC DEPLOY /START /DEPNAME:Preflight /SOURCE:ACDW822AS /SOURCEUSER:ASTTEST /SOURCEPASSWORD:* /TARGETS:ACDW516AS /TARGETUSER:ASTTEST /TARGETPASSWORD:*   /APPNAME:ACPFAPP /COMPLUS /WAIT

Notice that rather than providing a password for the /SOURCEPASSWORD and /TARGETPASSWORD parameters, we used a wildcard, the asterisk (*), to trigger a prompt for each password. If you were running batch jobs for deployments, you'd likely hard code the password in the batch job. You should be fully aware of the security risk that this approach causes.

Security alert
We observed that using the Application Center command-line tool in conjunction with the Windows 2000 Scheduler Service could expose user credentials in plain text. Specifically, if you invoke the Scheduler Service with the AT command and specify an Application Center command that requires administrative credentials, those credentials will be put in a .job file that resides on the local disk.
For example, note the following command line:
 C:\WINNT>at \\appctr1 4:00PM /interactive ac cluster /add /member:appctr2  /user:Administrator /password:password1  Added a new job with job ID = x 
The preceding command will create a task that, at 4:00 P.M., invokes the AC CLUSTER command to add another member to the cluster. Because the /USER and /PASSWORD parameters are a part of the command, they are also placed in a .job file on the disk (%windir%\Tasks). If you open up this .job file in a text editor, you will see:
 G 2ÐÊCÁ@I>(tm)...† [7JF ê <  s À €! a c c l u s t e r / a d d / m e m b e r : a p p c t r 2 / u s e r :  A d m i n i s t r a t o r / p a s s w o r d :p a s s w o r d 1 0 Ð 
As long as the .job file remains on the disk, the administrator's password is available in plain text.

Presumably, only trusted individuals would have access to %windir% for a cluster member, mitigating the risk from this issue. Nevertheless, best practices strongly discourage keeping any plain-text passwords on disk, especially administrative-level passwords.