FREQUENTLY ASKED QUESTIONS
  1. I selected a document in the Submit New Request window, and clicked Modify. I got the Modify Document window as expected. Then, instead of clicking Save or Cancel, I clicked the browser's 'Back' button. When I went back into Submit New Request again and attempted to select the same document, I received the message that the document was currently being processed. However, it is not in any of the Approval Stages. What happened to the document?
      WebSite Director cannot detect that you used your browser's 'Back' button. And, since you had not saved the request, it has not been moved into a normal Approval Stage, but remains in a temporary "submissions-in-progress" stage. Go to the System Administration screen and click [Maintain Submissions] (to the left of the Submissions category). The Maintain Submissions screen lists documents that have been retrieved for processing but not yet assigned to a workflow stage. Select your document from the list and click [APPROVE REQUEST] to approve it into one of the workflow stages, or [DELETE REQUEST] to remove the request from the workflow process.
  2. I don't want to receive e-mail notifications when documents are published. I've gone to the Edit User Info screen and unchecked all of the notification checkboxes for my username. However, I'm still getting these messages. How do I stop them?
      The notification messages that you can select on your Edit User Information screen apply only to the WSD nightly notification messages sent when there are one or more documents in the selected stage that require processing. These notifications will not be sent unless you check the box for a specific stage.

      The "Author notification message" sent to document authors is controlled from the "Edit Stage" screen for each authoring stage defined for your installation. If a notification message has been defined for an authoring stage, each author will receive a personalized message whenever new work is approved into that stage. See the Setting Up Your WebSite Director Workflow tutorial for more information.

      The other notifications messages (document publication notice, and reminder notifications) are system-wides message controlled from the System Configuration screen. See the System Configuration Tutorial for more information on configuring those messages. Publication and reminder notices can not be turned off in the current release of WebSite Director. More control over the messages will be available in a future release of WebSite Director.

  3. I downloaded WebSite Director and the MiniSQL database from your download site onto my UNIX system. I installed the database software, and attempted to install WebSite Director using the instructions in your installation guide. However, the installation fails with the message: "Unable to connect to database."
      If you download the version of WSD built with the mSQL 2.x library and attempt to install it on a system running a mSQL 1.x database server (or vice versa), the installation will fail and display this or a similar message. This occurs because the interface between the mSQL library and the mSQL database server is not compatible between version 1.x and version 2.x of mSQL. The mSQL library used to build WSD was configured with the default mSQL server configuration settings. If you are installing WSD with a mSQL database server configured differently than the default, and do not specify database configuration information in the WSD install form, you will see this message.
  4. Our e-mail submission files are named 'wsdsavemail.00n' instead of 'requestxxxxxx'. Why?
      The files for incoming e-mail messages are converted from the wsdsavemail.xxx files into the request files when the e-mail message is parsed for attach files and embedded HTML documents. So it seems that something is not working properly in the decoding of the e-mail messages.

      There should be a file called "wsdsavemail.log" in the WSD installation directory. This log file should have a complete record of all incoming e-mail messages. If any errors occur while parsing those e-mail messages you should see an error entry in the log file. If you can find any error messages in that log file, send them to wsd-support@cyberteams.com so we can analyze and resolve these errors.

  5. Is it possible to capture additional document information in the submission page? We have several additional pieces of information that we need to capture with every article, including key words, lead line, by line, etc.
      The WSD "Document Info" screen provides the ability to capture much of this information. These include Keywords, Description, Author, Maintainer and Submitter. Note that Author, Maintainer and Submitter must be authorized WSD users with login capabilities. See the Submit Document Info Help Screen for more information about these fields. The current version of WebSite Director does not support adding new custom Document Info fields, but such a capability is planned for a future WebSite Director release.
  6. Will we receive the upgrades automatically or will we be expected to purchase them?
      Our policy on upgrades is the following:
      • "Point Upgrades" (version 1.1, .2, etc.) are free for the first year.
      • "Bug Fixes" are always free. We don't charge you to fix our mistakes.
      • After the first year there is a 15% (of original purchase price) "annual maintenance fee" for continuing customer support.
      We anticipate major functionality improvements to be released annually as "New Versions" (e.g. version 2.0). These will be offered to at a significant discount to existing customers who are under maintenance. That is, those customers who are in their first year or who are paying for annual maintenance. Upgrading to the new version will be at the customer's discretion.

      If we retire a version and no longer support it, we will upgrade customers who are under maintenance at no charge.

  7. What's the best way to clean-out the database and reset the document counter in WSD? We could just reinitialize the database in mSQL and reset the counter in WSD, but is this the best way to do it?
      Reinitializing the database is the best way to clean out the database, and if you re-initialize the database by re-installing WSD with the "Initialize Database" option set to Yes, it will reset the document counter automatically.

      If you re-initialize the database, you must delete any files in the WSD "Request" and "Version" directories. There is one file in each of those directories for each request or document record in the WSD database, respectively. If you reinitialize the database without deleting those files, you will end up with "orphaned" request and version history files in those directories.

      Re-initializing the database and clearing out the "Request" and "Version" directories will not affect published documents on the web site in any way.

  8. Can our content, QA, and programming teams use their own applications (Dreamweaver, CFstudio, etc.)?
      Yes. In that scenario, your team members using "Authoring Applications" (Dreamweaver, CFstudio, etc.) would upload/download content (via their browser) directly into and out of WSD.

      Your reviewers and approvers could still use our "Browser Edit" function to make minor content changes from within WSD. Users doing this must exercise care to not alter the HTML tags/code in the content pages.

        Note: WSD's "preview" and "view document" functions virtualize the working page into its proper location using the HTML <base href="http://www.... tag, so that links operate as if the displayed page is actually published to the public site at it's final destination.
  9. Does WSD have a version control system with check-in and check-out?
      Yes, all documents published by WebSite Director are maintained with full version history in a version control system that is independent of the published document on the live web site.

      When you "Submit a New Request" to modify an existing document, you are "checking out" the specified document (HTML, gif, zip, exe, etc) from the internal version control system. When you "publish" the document to the site, you are "checking in" that same document.

      If you have populated the web site externally to WSD and no previous version for a new request exists in the version control system, WSD uses the existing content to create an initial version of that document and begins version tracking with that submission.

      We offer a customizable utility program that will parse your site content and populate version control system before you begin manipulating your content using WSD. Because utilities like this provide access to proprietary information regarding WSD's design, we would require a signed Non-Disclosure Agreement (NDA) to be executed. Please contact CyberTeams Support at wsd-support@cyberteams.com for more information about this utility.

  10. Does WSD compare versions of a document and automatically display the differences?
      Not at the present time. That functionality is currently scheduled for a future release.
  11. Does WSD provide for different levels of permissions?
      Yes. Permissions are assigned on a user basis and specify which groups (teams) a user has membership in and which stages of the (workflow) approval process the user is authorized to access content and issue approvals for.
  12. Does WSD allow us to create permission sets?
      Not at the present time. We are currently working on a future re-design of several areas, including this one, for a future release. Your comments and suggestions will be greatly appreciated.
  13. Can workflow be tracked from one server to another (Design on NT, QA on Sun Solaris)?
      Not in the present release. We are participating in the WWW Distributed Authoring and Versioning (WebDAV) group which is defining a proposed standard addressing these issues. See: http://www.ietf.org/html.charters/webdav-charter.html.

      Any current implementation would be a customized solution, and probably not in the best interest of, nor of long-term benefit to, our customers. We believe a WebDAV standards-based solution will be more appropriate. We plan to be among the first to implement the WebDAV standards by integrating them into WSD. We are targeting Q4 of 1998 for a WebDAV implementation of WebSite Director.

  14. Do server load-balancing and clustering (e.g. Resonate) introduce any problems?
      Not as long as all content is retrieved from a single file system; e.g. a Network File System (NFS). While the content can be publicly served using load balancing, WSD operates from a specific server. As such, content "check out" and "publishing" should be segregated on a per-server basis with all content aggregated for a single site entity managed by WSD installed on one server.
  15. Can pages from a site or project be grouped as a "project unit" for traveling through the workflow?
      Not in the present release. We are also looking at this as part of the WebDAV implementation (see answer 13 above). Any other solution would be of a proprietary nature and therefore less desirable to both us and our clients. While this may cause inconvenience in the short term, we believe our customers have a higher long-term benefit because our WebDAV implementation will support an environment that promotes better and more open collaboration.
  16. Is there a built-in system for making QA checklists for each page and/or "project unit"?
      Not in the present release. Presently, checklists should be included with the original work request as "comments" that are updated as the document travels through the workflow process.

      We are currently investigating the feasibility of integrating one or more third-party products to provide that functionality. Interaction between "to-do lists" and content packaging is a strong requirement for us. We will make a final decision for a solution in this area once the WebDAV functional implementation plans have been finalized and design of that functionality is complete.

  17. Does WSD build a projects-to-be-checked list that can be used by our project managers and QA team members?
      No. In the existing environment we recommend that individuals use third-party products, extracting items like the "to-do list" (built as comments) into their favorite calendar programs. At the end of a project, the completed list can be pasted back into the comments before publishing content to the public site. Doing that preserves the history and any other ancillary associated materials for posterity in the version database.

      Project managers can use WSD's reporting facility to track outstanding requests for work-in progress and, like the individual team members, rely on products they are familiar with to keep local records of work in progress by other team members.

  18. Is there a built-in system for tracking comment lists, bug lists, and feature requests for each file/project?
      Not at the "Project" level. Comments for individual content components are maintained by WSD and archived with the content and other version-related information for published documents. Comment threads are kept with each content component during the workflow (approval) process and archived with that component for versioning.
  19. Is remote contribution/editing/QA possible? And remote administration?
      Yes to all of the above. Details as follows:
      1. Remote contribution: Two methods are available:
        1. Because WSD is browser-based, any authenticated user can use his/her browser to submit content from any location that can access the server on which WSD is installed.
        2. Additionally, you can set up an e-mail alias to receive content from users who do not have direct, authenticated, access to the server. This opens up the community of submitters to anyone who can send e-mail and eliminates the need to provide authenticated access (extra user licenses) to people who have no other workflow responsibilities past the submission stage. WSD will place e-mail submissions into the first workflow stage for examination and approval or rejection of the submitted materials.
      2. Editing: As with (a) above, editing can be accomplished from anywhere with access to WSD. WSD provides a "browser edit" function for simple editing using the browser. Users managing content with third-party products, can download content (leaving the WSD entry "locked" to prevent access by others) edit it, and then upload the modified document prior to releasing the document to the next workflow stage.
      3. QA: As with (a) and (b) above, this can be accomplished from any browser from any location that can access WSD.
      4. Remote administration: One of WSD's primary strengths is its ability to support user-authenticated remote administration from any location with access to WSD.
  20. Does WSD have an archiving feature for outdated content?
      WSD keeps all version information in its version control system forever. Independent utility programs can be written to extract and archive this information to some other file system.
  21. Will WSD integrate easily with existing advertising servers? With Cold Fusion? With Java? And ActiveX?
      WSD co-exists peacefully with all third-party products we are aware of. Because those servers typically come into play after publishing, we don't anticipate any problems.
  22. Approximately how long would you estimate it will take us to install and configure WSD on one server for thirty clients?
      Setup can take from 10 minutes after download to however long it takes to set up server permissions outside WSD and to configure your workflow stages. Typically we find it takes approximately 2 hours.
      • The largest time segment will be installing Groups and Stages after installing the WSD software.
      • The actual time it will take depends on the complexity of your workflow/approvals process.
  23. How much training time would be required for our content team, programmers, and system administrators?
      Assuming browser proficiency, approximately 1/2 day in a structured environment with up to an additional 1/2 day of supervised "practice time."
  24. If my web site is hosted by an Internet Service Provider, will my ISP have to install WebSite Director?
      The answer to this question depends on your ISP's policies. If your ISP allows customers to install custom CGI programs, then you can install WebSite Director (WSD) yourself. If you are sharing a server with another ISP customer, the ISP may want to evaluate the WSD software before you can use it.

      The ISP hosting one of the CyberTeams Quality Assurance testing sites falls into the latter category and did the installation and testing the first time we installed WSD to make sure our software would not cause any server runaways. Your ISP may also require this, but then may allow you to install your own upgrades later.

      If you are operating on a UNIX host, you also will need to install or gain access to a MiniSQL database. If your server is running Microsoft Windows NT, you will need access to an ODBC data source, or be able to install MiniSQL.

  25. How does WebSite Director work with pages and web sites published via MicroSoft's FrontpageŽ with the extensions installed since it is not wise to FTP a site with the FP extension installed?
      WebSite Director (WSD) was designed to co-exist on a web server with other systems that are used to maintain web content. This includes FrontPage and FTP. The trick in getting two different content management systems working together is getting the file permissions set properly. For instance, if WSD is set up to run as the user "nobody," and you need to update a file through FTP with your login account, you are going to have some problems. Similarly, if FrontPage expects files to have certain file permissions, and FTP sets those permissions to something else, FrontPage will have problems accessing the files.

      To solve these problems, all of our products support six different methods of managing file permissions. The method you use will depend on the options available on your web server and your login account, as well as how secure your files need to be. The complete list of options, and the benefits and disadvantages for each, can be found in our File Permissions tutorial page:

        http://www.cyberteams.com/newsletters/WSD_File_Permissions.html
      Also, FrontPage usually assumes that it has complete control over the content of the site, and that the files that it maintains on your local desktop machine are identical to the files on the web server. When more than one person maintains these files, each person keeps overwriting the other person's changes. Similarly, if you update a file on the web server via any mechanism outside of FrontPage (i.e., FTP, WSD, etc.), and then 'publish' your local FrontPage content to the web server, it will overwrite any changes you made on the web server.

      One solution to this is to always download the latest files from the web server into FrontPage before updating pages in FrontPage and then republish them to the web server. Another solution is to avoid using the FrontPage publishing features, and always upload content to the web server using WSD or FTP. You can still use FrontPage as an editor to create and update pages.

  26. I have a Layout template. Is it possible to perform a SELECT statement inside a QueryInsert (or Update,..). If yes, where are the results stored?

      Any valid SQL query can be included in the Query... database publishing commands, but WSD only checks the results of the query for the correct number of updates.  WSD is not able to process the results of a SELECT statement used in a Query... command in any fashion usable in other Query... commands.  Depending on the SQL database server you are using, you should be able to do the equivalent of an interim SELECT statement within the INSERT or UPDATE SQL queries.  For instance, most SQL servers (including MySQL) support an "INSERT ... SELECT" form of the INSERT query where you can create new records based on a SELECT query specified as part of the INSERT query itself.  For updates, the WHERE clause should support just about anything you can do in a SELECT.  And for more complicated query constructions, you could use some kind of temporary tables in the database, using INSERT ... SELECT queries or if you are using Oracle databases, some form of "SELECT ... INTO TABLE ..." query.

  27. Does the IUSR_MACHINENAME account need to have full access permissions on the webroot, the /winnt/temp, the /cyberteams directory?

      Since WebSite Director needs to be able to create files and directories in the Document Root directory, the assigned temporary directory (used for versioning), and the WSD installation directory, whatever NT user account WSD is running as does indeed need full access permissions to those directories. Unless otherwise configured, WSD will run as the NT user account used by IIS itself, which normally defaults to "IUSR_". There are two ways to change what NT user account WSD runs as:
        1) Specify a different NT user account (and associated password) in the "Proxy User" field (and proxy password fields) during a WSD installation. The proxy user can only be set up during installation (or upgrade), it can not be configured manually.
        2) Set up IIS to run WSD on a different virtual web site (but sharing the same Document Root as the regular web site) on either a different hostname or a different port on the same hostname. You can then configure that virtual web site to use a different NT user account for anonymous access (set in the Account used for anonymous access field in Directory Security).

  28. What about password management/synchronization between LDAP/WSD? Which will be used/ignored, if/when they are out of sync with one another?

      When LDAP authentication is used, WSD isn't involved with passwords in any way. The Change Password function is ignored (or disabled, as is the case with Domino servers, where we know that authentication is handled externally). All password maintenance is done using the LDAP administration tools. The only requirement is that LDAP usernames match WSD usernames so that WSD permissions take effect once the authentication is completed.

  29. Can WebSite Director users authenticate against an ldap server instead of the UNIX server on which WebSite Director is running?

      WebSite Director does not actually handle the initial authentication of user login information. That is handled by the web server's built-in authentication mechanism (or our add-on ISAPI filter in the case of IIS). WebSite Director manages the user authentication information for the web server through the its User Administration screens. WebSite Director can manage users and passwords in the following environments:
        1) .htpasswd files used in Apache and Netscape web servers
        2) .htpasswd files used by the WSD ISAPI authentication filter for IIS
        3) Netscape User Databases in versions 1.x and 2.x of the Netscape web server.
        4) O'Reilly WebSite Pro user databases.
      At the present time, WebSite Director does not support managing user and password information stored in LDAP servers, although that is planned for a future release. This does not prevent the use of WebSite Director in LDAP-based authentication environments, however. When an LDAP server is used for authentication, user information for authenticating login access needs to be updated independently of user information within the WSD system itself since WSD can not update the LDAP server directly. So to add a new user, for example, the appropriate username and password would be added to the LDAP server to allow login authentication, and the same username would have to be added in WSD's Add New User screen to set up permissions for that authenticated user. As long as usernames are synchronized manually between the LDAP server and WebSite Director, WebSite Director would operate normally.

Copyright 2000-2005 CyberTeams, Inc., http://www.cyberteams.com All rights reserved.
CyberTeams and WebSite Director are registered trademarks of CyberTeams, Inc. All other marks are the property of their respective owners.