The Site Manager has probably changed more than any other component of CMS. Originally called the Desktop Client, it was later renamed the Site Builder. At one point, the Site Manager was the only business user interface to the CMS application. Before the PAPI, the Authoring Connector, the Web Author, or the Server Configuration Application, the Site Manager was being used by CMS customers. At that point, almost all authoring and administration was done using the Site Manager.
In CMS 2002, authoring features were removed from the Site Manager. The intent was that the Web Author (and Web Author .NET) would handle authoring, and the new Site Manager would be used purely as an administrative interface. CMS administrators and channel managers can use the Site Manger for site maintenance tasks. These tasks include administering user roles and rights, and working with CMS containers.
The Site Manager exposes four types of virtual containers: channels, resource galleries, template galleries, and user roles. Originally there were five types of containers. Pages were stored in containers called folders. At this time, a distinction was made between a "page" and a "posting." Pages contained content, and postings determined the location and schedule for publication. However, authors found this separation to be confusing, and eventually it was decided that the folders container would be hidden. Since this change, "page" and "posting" are used interchangeably.
It is interesting to point out that, under the covers, the folders and pages still exist. The server layer was not altered a great deal when this level of abstraction was removed.
These are the CMS 2002 container types:
Note that these containers have no physical representation; they are an abstraction created by the CMS server.
The properties of the Site Manager shortcut show that the application is called NRClient.exe. This is short for NCompass Resolution Client. The shortcut also shows the path to the ASP interface for the Site Manager (http://localhost/NR/System/ClientUI/login.asp). This is the login page that is shown when the Site Manager is launched.
It is possible that the Site Manager will be phased out in the next release of CMS. There are various reasons for this change. If the Site Manager features were available elsewhere, they could be easier to maintain, they could be updated for new features of CMS, and they could be built with remote interfaces.
The Site Manager has a remote interface, but this ability is provided through a custom proxy. Since there are better ways to provide remote interfaces, the custom proxy will most likely be removed. Using port 80, the Site Manager client sends and receives XML messages. The proxy was originally written in Java. However, for the CMS Service Pack 1 release, the proxy has been written using the J# managed language.
The Site Deployment feature is also partially exposed through the Site Manager. In addition to the Site Manager, it is possible to access Site Deployment through its own API. However, the only graphical user interface for Site Deployment is within the Site Manager client.
Server Configuration Application
The Server Configuration Application exposes a Web interface for managing CMS sites. The application is written in ASP and is built on top of the CMS server's private Server Configuration API (SCAPI).
The SCA is used to write CMS settings to the system registry, assign the CMS system account file system Access Control Lists (ACLs), configure settings within the CMS database, and create the CMS structure within the IIS metabase. Some of the properties set by the SCA are local to the particular server; other settings are global across a CMS server farm. In the SCA interface, the local settings are distinguished by a small server icon. This allows a CMS administrator to easily see whether the setting will affect one machine or the entire server farm.
An example of a default install location for the SCA is http://localhost:9291/NRConfig/SCAConfigMain.asp. On Windows Server, the default install location is in the administration Web site. However, XP only supports one Web site, so the default install location is the less secure default Web site.
The SCAPI interface is installed via the ServerConfigurationAPI.dll file. The SCA and the Site Manager are the only remote administration interfaces to the CMS server. They both function over HTTP, and they handle almost all of the configuration and maintenance of the CMS server.
Database Configuration Application
The Database Configuration Application is used to manage the connection between the CMS server and the Microsoft SQL Server 2000 database. The DCA is triggered automatically during the CMS server install, but it can also be run manually at any point. A CMS administrator would use the DCA to change the CMS database that the server is using. Once CMS is installed, it is unusual for an administrator to run the DCA. It is more common for CMS developers to use the DCA to change from one development database to another.
The DCA application is installed as the file NRDCApplication.exe. The application uses the private SCAPI interface to perform many of the same tasks as the SCA. The DCA also triggers the code necessary for migrating one version of CMS to the next version.
The CMS Site Deployment feature has evolved considerably over the last few releases. From its creation, Site Deployment used XML packages to move CMS objects from one server to another. Site Deployment Object (SDO) packages can contain various CMS objects. For example, SDO files (which were previously referred to as Resolution Object Packages or ROP files) can be used to move CMS template objects, pages, or CMS resources.
SDO files use the Windows Cabinet compression format. By changing the .sdo extension to .cab, you can open the package and view the contents. Inside the package are XML files (that describe the SDO file) and various other file types that contain the CMS data.
Previously, the Site Deployment feature was only exposed via the Site Manager. However, Site Deployment has recently been enhanced to use a component called the Site Deployment API (SDAPI). The SDAPI allows CMS developers much more flexibility than was previously possible. Using the SDAPI, a developer can write a script that will trigger Site Deployment events.
Site Deployment can also be used as part of a backup or versioning strategy. Regular SDO exports can be backed up and used to store versions of the CMS site.