PowerShell and AlwaysOn – Gotcha – Exception setting "ConnectionString": "Keyword not supported: ‘applicationintent’."

Here is the an issue I saw come across an alias that is a gotcha!

I’m running into a problem connecting to an AlwaysOn read-intent secondary and I was wondering if someone could help me out.  I have the .Net Framework 4.5 installed and the newest SQL Client install for SQL Server 2012.  Running this command from the server where SQL Server 2012 is installed works fine:        


$conn=new-object System.Data.SqlClient.SQLConnection

$ConnectionString = "Server=tcp:AGL,1800;Database=Contoso;Integrated Security=SSPI"




However, as soon as I include the ApplicationIntent=ReadOnly switch, it fails.  I’m not sure how to specify that the SQL Native Client 11 should be used in the connection string (and not sure if I need to do such a thing. 

$conn=new-object System.Data.SqlClient.SQLConnection

$ConnectionString = "Server=tcp:AGL,1800;Database=Contoso;Integrated Security=SSPI;ApplicationIntent=ReadOnly"




Here is the error I receive, which is odd.  The casing in the error message is completely different than I specify.  Must be hard-coded somewhere.


Exception setting "ConnectionString": "Keyword not supported: 'applicationintent'."

At line:3 char:7

+ $conn. <<<< ConnectionString=$ConnectionString

    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException

    + FullyQualifiedErrorId : PropertyAssignmentException"


Answer: You have to use a version of PowerShell that loads the correct framework. 

You can execute the following PowerShell command to interrogate the version of CLR loaded: $PSVersionTable.CLRVersion

You can either:


Bob Dorr - Principal SQL Server Escalation Engineer

Comments (1)

  1. Antony says:

    I think the issue is that SqlConnection uses the .net framework sql provider, not sql native client. Instead, try using System.Data.OleDb.OleDbConnection (they implement the same interface, so you shouldn't have a problem using it instead of a SqlConnection), and specifying "Provider=SQLNCLI10.1;" as one of the connection string attributes.

    Works for me, anyway.

Skip to main content