The TDI 7.1 MQe Configuration Utility (a command line utility) creates a default MQe Queue when initially setting up the MQe Queue Manager. This default MQe Queue is named "_default". This default Queue is created for convenience only - so that a user can use the MQe Configuration Utility to set up MQe (using the appropriate MQe Configuration Utility command) and then start using the System Queue and the System Queue Connector right away.
IBM TDI 7.1 provides a default configuration file, in TDI_install_dir/MQePWStore/pwstore_server.ini, the configured parameters of which is used unless you modify them by using this utility.
Additionally the TDI 7.1 MQe Configuration Utility can be used to create and delete user MQe Queues to be used by the System Queue and the System Queue Connector.
mqeconfig mqeconfig.props create queue queue_name
mqeconfig mqeconfig.props delete queue queue_name
If the solution needs any special configuration, then we can use the MQe Explorer to fine tune your MQe configuration. The MQe Explorer is not bundled with TDI, but can be downloaded as part of the MQe Server Support ES06 pack at http://www-1.ibm.com/support/docview.wss?rs=0&dc=D400&q1=MQe&q2=MQ+Everyplace&uid=swg24007943&loc=en_US&cs=utf-8&cc=us&lang=en.
In TDI 7.1 access to MQe can be secured by means of authentication using the MQe Mini-Certificate Server to issue certificates to be used for authentication. For that purpose several additional properties available in TDI 7.1 must be added to the mqeconfig.props properties file, which contains the configuration properties of the MQe Configuration Utility.
The certificates issued by the MQe Mini-Certificate server have a configurable validity period. The default validity period is 12 months. The MQe documentation states that issued certificates should be renewed before the period expires. To enable this, the MQe configuration utility include an option to renew certificates. Typing the following command renews the certificates:
mqeconfig mqeconfig.props renewcert {client | server}
There is no additional coding required to support this feature. It should be noted that DNS support is really an MQe feature, since the TDI component implementations simply pass the configuration properties from mqeconfig.props through to the MQe APIs. Themqeconfig.props properties which can accept DNS name or IP address values are:
To support high availability deployments, we have the possibility to deploy and configure multiple instances of the TDI MQe components. In some deployments, it may be necessary to configure multiple TDI MQe Password Store components. For example, if password change plug-ins have been configured for multiple Windows Domain Controllers--in this case, it is likely that there separate instances of MQe client side Queue Managers with the name "PWStoreClient". Additionally, for each of the client Queue Managers, there is a remote queue proxy connection to the MQe server side Queue Manager queue used by the TDI MQe Password Connector. The remote queue proxy name is "PWStoreServer+passwords". When we use this type of deployment scenario, the authentication certificates associated with these two MQe entities (that is, "PWStoreClient", "PWStoreServer+passwords") is requested and issued multiple times. This happens each time the mqeconfig utility is executed. Before executing the second and each subsequent instances of the mqeconfig utility, it necessary to re-enable certificate issue for each of the MQe entities mentioned above.
For some deployments, you may prefer to configure the TDI MQe Password Connector such that it supports a particular high availability requirement. You may expect that an implementation supporting this type of requirement would employ multiple instances of the TDI MQe Password Connector, each with its own associated MQe Queue Manager configuration. In this case you would deploy multiple identical MQe server side configurations, allowing a network load balancer to route requests from the TDI MQe Password Store client to an available server instance. Each MQe Queue Manager on the server side is configured using the mqeconfig utility. When this utility executes it automatically request authentication certificates from the MQe Mini-Certificate server for the entities named "PWStoreServer" and "PWStoreServer+passwords". These represent the Queue Manager and Queue names respectively. Before executing the second and each subsequent instance of the mqeconfig utility, it necessary to re-enable certificate issue for the two MQe entities mentioned above.
mqeconfig mqeconfig.props create remotequeue queue_name targetQMname [QM_ip_or hostname comm_port]In the above command line QM_ip_or_hostname and comm_port parameters are optional; if they are missing only a remote queue definition is created. If you provide these two parameters, a Connection definition also be created before creating the remote queue definition.
A remote queue is not usable without a Connection definition. In addition several remote queues can be defined to share a single Connection. The targetQMname parameter specifies the name of the remote MQe Queue Manager.
mqeconfig mqeconfig.props delete remotequeue queue_name targetQMnameIn the above command line the targetQMname parameter specifies the name of the remote MQe Queue Manager.