Saturday, September 29, 2007

How to remove account text field

Content Server 7.x as well as 10G includes an editable text box next to Account field on content check in form. Allowing users to type in arbitrary accounts increases the risk of newly checked in content becoming inaccessible to others and has a potential of causing performance problems due to proliferation of account-related directories in weblayout. Many people wonder if they can remove it so users can only pick from the list of pre-defined accounts.



Here is how to accomplish that in just a few minutes without resorting to custom component development.

1. Start Configuration Manager

2. On the Tables Tab go Add table

3. Select DocumentAccounts table, Click OK

4. On the Views Tab go Add…

4.1 Pick DocumentAccounts as your table and select dDocAccount field so it will be shown

4.2 On Security Tab uncheck the Publish view data and select “Use standard document security” as shown below




4.3 Hit OK to close Edit View dialog

5. On Information Fields tab hit Add…

5. 1 Type field caption such as “SecurityAccount” , pick desired field order

5.2 Check the Enable Option List checkbox as shown below and click Configure button besides it




5.3 Select the Use View option as shown below. Select the view you’ve created on step 4 as shown below




5.4 Click OK to close the Configure Option List dialog

5.5 Click OK to close Edit Custom Info Field dialog

6. Click Update Database Design button (right side on the Information Fields tab on Configuration manager)

7. Select the Rules tab and click Add…

7.1 Type in a name for the new Global Rule you will be creating

7.2 On the Edit Rule dialog make sure that “Is global rule with priority” box is checked

7.3 Select Fields tab (see below)




7.3.1 Click Add to add a new filed

7.3.2 Select the filed you’ve created on step 5

7.3.3 Change Type to required or leave as Edit depending on your preference

7.3.4 Add dDocAccount field as you did on step 7.3.1 but this time mark is Hidden

7.3.5 Make sure that “Is derived field” box is checked and click “Edit…” as shown below




7.3.6 Switch to Custom tab on the Script Properties dialog as shown below




7.3.7 Check “Custom“ check box and paste the following text into it:

