Turn Off Tabs
Serena Business Manager 10.1.2.2 Readme
This readme file contains known issues and other important information for Serena® Business Manager. This file also contains information that might not be available in other SBM documentation. Last updated on 2013-07-19.

Contents

About this Release

SBM 10.1.2.2 is the version that immediately follows SBM 10.1.2.1. All of the features, changes, and fixes that were made in SBM 10.1.2.1 can be found in SBM 10.1.2.2.

Note: SBM 10.1.2.2 contains defect fixes, but does not contain any new features.

SBM 10.1.2.2 supports new installations—you do not need to install a previous version of SBM before installing this version. If this is a new installation, download version 10.1.2.2 from http://www.serena.com/support and then follow the instructions in the SBM Installation and Configuration Guide.

SBM supports upgrades from any release after 2009 R1. SBM 10.1.2.2 supports the following two different upgrade paths:
  • If you have already installed SBM 2009 R3 or later, follow the steps in Minor Upgrades to upgrade to SBM 10.1.2.2.
  • If you have not yet upgraded to at least 2009 R3, follow the steps in solution S138037 to perform the upgrade to SBM 10.1.2.2.

SBM 10.1.2.2 is available in U.S. English only.

Terminology Changes

The following terminology and component name changes have been made since the release of SBM 2009 R4.

Old Term New Term

SBM Application Administrator

SBM Application Repository

Web Administrator

SBM Application Administrator

Manage Data

Auxiliary Data (in SBM Application Administrator)

Notification Server (in the SBM installer)

SBM Mail Services
Terminology changes in earlier releases:
  • For changes made in SBM 2009 R4, refer to the readme.
  • For terminology changes made since TeamTrack 6.6.1, refer to the Moving to Serena® Business Manager guide.

Supported Configurations

The sections below discuss changes in supported software configurations. Detailed information about supported platforms and software configuration is available in the Supported Platform Matrix.

Web Services

The latest application Web service calls can be found in the sbmappservices72 WSDL. The latest administrative Web service calls can be found in the sbmadminservices72 WSDL. All TeamTrack Web services and earlier SBM Web services (including ttwebservices, aewebservices70, and aewebservices71) are still compatible with this release. However, these WSDLs have been deprecated and will not contain any of the new calls or parameters found in SBM Web services version 7.2. For new Web service implementations, use SBM Web services version 7.2.

Note: For 64-bit SBM installations, you can install and run Serena License Manager 2.1.5, which is supported natively for 64-bit systems.

Build Numbers

The following component build numbers apply to this version:

  • SBM User Workspace: Build 143
  • SBM Composer : Build 060
  • SBM System Administrator and SBM Application Administrator: Build 143
  • Application Repository: Build 84
  • SBM Configurator: 10.01.02.02.40
  • Database version: 1012101009
Note: The 10.1.2.2 documentation is versioned as follows:
  • English – 10.1.2.1
  • Japanese – 2009 R4.01 (the translated content applies to version 2009 R4.01)

Third-Party Tools

For third-party software information, refer to:

Third Party Copyrights

Third Party Client Licenses

Third Party Suite Licenses

Upgrades

This section provides general upgrade information and important notes for all upgrades to SBM 10.1.2.2. Before you upgrade, review the following sections and proceed with the upgrade according to the version that you currently have installed.

Please refer to prior readmes for a list of features and changes that were added in another version before this release.

Upgrades from the following products and versions are supported in this release. Upgrades are supported from specified major releases and minor releases on those base releases.
  • TeamTrack 6.6.1.x
  • Serena Business Mashups 2009 R1.0x
  • Serena Business Mashups 2009 R2.0x
  • Serena Business Mashups 2009 R3.0x
  • Serena Business Manager 2009 R4.0x
  • Serena Business Manager 10.1
  • Serena Business Manager 10.1.1.X
  • Serena Business Manager 10.1.2
  • Serena Business Manager 10.1.2.1
Tip: If you are using a version of SBM prior to 2009 R1, first upgrade to 2009 R4.0x, and then upgrade to 10.1.2.2.

New Installations of Serena Business Manager

If this is a new installation, download version 10.1.2.2 from http://www.serena.com/support and then follow the instructions in the SBM Installation and Configuration Guide to install Serena Business Manager.

Upgrading From Tracker

