Queue managers can be migrated between systems by taking backup of the queue manager. The process of backing queue manager and restoring queue manager is explained in below link
Queue manager backup and restore
Also before performing any migration process, it is worth taking a backup of queue manager configuration
dmpmqcfg -m MYQMGR -a > /mq/backups/MYQMGR.mqsc

Migration of queue managers between windows system is slightly different. In scenarios where a queue manager is moved to a different server with same MQ level, under Unix platforms the approach is straight forward where we create new queue manager similar to that in the old system then replace log and data directories. We need to ensure that new server should have same usernames and groups to match that of authorization records on the queue manager. But a similar approach will not be appropriate when it comes to Windows platform because of SID associated with users. A security identifier (SID) is a unique value of variable length used to identify a user account. When we follow similar approach followed on Unix platforms to bring the queue manager up we can see there are authorization records matching with SID of old windows system.
For example:
setmqaut -m MYQMGR -n @CLASS -t topic -p S-1-5-21-1044885269-2648042281-2468751366-1000 +crt
setmqaut -m MYQMGR -n @CLASS -t topic -p S-1-5-21-1044885269-2648042281-2468751366-1001 +crt
setmqaut -m MYQMGR -n @CLASS -t comminfo -p S-1-5-21-1044885269-2648042281-2468751366-1000 +crt
setmqaut -m MYQMGR -n @CLASS -t comminfo -p S-1-5-21-1044885269-2648042281-2468751366-1001 +crt

In windows, MQ authorization records match the users based on the SID. MQ stores the SID and tries to find the user account based on SID. After migration SID doesn’t match with any user in new system, hence SID’s are seen in authorization records rather that user id. In such cases we have to set new authorization records using dmpmqcfg for mqm group. Now when we display authorization records we can see both records matching SID of old system and newly defined records. The old records can’t be deleted in MQ 7.5 levels as SID doesn’t match with any users. So these will remain stranded in configuration file. From MQ v8 onwards we can delete OAM entries to a particular windows user account using ‘-u SID’ option of setmqaut.

The entire above scenario can be avoided in windows if domain accounts are used and the queue manager is restored on another server that is part of the same domain.

Deleted user IDs or groups vs Authorization records
In this section we will be mainly concentrating in Windows platform. But the procedure explained in this section is applicable to Unix platforms as-well. Before deleting a user or a group, it is a good practice to delete all the authorization records first else these redundant records will remain stranded. If a user is deleted before it’s concerned authorization records are deleted then as mentioned in the earlier section MQ v8 setmqaut option ‘-u’ can be used to delete the record. But if MQ level is MQ 7.5 or lower level then these redundant records of deleted SID can be removed in following way
– Backup the queue manager configuration using dmpmqcfg command
dmpmqcfg -m MYQMGR -a > C:\backups\MYQMGR.mqsc
– Record queue manager initialization settings like log file type, number, size. Back up other queue manager customization and exits if they exist. Unload the messages from the application queues if they need to be preserved.
– Delete the redundant authorization records from the back up configuration file.
– Shut down and delete the queue manager.
– Re-create the queue manager with same log file type, number, size and customization.
– Using the edited configuration file re-create the objects and authorization records.
– Load application messages to the queues

3 comments on"Migrating queue managers between systems on windows platform"

  1. […] Migrating queue managers between systems on windows platform […]

  2. When you say “Authentication Records” throughout this blog post, did you mean “Authorization Records”?

    • Yes, I meant Authorization Records when I say Authentication Records in the blog. I will update further to rectify this confusion in the blog. Thanks for spotting it out.

Leave a Reply