Operations Automation 6.0: Known Issues, Limitations, and General Notes
The article describes known issues and limitations of Operations Automation 6.0, as well as general notes about the release.
After the upgrade, check firewall configuration
During the upgrade, the system checks the iptables configuration. In case iptables/ip6tables aren't loaded into kernel, the upgrade does not fail but the respective warning message is added to upgrade log. For more information on how to harden PostgreSQL end-points of Operations Automation and Business Automation system databases, refer to this KB.
The issue occurs if the Online Store is installed in container running on Linux.
Public Folders coexisting with Exchange 2007/2010 is not supported by Exchange 2013.
Upon migrating an organization with Public Folders, they should remain on the legacy Exchange version. Decommissioning the Public Folder Stores on Exchange 2010 and Exchange 2007 is possible only after every organization has been migrated to Exchange 2013, and requires a special procedure. For more information, see the Operations Automation Hosted Exchange Deployment Guide.
Offline address book (OAB) is not generated on Mailbox server in Exchange 2013 CU5
In a newly deployed Exchange 2013 with the latest Cumulative Update 5 on POA 5.5.x, OAB is not generated on the Mailbox server. Check the KB article for details.
Upgrade of Exchange 2013 from CU2 to CU3 fails
Upgrade fails due to the presence of the brands with the Exchnage2013Protocols turned on. Check the KB article for details.
Account-Wide Service Users for APS 2 Subscriptions
Non-APS 2 services (for example, Hosted Exchange, Hosted SharePoint, Windows Shared hosting and any APS 1.x applications) must be in a single subscription to BES (BlackBerry Enterprise Server) used by the same Service User (same behavior as in previous versions of Operations Automation).
APS 2 services that use Operations Automation Active Directory (for example, Hosted Lync) are treated like non-APS 2 services above.
Operations Automation 6.0 Management Node on Windows stability issue: JBoss must be tuned after upgrade
After Operations Automation is upgraded to version 6.0 do the following:
Find JBoss configuration file in the directory where Operations Automation is installed on Operations Automation Management Node, e.g.:
Open the file and add the following text to the end of the 'datasource' block:
<datasource ...> ... <validation> <validate-on-match>true</validate-on-match> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"> </valid-connection-checker> </validation> </datasource>
Save the file. After that you need to stop the Operations Automation services by executing the following commands in the command line:
net stop pemui net stop pem net stop pau
Then start the Operations Automation services by executing the following commands in the command line:
net start pau net start pem net start pemui
Operations Automation 6.0 Management Node fails to restart, because the pau service does not start
The pau service may fail to start on a low performance hardware, due to the fact that the 30 seconds startup timeout is over.
To resolve this issue, increase the pau startup timeout up to 120 seconds.
SHUTDOWN_WAIT variables in the
Set both of them to 120 seconds.
Operations Automation 6.0 upgrade at Windows Management Node
After upgrade of Operations Automation to version 6.0 at Windows Management Node host, perform the following steps:
- Open the Internet Information Service (IIS) Manager and delete the "POA Task Logs" site.
- Make sure that the "Initial POA tarballs storage" site is running.
After upgrade of Operations Automation to version 6.0 at Windows Management Node host with Linux slave hosts, perform the following steps:
- Open Windows SQL Server Management.
- Connect to the plesk database (plesk/plesk).
- In the confman_parameters table find the parameter "pa.central.yum.repo.proxy.url". You can just make the following query:
select * from [dbo].[plesk].[confman_parameters] where [name] like '%yum%';
- Update this parameter with some not null value. You can use the "pa.central.yum.repo.url" parameter value.
You can also do it through Provider CP:
- Go to Infrastructure > Package Repository > Yum Configuration and click Edit.
- In the Repository proxy URL box, enter some value. You can use the "pa.central.yum.repo.url" parameter value.
Operations Automation 6.0 Management Node on RHEL/CentOS 5 issue: installation of modules fails
After upgrade of Operations Automation to version 6.0, installation of modules may fail because of dependency processing failed: libicu.i386 >= 3.8.
To resolve this issue do the following:
- Enter the RHEL/CentOS 5 node.
Download the source RPM for libicu 3.6 for any RHEL-compatible system (icu-3.6-5.16.1.src.rpm). For example, from http://rpm.pbone.net/index.php3/stat/3/srodzaj/2/search/icu-3.6-5.16.1.src.rpm
- Change a directory to
/usr/src/redhatand do the following:
- Install the source RPM:
rpm -Uhv icu-3.6-5.16.1.src.rpm
Edit the version to be 3.8:
Name: icu Version: 3.8 Release: POA.92391
Build the package:
rpmbuild -bb SPECS/icu.spec
You will have several RPMs:
Wrote: /usr/src/redhat/RPMS/i386/icu-3.8-POA.92391.i386.rpm Wrote: /usr/src/redhat/RPMS/i386/libicu-3.8-POA.92391.i386.rpm Wrote: /usr/src/redhat/RPMS/i386/libicu-devel-3.8-POA.92391.i386.rpm Wrote: /usr/src/redhat/RPMS/i386/libicu-doc-3.8-POA.92391.i386.rpm Wrote: /usr/src/redhat/RPMS/i386/icu-debuginfo-3.8-POA.92391.i386.rpm
/usr/src/redhat/RPMS/i386/libicu-3.8-POA.92391.i386.rpmfor installation on the Management Node.