There are two methods for migrating from Tracker to SBM. For more information on migrating your Tracker data to SBM, refer to the "Migrating Tracker Data to SBM" solution (S138468).

Note: Serena Business Manager is now supported on the 64-bit version of Windows Server 2008; however, the Tracker migration utility is not available in the 64-bit version of the SBM System Administrator. Therefore, if you plan to run SBM on a 64-bit version of Windows 2008, you must first use the 32-bit version of SBM System Administrator on Windows 2003 or 2008 SP2 to migrate your Tracker data and then install SBM on your 64-bit server and connect it to your SBM database.

Upgrading From TeamTrack 6.6.1.x

If you have TeamTrack 6.6.1.x installed, download version 10.1.2.2 from http://www.serena.com/support, and then follow the instructions in Moving to Serena® Business Manager. This guide only covers upgrades from TeamTrack.

Note: This version requires a database upgrade. Back up your existing database before installing this version.

You should also refer to solution S137372 to learn about the upgrade preparation utility.

Upgrading From Earlier Versions of SBM

To test this release, you must mimic your installation on a separate set of hardware. This test installation should include all environments used by your system. You can then upgrade and test this installation before upgrading your production installation. To upgrade successfully, SBM 10.1.2.2 must be installed on each server and client machine.

This release supports both major and minor upgrades:

Important Notes for Major and Minor Upgrades

