0

We are in the process of migrating an app from a Server 2008 set of servers to Server 2016, and since this app has ~75 private MSMQ queues, I wrote a very basic C# utility (just a console app) to get the list from our production server and recreate them on the new 2016 server via the following:

//connect to the specified server to pull all existings queues
var queues = MessageQueue.GetPrivateQueuesByMachine("[production server name]");

var acl = new AccessControlList();

acl.Add(new AccessControlEntry
{
    EntryType = AccessControlEntryType.Allow,
    GenericAccessRights = GenericAccessRights.All,
    StandardAccessRights = StandardAccessRights.All,
    Trustee = new Trustee("Everyone")
});

acl.Add(new AccessControlEntry
{
    EntryType = AccessControlEntryType.Allow,
    GenericAccessRights = GenericAccessRights.All,
    StandardAccessRights = StandardAccessRights.All,
    Trustee = new Trustee("Network Service")
});

foreach (var queue in queues)
{
    var newQueue = MessageQueue.Create($".\\{queue.QueueName}", true);
    newQueue.SetPermissions(acl);
    newQueue.Label = queue.QueueName;
}

When I start running our web app on the new server and execute an action that places a message on the queue, it fails with System.Messaging.MessageQueueException: Access to Message Queuing system is denied, despite the Everyone ACL entry that is confirmed added to the queue.

The really strange part I'm running into though, is if I delete the queue in question and recreate it manually on the server with the same Everyone has full control permissions, the code works successfully. I've compared the properties of an auto-generated queue to a manually created one and everything is 100% identical, so it makes zero sense why this would occur.

Any suggestions? I'm at a loss, but trying not to have to create all of these queues manually if I can avoid it.

Scott Salyer
  • 2,165
  • 7
  • 45
  • 82
  • 1
    Shot in the dark, I know for our setup "ANONYMOUS LOGON" is also required and is added by default with 'send' permission when you manually create the queue. Maybe that needs added to your programmatic implementation? – justsomeguy Mar 26 '19 at 20:05
  • 1
    For clarity, 'Everyone' only includes accounts that the PC can see (local security database, domain members, etc.). Any accounts from outside that area, such as those on machines in foreign domains or in workgroup mode require 'anonymous logon'. – John Breakwell Mar 27 '19 at 14:53
  • No luck with adding ANONYMOUS LOGON (it added, but didn't change anything), however, I did notice manually created queues don't actually have that on Server 2016 (though I remember seeing it in prior versions of Windows Server). Even stranger, I noticed the app pool in IIS on the server we're moving from is running under the context of what would be a local admin account (not domain admin, just a domain account associated with local admins), so I tried setting that up for now and still an access denied error. That really makes no sense. – Scott Salyer Mar 28 '19 at 14:26

1 Answers1

0

After a lot of back and forth testing, I reached out to Microsoft Support and one of their engineers has confirmed there's a bug of some kind on the .Net side with creating queues. We confirmed everything was identical, but the only time permissions worked was if the queue was created manually via the Computer Management snap-in. Creating it in code, regardless of permissions, caused it to not work correctly for multiple accounts.

Hopefully this helps anyone else trying to do this!

Scott Salyer
  • 2,165
  • 7
  • 45
  • 82