Saturday, February 21, 2015

Compiling OpenSSL, curl, and zlib on Windows

Getting these libraries compiled on Windows was surprisingly easy. Cross-platform support has come a long way. OpenSSL required the most setup. Both ActiveState Perl and NASM were necessary for the build process. Also, this assumes there is a temporary compile folder and then an install folder. The temporary compile folder in these examples has the version number afterward. The install folder is just the product name.

zlib
 mkdir \projects\zlib 
 mkdir \projects\zlib\bin
 mkdir \projects\zlib\include
 mkdir \projects\zlib\lib 
 cd \projects\zlib-1.2.8\  
 nmake /f .\win32\Makefile.msc  
 copy zlib.h ..\zlib\include
 copy zconf.h ..\zlib\include
 copy *.lib ..\zlib\lib  
 copy *.dll ..\zlib\bin  

curl
 cd \projects\curl-7.40.0\  
 nmake /f Makefile.vc mode=dll MACHINE=x86  
 move .\builds\libcurl-vc-x86-release-dll-ipv6-sspi-winssl ..\..\libcurl  

OpenSSL (static)
 cd \projects\openssl-1.0.2  
 perl Configure VC-WIN32 --prefix=c:/projects/openssl  
 .\ms\do_nasm  
 nmake -f .\ms\nt.mak  
 nmake -f .\ms\nt.mak test  
 nmake -f .\ms\nt.mak install  

OpenSSL (dll)
 cd \projects\openssl-1.0.2
 perl Configure VC-WIN32 --prefix=c:/projects/openssl  
 .\ms\do_nasm  
 nmake -f .\ms\ntdll.mak  
 nmake -f .\ms\ntdll.mak test  
 nmake -f .\ms\ntdll.mak install  

I may expand on this post. There are a few other libraries that I'd like to use and keeping instructions in one place seems like a good idea.

Friday, February 20, 2015

Problems using the Command Line Install on SQL Server 2014 Express

The installation sets for SQL Server Express are actually wrapper executable, which basically means they are large zip files which contain the setup files. So, the first thing that happens after running it is that all the files are extracted to a temporary directory and then the Setup.exe is executed using the command line parameters passed to the wrapper.

Unfortunately, there are a few bugs in the wrapper executable for SQL Server 2014 RTM. These seem to be exclusive to SQL Server 2014 RTM, and according to Microsoft will be fixed in service pack 1. In previous versions of the SQL Server Express installation sets, the extract folder is randomly generated and the files are automatically extracted.

Because of this, you can run the wrapper in one of two ways.
  1. Using the same command line parameters as I used in SQL Server 2008 Express and 2012 Express, I am prompted for an extract folder. Once extracted, the Setup.exe is correctly executing using command line parameters passed to the executable. This has the down side of making completely automated installs impossible. 
  2. Using command line parameters exclusive to the wrapper, I can specify an extract folder. This has the down side of ignoring any other command line parameters. So, I'm going to have to extract the files and then run Setup.exe separately.
Command line parameters supported by the wrapper
  • /Q - Quiet mode. This is the same as Quiet mode for Setup.exe
  • /U - Progress Bar mode. This displays a progress bar as the files are extracted.
  • /X:<PATH> - The Extract Folder where the files are extracted. This last parameter has a few caveats. 
Extract Folder Parameter
  • The parameter must be the last parameter. Anything after that is considered part of the path.
  • The parameter must be followed by a colon and then followed by the path.
  • There must be no space between the X and the colon or the colon and the path.
What this means is that anyone wanting to automate the installation of SQL Server will need to first extract the files. Then, run Setup.exe separately.  Afterward, any temporary folder and files will need to be cleaned up.

While this isn't a huge burden for developers, it definitely qualifies as annoying. It did involve a couple of extra days worth of testing to make sure I covered all the bases.


Thursday, February 19, 2015

SSL/TLS Protocols Supported by Windows

