Preserving CE/Vista Settings

I’ve been asked for notes about this a few times. So here’s a blog post instead.

A coworker is working on scripting our updates. We lost the Luminis Message Adapter settings in applying the patch to the environment we provide to our clients. Fortunately, those settings are maintained by us not our clients. So I pushed those settings back very easily. Unfortunately, it points to the need to capture the settings for the potential purpose of restoring the settings.

In Oracle databases, this is pretty easy. As the schema user, run the following. It does some intentional things. First, we have multiple institutions, so the breaks make identifying which institution easier. Second, the same label for multiple forms gets confusing, so I am sorting by setting description id under the theory these ids are generated at the time the page is created, so the same tools will float together. (The last modified time stamp is probably unnecessary, I used it in an earlier version and left it just in case Vista for whatever reason added a new setting for the same label instead of modifying the existing one.) This can be spooled both before and after the upgrade. Use diff or WinMerge to compare the versions. Anything lost from the before version should be evaluated for inclusion adding back to the settings.

col lc_name format a50
col setting_value format a80
col label format a80
col lock format 999
col child format 999

clear breaks computes
break on lc_name skip 1

select lc_name, settings_description.label, settings.setting_value,
settings.locked_flag “lock”, settings_description.inheritable_flag “child”
from learning_context, settings, settings_description
where settings.settings_desc_id =
and settings.learning_context_id =
and learning_context.type_code in (‘Server’,’Domain’, ‘Institution’,’Campus’,’Group’)
order by, settings.settings_desc_id

An example of the multiple forms issue is external authentication. CE/Vista provides an LDAP (A) and an LDAP (B). The settings_description.label for both is contextmgt.settings.ldap.source. The for both is source. It looks like each of the two identical labels has a different settings.settings_desc_id value depending on whether it is A or B. To me it seems lame to use the same label for two different ids.

The most vulnerable parts of the application to lose settings during an update are the System Integration settings. A mismatched Jar on a node will wipe all the settings associated with that Jar.

However, I can see using this to capture the settings as a backup just in case an administrator or instructor wipes out settings by mistake. Yes, this is scope creep. Create a backup of the settings table to actually preserve the settings.

create table settings_backup_pre_sp2hf1 tablespace WEBCT_DATA as select * from settings;

Contexts: As a server admin, I maintain certain settings and push those down. Each client has control over some other settings and may push those down from the institution context. Maybe some are creating division and group admins? Maybe some instructors are changing things at the course or section levels. I may end up capturing everything?

Restoration: The whole purpose of preserving the settings is to restore them later. There are a couple methods in theory:

  1. Providing the settings to a human to re-enter. The labelling issue makes me question the sanity of trying to explain this to someone.
  2. Update the database directly would just need ensure it is the right location. Maybe dump out the settings in the format of an update command with labels on each to explain the context? Ugh.

If settings were not so easily lost, then this would be so much easier.

View: Another table of interest is the settings_v view. (Redundant?) The only reason I don’t like this view is it reports the values for every learning context which makes reporting off it much, much longer. For example, the encryption key for a powerlink is listed 8 places in settings/settings_description and 18,769 places in settings_v.

Enrolling Administrators

One of the challenges of having 42 institutions is managing the administrators. (Actually we created some 12 spare institutions but why is another  post.) So my challenge was how to not drive myself insane trying to enroll the 6 same admin users to each institution. The best way in my opinion is to create the users in an IMS XML file for each institution and import the data. Creating the users was easy. Next was doing the enrollments.

Naturally, I turned to the Vista 8 Enterprise System Integration Guide on pages 66-67 and 95-96 where it describes which roles can be enrolled at which learning contexts. They go from the lowest most common enrollments at the section level up to the division level. Yeah, there was not anything for the institution level. It even had a comment before the table on pages 66-67:

NOTE: Roles not specified in the table can only be added through the Vista Enterprise administrative interface.

So, because the Institution Administrator is not listed, I could not enroll users to it through the import? It depressed me for about a week. A flash of inspiration had me check the Vista 3 documentation. Sure enough, on page 49 of the Vista 3 System Integration Guide, Institution Administrator is listed. (Admin roles at domain and server contexts, designer roles at instiution and domain contexts are also listed.)

The XML is easy enough to write. Normally, when writing this XML, I just need to refer to the SourcedId for objects I create, so I know their values. However, with this, I need to the know the SourcedId.Id for the institution.

Fortunately, we have collected the properties to a and parse it to generate what to run at the command line. Rather than by hand copying the files into place one-by-one, I created a script to take a template, check this and place the files in the correct place. In order to make each object unique, a portion of the SourcedId.Name was changed to the name of the destination folder.

Now I just need to add to the script a portion to change the SourcedId.Id for the Institution to the source_id value in the That is easy. Much easier than figuring out where to look in the documentation to find what is correct.

IMS Data Going to Wrong Place

I should know better than to trust documentation over my own intuition. Or to change based on what others tell me.

I followed:

Log in to Vista Enterprise as a Server Administrator or Institution Administrator.
NOTE: To set glcid, you must log in as a Server Administrator.

From the Administration tab, click the Utilities tab.
Click Settings.

Under System Integration, click System Integration API IMS….

Enter values to configure settings. See the table that follows, Standard and IMS Adapter
details on each value.

Click Save Values. The Settings screen appears and the settings are configured.

Standard and IMS Adapter Settings
The following table describes the parameters you can set using the administration user interface.
Setting Description

• Stands for global learning context identifier.
• Set by Server Administrator only.
• Required to run IMS and Standard adapter

• Identifies the institution in which the adapter
command runs
• Automatically assigned by Vista Enterprise
upon creation of an institution

Of course, it doesn’t say which Glcid, right? After all, every learning context has a Glcid. Since, at the time I only had one institution (before I created the 54 others), I set the Glcid to the one for that institution. Should it be the Glcid for the server or domain learning context? If so, then couldn’t Blackboard just pre-populate it at the time of install? Why do I need to put it there?

At the same time, I didn’t believe it necessary because I had seen IMS imports work without the Glcid set at the server learning context. They worked because the command used to run the IMS import has the glcid.

The result? My imports went into the the institution with the Glcid set at the server learning context, despite the defining in the command I ran to use a different Glcid. Removing the Glcid from the server learning context settings allowed the command to work as I thought it should.

So much for a pristine, clean database.

Tar Owner

Some of my previous blog posts about a little discovery have save me time in the past.

I made a tar of some system integration scripts we wrote for Vista 3 and brought them over to a Vista 8 test box to work on updating them for this new version. A decision we made earlier to change the userid came to light.

Using gtar -zxvf file.tar.gz gave me the wrong owner. Thankfully the people who made tar long ago solved this problem with –owner. Look for it in the man pages. Using gtar -zxvf file.tar.gz --owner newid gave me the files I needed with the right owner.

Also, thankfully, the old owner account was still on the box so I go into it and remove the files before extracting with the new id. Hopefully my Systems people (who read this blog) will not kill that account or our access to it until after this project is done?