Windows Server 2008 R2 introduces a new feature in Active Directory, the Active Directory Recycle Bin. When MSMQ is installed on a domain-joined machine with the MSMQ directory integration feature installed, it makes use of Active Directory objects, particularly MSMQ configuration objects (objects named "msmq" which are children of computer objects) and public queue objects (which share the name of the public queue and are children of MSMQ configuration objects). We did some experimentation with the AD Recycle Bin and these objects recently and found some points which might be of interest to MSMQ administrators.
Our experimentation covered cases where an MSMQ configuration object or public queue object was deleted accidentally in AD. In you delete a public queue through MSMQ, or uninstall MSMQ on a machine, then you will end up with deleted AD objects, but recovering them from the AD Recycle Bin will not undo that. This is strictly about the case where something has happened in AD and you're trying to undo it, hopefully without affecting your running instances of MSMQ.
Before continuing, I suggest reading the AD Recycle Bin information at http://technet.microsoft.com/en-us/library/dd392261.aspx.
The first note is that part of the process of recovering an AD object from the AD Recycle Bin involves updating its distinguished name, and this property is protected on MSMQ AD objects, so you will need to change the security on the deleted object before you can recover it. Fortunately, this is relatively simple:
Of course, you will want to undo this security change once you have successfully performed the recovery.
The second note is that if an MSMQ configuration object is deleted and there were any public queues, you will have to recover all of the public queue objects individually. Start with the MSMQ configuration object, then continue with the public queue objects.
Now, let's consider what happens if a public queue object is accidentally deleted. You won't be able to see the queue in the MMC snapin anymore if you refresh, but any applications currently sending to that queue -- meaning they have an MSMQ handle to the queue which was opened for send -- will continue sending as though nothing had happened. Applications which try to open new handles to the queue may succeed if the local queue manager has a cached copy of the public queue object, otherwise they will fail.
In this situation, do NOT restart the MSMQ service which hosts the public queue whose AD object was deleted. If you can restore the public queue object, then the queue will be visible in the MMC snapin and all the messages in it will still be there, including those sent while the object was deleted. If the MSMQ service restarts while the public queue object is still deleted, then the messages in the queue will be disposed of. Messages for which deadlettering, journaling, or administrative NACKs were requested will be deadlettered, journaled, or NACKed as appropriate, so well-written applications should not experience any loss of messages.
If an MSMQ configuration is deleted, the situation is more complicated. All the public queue objects for public queues hosted on that instance of MSMQ are also deleted, with the effects discussed above. The MSMQ service itself will continue running, and if you can restore the objects quickly enough, there will be little disruption. If the MSMQ service restarts while the objects are still deleted, it will be able to perform operations with any private queues which may be configured. Even in this case, if you restore the objects, MSMQ can recover gracefully: the service will notice that the configuration object has reappeared and directory-integrate itself, and the public queues will reappear as their objects are restored.