The following notes apply to both major and minor upgrades:
  • SBM Configurator warns you if your installation currently uses default certificates (which should be replaced) or if your current certificates will expire soon.
    Important: To properly secure your installation, you must generate new key pairs even if you do not plan to use SSO. If you do not generate new key pairs, then the default certificates that the STS inherently trusts are used. To increase security, launch SBM Configurator and generate new unique certificate for all components. For details, see "Securing SBM" in the SBM Installation and Configuration Guide.
  • As 10.1.2, the SSO Login Application (Federation Server) has been merged with the SSO Security Token Service (STS) into a single SSO Security Server (also known as the Identity Provider (IDP)). This means that the ALFSSOLogin.war and TokenService.war directories have been merged and replaced with a new idp.war directory on the SSO server.
    Important: If you have created custom SSO integrations, you must review all URLs and calls to ensure that they use the new directory names. For example, if your existing integrations call the Security Token Service (STS), you must ensure that the new idp.war directory is used (instead of ALFSSOLogin.war or TokenService.war).
    The endpoints of the SSO services must be changed accordingly. The relative URIs will stay the same, but since the application is new, the login application entry point will be:
    http(s)://host[:port]/idp/login
    For the STS, it will be:
    http(s)://host[:port]/idp/services/Trust
  • You must have one instance of SSO installed in order to have a functional instance of SBM, regardless if you plan to enable SSO or not. The SBM upgrade does not install missing components; therefore, if SSO is not currently installed, you must run the installer, perform an uninstall, and then reinstall SBM with SSO included. In a distributed installation, choose a server to host SSO, and then perform the uninstall and reinstall on that machine.
  • For Oracle systems, the required roles and privileges for the SBM schema user have changed. Please visit S133641 for details.
  • You must ensure that all of the SBM components are installed on one or more servers prior to upgrading. This includes SSO and SBM Common Services. You can choose to enable or disable SSO once it is installed; however you still must install the SSO component for SBM to function properly.
  • You must disable the User Access Control (UAC) setting before you install SBM on Windows 2008 or 2008 R2. To disable this setting, perform the following steps:
    1. From the Windows Start menu, open the Control Panel and select User Accounts.
    2. Turn off UAC:
      • On Windows 2008, open the User Accounts window, click Turn User Account Control on or off and clear the Use User Account Control (UAC) to help protect your computer check box.
      • On Windows 2008 R2, click Change User Account Control settings, and move the slider to the Never notify position.
    3. Click OK.
    4. Reboot the server and perform the install.

    After the installation is finished, you can enable UAC; however, you must disable it again if you attempt to uninstall SBM.

  • Microsoft .NET Framework 3.5.1 must be installed on all Windows machines. If it is not detected, .Net Framework 3.5.1 is installed by SBM. To save download and installation time, you may want to install version 3.5.1 prior to running the SBM installer. Also, if you will not have Internet access during the installation, you should download and install 3.5.1 beforehand.
    Note: Microsoft .NET framework 3.5.1 is not installed by the suite installer on Windows 2008 R2 servers if version 3.5.1 is not detected on the server. To work around this issue, navigate to the Control Panel, select Programs and Features, select Turn Windows features on or off, and install .NET 3.5.1 from the Features list.
  • On Windows 2003 systems, the SBM installer requires Windows Installer 4.5 in order to install SQL Express without a system restart. (This is not a requirement if you are not installing SQL Express). If you do not pre-install Windows Installer 4.5, the SBM installer performs the install for you and prompts you to restart the system after you select the option to install SQL Express. When the system restart is finished, you must begin the installation again starting from the Welcome dialog. Therefore, to avoid an unscheduled system restart, download and install Windows Installer 4.5 from Microsoft, restart your server, and then install SBM. To determine if version 4.5 is already installed, open the command line and enter the following:
    msiexec -?
  • If you are connecting to a Microsoft SQL Server 2008 database, you must select the 2008 SQL Server Native Client driver. The SQL Server ODBC driver is not compatible with Microsoft SQL Server 2008.
  • If you upgrade to Windows 2008 in addition to upgrading SBM, you must enable the Web Server (IIS) role before you install SBM Application Engine. If the Web Server (IIS) role is not already configured on your Windows 2008 server, see the "Enabling the Web Server (IIS) Role in Windows 2008 Server" section in the SBM Installation and Configuration Guide for steps to enable the role.
    Note: SBM requires Internet Protocol Version 4 (IPv4) on Windows 2008 systems (IPv6 alone will not work). Both IPv4 and IPv6 protocols can be enabled simultaneously on Windows 2008; however, SBM requires at least IPv4 on each Windows 2008 server in your SBM environment.
  • Upgrade support for migrating to a 64-bit version of SBM is handled through a new suite installation on one or more 64-bit Windows 2008 R2 servers. You can either perform a Custom install that installs one or more SBM components on multiple 64-bit operating systems or you can perform a Complete install, which installs every component on a single 64-bit server. You can still perform Remote Administration tasks or connect directly to the database via ODBC using 32-bit clients.

    You can use the SBM System Administrator that is installed by the suite installer on a 64-bit Windows 2008 R2 server to upgrade the database. As part of the upgrade, review and upgrade any scripts and APIs that were originally created on a 32-bit operating system to ensure that they also run on a 64-bit system. For example, if you have any scripts that load .dll files, those dll files must be upgraded to run on a 64-bit machine.

    The hardware requirements for SBM running on a Windows 2008 R2 64-bit operating system are as follows. The memory requirements are greater than those for a 32-bit operating system.

    • Recommended Requirements – 2 GHz or higher multi-processors; 16 GB memory; 10 GB operational disk space.
    • Minimum Requirements – 800 MHz or higher single processor; 8 GB memory; 2.5 GB operational disk space.
  • For Oracle systems, you must perform the database upgrade using either the Mashup2009 DSN that is installed with SBM or a system DSN that uses the "Oracle for SBM" driver that is installed with SBM. As part of the upgrade, the existing Mashup2009 DSN is automatically converted to use the new "Oracle for SBM" driver. If you attempt to use a DSN other than the Mashup2009 DSN provided by SBM, the SBM System Administrator prompts you to either use the Mashup2009 DSN or to modify or create a DSN that uses the "Oracle for SBM" driver.
    Important: The underlying driver used in the "Oracle for SBM" DSN that ships with SBM has changed in SBM as of version 10.1. If you currently use the Mashup2009 DSN with SBM, you do not need to do anything. If you created your own custom DSN with the "Oracle for SBM" driver prior to upgrading to SBM 10.1 or later, then you must recreate the DSN and use the new "Oracle for SBM" driver that ships with SBM after the upgrade is finished.

    If you previously designated a SID for Oracle, then that SID is automatically used in the Service name field in SBM Configurator. Verify with your DBA that the correct service name is now used in the Database Servers tab of SBM Configurator.

  • For existing multi-environment installations (the development, test, and productions servers that you plan to upgrade), you can create new databases to host Common Log data for each environment.

    For example, you can back up your current Common Log database on your production server and restore it to a new space on your development database server. Once the data has been restored in the development database, purge the existing Common Log database space on the production database server and create a new database space for your test server (this results in two blank databases--one for test and one for production). Run SBM Configurator on the test and development SBM servers and update the Database Servers tab with the database connection information for the two new unique Common Log databases.

    This ensures that you have unique databases for the Common Log in each environment and it also moves your existing Common Log data from the previous production space into the new development space.

  • States, transitions, and projects now have unique internal names that make it possible to unambiguously refer to them in a Web service, AppScript, or API call. (This enables you to change the display name of the state or transition and not interfere with any of these references). Note the following:
    • The internal state and transition names are derived from the internal name of their defining workflows. These internal values are set when you open a process app in SBM Composer for the first time after upgrading to SBM 10.1 or later versions.
    • You can change the new default internal names for states and transitions at any time before the process app is published for the first time in SBM 10.1 or later versions. Once the process app is published, the internal names cannot be changed.
    • The internal names for existing projects are automatically created upon upgrade to SBM 10.1 or later versions. When you create new projects in the Application Administrator in versions after 10.1, SBM automatically creates the internal project name for you.
      Note: During promotion, if the internal project name clashes with an existing internal project name, the internal name in the target database is affected in one of two ways:
      • For new projects that are added during promotion, when a conflict occurs, the project name in the target database will be a blank or empty string.
      • For existing projects that are updated during promotion, when a conflict occurs, the project name in the target database remains unchanged. If the internal name in the incoming XML does not conflict with the internal name in the target database, then the promoted project's internal name is used.
  • The Java Notification Server does not support the MAPI standard. For upgrading customers formerly using MAPI with the Notification Server, you can now connect to your Microsoft Exchange server using the Exchange e-mail server type in SBM Configurator. The Exchange option enables SBM to communicate with your Microsoft Exchange server using the MS Exchange Web services API.

    For customers currently using MAPI, perform the following steps to configure the Notification Server to connect using MS Exchange:

    1. Run the SBM Configurator on each server where the Notification Server is installed.
    2. In the Mail Services tab, select the Notification Server tab.
    3. In the E-Mail Server Type drop-down list, select Exchange.
    4. Enter your current Exchange server version, connection URL, and system user credentials.

    You might use the Exchange option if your company does not allow connection through SMTP. The Exchange protocol is also available for use with the Mail Client in the event your company does not allow connection through POP3 or IMAP. If no such restrictions exists, consider choosing SMTP for the Notification Server and POP3 for the Mail Client because they enable faster connection speeds than MS Exchange.

  • In SBM 2009 R4, application icons were introduced. You could specify an icon in the application editor in SBM Composer, and the icon appeared on the application tabs in the SBM User Workspace. If you did not specify an icon, a default red icon was automatically used. As of SBM 10.1, the red icon is no longer the default; instead no icon is used if you do not specify one.
    • If you are upgrading from a release earlier than SBM 2009 R4, you will see no change; no icon will appear on the application tab.
    • If you are upgrading from SBM 2009 R4 or later, and changed the default red icon to something else, you will see no change; your icon will still appear on the application tab.
    • If you are upgrading from SBM 2009 R4 or later, and kept the default red icon, you will no longer see the icon; the application tab will be blank. If you want to restore the red icon, you can select it from the list that opens when you select "New image..." from the drop-down list in the application editor in SBM Composer. Redeploy your process app after making this change.
  • Security Tokens are now generated for authenticated users regardless of the log in method you choose in SBM. Note the following behavior for upgrades from releases prior to 10.1:
    • If SSO was enabled in a prior release, after the upgrade to 10.1.2.2, deployed apps will use Security Tokens automatically without having to be redeployed.
    • If SSO was disabled in a prior release, after the upgrade to 10.1.2.2, deployed apps will not use Security Token authentication unless they are redeployed (even if SSO is enabled after the upgrade).
  • The following information only applies to SBM systems in which external events were used with orchestration workflows and SSO was not used:
    • With the use of security tokens for all communication with SBM components regardless of authentication method, it is now necessary to provide credentials in the User element of external events that are processed by the Event Manager. Credentials must be supplied in order to receive a security token.
    • Previous SBM releases allowed anonymous events if SSO was disabled. As of SBM 10.1, security tokens are used in all underlying communication. As part of the upgrade process, in order to still accept external events without credentials, the Event Manager is automatically configured to continue to accept external events without authentication credentials. If SSO was enabled prior to upgrade, then it is assumed that external events always included credentials and will continue to do so in your environment.
      Important: If you are currently using external events without SSO, it is strongly recommended that you adjust the source of those external events to now include credentials. Once you adjust the external source to include a credential, you can then manually override the Event Manager settings by setting the no_authentication parameter to “false” in the alf.properties file. For configuration instructions, see solution S138463.
    • After upgrading, the no_authentication setting is independent of the SSO setting. If you are performing a new installation, you can override the default behavior for the Event Manager and enable it to accept external events without credentials. For configuration instructions, see solution S138463.
    • For SBM Application Engine Web services, the SBM Application Engine auth still overrides the security token auth. In some cases, this is useful in day-to-day operations and may be useful if you are upgrading from versions prior to 10.1. For example, orchestration workflows that contain coded auth for the SBM Application Engine service calls will continue to work if the external event is changed to send a credential; the coded auth will override the security token and continue work as it did prior to upgrade.
  • User credentials in SBM Application Engine Web service calls that use Basic authentication are now handled exclusively by SBM Application Engine itself, instead of IIS. This configuration is common if your SBM system is set up with NT Challenge Response for end-user authentication. After upgrade, this means that you must now specify the Windows domain for Web service calls in SBM System Administrator, otherwise the domain that the IIS server machine is installed on is used for user validation.
    As part of the upgrade, SBM Configurator should perform the following steps for you automatically to accommodate this new requirement. However, for systems that use NT Challenge Response authentication that have an authentication override set in SBM System Administrator, you must perform the following steps manually:
    1. In IIS, copy or take note of the current domain that you have set for Basic Authentication on the GSOAP directory.
    2. Clear Basic Authentication from the GSOAP directory and only specify Anonymous Access or Anonymous Authentication. (In previous versions of SBM, you had to specify Basic Authentication on the IIS GSOAP directory and provide the domain there).
    3. From the Options menu in the SBM System Administrator, select Settings or click the Settings icon on the toolbar. The Settings – Server tab opens.
    4. Paste or enter the correct Windows domain in the Default domain for web services field.
  • If your database does not contain at least one Regular User or Managed Administrator account with Remote Administration privilege, the Reset Administrative User Access Wizard appears immediately after the database upgrade is finished. You use this wizard to define at least one user as your primary system administrator (an account that has Regular User or Managed Administrator product access with Remote Administration privilege). Once the wizard is finished, you should be able to log in to SBM Application Administrator using the user account that you specified in the wizard. For details, see the SBM System Administrator Guide.
  • Note: The following information is only applicable if you had previously upgraded to 10.1 or 10.1.1.1. If you did not upgrade to either version prior to upgrading to 10.1.2.2, then you can ignore the following information.
    Values in promotion profiles that were created in 10.1 or 10.1.1.1 were set to All by default. As of 10.1.1.2, entities for new items (items added to a process app since the profile was created) will be set to None by default.
    In addition:
    • Profiles created prior to 10.1 that had entities set to None may have been incorrectly using All. These entities will be set back to None.
    • Profiles created in 10.1 or 10.1.1.1 that had entities set to the default All may also be set to None. These entities must be manually corrected.
    In general, it is recommended that you review your promotion profiles and adjust the settings accordingly.
  • If you installed 10.1, which had the Transition Group Restrictions and User Field Selections check boxes selected by default in promotion profiles, and then upgrade to 10.1.2, the check boxes could become unchecked.
  • Prior to 10.1.2, renaming an orchestration in SBM Composer and then redeploying the process app would leave the originally deployed orchestration event map in place while also deploying a new event map with the new name. The original event map was still associated with its events, so events associated with the orchestration would cause both the original event map to run the orchestration workflows and the new event map to run the orchestration workflows. This problem could reoccur on each new deployment. Generally, the behavior was that an orchestration workflow would appear to run twice or more simultaneously, where it was only expected to run once (although other unexpected behavior was also possible).

    This problem is fixed as of 10.1.2 for deployments of new process apps, and an upgrade is provided that as far as is possible, fixes existing deployments by removing any duplicates. For systems installed prior to SBM 10.1, certain cases of existing deployments cannot be automatically upgraded and will still be prone to this renaming issue. Mostly, these cases can be addressed by redeploying the currently deployed process apps.

    Note: If you suspect duplicated event dispatches after upgrade, contact Serena Customer Support for assistance.
  • If you have applications in SBM that use Tomcat (such as DVM), you must clear out the Tomcat work subdirectory (typically %TOMCAT_HOME%/work). Clearing the browser cache alone is insufficient. This applies to both Firefox and Internet Explorer browsers.