I know I'm a bit slow out of the gate here. This post is coming much later than it should have. Anyway, I wanted to find a list of TLS/SSL protocols supported by Windows. Unfortunately, that statement is rather dubious.

It should be two separate questions. What protocols are supported by IIS; and what protocols are supported by Internet Explorer. The answer to the first is very simple.

IIS on Windows XP/2003/Vista/2008 support

  • SSL2
  • SSL3 
  • TLS1

IIS on Windows 7/2008R2/8/2012/8.1/2012R2 support

  • SSL2
  • SSL3
  • TLS1
  • TLS1.1
  • TLS1.2

If you are using IIS on an older version of Windows than 2003, please don't. Considering the number of vulnerabilities in IIS on Windows 2000 over the years and the fact that the OS is no longer supported in any way by Microsoft, you shouldn't even be it.

The answer to the second question is a little less simple because each version of Internet Explorer is built to run on multiple versions of Windows. So, it's more along a combination of the version of Windows plus the version of Internet Explorer.

A full comprehensive table is listed on Wikipedia of all browsers with helpful references to vulnerabilities and how those browsers are affected by them. The best situation for Internet Explorer users is using Internet Explorer 11 on Windows 8.1. Users of Internet Explorer 8 (or greater) on Windows 7 (or greater) can get just as secure a setup as those on IE11/Win8.1 by making a few option changes.

References

Monday, January 19, 2015

SQL Server Driver Versions, According to MS-TDS

While playing around with Wireshark and MS-TDS, I had a chance to see the different version numbers being sent to the server by the various SQL Server drivers. I thought this might give some insight into determining how compatibility is determined. It didn't, but I thought I would share what the versions being sent by the client actually are.

SQL Server (SQLSRV32.DLL) on Windows Vista SP2 
Hex: 0x08,0x00,0x01,0x55
Parsed: 08.00.341
Product Version (on the dll): 6.0.6002.18005

Hex: 0x09,0x00,0x0b,0xe2
Parsed: 09.00.3042
Product Version (on the dll): 9.0.3042.0

SQL Native Client 10 (SQLNCLI10.DLL) for SQL Server 2008 R2 SP3
Hex: 0x00,0x2e,0x00,0x00
Parsed: 00.46.0000
Product Version (on the dll): 10.50.6000.34

SQL Native Client 11 (SQLNCLI11.DLL) for SQL Server 2012 SP1
Hex: 0x0b,0x00,0x0b,0xb8
Parsed: 11.00.3000
Product Version (on the dll): 11.0.3000.0

Hex: 0x0b,0x00,0x08,0xde
Parsed: 11.00.2270
Product Version (on the dll): 11.0.2270.0

For the most part, the version numbers match up with the "Product Version" on the dll, except the built-in SQL Server driver and SQL Native Client 10.

The built-in SQL Server driver is a holdover from the old days of MDAC, where you had to manually install drivers onto Windows to get connected. Starting with Windows Vista, the built-in SQL Server driver truly became built into the OS. From that point forward, the Product Version on the dll would always match the OS.

With the SQL Native Client 10, I have no idea what's going on there. Considering the version number sent by SQL Native Client 10, I can only assume that the SQL Server ignores the version number being sent and that other features determine compatibility. Perhaps compatibility is left strictly to the client. On the client side, I'm guessing that drivers make a number of assumptions based on the server version being sent back as well as various function calls, like the ODBC SQLGetTypeInfo, SQLGetFunctions, and SQLGetInfo functions.

I think I've been nerd sniped again.

Wednesday, January 14, 2015

Making something useful out of the MS-TDS PRELOGIN packet (SQLPing)

I've been playing around with the low level SQL Server network protocols. These are officially known as [MS-TDS] Tabular Data Stream Protocol and [MC-SQLR] SQL Server Resolution Protocol and are fully documented on the Microsoft Protocols web site. Unfortunately, like every other protocol and RFC I've ever read, comprehension is not easy.

