Using Impersonation in Dynamics CRM

While you can’t log in as another through the Dynamics CRM front  end, as a System Administrator it is possible to impersonate another user when making calls to the CRM API.

This is very useful if you want to be able to do the following:

  • Test the correct implementation of security roles.
  • Check which records can be seen by which users if sharing is being used.
  • Search for charts or views belonging to different users.

For example, if you have complex security rules involving automatic sharing of records with certain privileges, this can be very time-consuming to test through the CRM front end. Writing an integration test where a record is created by one user, and then the permissions on this record can be immediately checked for another user, is very simple using impersonation.

As another example, we recently had a support issue where a team were all using a personal view created by one of the team. A few of the team were on holiday and no-one knew who had originally created the view. It was straightforward to cycle through a list of users in a particular team and list the personal views to which they had access and who the views were created by. This information is not readily accessible through the front end, nor through the API without being able to switch users, but using impersonation it was very easy to retrieve the information needed.

Here is an example which works in LINQPad but which you can easily amend to work in a Visual Studio project. The line in which we switch caller id is highlighted.

This sample shows how you can change the callerid of the organisation service proxy
allowing you to impersonate different users
void Main()
	// Log in with system administrator account
	var orgService = ConnectToCrm(Util.GetPassword("dev org service url"));

	// Display name of currently logged in user
	WhoAmIResponse whoami = (WhoAmIResponse)orgService.Execute(new WhoAmIRequest());
	Entity u = orgService.Retrieve("systemuser",whoami.UserId, new ColumnSet("fullname"));
	Console.WriteLine("Current user is " + u["fullname"]);
	// Create an account and display the user who created it

	// Get the user details of a different user
    string username = Util.GetPassword("myusername");
	Entity user = GetUser(orgService, username);
	// Switch the Caller ID to that user
	Console.WriteLine("Switching caller id to " + username);
    orgService.CallerId = user.Id;

	// Create an account and display the user who created it

private void CreateAccountAndShowWhoCreatedIt(OrganizationServiceProxy orgService)
	Entity account = new Entity("account");
	Guid accountId = orgService.Create(account);
	account = orgService.Retrieve("account", accountId, new ColumnSet("createdby"));
	Console.WriteLine("Account record was created by " + ((EntityReference)account["createdby"]).Name);	

private static OrganizationServiceProxy ConnectToCrm(string uri)
	string UserName = Util.GetPassword("sysopsuser");
	string Password = Util.GetPassword("sysopspassword");

	AuthenticationCredentials clientCredentials = new AuthenticationCredentials();
	clientCredentials.ClientCredentials.UserName.UserName = UserName;
	clientCredentials.ClientCredentials.UserName.Password = Password;

	OrganizationServiceProxy serviceProxy = new OrganizationServiceProxy(new Uri(uri), null, clientCredentials.ClientCredentials, null);

	Console.WriteLine("Connected to " + serviceProxy.ServiceConfiguration.ServiceEndpoints.First().Value.Address.Uri);

	return serviceProxy;

public static Entity GetUser(OrganizationServiceProxy orgService, string domainName)
	QueryExpression queryUser = new QueryExpression
		EntityName = "systemuser",
		ColumnSet = new ColumnSet("systemuserid", "businessunitid", "domainname"),
		Criteria = new FilterExpression
			Conditions =
						new ConditionExpression
							AttributeName = "domainname",
							Operator = ConditionOperator.Equal,
							Values = {domainName}

	EntityCollection results = orgService.RetrieveMultiple(queryUser);
	return results.Entities[0];

Here is a LINQPad script of the above code.

For fairly obvious reasons, it is not possible to change the caller id to that of a user who is disabled, or to a user who has no security roles. Such a user would not be able to make any API calls, so there would be no point in doing so anyway.

Posted in Dynamics CRM, LINQPad | Tagged , | 2 Comments

Integrating LINQPad scripts into Source Control

Whilst there is no built-in source control integration in LINQPad, it is still easy to keep your LINQPad scripts under source control. This means that scripts can easily be shared amongst your team and you can take full advantage of the benefits of source control, such as versioning and safe file storage in an external repository.

As an example I will show you how we have integrated LINQPad scripts into our Visual Studio Team Services code repository – the same pattern should work equally well for other source control systems.

First of all, create a folder within your VCS which will hold your LINQPad scripts. We have a folder called LINQPad queries with sub-folders for different projects and another folder for useful samples. Once you have created that folder, you can link that folder location on your computer to the ‘My Queries’ folder in LINQPad by clicking on the ‘Set Folder…’ link…

… and then selecting this as your custom location for queries:

Now that your LINQPad queries folder is under source control, any changes you make will be flagged as Pending Changes in Visual Studio, and you can add new files to the repository using the Source Control Explorer in Visual Studio.

