Quantcast
Channel: Microsoft Dynamics 365 Community
Viewing all articles
Browse latest Browse all 13977

Deploy Dynamics CRM with PowerShell Part 2: Importing SLAs

$
0
0

Today's post is written by Ian Moore, a Developer at Sonoma Partners.

If your Dynamics CRM deployment includes Service Level Agreements, you have probably encountered the following error in the import log when importing solutions from a dev environment to a testing environment:

“You can't edit an active SLA. Deactivate the SLA, and then try editing it.”

clip_image002

This error occurs because your solution contains an SLA that is active in the current environment. Having an SLA in your solution can complicate imports if you forget to deactivate the SLA before starting, as the error will come at the end of the import process and you will have to start over. Thankfully we can use PowerShell to automatically deactivate any active SLAs and re-activate after importing an updated solution.

For this example we will use a simple solution that contains one SLA component, and try importing it into an organization that already has an active previous version of the SLA.

clip_image004

After getting a connection with Get-CrmConnection, we can query for active SLA’s with Get-CrmRecords in the org we will be importing to:

$crmOrg = Get-CrmConnection–InteractiveMode

# get any active SLAs in the org
$SLAresults = Get-CrmRecords-conn$crmOrg-Entitylogicalnamesla-Fieldsslaid, statecode, isdefault-FilterAttributestatecode-FilterOperator -eq -FilterValueActive

From here we can deactivate the SLAs with Set-CrmRecordState and import the solution:

# deactivate the active SLAs
$SLAresults['CrmRecords'] |% { Set-CrmRecordState-conn$crmOrg-CrmRecord$_-StateCodeDraft-StatusCodeDraft }

# import solution
Import-CrmSolution -conn $crmOrg-SolutionFilePathC:\Path\To\Solutions\CaseEnhancements.zip-ActivatePlugins -PublishChanges

With the SLAs in draft status, the solution should import successfully. Once it is completed, we can re-activate the SLAs. One catch to this process is that any SLA that was not marked as Default will not be restored when it is reactivated – so after reactivation we can use Set-CrmRecord to update the “Is Default” property as necessary.

# re-activate SLAs
$SLAresults['CrmRecords'] |% { Set-CrmRecordState -conn $crmOrg-CrmRecord$_-StateCodeActive-StatusCodeActive }

# update any default SLAs to be default again
$SLAresults['CrmRecords'] |
? { $_.isdefault -eq 'Yes' } |
% { Set-CrmRecord-conn$crmOrg-EntityLogicalNamesla -Id $_.slaid -Fields @{'isdefault'=$true} }

Now any SLAs should be restored to their original state, and the solution with SLA updates is imported and applied. Here is a sample script that shows the whole process:

Make sure to download the Microsoft.Xrm.Data.PowerShell module from GitHub at https://github.com/seanmcne/Microsoft.Xrm.Data.PowerShell and follow https://blogs.msdn.microsoft.com/crminthefield/ for updates to the module!


Viewing all articles
Browse latest Browse all 13977

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>