MSMQ and non-local storage

A number of companies make use of storage devices that are not physically attached to the machine using them, such as storage area networks (SAN) and network-attached storage (NAS), as well as more exotic geographically dispersed solutions.

The question is whether MSMQ can be used on these and the official answer is no.

This doesn't necessarily mean it won't work, though. As long as these SAN/NAS/wherever solutions support the standard file I/O API that MSMQ uses (WriteFile, flushViewOfFile, etc) then MSMQ is happy. Otherwise MSMQ will see any anomaly, such as a file I/O failure, and will exit. There is no code in MSMQ to deal with disk failure. It is the customer's responsibility to provide reliable fault tolerant hardware.

Comments (6)

  1. Nathan says:

    How does that fit in with the support of MSMQ in a clustered environment where SAN storage is the normal way of providing shared disk?

    Thanks for the blog by the way, really useful stuff.

  2. MSDN Archive says:

    Hi Nathan,

    That’s easy – if you have a MSMQ clustering problem that resists standard troubleshooting then you will be expected to reproduce it on a traditional MSCS system with local disks.

    Should it not reproduce in an environment that MSMQ was designed/tested on then you will be advised to contact the SAN provider for further support. If required, they can then engage Microsoft through support arrangements like TSANet.


    John Breakwell (MSFT)

  3. Nathan says:

    Thanks for that.

    Would be handy if the MS docs on the subject mentioned it, there are docs discussing MSCS on a SAN:

    And a doc discussing clustering of MSMQ

    Which doesn’t mention that MSMQ clustering can’t use SAN storage even though it is  supported with MSCS.

    Is there an official statement on this as I’ll have to update some documentation and review a proposal – going to be a bit more challenging if MS officially say it isn’t supported.


  4. MSDN Archive says:


    There won’t be anything that says MSMQ clustering can’t use SAN storage as that is not the case.

    The bottom line is that MSMQ uses the standard file IO API, both in the service (user mode code) and in the driver (kernel mode code).

    If these API calls behave correctly with a SAN, then MSMQ is OK. Microsoft hasn’t (and probably cannot) test MSMQ with each and every configuration of RAID, SAN, NAS or any other exotic storage system. That’s the reason Windows provides a standard API (like WriteFile, FlushViewOfFile, etc) to abstract the specific details of the disk hardware. If there are problems with this abstraction then MSMQ may fail, but then every other piece of software will fail too in these circumstances.

    Similarly, we don’t test MSMQ on all possible network adapters, firewalls, clusters, etc. If the hardware is on the HCL then you can use it. If MSMQ fails then we’ll have to support it although the support may be slow because we won’t be able to reproduce the problem in-house.

    The focus should be instead on the hardware vendor and how well their devices support the File I/O API.


    John Breakwell (MSFT)

  5. MSDN Archive says:

    A bit more digging on the subject:

    From MSDN

    "When flushing a memory-mapped file over a network, FlushViewOfFile guarantees that the data has been written from the local computer, but not that the data resides on the remote computer. The server can cache the data on the remote side. Therefore, FlushViewOfFile can return before the data has been physically written to disk. However, you can cause FlushViewOfFile to return only when the physical write is complete by specifying the FILE_FLAG_WRITE_THROUGH flag when you open the file with the CreateFile function."

    Does the storage vendor allow FILE_FLAG_WRITE_THROUGH to work as designed or is the data intercepted and cached somewhere instead for performance reasons?


    John Breakwell (MSFT)

  6. Nathan says:

    That clarifies it, ta – will look at the EMC specs.

    Thanks for your help.


Skip to main content