Minor Upgrades

This section provides important notes and upgrade instructions for upgrades to SBM 10.1.2.2 from version 2009 R3 and later.

Before you upgrade, review the information above in addition to the following topics:

Pre-upgrade Steps

Follow these steps before beginning the upgrade:

  1. Verify that SBM 2009 R3 or later is installed on your system by opening the "About" box in the Web interface. You can also view the current version of each component in the System Information tab of the SBM Configurator.
  2. Back up your existing database before installing this version.
  3. Back up the SBM installation directory structure on your Application Engine Web server machine.
  4. Download the release from support.serena.com.

Server Installation

Note that you must replace all client and server components for all environments. To upgrade to this release on all server machines:
  1. Extract the server installation files.
  2. On the server machine for each server component, launch the suite executable. An installer message prompts you to confirm that you are upgrading your system. Click Next to continue.
  3. The Upgrade Summary dialog box appears and summarizes the components that are currently installed on the server and ready for upgrade. The current installation directory that will be upgraded is noted as well.

    As of SBM 10.1, the Notification Server and Mail Client are powered by Serena Common JBoss and installed independently from the SBM Application Engine component. For upgrades from versions prior to 10.1, the option to install the new SBM Mail Services (which contains the Notification Server and Mail Client) is selected by default (except on servers that host only the SBM Application Engine and no other components; in that scenario, you must manually select the SBM Mail Services check box to install the Notification Server and Mail Client because the installation of these components now includes the Serena Common JBoss service, which consumes additional resources on the server).

    Before you install the SBM Mail Services, review the following installation considerations:

    • For your production environment, if you have a high volume of Notification Server and Mail Client activity, you can now add additional instances of the SBM Mail Services. Installing multiple instances not only provides failover in case one of the servers shuts down; it also improves the overall performance of notification handling because the processing load is distributed across multiple servers.
    • For installations with over 1000 users or heavy orchestration usage, consider installing the SBM Mail Services on a dedicated server without any other SBM components. If you install the SBM Mail Services separately, you must enter the SBM Application Engine host name and port in SBM Configurator after the installation. This enables the Notification Server and Mail Client to communicate with the SBM Application Engine.
    • For multi-environment installations that include separate SBM Application Engine installations for test, staging, and production environments, install the SBM Mail Services at least once in each environment.

    After you have reviewed the components that are currently installed and decided whether or not to install the SBM Mail Services, click Upgrade Now to proceed.

    Note: For minor upgrades, if you want to uninstall existing components or install new components other than the SBM Mail Services, you must use the Windows Add/Remove Programs utility to completely uninstall SBM and then perform a Custom install using the suite installer again (which performs a clean install). This process does not upgrade the current installation. It is recommended that you back up your existing SBM installation directory before you uninstall and reinstall with different component selections. Once the desired components are installed, continue to the next step and reconfigure your installation using SBM Configurator.
  4. At the end of the installation process, click Configure to launch SBM Configurator. You must complete the SBM Configurator wizard before you can access SBM.
    Note: If you are prompted to restart your server, SBM Configurator launches automatically once the server has restarted. (On Windows 2008 systems, you must launch SBM Configurator manually once the server has restarted). If you decline to restart the server at this time, you will not be able to run SBM Configurator until the server has restarted.
    When you launch SBM Configurator, it detects that you are upgrading your system and it upgrades the file system by merging existing configurations from your previous installation into the new installation files. After SBM Configurator is finished upgrading your file system, you can run it anytime thereafter to verify or modify your configuration settings as needed. Guidance is available by clicking the Help buttons throughout the wizard.
  5. Launch SBM System Administrator and upgrade the SBM Application Engine database. If you use multiple environments, you must perform this step for each database in each environment.
    Tip: Plan ample time for the database upgrade to complete. When the upgrade finishes successfully, a message appears that directs you to the upgrade log.
  6. Review the database upgrade log file in the Log folder of the installationDirectory\Serena\SBM\Application Engine directory and correct any problems that occurred during the upgrade. If the log file is empty, no errors or warnings occurred during upgrade.
  7. Merge custom modifications to HTML templates, e-mail templates, and Web interface online help files made to your upgraded files. Backup templates are stored in a backup folder in the installationDirectory\Serena\SBM\Application Engine\Backup<version>-<date>-<time> directory.
    Note: See solution S139840 for a list of configuration Files, Web Interface templates, JavaScript files, and strings that have changed in this release. You must manually merge some of your existing SSO customizations into the newly installed files after you upgrade your software and database.

    If you previously used a custom HTML template for your reports, the reports might not display properly after upgrade. Therefore, consider using the default template or modifying it as needed. For example, as of SBM 10.1.2, several changes were made to Summary Reports that might not display properly using a custom template from a prior release. Instead, either use the new default template or merge your customizations into the default template to create a new custom template.

    Important: If you installed the TT4ZMF integration prior to upgrading, you must follow the instructions in the TT4ZMF readme to reinstall the integration after the SBM upgrade is complete.
  8. If you performed the previous step, open SBM System Administrator, select File, and then select Put Files in Database. ALL templates and images in the database are replaced by files on your local machine.
  9. In SBM Configurator, verify that these services are started in the Manage Services tab: SBM Application Engine Web server (Internet Information Services - IIS), Serena Common JBoss, Notification Server, and Mail Client.
  10. Instruct all SBM Composer users to install the client tools using the instructions in the following section (Client Installation).
  11. Instruct SBM User Workspace and SBM Application Repository users to clear the cache in their Web browsers.

