You receive an error message when you use Business Intelligence Development Studio to build a SQL Server 2005 Integration Services package

When you use Business Intelligence Development Studio to build a Microsoft SQL Server 2005 Integration Services (SSIS) package, you may experience the following behavior:

• When you try to create a new connection manager for an Integration Services package, the SQL Native Client ODBC provider is not listed in the provider list.
• When you try to create a new connection manager for an Integration Services package, you receive the following error message:
  The connection type "OLEDB" specified for connection manager "{83ED4D5C-85E5-4E2E-A4B5-7CD48DD1B683}" is not recognized as a valid connection manager type. This error is returned when an attempt is made to create a connection manager for an unknown connection type. Check the spelling in the connection type name.
• When you open an Integration Services package that was already created, you receive the following error message:
  Error loading 'Package.dtsx' : The package failed to load due to error 0xC0010014 "One or more error occurred. There should be more specific errors preceding this one that explains the details of the errors. This message is used as a return value from functions that encounter errors." This occurs when CPackage::LoadFromXML fails.

This behavior occurs because the installation of a third-party application or of a third-party driver may incorrectly set up the permissions of the registry subkeys under the HKEY_LOCAL_MACHINE\Software\Classes\CLSID subtree. If the Component Category Manager encounters a registry key for which it does not have read permissions, it reports an access error and stops enumerating components. Therefore, the Component Category Manager cannot enumerate the SSIS components that have a CLSID that has incorrect permissions in the subtree.

Applications that are known to possibly cause this behavior are Lexmark printer drivers (Lexdrvx.dll) and Macromedia Flash. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

Service pack information

To resolve this problem, obtain the latest service pack for SQL Server 2005. For more information, click the following article number to view the article in the Microsoft Knowledge Base: Note In SQL Server 2005 Service Pack 1, SQL Server will correctly report the error as follows:
Even with the improved error message, you may still have to use the method in the "Workaround" section to help identify the problem registry keys and resolve the problem.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

To work around this behavior, follow these steps:

1. Log on as a user who is not a member of the Administrators group, or use the runas command.
2. Use the following C# code sample to identify the registry subkeys that have incorrect permissions.

   using System;
   
   using Microsoft.Win32;
   
    
   
   namespace CheckClsidPerm
   
   {
   
       class Program
   
       {
   
           static void Main(string[] args)
   
           {
   
               RegistryKey clsid = Registry.LocalMachine.OpenSubKey(@"Software\Classes\CLSID");
   
               string[] clsids = clsid.GetSubKeyNames();
   
               Console.WriteLine("found {0} keys", clsids.Length);
   
    
   
               foreach (string s in clsids)
   
               {
   
                   try
   
                   {
   
                       using(RegistryKey clsidKey = clsid.OpenSubKey(s))
   
                       {
   
                           using(RegistryKey ic = clsidKey.OpenSubKey("Implemented Categories"))
   
                           {
   
                           }
   
                       }
   
                   }
   
                   catch( Exception e )
   
                   {
   
                       Console.WriteLine("error while reading key {0}: {1}", s, e.Message);
   
                   }
   
               }            
   
           }
   
       }
   
   }
   
   

3. Compile and run this code. Notice that the security permissions on the registry keys that are reported by the program are incorrect. These security permissions prevent SSIS from enumerating SSIS components. You have to grant the Read permission to the Users group for these registry subkeys.

Notes

• You must restart the computer after you modify the registry for the changes to take effect.
• This workaround uses the code sample to test registry key access from the same permission context of non-Administrator users. This permission context is the common context for applications. Therefore, make sure that you execute the compiled version of the code sample as a user and not as a member of the Administrators group.

When you are logged on to a user account that is not a member of the Administrators group, you can use this C# code sample to identify the registry subkeys that have incorrect permissions. To do this, you can use the Runas command to run this C# code sample. For more information about how to use the Runas command, visit the following Microsoft Web site: To use this C# code sample, you must compile it first. To compile this C# code sample, you can use the C# compiler (Csc.exe) or Microsoft Visual Studio .NET.

This behavior is by design.

The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.