Remote Microsoft Dynamics CRM 2013 server administration with PowerShell

When Microsoft Dynamics CRM 2011 was released, the on-premise installation included a set of PowerShell cmdlets for administering configuration and deployments. While these were incredibly powerful, the out-of-the-box cmdlets only worked on the same server that was running CRM. In CRM 2013, these cmdlets have been updated to run from remote systems, so you can use them to administer your on-premise CRM 2013 deployments without needing to be logged on to the actual application server. In this post I will show you how to set up your local system to run the CRM 2013 PowerShell cmdlets and then walk you through an example scenario.

Setting up your system

First, you need to get files that contain the Microsoft.Crm.PowerShell cmdlets. If you have access to the CRM 2013 install media, you can find them in the "\server\amd64\PFiles\MSCRM\Tools" directory. If don't have the install media handy, you can find them in the "\Program Files\Microsoft Dynamics CRM\tools" directory on your CRM application server. You'll need to copy three files to your local system. They are:

  1. Microsoft.Crm.PowerShell.dll

  • Microsoft.Crm.PowerShell.dll-Help.xml
  • Microsoft.Crm.PowerShell.Strings.dll

    Once you copy these files to your system, make sure to unblock them by right-clicking on each file, then selecting properties->unblock. If you don't unblock them, you will not be able to load the cmdlets in a PowerShell console.

    After you've unblocked the files, open up a PowerShell console, navigate to the directory where you downloaded the Microsoft.Crm.PowerShell files and import the cmdlets to your session by executing the following: Import-Module .\Microsoft.Crm.PowerShell.dll.

    (Alternatively, you can register the Microsoft.Crm.PowerShell cmdlets on your local system with the Installutil.exe installer tool if you have Visual Studio or the Windows SDK installed. The syntax for that command is [directory-containing-installutil.exe]\installutil.exe ["directory-containing-cmdlets"]\Microsoft.Crm.PowerShell.dll. Then instead of using the Import-Module command to load the cmdlets, you will execute Add-PSSnapin "Microsoft.Crm.PowerShell" to load them in your PowerShell console.)

    Running Get-Command -module "Microsoft.Crm.PowerShell" will list all the CRM-related cmdlets that are now available.

    A real-world scenario

    Now that you have the Dynamics CRM cmdlets loaded, let's actually do something useful. A few weeks ago, I discussed the new Dynamics CRM 2013 access teams feature in a post on this blog. One default limitation on access teams is that CRM will only allow you to set up two auto-created access team templates per entity. Fortunately, this value can be changed with just a few lines of PowerShell scripting. In the following example, I will show you how to change the value from two to five.

    Setting up the server connection

    When using the CRM PowerShell cmdlets directly on the CRM application server, PowerShell uses the credentials of the logged-in user and assumes you want to use the local CRM deployment web service (DWS) by default. When working from a remote machine, however, PowerShell needs you to specify those values every time you execute a CRM cmdlet. While you could input the user credentials and DWS URL for every operation, I find it's easier to set variables at the beginning of my session and then reuse them. To populate a credential variable, run the following command: $mycred = Get-Credential

    This will open a prompt for you to supply your username and password. In my case I have a user named "lucas" who is a member of a domain called "lucas." After inputting your details and hitting "OK," you'll now be able to reuse the $mycred variable for the rest of the session.

    Setting the DWS URL is even easier because it's just a simple string variable assignment:$dwsurl = "https://URL-TO-YOUR-SERVER-HERE"

    Updating the CRM server

    After those variables are set up, now we can update the CRM configuration. The following PowerShell script will do the following:

    1. Load a local $setting object with the CRM server's "TeamSettings" values.
    2. Print the contents of the $setting object value to the local console window.
    3. Update the MaxAutoCreatedAccessTeamsPerEntity attribute of the local $setting object to 5.
    4. Update the server TeamSettings values from the local $setting object.
    5. Print the CRM server's TeamSettings values to the local console window to make sure the change was successful.
    #1. Load a local $setting object with the CRM server's "TeamSettings" values.
    $setting = Get-Crmsetting -settingtype teamsettings -credential $mycred -dwsserverurl $dwsurl
    #2. Print the contents of the $setting object value to the local console window.
    $setting
    #3. Update the MaxAutoCreatedAccessTeamsPerEntity attribute of the local $setting object to 5.
    $setting.MaxAutoCreatedAccessTeamsPerEntity = 5
    #4. Update the server TeamSettings values from the local $setting object.
    Set-Crmsetting -Setting $setting -credential $mycred -dwsserverurl $dwsurl
    #5. Print the CRM server's TeamSettings values to the local console window to make sure the change was successful.
    Get-Crmsetting -settingtype teamsettings -credential $mycred -dwsserverurl $dwsurl

    That’s all there is to it. The new CRM 2013 PowerShell cmdlets make it easier than ever before to administer your on-premise CRM deployments. Have you tried PowerShell for Dynamics CRM administration? If so, what did you think? Let us know in the comments!

    A version of this post was originally published on the HP Enterprise Services Application Services blog.