If your team all map their ‘My Queries’ folder to the same location, then all files in the repository become shared with the team.

You can avoid uploading passwords and other sensitive information in your scripts by using the Util.GetPassword method, as explained in this blog post.

PS If you just want to share LINQPad scripts with other users without putting them into source control, LINQPad has a feature called Instant Share which allows you to upload a file to a repository on the LINQPad server – you will then be given a URL of the uploaded file which you can share with colleagues or post on your blog, like this script which shows you how to generate a PDF in LINQPad.

Posted in LINQPad | Tagged | Leave a comment

Creating snippets for use with LINQPad

LINQPad automatically makes available any snippets which are configured in Visual Studio. For example, if you type ‘cw’ (for Console.Writeline), LINQPad will inform you that it is aware of the snippet and prompt you to press Tab to insert the snippet at the cursor.

It is also possible to create your own snippets in LINQPad, giving you quick access to blocks of code which you need regular access to.

For example, take a look at the script below. This is the bare minimum which you might need to connect to CRM from LINQPad without using the CRM Driver for LINQPad, as described in this post.

Turning the ‘ConnectToCrm’ method into a snippet for reuse in other scripts could not be easier. Select the code that you want to turn into a snippet (in this case the ‘ConnectToCrm’ method).

Press ‘F4’ to access the Query Properties and then press ‘Save as snippet…’. The Create Snippet dialogue box appears:

Make sure that you tick the ‘Code’ tickbox. Click Next and save the snippet in the suggested location with a sensible name (such as ‘ConnectToCRM’).

LINQPad will confirm that your snippet has been saved.

In a new c# program script, your snippet will be available to use:

Press tab to insert the snippet and F5 to run the script:

Your script should automatically contain the right references and run without any problems.

Posted in LINQPad | Tagged | Leave a comment

Connecting LINQPad to Dynamics CRM using a manually created connection

In the first article in this series, I demonstrated how to use the Dynamics CRM LINQPad Driver to connect LINQPad to CRM. In this follow-up I will show how to create a ‘manual’ connection, and why you might want to do this.

Create a basic ‘WhoAmI’ request in LINQPad without the CRM LINQPad driver.

Whilst the steps outlined below might seem laborious, you will only need to carry out the majority of these actions the first time you create a manual connection to CRM.

Create a new query in LINQPad and change the type to C# Program. You will see the following program template:

Replace the entire query with the following code:

void Main()
	OrganizationServiceProxy orgSvc = ConnectToCrm();
	WhoAmIResponse whoResp = (WhoAmIResponse)orgSvc.Execute(new WhoAmIRequest());
	Entity user = orgSvc.Retrieve("systemuser", whoResp.UserId, new ColumnSet(true));
	Console.WriteLine("Name of logged in user: " + user["fullname"]);

private static OrganizationServiceProxy ConnectToCrm()
	AuthenticationCredentials clientCredentials = new AuthenticationCredentials();
	clientCredentials.ClientCredentials.UserName.UserName = "PUT YOUR USERNAME HERE"; 
	clientCredentials.ClientCredentials.UserName.Password = Util.GetPassword("mypassword");
	Uri OrgServiceURL = new Uri("This should be the URL of your organisation service");
	OrganizationServiceProxy serviceProxy = new OrganizationServiceProxy(OrgServiceURL, null, clientCredentials.ClientCredentials, null);
	Console.WriteLine("Connected to " + serviceProxy.ServiceConfiguration.ServiceEndpoints.First().Value.Address.Uri); return serviceProxy;

NB This example uses an internet facing on-premise connection to CRM 2015. You may need to adjust the code to make a connection to your own CRM organisation.

You will notice that certain elements in the code are highlighted red – this is an indication that the script is missing an assembly reference:

The way in which you deal with this will depend on whether you are using LINQPad Premium/Developer or the Free/Pro edition.

Importing assemblies using the NuGet package manager

The Premium and Developer editions offer full NuGet integration, so you can import the missing assemblies from NuGet. To import the missing assemblies, press F4 and then ‘Add NuGet’ to launch the LINQPad NuGet package manager (or press Ctrl+Shift+P to go to it directly). Search for Dynamics CRM to show a list of relevant assemblies – I tend to use the Dynamics CRM 2015 Clean SDK Assemblies, but you may use others depending on your version of CRM, etc.

Click ‘Add to Query’ for the assembly you wish to add:

Now press ‘Close’ and ‘OK’ to return to your query

Adding assemblies to your query manually

If you do not have the Developer or Pro editions of LINQPad you can still add the required assemblies to your query. Press F4 to launch the Query Properties window. Browse to the location of the assemblies you want to add (such as your SDK Bin folder) and select the assemblies you require – for this example you will only need Microsoft.Crm.Sdk.Proxy.dll and Microsoft.Xrm.Sdk.dll.

