Solution: Ensure that every broker is configured with the User Name Server. Use a single User Name Server for
the whole broker domain. In addition, all the brokers and the Configuration
Manager must
be able to access the User Name Server's queue manager. If BIP8303 errors are recorded in any broker's log
after startup, it indicates a communication problem with the User Name Server.
Check your WebSphere MQ channels to and from
the User Name Server and try again. You should see
event message BIP8204I for both the Configuration
Manager and
any brokers, showing that they have successfully registered with the User Name Server.
There
might be problems with users and group memberships if your broker domain spans
a number of systems with different lists of users. For each computer holding
a broker, there must be a group called
mqbrkrs.
This must contain the following principals, or authorization failures are
reported:
- Local broker's service user ID
- All neighboring brokers' service user IDs
- The Configuration
Manager's service user ID
For client applications, if the user ID in the message is a member of
the
mqbrkrs group, security is bypassed
(even if a
User Name Server is being used).
If
your publish/subscribe request fails, and event message BIP7017 is
issued, check that the client user ID is known to the system on which the User Name Server is running. Also, if you are operating
in a Windows domain environment, ensure
that the User Name Server was created with the -d parameter on the mqsicreateusernameserver command set to the appropriate domain,
and that all client application user IDs are members of this domain.
Message persistence in publish/subscribe is
normally preserved. However, a subscriber might not get the expected persistence
if ACLs do not allow it.