This interest mainly comes from wanting to understand the SQLPing utility written by Chip Andrews. To put is simply, SQLPing nerd sniped me. I've known about and used this little utility on a number of occasions, but I never had the chance to dig into it. After playing with the code and reading over the protocol, I wanted to share and translate tech-speak into something human friendly. This particular post is going to cover the PRELOGIN message in MS-TDS. I'll cover MC-SQLR in a separate post.

The SQL Handshake

When connecting to a SQL Server, the first thing that happens after connecting is a PRELOGIN exchange. This happens before any authentication or encryption. It's a knock on the door, which allows the SQL Server and the client to check each other out to see if they are compatible with each other. If the SQL Server can't understand what you send, it kills the connection right then and there - long before any authentication is attempted.

After a successful PRELOGIN, the client can attempt a second PRELOGIN for wrapping a SSL/TLS handshake to start encrypting the connection. Regardless, after the PRELOGIN, the connection is authenticated using LOGIN7. Finally, if everything has been successful, the client can begin to execute SQL statements.

Microsoft was kind enough to provide a flowchart, as well, for anyone interested in how the connection is fully negotiated.

The PRELOGIN Request & Response

The structure of the packet is a fairly simple binary format. It can be broken down into three main parts. First the packet header, next the token list, and finally the token data. The tokens are data containing a combination of compatibility and debug information.

One of those tokens is a version numbers. For the client, the driver version is sent. For the server, the product version is returned. In fact, besides the underlying packet structure, the version is the minimum amount of information that must be sent between client and server.

Here is a bare-bones example of a PRELOGIN request packet in CSharp. It contains the minimum amount of information required to get a response from the server.

var request = new byte[]
{
    // Start Packet Header      // 0x00 - 0x08
    0x12,                       // PRELOGIN packet header
    0x01,                       // Status (EOM) (last packet in message)
    0x00,0x14,                  // Packet Length (uint16)
    0x00,0x00,                  // Spid (uint16)
    0x00,                       // Packet (uint8)
    0x00,                       // Window (ignored; always 0x00)
    // End Packet Header
    // Start Token List         // 0x09 - 0x0e
    0x00,                       // VERSION token
    0x00,0x06,                  // Offset Position (from Start Data Header)
    0x00,0x06,                  // Data Length (uint32 + uint16)
    0xff,                       // TERMINATOR token
    // End Token List
    // Start Data Content       // 0x0f - 0x14
    0x08,0x00,0x01,0x55,        // UL_VERSION   (driver 8.00.341)
    0x00,0x00,                  // US_SUBBUILD  (always zero)
    // End Data Content
};

Likewise, here is a bare-bones example of a PRELOGIN response packet in C#. In fact, if you compare the request and the response packet, they contain the same structure and data, although the version numbers and packet type are different.

var response = new byte[]
{
    // Start Packet Header      // 0x00 - 0x08
    0x04,                       // PRELOGIN response packet header
    0x01,                       // Status (EOM) (last packet in message)
    0x00,0x14,                  // Packet Length (uint16)
    0x00,0x00,                  // Spid (uint16)
    0x01,                       // Packet (uint8)
    0x00,                       // Window (ignored; always 0x00)
    // End Packet Header
    // Start Token List         // 0x09 - 0x0e
    0x00,                       // VERSION token
    0x00,0x06,                  // Offset Position (from Start Data Header)
    0x00,0x06,                  // Data Length (uint32 + uint16)
    0xff,                       // TERMINATOR token
    // End Token List
    // Start Token Data         // 0x0f - 0x14
    0x0c, 0x00, 0x07, 0xd0,     // UL_VERSION (server version 12.00.2000)
    0x00, 0x00                  // US_SUBBUILD  (always zero)
    // End Token Data
};

The Packet Header

