Enabling MSMQ in Windows via PowerShell

First, let's start off by seeing which Windows features for MSMQ are available in your installation:

Get-WindowsOptionalFeature -Online | ? { $_.FeatureName -like '*msmq*' }

If you see a message like "Failed to load program with incorrect format", double check that you're running a 64-bit version of PowerShell if your machine is running a 64-bit version of Windows.

Then, let's enable the ones we actually need:

$packageResults = @(Get-WindowsOptionalFeature -Online | ? { $_.FeatureName -like '*msmq*' -and $_.State -ne 'Enabled' } | Enable-WindowsOptionalFeature -Online -All -NoRestart)

$packagesRequiringRestart = @($packageResults | ? { $_.RestartNeeded })

if ($packagesRequiringRestart.Count -gt 0)
{
    Restart-Computer
}

This script takes the packages with MSMQ in the name, enables them along with any requisite parent features and prevents restart during installation. Once complete, we check the results to see if any installations require a restart. If there are any that require a restart, we restart the computer. As with anything else in PowerShell, and IT in general, use judgement and critical thinking.

IMPORTANT: The Get-WindowsOptionalFeature cmdlet and associated module are part of the DISM module. This module is available built-in with Windows Server 2012 and up. In Windows 7 / Windows Server 2008, it's available as part of the Windows Assessment and Deployment Kit available here. Even though the page says the installer is for Windows 8.1, it works on Windows 7 / Server 2008

Journey to robust windows services: Service could not be installed. Verify that you have sufficient privileges to install system services

This is an annoying and almost entirely useless error. It can be caused by any number of things. However, in my case today, it was caused by the fact that the EventLog Source hadn't been created when I tried to install my Windows Service using the WiX installer that I had developed (which it turned out wasn't quite complete). Fortunately, WiX (at least as of 3.5) has built-in support for creating Windows Event Log sources as part of the installation process. Fortunately, I was able to rely on this article on stackoverflow.com to guide me through the process. The gist of the article:

1. Add the "http://schemas.microsoft.com/wix/UtilExtension" namespace to your .wxs file root XML element
2. Add a util:EventSource Log="Application" Name="MyServiceLogSourceName" EventMessageFile="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll" element to each component which requires an Event Log source
3. Problem solved

Journey to robust Windows Services

Because I have the need for it in several projects, I'm going to be working with Windows Services implemented with .NET quite a bit in the next little while. That said, I'd like to refer to some resources for working with Windows Services:

• The MSDN page on creating windows services
• The MSDN page on debugging a Windows Service
• The MSDN page on installing and uninstalling Windows Services

Also, there are some issues that I ran into while working on my first service. I had originally planned to expose a WCF endpoint through WS-HTTP, however, I can into an unpleasant exception when I tried to do so: AddressAccessDeniedException. Apparently, the cause of this is the fact that http bindings are reserved for processes run as administrators. Fool me once, shame on me. In light of that fact, I'm switching over to using net.tcp for my local Windows Service-hosted WCF service. I'll post more here as I learn it.

Adding the Network Service account to the permissions for a file/folder/registry key etc

I'm currently developing a Windows Service that's to be run under the Network Service account (owing to the fact that it requires substantial network access). I'm just starting to learn how to program Windows Services, so this is very new to me. I just started developing a simple service to start, and when I followed the instructions on this MSDN page, I was surprised when, after trying to start my service, I got the error 005: Permission denied. I later found out that I needed to give the network service account to the folder from which the service was running, i.e. the debug output folder of my project. Doing this isn't as simple as setting the permissions for other users. To add the network service account to the permissions list in Windows 7, do the following :

1. Right click on the folder containing the service you want to debug, and go to Properties
2. Go to the Security tab, and under the box marked "Group or user names", click on Edit ...
3. Under the window that pops up, you'll see another box marked "Group or user names". Underneath that box, click on Add ...
4. In the "Select Users or Groups" dialog that pops up, click on the Advanced... button at the bottom left.
5. In the advance "Select Users or Groups" dialog that pops up, click on Find Now to find all the users, groups and built in security principals.
6. Once the search results are populated, scroll down and select "NETWORK SERVICE" (not "NETWORK") and click on Ok, then Ok again in the Select Users or Groups dialog.
7. One you're back to the Permissions window, ensure that you give the Network Service account Full Control over the folder in the Permissions box, then click Ok.
8. Click Ok one last time to close the properties for your folder, and you're done.