Dependent clients still good past their sell-by dates
Sharing an interesting support case that I resolved today.
Dependent clients are not a common MSMQ installation type for a number of reasons. Mainly people don't know they exist but also support for them has been reduced in recent versions of MSMQ).
An example scenario where dependent clients are useful could be as follows:
A dangerous environment has computerised sensors which use MSMQ for data handling.
Independent clients would not be a good choice as messages on the local hard disk could be lost should the sensor be destroyed.
Dependent clients would be better as messages are created and manipulated on the remote server so losing the client leaves the messages in a safe place.
The customer I helped today had a different scenario involving separate production and development forests. Dependent clients were used because it allowed applications to be written locally in the development environment that would effectively run in the production environment without being deployed there before they were finished. I expect there were other cost, security and administration considerations that helped make this choice too. I'm not saying it's the best approach but I did find it interesting.
I became involved because the Windows 2000 dependent clients were being replaced by Windows XP installations (I'm reasonably sure dependent clients don't exist in Windows Vista/Windows 7) and there were issues with the upgrade process.
The first problem was how to install the dependent client as this was no longer an option in the user interface.
The on-line help (Message Queuing, How to …, Install Message Queuing, Install dependent clients) documented that the (admittedly non-intuitive) method was to unselect the Local Storage component of MSMQ to force installation as a dependent client:
This allows you to specify the name of the Supporting Server and complete setup.
The second problem was that the Windows XP dependent clients, once installed, could not find the public queues that were used by the applications being developed. This was down to the move from the RPC protocol (MSMQ 2.0) to LDAP (MSMQ 3.0 and above) when querying Active Directory for such information. The Windows XP clients were talking LDAP to the local domain controllers in the development forest which had no information in directory services about the public queues in the production forest. The solution was to downagrade the functionality back to using RPC again by setting the EnableLocalUser registry value as documented here:
You cannot manage public queues that are created in a Windows NT 4.0 domain from a Windows XP computer
https://support.microsoft.com/kb/840146
So, years after these versions of MSMQ came out, I'm still learning new ways of doing things.