<$dprDerivedValue=getFieldViewValue("xSecurityAccount",#active.xSecurityAccount,"dDocAccount")$>

7.3.8 Click OK to close Script Properties dialog.

7.3.9 Click OK to close Edit Rule Field dialog

7.4 Click OK to close Edit Rule dialog

8. Select Options -> Publish Schema and Options -> Publish Schema Base so that your changes are visible on the check in form

WARNING : The global rule created on step 7 will hide the built in Account filed on content information, search and update screens to above steps will only be sufficient if you perform them on a new instance of content server. If you are working on an instance with existing content – follow the steps below:

9. Under Rules tab of Configuration Manager select the rule you’ve added on step 7 and hit Edit…

9.1 Select “Use rule activation condition” as shown below



9.2 Click Edit… and Add… to add a rule condition as shown below.




This will ensure that the original Account field is still visible and none your users are affected when they perform and update. You might want to add another rule to hide your newly created filed on search and content information pages…

Monday, September 3, 2007

Who else didn’t upgrade to 10G R3?

We’ve recently upgraded our instances of Stellent Content Server 7.5.1 to the latest Oracle release 10G R3. Upgrade procedures, as most of the things in Stellent, are fully documented but we still hit a few bumps on the road. Here are the notes for which I was ready to walk to the top of the mountain in a blizzard if I only knew they existed.

What was missing in the manual

We slightly disagree with Oracle when they say in Windows Install Guide

“It is recommended that you disable all installed components before the upgrade and enable them one by one after the upgrade. This is a good strategy because it allows you to determine which components may have been broken by the upgrade. Please note that this is not necessary for the software upgrade as such to succeed; it is merely a useful customization upgrade strategy.”

This is the only way we got our servers to come up after the upgrade so in our case it was required.

What Server Install Guide didn’t mention was that if you have a Site Studio installed, none of your sites would come up if you follow that procedure. (When you navigate to the Site Studio site URL even after you reinstall the new Site Studio component – you will get “Page can not be found” error).

WARNING: Your upgrade path will change depending on which custom components you have installed! Please review upgrading instructions for new versions of all of your installed components prior to upgrade.

For instance, if you have Folders and Site Studio together – you shouldn’t uninstall or disable them prior to upgrade so that each site can be migrated from a folders-based hierarchy to a project-based hierarchy

Upgrade process overview

Here is what your upgrade task list might look like:

  • Update JVM - 10G no longer works with JDK 1.4
  • Make a copy of Stellent Installation directory
  • Disable all components except Folders.
    Once again, see your components upgrade instructions prior to keeping or removing them! Sample list would look like that:
    • Uninstall components except Folders
      • The following components need to be disabled and then uninstalled:
        • Site Studio
        • Dynamic Converter
        • tzus2007
        • WebDAV
      • The following components need to be disabled but not uninstalled :
        • FoldersLocal
        • FolderStructureArchive
        • BackgroundThread
        • Lists
        • Helper
        • All other components except Folders
  • Disable Indexer Auto Update Cycle
  • Restart server and make sure that there are no errors in the output after every subsequent component disabling and uninstall
  • Install new Site Studio Component
  • Perform Content Server upgrade
  • Enable Indexer Auto Update Cycle
  • Install Dynamic Converter
  • Web sites should be fully functional including contribution mode and WebDAV
Tips and tricks

Here are a few more tips that may save you a few more hours

  • If Verity is you search engine - set the following variable (as shown, in all caps) in the [install_dir]/config/config.cfg file:

    SearchIndexerEngineName=VERITY.VDK.4

    New Content Server will continue working with your existing Verity installation and you won’t need to wait for index to rebuild. That said, you might consider upgrading to Verity VDK6 at later date if you have content in multiple languages.
  • If your database is MS SQL Server or Sybase - download jTDS JDBC Driver The old driver may not work. JDBC driver classname will be net.sourceforge.jtds.jdbc.Driver
  • If you are having WebDAV problems following successful upgrade - make sure default web site in IIS Admin doesn't have two Stellent ISAPI filters as it is shown below.


If two filters present, remove the second one. Subsequent IIS should render WebDAV fully operational.

Good luck!

Thursday, February 22, 2007

Are you in control of your Stellent Systems?

A few days ago I've got a call from my old time client. He was reading SANS' Top-20 Internet Security Attack Targets and was wondering if his Stellent installation might be vulnerable. He had all the latest patches at that time but something kept him thinking of his Stellent installation after hours.

We did an audit on his instance and found that even though the system was completely up to date with security patches, most of his contributors were in fact super admins! They couldn't find a better way to let contributors access the site continent they needed to access - there were simply too many security groups and accounts to deal with!

In my years as Stellent architect I've seen many capable sysadmins badly misconfiguring their security system. Is there anything wrong with Stellent security? Ten years of its succeess in multiple industries tells us otherwise. Stellent is simply very different when it comes to security. Here is why.

In my other post I've explained the limitations of a hierarchical folder structure which grows unwieldy over time making it difficult to find documents. Stellent overcomes this by providing a single metadata-driven content repository. This strategy is very effective for managing content but it takes away conventional files and folders where all of us are so used to set permissions! So where do we set permissions now? Just the content items themselves. There is no permission inheritance. Once the content checked in - its group and account values are set. Unlike Windows where you can specify who can do what with a file, in Stellent you specify what content group it belongs to and then you specify who can do what with your content groups.

Another major confusion point is the actual naming convention. What Stellent calls "Group" and "Account" is not always what the rest of the world calls them. Unfortunately, there is only a few simple words in English that can describe a group of content so Stellent calls it "Group". Windows users are trained that a "Group" is a group of users and "Account" is a user security record... Once again, a "Group" in Stellent is a Group of Content or "Content Group". An "Account" is another grouping of content or "Content Account". Try these names in your next security discussion and see confusion subside!

What if your system is already implemented? Is it too late to change content security? Do you have to manually update content group and account of every content item? Fortunately, in most the answer to those questions is no. Existing systems can have their security updated in just a few days. If your system is vulnerable - it can be fixed.