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 typically preserved. However, a subscriber might not get the expected persistence if ACLs do not allow it.