Yesterday I discussed changing the storage location for MSMQ. While testing out the user interface with Windows Server 2008 today, I found some strange messages that I thought I would share.

Here's the normal Storage tab that you expect to see on all versions of MSMQ - nothing new: 

I typed in "C:\msmqstorage" and OK, which created the following message box:

Obviously "Yes" is the correct choice. Strangely, Message Queuing then complained that the folder was "not located on a valid NTFS drive".

I know the drive is virtualised within Virtual Server 2005 but I'm sure it's not complaining about that so I continue by clicking "Yes". The next message box is to be expected so I clicked "Yes" again.

Everything was up and running successfully but I had a look at the Security for the new folder which MSMQ had created and secured for me:

There is no MSMQ user or group account listed in Computer Management as this is another type of special account - a Service Security Identifier. As the article says:

"This enables developers to control access to the objects a service uses, instead of relying on the use of the LocalSystem account to obtain access."

So MSMQ is given access to the Storage directory through the "NT SERVICE\MSMQ" Service SID.

To see what MSMQ would do with a directory that already existed, I created C:\storage4msmq using the defaults:

Changing the folders in the Storage tab generated the following warning:

This seems a bit tricky considering as it does not tell you how to set the security on the storage4msmq folder properly. The MSMQ service started up successfully none the less.

Normally, when setting permissions, you can type in a special account name, like "SYSTEM" or "ANONYMOUS LOGON", and get Windows to find it for you so it can be added to an Access Control List (ACL). In this case, though, MSMQ cannot be found and you will need to use command line tools like ICACLS.

icacls c:\storage4msmq /grant:r "BUILTIN\Administrators":(F)
icacls c:\storage4msmq /grant "NT SERVICE\MSMQ":(F)

Remember to back up the DACLS before tinkering.

[[Thanks to Joe Noyce for his assistance, and Jatin Zalavadia for testing]]