Client Installation

The client executable contains SBM Composer and is intended to be run only on client machines.

Previous versions of SBM System Administrator are automatically uninstalled as part of the upgrade (administrative duties are now performed using SBM Application Administrator). Previous versions of SBM Composer are upgraded automatically and do not need to be uninstalled prior to upgrading. The new versions are installed in the same location as the old versions.

To upgrade SBM Composer:

  1. Download the client installer from support.serena.com.
  2. Launch the installer by double-clicking the file.
  3. Click Next on the Welcome dialog box.
  4. Click Install to upgrade the current client installation.

Fixed Issues

A list of defects fixed in this version can be found in the Knowledge Base. You must have a Serena.com user account to view items in the Knowledge Base. Register for a free account if you do not have already have one.

Beginning in SBM 10.1, user accounts are managed in SBM Application Administrator rather than in SBM System Administrator. SBM Application Administrator, which requires a connection to the SBM Web server, is not available if the number of users in your system exceeds the number of installed seat licenses.

If you receive a seat license error in a version earlier than SBM 10.1.1.4, contact Customer Support for assistance is resolving the issue. If you have SBM 10.1.1.4 or later installed, the Users tab in the SBM System Administrator is enabled automatically if you encounter this problem. Open SBM System Administrator and delete or modify user accounts so that they are in compliance with their seat licenses. (If you encounter this problem and the SBM System Administrator is already open, you need to close it and reopen it for the Users tab to appear.) Once you resolve user accounts, the Users tab is not visible the next time you open the SBM System Administrator.

