Share via

MSMQ and the Active Directory Recycle Bin

  • Article

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 https://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:

  • In the ldp.exe tool, once you have located in the tree the object you wish to recover, right-click on it, select Advanced in the menu, then select Security Descriptor.
  • Click on OK in the dialog that comes up.
  • In the next dialog, select the ACE which denies to Everyone "Write property(cn)". This will usually be the first ACE in the listbox.
  • Click the Edit ACE button.
  • In the dialog which comes up, click the Allow radio button, then OK. This changes the deny ACE to allow, temporarily giving Everyone permission to modify the distinguished name.
  • Click the Update button to actually change the security on the object in the directory.
  • Now you can follow the rest of the instructions to use ldp.exe to recover the object.

Of course, you will want to undo this security change once you have successfully performed the recovery.

  • Using the ADSIedit tool, which should be available from the Start menu under Administrative Tools, connect to the DC and drill down in the tree to the object which you recovered.
  • Right-click on the object and select Properties.
  • Switch to the Security tab and click the Advanced button.
  • Select the ACE which allows Everyone, which will usually be the first ACE in the listbox, and click the Edit button.
  • Switch to the Properties tab.
  • Scroll down in the list of permissions to "Write cn". There will be a checked box in the Allow column. Click on the box in the Deny column.
  • OK out of the dialogs. You will see a warning about setting a deny ACE, click Yes.

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.

Comments