How Site Packager Works
In addition to site resources, applications, and the Internet Information Services (IIS) settings that are required to re-create the Web server configurations, Site Packager also includes the property values from the Administration database. For example, when you package the Profiles resource, all the current property values are also packaged. When you unpack the Profiles resource, the property values are unpacked into the Administration database.
The package includes global resource pointers, but not the global resources themselves. The package recognizes the connection strings that are in the application, but does not contain the actual data in the connection string.
Note
Connection strings that contain a computer name are not packaged.
During the application packaging process, Site Packager searches the IIS metabase on your local computer and finds the physical directory that is the root for that application. It then starts at that root directory and packages all the subdirectories in the following section into a new file that has a .pup file name extension. Site Packager preserves certain settings in IIS, such as authorizations and access permissions.
Csapp.ini File
Server Site Packager generates the Csapp.ini file during the unpacking process. After the unpacking process is complete, do not delete Csapp.ini. Both AuthManager and AuthFilter require this file, and it must be located in the site root folder.
The following table lists the properties that are contained in the Csapp.ini file and their descriptions.
Property |
Description |
|---|---|
Path |
The physical path of the root of the application. |
SiteName |
The name of the site as it appears in the Administration database. |
AddressKeyName |
The name of the application in the Administration database under which all information for the IIS application is put. |
RelativeURL |
The name of the IIS virtual directory for the application relative to the default Web site. For example, if the application was installed at the root of the IIS Web site, it is relative to the base root of a given IIS Web site. |
AbsoluteURL |
The address of the application. This also includes the computer name. |
PackagePath |
The package from which the application was extracted. |
The only property in this file that should be changed is the RelativeURL property. If you manually move an application to a different IIS path, the RelativeURL property must be modified to point to the accurate relative virtual directory under the IIS Web site. If the application is moved to the root of a Web site, it must contain a slash (/), for example, RelativeURL=/. The RelativeURL exists so that the CS Authentication service can determine from where it is operating. Commerce Server 2009 recreates the RelativeURL property every time that you unpack a package.
Note
To help secure the Csappi.ini file, clear the selections for read, write, and script source access to it in IIS. If you use NTFS File System permissions to help secure this file, you must grant read access to all user accounts that access the site, such as the IUSR_<computername> account. Also, after you unpack a site, do not delete Csapp.ini; both AuthManager and AuthFilter require this file, and it must be located in the site root folder. AuthManager retrieves SiteName and AddressKeyName from Csapp.ini.
IIS Virtual Directories
If you have virtual directories located in the application, the virtual directory object and the folders and files in the path it points to will not be packaged. If you want to package these folders and files, copy them to a folder in the physical path of the application before packaging them.
NTFS Permissions
NTFS permissions and access control lists on folders and files are not packaged. You can use the unpack.vbs script or postsite.vbs script to apply NTFS permissions automatically after unpacking.
Global Resources
Commerce Server 2009 installs the Direct Mailer global resource (if you selected it) when you use the Installation Wizard; all other global resources are installed by using Site Packager. Before you unpack a site that requires the global resource Direct Mailer, you must install these resources by using the Installation Wizard. For information about how to install a global resource, see How to Install and Uninstall Global Resources.
Database and Application Names
Site Packager derives database and application names from the package. An IIS application is created for each application in the package. The full path of each application is stored in the package.
Site Packager does not prompt you to specify the locations of your database files. Instead, it accepts the SQL Server default folders. Make sure that there is sufficient disk space to create the databases on the database servers.
Web Server Permissions
You can configure IIS Web server permissions to limit the access of anonymous users to your applications, and the viewing of source code over the Internet, even for users who have Windows permissions or access control entries.
It is important to understand the difference between Web server permissions and NTFS permissions. Unlike NTFS, Web server permissions apply to all users who are accessing your Web sites. NTFS permissions apply only to a specific user or group of users who have a valid Windows account. NTFS permissions control access to physical directories on your server, whereas Web permissions control access to virtual directories on your Web site.
When you package a site, the Web server permissions as set in the source site will be persisted. For example, if you set the Execute Permissions setting to Scripts and Executables in the root folder of the application on the source computer, the virtual root folder on the destination computer will have the same setting.
For example, the following table describes how the IIS permissions are set in the packages provided by Microsoft.
Folder |
Permissions |
|---|---|
Root |
Set Execute permission to Scripts and Executables. |
Pipeline, Include, Template |
Deny permission to read, write, and execute. |
Note
Site Packager does not preserve Windows access control lists (ACL), which contain NTFS permissions. ACLs describe the groups and individuals who have access to specific objects in Microsoft Windows Server. These objects include Active Directory directory service objects, local NTFS files and folders, the registry, and printers.
Name and Size Restrictions
This section lists the name and size restrictions for Site Packager.
Site names
To avoid unpacking errors, site names cannot contain the following special characters:
/, ?, &, \, <, >, :, |, #, @, %, and '
Do not specify a site name of more than 127 single-byte or double-byte characters.
Do not name your site "Commerce." This is a reserved OLAP database name. Naming your site "Commerce" could cause the overwriting of your OLAP database the next time that you unpack a site.
Virtual names
To avoid IIS errors, virtual directory names cannot contain the following special characters:
#, @, %, and '
Site Packager unpacks each application under the root directory of its corresponding IIS Web site. In the root directory, Site Packager creates a subfolder using the IIS virtual directory name of the application.
Application names
You cannot give your applications the following names:
Campaigns
Transactions
Product Catalog
Direct Mail
App Default Config
Biz Data Service
Transaction Config
Site Data Warehouse
Global Data Warehouse
Site CS Authentication
Marketing
Inventory
Application names cannot contain the '\' character.
If you want to unpack the application to the root of the Web site, you can use the '/' character or leave the IIS path field blank.