Known Issues

For a complete list of known issues and potential workarounds, refer to the Knowledge Base.

Administrator Issues

  • Note: The following issue is only applicable if you had previously upgraded to 10.1 or 10.1.1.1. If you did not use either version prior to upgrading to 10.1.2, then you can ignore the following information.
    Values in promotion profiles that were created in 10.1 or 10.1.1.1 were set to All by default. Starting with 10.1.1.2, entities for new items (items added to a process app since the profile was created) will be set to None by default.
    In addition:
    • Profiles created prior to 10.1 that had entities set to None may have been incorrectly using All. These entities will be set back to None.
    • Profiles created in 10.1 or 10.1.1.1 that had entities set to the default All may also be set to None. These entities must be manually corrected.
    In general, it is recommended that you review your promotion profiles and adjust the settings accordingly.

Installation and Configuration Issues

  • SOO does not currently support separate Oracle schemas for each SBM component within the same Oracle instance. This also applies to multi-environment or "path to production" installations—the same Oracle instance cannot be used for multiple SBM environments (such as development, test, and production).
    Important: If you currently use multiple schemas with SBM in the same Oracle instance and you plan to use SOO, please contact Support for assistance.

    However, SBM can be configured with separate schemas as long as the Orchestration Engine and Common Log tables share the same schema. This means Orchestration Engine and Common Log will share one schema, while Application Engine and Application Repository have their own schemas or are shared in a separate schema. If you plan to use additional environments, you must create them in separate Oracle instances in this scenario.