Consider the following scenario:
- You have a SQL Server instance that is installed on a system that is running Windows Vista or later Operating System.
- On this instance of SQL Server you configure a linked server to an OLEDB data source using an OLEDB provider for the data source.
- The OLEDB provider is configured to be instantiated outside the SQL Server process. Usually this is the default for most of the OLEDB providers except SQL Native Client. This can be controlled by the Allow inprocess
option that can be set using the provider’s properties in SQL Server Mangement Studio.
- The linked server security is configured to use the be made using the login's current security context option.
In this scenario, if non-privileged users logs into the SQL Server instance using Windows authentication and try to access the linked server, they will experience an error message that is similar to the following:
Msg 7399, Level 16, State 1, Line 1
The OLE DB provider <OLEDB provider name> for linked server <Linked server name> reported an error. The provider did not give any information about the error.
Msg 7330, Level 16, State 2, Line 1
Cannot fetch a row from OLE DB provider <OLEDB provider name> for linked server.
Note: In this context a non-privileged user is a standard user who does not belong to a privileged access group at Windows level (for example: Administrators)
When an OLE DB provider is run out of process, the OLE DB Interface Remoting Dll (msdaps.dll) handles the communication between the proxy side process, in which OLE DB consumer resides, and the stub side process, in which OLE DB provider resides. In the current implementation. OLE DB Remoting uses named file mapping objects to transmit OLE DB rowset data. On systems running Vista or a later version of the operating system, the proxy side and the stub side are run in different sessions because of Session 0 isolation
and hence OLE DB Remoting must use a global for proxy-stub communication on these systems. However, since the user account does not have sufficient privileges to create a global file mapping object in the specified linked server configuration, the proxy-stub communication cannot be initiated resulting in error messages discussed in the Symptoms section of this article.
You can workaround the problem using either of the following methods:Workaround 1
: Configure the OLEDB provider to run in-process.
Note: You cannot use this workaround for OLEDB providers that are based on .Net versions that are earlier than 4.0.Workaround 2
:Assign the users the "Create global objects" user right. To do this, follow these steps:
- Click Start, point to Administrative Tools, and then click Local Security Policy.
- Expand Local Policies, and then click User Rights Assignment.
- In the right pane, double-click Create global objects.
- In the Local Security Policy Setting dialog box, click Add.
- In the Select Users or Group dialog box, click the user accounts that you want to add, click Add, and then click OK.
- Click OK.
: Microsoft is currently working on fixing this issue in a future release of the product.
for other considerations.