The packet header contains six pieces of information, stored in eight bytes.
  1. Type - The type of message being sent. In the case of PRELOGIN, the client will always send 0x12 (PRELOGIN) and the server will always send 0x04 (TABULAR RESULT).
  2. Status - The state of the message. In this case, both the client and server will always send 0x01 (EOM or end of message), meaning this is the last packet in the message.
  3. Length - The length of the packet - as an unsigned short - from the start of the packet header to the end of the token data.
  4. SPID - The session id for the connection - as an unsigned short. In this case, because a session id is not assigned until after authentication occurs, this will always be zero.
  5. PacketID - The index of the packet in the message. For messages spread across multiple packets, this would be incremented for each packet sent (mod 255). In this case, since we are only sending an receiving a single packet, this will always be zero. This is largely unused and can be ignored by always setting to zero.
  6. Window - Unused. This will always be zero.

The Token Header

The token header contains two or more tokens, as well as descriptive information about the tokens. For the PRELOGIN packet, there are a total of nine different tokens supported. Actually, it's probably better to say there are eight tokens and a TERMINATOR "token", which marks the end of the list of tokens. Besides the TERMINATOR, each token is followed by an offset and a length. The token itself is a single byte, while the offset and length are both unsigned shorts.

The offset contains the starting point in the packet body - ignoring the packet header - where the data is stored. In the example above, the VERSION data is stored at 0x0006, which is six bytes after the first token. I'm assuming this, but this would allow a more efficient coding in the network library by separating reading the packet header from the packet body. The packet header will always be eight bytes, while the remainder of the packet will vary.

Also, because the VERSION token is the first token in packet, the data will also be the first after the TERMINATOR. This makes the version fairly easy to find since it will be the first six bytes after the 0xFF.

The length contains the number of bytes used by the token data and can be zero. In the example above, the VERSION data occupies six bytes (0x0006) in the token data block.

  • VERSION - The version and the only required token, other than the terminator. For the client, this represents the driver version, while on the server, it represents the product version. The version is stored across as a unsigned long, followed by an unsigned short. More acccurately, it is stored in the form of major version (byte), minor version (byte), build (unsigned short), minor build (unsigned short, always 0x0000).
  • ENCRYPTION - Contains one of four values. This setting is used in the negotiation between the client and the server to determine if a SSL/TLS handshake will follow the PRELOGIN. In this case, the value is not important, but the best setting to use is ENCRYPT_OFF (0x00), since this will return the server's ENCRYPTION setting.
  • INSTOPT - For the client, this represents a NUL terminated string containing the instance name of the server. For the server, it is a booleaning representing a success (0x00) or failure (0x01) whether the instance name passed by the client matches the one on the server.
  • THREADID - An unsigned long used for debug purposes, representing the client application thread.
  • MARS - A boolean to enable or disable Multiple Active Result Sets. According to the people at FreeTDS, there is No Earthly Reason for MARS. I won't argue. It's not relevant for this discussion, anyway and only works on SQL Server 2005 or greater when using SQL Native Client drivers or the ODBC driver for SQL Server 11.
  • TRACEID - A 16 byte GUID, followed by a 20 byte Activity Id used for debug purposes. I have only seen this token when using SQL Native Client drivers. Again, not relevant for this discussion.
  • FEDAUTHREQUIRED - A boolean to enable (0x01) or disable (0x00) Federated Authentication. This is later used in the authentication process. I'm not sure what this is; but it's not relevant for this discussion.
  • NONCEOPT - A 32 bit nonce used with Federated Authentication.
  • TERMINATOR - A single byte containing 0xFF. This represents the end of the token header and the beginning of the token data. Unlike other tokens, it is not followed by an offset or a length.

Additional Examples

