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.
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.
Running Get-Command -module "Microsoft.Crm.PowerShell" will list all the CRM-related cmdlets that are now available.
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.
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"
Load a local $setting object with the CRM server's "TeamSettings" values.
Print the contents of the $setting object value to the local console window.
Update the MaxAutoCreatedAccessTeamsPerEntity attribute of the local $setting object to 5.
Update the server TeamSettings values from the local $setting object.
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.
#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.
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!