Welcome to MSDN Blogs Sign in | Join | Help

Microsoft Business Integration Road Show reaches Reading

An opportunity (aimed at IT decision makers) to learn more about Biztalk Server:

Microsoft Business Integration Road Show - Integrate, Automate and Simplify your business
December 2nd, 2009

Event Overview
"The global roadshow comes to Microsoft Reading to enable you to discover BizTalk Server 2009 and the Microsoft Application Platform.  Learn how these technologies enable you to integrate your business applications and data, automate your end-to-end business processes and simplify the ability for your employees to gain access to critical data and functionality."

(I would go but I'm on vacation that day.)

Posted by JohnBrea | 0 Comments
Filed under:

Free eBook download - "Introducing Windows Server 2008 R2"

Sadly no MSMQ 5.0 content but may still be of interest:
 

Download the Free MS Press eBook: 

Introducing Windows Server 2008 R2 

Blurb: "Introducing Windows Server 2008 R2, by Charlie Russel and Craig Zacker, is a great resource for learning about the new features of Windows Server 2008 R2 in the areas of virtualization, management, the Web application platform, scalability and reliability, and interoperability with Windows 7."

Download your free copy from Microsoft.com.

 

 

Oh, there's also a Haiku competition to help promote Windows Server 2008 R2 but unfortunately it's only open to residents of the United States.

Posted by JohnBrea | 0 Comments

Deleting MSMQ Queues with PowerShell

Here's a short blog post by Ivan Suhinin about deleting MSMQ queues with PowerShell:

Friday, 13 November 2009
Delete all MSMQ queues at some PC with PowerShell

Posted by JohnBrea | 0 Comments
Filed under: ,

MSMQ and Silverlight - pardon?

I was stalking the MSMQ topic on Twitter and found someone bemoaning the absence of MSMQ in Silverlight. This did cause me to reassess my (very limited) concept of what Silverlight actually was - a system for generating pretty graphical apps that competes with Adobe's Flash. Basically I found I had no idea what Silverlight could, or could not, do.

According to the Microsoft site, "Silverlight helps you create rich web applications that run on Mac OS, Windows, and Linux. Welcome to a new level of engaging, rich, safe, secure, and scalable cross-platform experience." and this helps to explain why MSMQ is not currently supported.

Bryant Likes on the Silverlight forum explained why quite succinctly:

MSMQ has a couple of issues that I think will prevent it from being accessible by Silverlight:

  1. MSMQ is Windows-only; Microsoft is trying to make Silverlight cross-platform.
  2. MSMQ takes quite a bit of code on the client. Silverlight is a 4MB download and I don't think there are plans to grow that size.
  3. Giving a browser application access to a service like MSMQ would also be a security risk and since users aren't very familiar with MSMQ (or at least not as familiar with them as files) it would be very hard to get them to understand what it is doing. Kind of hard to say "this application is trying to access the queue MyComputer\SomeMessageQueue, do you want to allow this access?".

You could try to implement something MSMQ-like using isolated storage by queuing up messages going out and storing incoming messages there before processing them. Not a perfect solution, but it works today.

I would add a 4th - On Windows, MSMQ is not installed by default and is not available on Windows XP Home.

I have, though, passed the suggestion onto the product groups to see what they think.

Posted by JohnBrea | 3 Comments
Filed under: ,

Which editions have full 64-bit support in BizTalk?

There are times when a table explains things so much better than just text.

From BizTalk Server 64-Bit Support:

Which versions of 64-bit Windows are supported?
All versions of BizTalk Server 2006 support 32-bit execution on Windows Server 2003 x64 (including R2) and Windows XP Professional x64 by using WOW64. Additionally, BizTalk Server 2006 Enterprise, Developer, Branch, and Evaluation Editions support native 64-bit execution on Windows Server 2003 x64 (including R2) and Windows XP Professional x64 by installing both 32-bit and 64-bit executables and providing configuration options to use either 32-bit or 64-bit modes. 

 which means:

Edition

32-bit execution by using WOW64

Native 64-bit execution

on Windows Server 2003 x64 (including R2) and Windows XP Professional x64

Branch

Yes

Yes

Developer

Yes

Yes

Enterprise

Yes

Yes

Evaluation

Yes

Yes

Standard

Yes

No

Here's the justification (that I've borrowed from an official response on one of Microsoft's forums):

"We consider 64-bit support an Enterprise Edition level feature that a customer would only select if they require faster messaging/orchestration processing or the larger addressable virtual memory of 64-bit mode for large BizTalk message mapping or other memory intensive operations. Because the Standard Edition is designed for small-to-medium environments, it is licensed to only run on a single BizTalk server with a maximum of two CPUs, maximum of five "BizTalk Applications", and a single message box. 64-bit support for the Standard Edition seemed counter-intuitive from a technical and licensing perspective. If the deployment scenario requires 64-bit hardware then it certainly requires BizTalk Enterprise as well. Standard edition is for single box only installations. Enterprise is also required for multi-box installs and for clustering."

Posted by JohnBrea | 0 Comments
Filed under: ,

Message Queuing Downlevel Client Support won't work with MSMQ error code 0xC00E1001

To test out a problem for a customer, I had to add a Windows 2000 server and MSMQ 2.0 to one of my domains. The installation of the Active Directory Integration portion failed as it could not contact the domain controller. The DC was definitely running but the "Message Queuing Downlevel Client Support" service, although set to Automatic, was failing to start which meant MSMQ was deaf to any 2.0 clients.

Event Type: Error
Event Source: MSMQ
Event Category: None
Event ID: 2035
Date:  02/11/2009
Time:  17:03:37
User:  N/A
Computer: DC4BTS
Description:
The Message Queuing service cannot start. The Active Directory interface cannot be initialized (Error: 0xc00e1001 in the downlevel client support service. See article 875530 at support.microsoft.com).

 The event description directs me to the following KB article:

875530 The installation of Microsoft Message Queuing 3.0 is not successful in a child domain when you use an Enterprise Administrator account

but unfortunately it was not relevant to my environment (only one domain in the forest).

First port of call was to see what the error code meant (in DSSVCERR.H): 

0xC00E1001 - MQDSSVC_ERROR_SETTING_NOT_FOUND

although that information wasn't startlingly useful as it doesn't say what setting it cannot find.

Next I had a look at the formatted output of the MSMQLOG.BIN error log and found something more revealing - "Failed to retrieve this site's information". So I was having site-specific problems.

Using the Active Directory Sites and Services snap-in, I could see that for some reason the domain controller's "MSMQ Settings" object was missing. Reinstalling MSMQ on the DC recreated the desired object and allowed Downlevel Client Support to start which in turn meant the Windows 2000 client was able to install properly.

 

Posted by JohnBrea | 0 Comments
Filed under: ,

How much load does MSMQ put on Active Directory?

I recently had a request from a customer who is planning on changing his MSMQ servers from workgroup mode to AD Integrated mode. They were looking for information and guidance on what kind of stress this would place on their AD Infrastructure. They have 20 queues, processing a total of 100,000 messages/day, with a 1MB average message size. I thought I would share my thoughts on this migration.

The first point to cover is what MSMQ uses Active Directory for and how it doesn't have to relate to delivering messages.

The usual analogy I use is to compare MSMQ to the telephone system. Imagine a table on which is a traditional telephone with a local directory listing next to it. To make a call, you can just dial the number (if you know it) or you can look it up in the book (if you don't). Additionally, you can use the directory listing to determine the location of the person you are calling - maybe it's a shop or someone that shares a common name. The actual connection to the person you are calling is made using the same method, independent of whether you looked the number up or not.

With MSMQ it is the same. You can either send a message directly to a destination queue or you can contact Directory Services for assistance or additional information. Once the destination has been determined, a point-to-point connection is made and the message delivered (unless you are using Routing Servers, of course).

To relate this to the original question, you can ignore message size and throughput as they do not have a corresponding Active Directory object. Even queues can be ignored to some extent as, although each may be represented by an object in Directory Services, they physically exist on the destination server itself and not a domain controller.

To determine the load on the Active Directory infrastructure, you need to instead look at the MSMQ-using applications you are running. For examples, do they make use of:

  • Addressing messages with Pathnames
  • Querying of queue properties
  • Querying of queue permissions
  • Message authentication
  • Message encryption

It is these sorts of operation that require access to Active Directory and which will generate load on the infrastructure. How much load there will be is difficult to say as it depends on how efficiently the applications have been coded. Test benchmarking will be the order of the day.

Note that an application initially designed to work on MSMQ in workgroup mode is unlikely to generate any extra load when ported to an AD-integrated environment as the code will not be making any calls to Directory Services.

To conclude, avoid contacting Directory Services unless you need the extra functionality provided as the calls are expensive.

  • If you know the machine and queue names, send the message DIRECT.
  • Use Negative Source Journaling and Dead Letter Queues instead of querying the queue's properties and permissions.
  • If you must use AD-Integration mode, remember MSMQ follows site (not domain) boundaries so ensure there are at least 2 domain controllers in every logical site where MSMQ clients exist.
Posted by JohnBrea | 0 Comments
Filed under:

TechEd Europe 2009 - Berlin here we come!

Only a few days to go before I'll be helping out on the "Ask The Experts" booths in Berlin.

If you are at the event then please pop by and say "hello" - you don't even need to have a question. :-)

During my free time I’ll be catching up on the BizTalk (plus WCF and Azure) sessions or trying out the Hands-On Labs.

The BizTalk sessions are as follows – ESB seems to be a subject that has been appearing a lot lately so INT306 should be worth at least an hour of your time.

Tuesday morning

INT205 Introducing the Microsoft Integration Server: BizTalk Server 2009

Optimising and automating business processes is a hot topic in today's market. In a struggling economy customers want to streamline operations and grow their business with less resources using seamless connectivity and automated business processes. This session gives an overview of BizTalk Server 2009 scenarios and capabilities. We also provide introduction to the enhancements and new features of the 2009 release and to the future roadmap.

Tuesday afternoon

INT04-IS Deep Dive with Microsoft BizTalk Server 2009 Development Platform

Take a deep dive into new features found in BizTalk Server 2009. We cover the deep integration with Microsoft Visual Studio Team System Team Foundation Server (TFS) and the new Application Lifecycle Management (ALM) experience. We look at the improvements in the BizTalk Project System and provide an overview of the new Visual Studio features, enhanced debugging support for various artifacts, as well as support for Unit Testing with Visual Studio Team Test and the new MSBuild support. This session is mainly demos and provides lots of tips to make you more productive with the new features in the BizTalk development platform.

Wednesday morning

INT306 Dynamic Messaging with Microsoft BizTalk Enterprise Service Bus (ESB)

As organisations look to Service Oriented Architectures to help them deliver flexible, agile, and responsive IT environments, the Enterprise Service Bus has emerged as a key architectural pattern to help achieve this goal. In this session we discuss the Microsoft BizTalk Enterprise Service Bus Toolkit (specifically the new version 2.0) and how it allows an organisation to build a dynamic, flexible, and practical ESB as part of the larger Service Oriented Infrastructure.

Thursday afternoon

INT401 Customising and Extending the WCF Adapters in Microsoft BizTalk Server

This session provides an introduction to BizTalk WCF adapters, and discusses extending the BizTalk WCF adapters with custom service/endpoint behaviours, message inspectors, and binding elements/channels.

Anytime

SOA26-HOL Microsoft BizTalk Server 2009: Building Your First BizTalk Solution

SOA27-HOL Microsoft BizTalk Server 2009: Managing Service Integration Using BizTalk Orchestrations

SOA28-HOL Microsoft BizTalk Server 2009: Processing and Routing Messages

SOA29-HOL Microsoft BizTalk Server 2009: Working with Messages

Posted by JohnBrea | 0 Comments
Filed under: ,

Host Integration Server 2009 Management Pack for SCOM 2007 is now available in the Management Pack catalogue

 

The Host Integration Server 2009 Management Pack for Operations Manager 2007 provides the capabilities for Operations Manager to discover and monitor the availability of Host Integration Server 2009 server components and applications. It includes availability monitors for the SNA Gateway, Application Integration, Data Integration, and Message Integration features. In addition to health monitoring capabilities, this management pack includes rules to generate alerts for critical conditions and views that enable near real-time diagnosis and resolution of detected issues.

 

The following features are new in this release of the Host Integration Server 2009 Management Pack:

·      Native support for System Center Operations Manager 2007 SP1 and R2 Releases

·         Health Monitoring for the following features

o    Data Integration

o    Message Integration – MSMQ-MQSeries Bridge

o    Transaction Integrator – Windows Initiated Processing (WIP)

 

Here is the link to download the pack from Microsoft.com.

MSMQ messages using HTTP just won't get delivered #17

If you are having trouble sending transactional messages from a Windows XP client, bear in mind that the format of the Mapping file you have created is going to be different from that used in later operating systems.

The differences are discussed in Message Queuing HTTP Deployment Scenarios for Microsoft® Windows Server™ 2003 and Microsoft® Windows® XP Professional

and I've highlighted the particular content in a table as follows:

Scenario 1: External Client Sending Transactional and Nontransactional Messages to a Hidden Message Queuing Computer Behind a Firewall

Windows XP

<mapping host="localhost" xmlns="msmq-queue-mapping.xml">
 <queue>
  <name>http://OrderServer/msmq/private$/orderq</name>
  <alias>http://www.northwindtraders.com/msmq/orderq</alias>
 </queue>

Windows 2003 and above 

<redirections xmlns="msmq-queue-redirections.xml">
 <redirection>
  <from>http://www.northwindtraders.com/msmq/orderq</from>
  <to>http://OrderServer/msmq/private$/orderq</to>
 </redirection>
</redirections>

 

Scenario 3: Internal Client Sending a Transactional Message to the System Outside the Firewall

Windows XP

<mapping host="localhost" xmlns="msmq-queue-mapping.xml">
 <queue>
  <name>http://OrderServer/msmq/private$/order_queue$</name>
  <alias>http://www.northwindtraders.com/msmq/orderack</alias>
 </queue>
 

Windows 2003 and above

<StreamReceiptSetup xmlns="msmq-streamreceipt-mapping.xml">
 <setup>
  <LogicalAddress>http://172.31.201.101/msmq/private$/httpqt</LogicalAddress>
  <StreamReceiptURL>http://www.northwindtraders.com/msmq/OrderServer
</StreamReceiptURL>
 </setup>
</StreamReceiptSetup>

Posted by JohnBrea | 0 Comments
Filed under:

Troubleshooting MSMQ over HTTP - nothing in the web server log files?

If you are scratching your head because the files in the %windir%\system32\LogFiles\W3SVC1 directory have no entries for the incoming MSMQ messages then you need to tick two boxes:

  • Open up Computer Management
  • Navigate to:
    • Services and Applications
      • Internet Information Services (IIS) Manager
        • Web Sites
          • Default Web Site
  • Right-click the web site and choose Properties
    • On the Web Site tab, tick "Enable Logging" and press OK
  • Right-click the MSMQ application underneath the web site and choose Properties
    • On the Virtual Directory tab, tick "Log visits" and press OK

 

From the Help:

Log visits
Select to configure IIS to record visits to this directory in a log file.
Visits are recorded only if logging is enabled for this Web site.

You should now start getting POST entries in the IIS logs:

2009-10-21 16:30:53 W3SVC1 10.0.0.1 POST /msmq/private$/webqueue - 80 - 10.0.0.5 - 200 0 0
2009-10-21 16:30:53 W3SVC1 10.0.0.1 POST /msmq/private$/webqueue - 80 - 10.0.0.5 - 200 0 64

Error 0xC00E0033 when you try and install MSMQ with Active Directory Integration

As is the way, when I set up various tests with my trusty servers I bump into problems that haven't been documented before. The machines are used for many scenarios so have changed domain a few times and been upgraded every now and then. I know I should build fresh ones but the old virtual machies are handy...

Most recent issue arose when I tried to get a Windows 2008 client to install MSMQ with Active Directory Integration. The client would install in workgroup mode fine but could not create the necessary objects in directory services:

  • MSMQ Event 2116
    • "Message Queuing was unable to create the msmq (MSMQ Configuration) object in Active Directory Domain Services. Error c00e0033h: %2"
  • MSMQ event 2124
    • "The Message Queuing service failed to join the computer's domain 'TESTDOMAIN'. Error 0xc00e0033:"

0xc00e0033 means "MQ_ERROR_COMPUTER_DOES_NOT_SUPPORT_ENCRYPTION" 

In this particular case, the root cause was a couple of old machine key containers in the C:\Users\AllUsers\Microsoft\Crypto\RSA\MachineKeys directory. The containers are files with GUID-style names so I had to open then in Notepad one by one until I had located the ones that specifically mentioned MSMQ amongst the scrambled text.

Once I deleted these two files (and only these!) and restarted MSMQ, I was up and running with AD integration.

Posted by JohnBrea | 0 Comments
Filed under: ,

Setting storage quotas for multiple instances of MSMQ on a cluster

Microsoft Message Queuing is capable of handling a large volume of messages at any one time but this ability is not limitless. The performance of any machine, no matter the specification, will degrade eventually and to prevent this it is recommended to make use of storage limits (also known as system quotas). Default values are usually 1GB but it is advisable to review your needs and raise (or lower) the value as appropriate.

There are two ways of setting the storage limit, depending on how MSMQ was installed.

  • Active Directory integrated mode - use either the 'Computer Management' or the 'Active Directory: Users and Computers' snapin
  • Worksgroup mode - use RegEdit.exe to edit the registry

Active Directory integrated mode  

Here is an example of setting the storage limit for the clustered MSMQ resource that uses the network name "VirtualMSMQ"; MSMQ was installed in Active Directory integrated mode so changes need to be made to the msmq child object:

  1. Run the 'Active Directory: Users and Computers' snapin
  2. On the View menu, select 'Advanced Features' and 'Users, Groups and Computers as containers'
  3. Drill down to the network name used by the clustered MSMQ resource
  4. Right-click on the msmq folder below it and select Properties
  5. Enter a value (in kilobytes) for the new storage limit
  6. Press OK

 

Workgroup mode

There is no user interface to set the storate limits if MSMQ has been installed in workgroup mode and it is necessary to edit the registry and change MachineQuota.

Here is an example of setting the storage limit for the clustered MSMQ resource called 'MSMQ Service':

  1. Run REGEDIT.EXE
  2. Navigate to HKey_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Clustered QMs\MSMQ$MSMQ Service\Parameters\MachineCache
  3. Double-click the MachineQuota registry value
  4. Change the 'Value data' to the required storage limit
  5. Press OK

Here is an example of setting the storage limit for the local node's MSMQ service: 
  1. Run REGEDIT.EXE
  2. Navigate to HKey_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\MachineCache
  3. Double-click the MachineQuota registry value
  4. Change the 'Value data' to the required storage limit
  5. Press OK

 

Note that the service will need to be restarted for any changes to take effect.

 

References

899612  How to set up computer quotas and queue quotas in Microsoft Message Queuing

Posted by JohnBrea | 0 Comments
Filed under:

Dependent clients still good past their sell-by dates

Sharing an interesting support case that I resolved today.

Dependent clients are not a common MSMQ installation type for a number of reasons. Mainly people don't know they exist but also support for them has been reduced in recent versions of MSMQ).

An example scenario where dependent clients are useful could be as follows:

A dangerous environment has computerised sensors which use MSMQ for data handling.
Independent clients would not be a good choice as messages on the local hard disk could be lost should the sensor be destroyed.
Dependent clients would be better as messages are created and manipulated on the remote server so losing the client leaves the messages in a safe place.

The customer I helped today had a different scenario involving separate production and development forests. Dependent clients were used because it allowed applications to be written locally in the development environment that would effectively run in the production environment without being deployed there before they were finished. I expect there were other cost, security and administration considerations that helped make this choice too. I'm not saying it's the best approach but I did find it interesting.

I became involved because the Windows 2000 dependent clients were being replaced by Windows XP installations (I'm reasonably sure dependent clients don't exist in Windows Vista/Windows 7) and there were issues with the upgrade process.

The first problem was how to install the dependent client as this was no longer an option in the user interface.

The on-line help (Message Queuing, How to …, Install Message Queuing, Install dependent clients) documented that the (admittedly non-intuitive) method was to unselect the Local Storage component of MSMQ to force installation as a dependent client:

This allows you to specify the name of the Supporting Server and complete setup.

The second problem was that the Windows XP dependent clients, once installed, could not find the public queues that were used by the applications being developed. This was down to the move from the RPC protocol (MSMQ 2.0) to LDAP (MSMQ 3.0 and above) when querying Active Directory for such information. The Windows XP clients were talking LDAP to the local domain controllers in the development forest which had no information in directory services about the public queues in the production forest. The solution was to downagrade the functionality back to using RPC again by setting the EnableLocalUser registry value as documented here:

You cannot manage public queues that are created in a Windows NT 4.0 domain from a Windows XP computer
http://support.microsoft.com/kb/840146

So, years after these versions of MSMQ came out, I'm still learning new ways of doing things.

Posted by JohnBrea | 0 Comments
Filed under: ,

How often does MSMQ crawl your forest?

MSMQ comes in two parts:

  1. The moving of messages from one place to another
  2. The mapping of where messages can be sent

For this blog post, I'm concentrating on the second.

If you have Active Directory-integrated clients then you will have a lot of information stored on the domain controllers to make them work.

For example, you may want to route messages from one side of your enterprise (or forest) to the other. This requires an understanding of the site topology and availability of routing servers between sender and destination. The MSMQ service will, at regular intervals, check the shape of the forest and update it's local information when required - basically lists of all the sites and the MSMQ servers within them.

There are four registry values to control this process.

These two contain the times of the next refresh of the Enterprise (or Forest) and Site lists (expressed as the number of 100 nanoseconds units since January 1, 1601):

and these two determine how frequently the lists are refreshed:

  • DSSiteListRefresh - the time interval, in hours, in which updating the current site's list of servers will take place; new time written to DSNextSiteListRefreshTime default value is 168 hours (7 days).
  • DSEnterpriseListRefresh - the time interval, in hours, in which updating the full sites / servers list will take place; new time written to DSNextEnterpriseListRefreshTime; default value is 672 hours (28 days).

Restarting the MSMQ service will NOT force a refresh - the DSNextSiteListRefreshTime and DSNextEnterpriseListRefreshTime registry values are used to maintain the "next refresh" times across a restart. Only if they are deleted will MSMQ perform a refresh the next time the service is restarted. The registry values will be recreated based on the DSSiteListRefresh and DSEnterpriseListRefresh values.

Before Windows 2000 sp2, these settings used to be governed by the single DSListRefresh registry value; this setting is now redundant.

In a large enterprise, there may be a lot of sites and servers to be returned to a requesting machine so any changes to DSSiteListRefresh and DSEnterpriseListRefresh should be made with caution. Increasing frequency puts more load on the domain controllers and generates increased network traffic.

If the list query fails, the MSMQ service will persist at regular intervals, as dictated by:

  • DSListRefreshErrorRetryInterval - the time interval, in minutes, in which the next update (retry) of either site or enterprise data will take place in case the current update failed;default value is 60 minutes.

There are a couple of related registry values which may (or may not) be of interest:

[[Edited October 20th, 2009]]

Note - DSNextEnterpriseListRefreshTime does not appear in the registry of MSMQ Routing Servers and is not used.

Posted by JohnBrea | 0 Comments
Filed under:
More Posts Next page »
 
Page view tracker