var response1 = new byte[]      // Four token response
{
    // Start Packet Header      // 0x00 - 0x08
    0x04,                       // PRELOGIN response packet header
    0x01,                       // Status (EOM) (last packet in message)
    0x00,0x25,                  // Packet Length (UInt16)
    0x00,0x00,                  // Spid (uint16)
    0x01,                       // Packet (uint8)
    0x00,                       // Window (ignored; always 0x00)
    // End Packet Header
    // Start Token List         // 0x09 - 0x14
    0x00,                       // VERSION token
    0x00,0x15,                  // Data Offset (UInt16) (from Start Data Header)
    0x00,0x06,                  // Data Length (UInt16)
    0x01,                       // ENCRYPTION token
    0x00,0x1b,                  // Data Offset
    0x00,0x01,                  // Data Length
    0x02,                       // INSTOPT token
    0x00,0x1c,                  // Data Offset
    0x00,0x01,                  // Data Length
    0x03,                       // THREADID token
    0x00,0x1d,                  // Data Offset
    0x00,0x00,                  // Data Length
    0xff,                       // TERMINATOR token
    // End Token List
    // Start Token Data         // 0x15 - 0x25
    0x08, 0x00, 0x07, 0xf7,     // UL_VERSION (08.00.2039)
    0x00, 0x00,                 // US_SUBBUILD  (always zero)
    0x00,                       // ENCRYPTION (ENCRYPT_OFF)
    0x00                        // INSTOPT (SUCCESS)
    // End Token Data
};

var response = new byte[]       // Five token response
{
    // Start Packet Header      // 0x00 - 0x08
    0x04,                       // PRELOGIN response packet header
    0x01,                       // Status (EOM) (last packet in message)
    0x00,0x30,                  // Packet Length (UInt16)
    0x00,0x00,                  // Spid (uint16)
    0x01,                       // Packet (uint8)
    0x00,                       // Window (ignored; always 0x00)
    // End Packet Header
    // Start Token List         // 0x09 - 0x26
    0x00,                       // VERSION token
    0x00,0x1f,                  // Data Offset (UInt16) (from Start Data Header)
    0x00,0x06,                  // Data Length (UInt16)
    0x01,                       // ENCRYPTION token
    0x00,0x25,                  // Data Offset
    0x00,0x01,                  // Data Length
    0x02,                       // INSTOPT token
    0x00,0x26,                  // Data Offset
    0x00,0x01,                  // Data Length
    0x03,                       // THREADID token
    0x00,0x27,                  // Data Offset
    0x00,0x00,                  // Data Length
    0x04,                       // MARS token
    0x00,0x27,                  // Data Offset
    0x00,0x01,                  // Data Length
    0x05,                       // TRACEID token
    0x00,0x28,                  // Data Offset
    0x00,0x00,                  // Data Length
    0xff,                       // TERMINATOR token
    // End Token List
    // Start Token Data         // 0x27 - 0x30
    0x0c, 0x00, 0x07, 0xd0,     // UL_VERSION (12.00.2000)
    0x00, 0x00,                 // US_SUBBUILD  (always zero)
    0x00,                       // ENCRYPTION (ENCRYPT_OFF)
    0x00,                       // INSTOPT (SUCCESS)
    0x00                        // MARS (OFF)
    // End Token Data
};

Example CSharp to Retrieve the SQL Product Version

On to the most useful bit in this post. The minimal set of code to retrieve the product version of the SQL Server. The only requirement is knowing the IP address and port for the SQL Server.