If you want these to be added by default for new queries, press the ‘Set as default for new queries’ button.

NB It is also possible to create a ‘Libraries’ folder in the same folder as the LINQPad executable. Any dll’s added to this folder will automatically get picked up by LINQPad.

Adding ‘using’ directives to your query

Regardless of the way in which you added assemblies to your query, you now need to add ‘Using’ directives to tell the query which assembly to use. You will notice that the lines which are highlighted red now have a little blue drop-down allowing you to either add a ‘using’ statement to the query, or to use a fully qualified class name:

Select the ‘using’ option and LINQPad will add an (invisible) using directive to the query. Repeat this for any other elements which are not yet bound to a using statement.

Once you have gone through this process, there will still be one unresolved reference. If you try and run the query you will get this error:

Hit F4. You will be asked if LINQPad should automatically add the missing reference:

Press “Yes, and add missing references automatically from now on”.

NB You only need to go through the above process once. Once you make the correct assemblies available to LINQPad, these will be available in other queries and the references will be automatically resolved.

NB2 You may also get an error saying that Microsoft.IdentityModel or one of it’s components cannot be found. To install Windows Identity Foundation on your machine, follow these steps:

Run the Query

Press ‘F5’ to run the query. The first time you do this you will be prompted to enter your password.

This is because we are calling the Util.GetPassword method. When you enter your password and select ‘Save Password’, your credentials will be stored by LINQPad’s password manager. This allows you to store credentials in encrypted format so that you do not have to store them as plain text in your query – this is particularly useful if you are sharing scripts amongst a team! Subsequent uses of the script will use your saved password without prompting. You can manage your passwords through ‘File -> Password Manager’.
After you have entered your password, the request should execute and you should see the results:

Why create a manual connection to CRM?

I would always advise you to use the LINQPad driver for CRM as it offers many advantages over the manual process outlined above. However, there are certain circumstances where you would want to connect to CRM without using the driver.

  1. You might want to be able to connect to more than one instance of CRM simultaneously. You might be wanting to do a comparison between data (or metadata) between two different CRM instances. With a manual connection you can connect to more than one Organization Service and query them both at the same time.
  2. If you are wanting to use impersonation in your query – it is possible to impersonate different users when making calls to the Organisation Service. It does not seem possible to do this when using the LINQPad driver.
  3. If you have an entity in your organisation which has the same name as a relationship, you will get an error such as “Cannot compile typed context: The type ‘Microsoft.Pfe.Xrm.ClassName’ already contains a definition for ‘entityName'” when connecting to CRM. This is a known issue and the only option here is the manual CRM connection.
  4. It seems as if the connector does not work with Dynamics 365. I have not been able to confirm this myself – if this is the case, you can try the LINQPad 4/5 Driver for Dynamics CRM Web API or create a manual connection.
Posted in Dynamics CRM, LINQPad | Tagged , | 1 Comment

Connecting LINQPad to Dynamics CRM using the Dynamics CRM LINQPad Driver

LINQPad is an invaluable tool for any .Net developer, and it will greatly enhance your ability to write and support applications using Dynamics CRM. There are two ways with which to connect to an instance of Microsoft Dynamics CRM using LINQPad. This two-part article will describe these two different methods and examine the reasons why you might choose one over the other.

Connecting to CRM using the Dynamics CRM LINQPad Driver

NB The CRM LINQPad driver works with CRM 2011 – 2017. It seems as if the connector does not work with Dynamics 365. I have not been able to confirm this myself – if this is the case, you can try the LINQPad 4/5 Driver for Dynamics CRM Web API or create a manual connection as described here.

The LINQPad Driver for Dynamics CRM has been developed by Microsoft’s Premier Field Engineering (PFE) team. It allows you to create a number of predefined connections to CRM, which you can then use in your LINQPad CRM scripts.

The LINQPad driver for Dynamics CRM can be downloaded here, and the (very easy) installation instructions are to be found here.

LINQPad connection definitions persists between sessions, so, providing your credentials do not change, you can use your predefined connections in all subsequent queries.

You can write and run code which utilises the Organisation Service of the connection you are using:

You can easily switch between organisations in your script by simply choosing from the list of available connections:

To help prevent you from accidentally running code against production which should not be run in production, you can mark individual connections as Production and they will display like this:

Not only can you write and execute code using the CRM Driver for LINQPad, you can also explore the entities within the organisation you are connected to:

and explore the composition of entities in detail:

The connector creates a set of Early Bound classes when it is initially set-up and it is therefore possible to write LINQ queries directly against these entities:

and the editor gives you full Intellisense on the entity:

In the second article in this series I will show you how you can manually create a connection to CRM in LINQPad and why you might wish to do this.

Posted in Dynamics CRM, LINQPad | Tagged , | 2 Comments