using System;                       // Exception
using System.Net;                   // IPAddress
using System.Net.Sockets;           // TcpClient, NetworkStream
namespace Example
{
    public static class SqlClient
    {
        public static Version Prelogin(IPAddress address, int port)
        {
            var data = new byte[]
            {
                // Start Packet Header      // 0x00 - 0x08
                0x12,                       // PRELOGIN packet header
                0x01,                       // Status (EOM) (last packet in message)
                0x00,0x14,                  // Packet Length (uint16)
                0x00,0x00,                  // Spid (uint16)
                0x00,                       // Packet (uint8)
                0x00,                       // Window (ignored; always 0x00)
                // End Packet Header
                // Start Data Header        // 0x09 - 0x0e
                0x00,                       // VERSION token
                0x00,0x06,                  // Offset Position (from Start Data Header)
                0x00,0x06,                  // Data Length (uint32 + uint16)
                0xff,                       // TERMINATOR token
                // End Data Header
                // Start Data Content       // 0x0f - 0x14
                0x08,0x00,0x01,0x55,        // UL_VERSION   (8.00.341)
                0x00,0x00,                  // US_SUBBUILD  (always zero)
                // End Data Content
            };
            using (var client = new TcpClient())
            {
                client.Connect(address, port);
                using (NetworkStream stream = client.GetStream())
                {
                    var bytesread = 0;
                    var bytespending = 0;
                    stream.Write(data, 0, data.Length);
                    // Read the response header
                    var responseheader = new byte[8];
                    bytesread = stream.Read(responseheader, 0, responseheader.Length);

                    // Double check to ensure the header contains useful data
                    if (bytesread != 8)
                        throw new Exception("A header must be 8 bytes.");
                    if (responseheader[0] != 0x04)
                        throw new Exception("A header must start with 0x04");

                    // Read the response body
                    bytespending = (responseheader[2] << 8) + responseheader[3] - 8;
                    var responsebody = new byte[bytespending];
                    bytesread = stream.Read(responsebody, 0, responsebody.Length);

                    // Double check to ensure the body contains useful data
                    if (bytesread != bytespending)
                        throw new Exception("The header bytes must match packet size.");
                    if (responsebody[0] != 0)
                        throw new Exception("The VERSION token must be the first token.");
                    var offset = (responsebody[1] << 8) + responsebody[2];
                    if (offset + 6 > bytesread)
                        throw new Exception("The VERSION data starts or ends after the packet.");
                    if (responsebody[3] != 0 || responsebody[4] != 6)
                        throw new Exception("The VERSION token must be 6 bytes long.");

                    return new Version(
                        responsebody[offset],
                        responsebody[offset + 1],
                        ((responsebody[offset + 2] << 8) + responsebody[offset + 3])
                    );
                }
            }
        }
    }
}

Update (January 19, 2015): Updated source code using some friendly code formatting.

Saturday, September 28, 2013

Virtual Machines, Snapshots and Domain Membership

I have a number of virtual machines that I use for QA. All of these machines have snapshots for easy rollback and all are members in an Active Directory (AD) domain. One of my goals has been to allow all the users in the domain to have administrative rights for these virtual machines, but getting that working has encountered a few hiccups.

Every once in a while, the domain membership breaks. When trying to log in with a domain login through RDP, I get an authentication error, specifically: The Local Security Authority cannot be contacted. When trying to log into the machine directly (through the vSphere Client) using the same domain login, I get a different a different - but also vague error: The trust relationship between this workstation and the primary domain failed.

The short and recommended answer is to rejoin the machine to the domain. This can be done in several creative ways in addition to Microsoft's recommendation, but it doesn't really solve the problem. Microsoft's article does give me a little more insight, though. "For Windows 2000 or Windows XP, the default computer account password change period is every 30 days." The article was written many, many moons ago, but this behavior hasn't changed with newer versions of Windows.

Roughly translated, every 30 days or so, a Windows machine that is part of a domain, renegotiates its connection to the domain. Basically, Windows changes its "machine password" on the domain controller. This new password is only known by the domain controller(s) and the machine. What this means for me is that every time I rollback one of my QA virtual machines, Windows loses its new password and goes back to using its previous password - the one created before the snapshot.

Considering these machines are going to be rolled back to a snapshot often, having to rejoin them to the domain after every rollback is not a viable option. A better solution would be to stop the trust from breaking in the first place. This is actually something I can accomplish pretty quickly thanks to the article Machine Account Password Process from the Ask the Directory Services Team blog.

Unlike Windows user passwords, machine passwords don't expire; they are entirely client driven - meaning the Windows machine itself decides whether to change the password or not. So, as long as no one messes up the Computer account in AD, as long as the machine doesn't change its machine password, we are good to go.

Thanks to that article, there are a couple of ways I can accomplish this, both of them through GPOs.


If you haven't read it and like knowing nitty-gritty details, I highly recommend reading the Machine Account Password Process article.

Friday, September 27, 2013

SQL Server 2012 Integration Services and DCOM Permissions

On my development machine, I noticed I was getting the same DistributedCOM error 28 times every 15 minutes.
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {FDC3723D-1588-4BA3-92D4-42C430735D7D} to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.
I'm not sure it is possible for this error to be any more cryptic. Luckily, I know a little about DCOM permissions. Roughly translated, there is a process calling a particular COM+ server (also known as a component). When that happens, the process fails to create/initialize the component because of a permissions error.

Debugging the Error

Based on the error, I know a couple of things. I know the process is a Windows service. Only Windows services can run under the Network Service (also known as "NT Authority\Network Service") user. I also know the GUID listed is the CLSID (also known as the Class ID) for the component.

Now, all COM security is configured from a little utility named dcomcnfg.exe. More specifically, the permissions I need to deal with are handled under the "DCOM Config" branch of the tree displayed in dcomcnfg.
Console Root -> Component Services -> Computers -> My Computer -> DCOM Config

So, a quick look at the listed components; and the CLSID can't be found. That's okay. Components can be listed in a variety of ways. The CLSID is only used as a last ditch effort if a more readable name is not stored for the component. To find the name for the component, I need to look it up in the registry under HKCR\CLSID, which gives me something much more useful.


Now I know that the COM+ server is named Microsoft.SqlServer.Dts.Server.DtsServer, and I know that this is definitely related to SQL Server - Data Transformation Services by the name. Switching back to dcomcnfg, the Microsoft.SqlServer.Dts.Server.DtsServer component is not listed either.

What else can the component be named? The registry key also displays an AppID GUID in addition to the component name. This represents the name of the process that hosts the component. Similarly to a component name, I can look up the application name in the registry under HKCR\AppID.


The process listed here is a Windows Service named MsDtsServer110, which is the short name for the SQL Server Integration Services 11.0 service. Switching back to dcomcnfg, the SQL Server Integration Services 11.0 component is listed. Perfect. Now all I have to do is configure it.

Fixing the Permissions

The steps listed here are very specific to my error but can easily be adapted to whatever component you need by replacing SQL Server Integration Services 11.0 with the appropriate application name, AppID or CLSID and replacing Network Service with the appropriate Windows user.
  1. In dcomcnfg, right-click on SQL Server Integration Services 11.0 and click on Properties.


  2. Change to the Security tab.
  3. Under Launch and Activation Permissions select Customize.


  4. Click [Edit] to display the Launch and Activation Permissions window.


  5. Click [Add] to open the Select Users or Groups window.


  6. Enter Network Service.
  7. Click [Check Names].
  8. Click [OK] to close the Select Users or Groups window.


  9. Select NETWORK SERVICE in the Group or user names list.
  10. Check the Local Launch and Local Activation permissions.
  11. Click [OK] to close the Launch and Activation Permissions window.
The error should now be resolved. For me, all I have to do is wait 15 minutes to see if the error is logged again. If your error can be duplicated another way, repeat those steps to see if you are still getting the error.

How did I get here?

Perhaps more important than all of this is, "why did I get this error in the first place?" The answer to that, in my case, is that I installed SQL Server 2012 and selected Network Service as the logon account for all the Windows services created by the installer. This is contrary to recommended practices, especially since the SQL Server 2012 installer has the ability to configure Windows accounts specifically for use by the Windows services it creates.

The short answer is that I shot myself in the foot because I didn't follow recommended security practices for the installation of SQL Server. Still, I would have thought that DCOM permissions would have been automatically configured for these components upon installation.

Regardless, it was relatively easy to fix, as long as I knew what DCOM was and how to deal with it.

Update (2013-09-28): Found another useful article for Troubleshooting DCOM and thought I would share.