Skip to main content

Enable Trace on Dynamcis 365 on premise using PowerShell

Enable trace settings through Windows PowerShell
Note These changes made in Windows PowerShell do not update the Registry. These changes update the DeploymentProperties and ServerSettingsProperties tables in the MSCRM_CONFIG database.
Register the cmdlets
1.     Log in to the administrator account on your Microsoft Dynamics CRM server.
2.     In a Windows PowerShell window, type the following command:
Add-PSSnapin Microsoft.Crm.PowerShell

To obtain a list of the current settings, type the following command:
Get-CrmSetting TraceSettings

Set the trace settings
1.     Type the following command:
$setting = Get-CrmSetting TraceSettings
2.     Type the following command to enable tracing:
$setting.Enabled=$True
3.     Type the following command to set the trace settings:
Set-CrmSetting $setting
4.     Type the following command to get a current list of the trace settings:
Get-CrmSetting TraceSettings

To disable tracing through Windows PowerShell, follow these same steps, except use the following command in step 2:
$setting.Enabled=$False
Note The format of the example commands for each value should be as follows:

$setting.Enabled=$EnabledValue ($True or $False)

$setting.CallStack=$StackValue ($True or $False)

$setting.Categories="*:Verbose"

$setting.Directory="C:\Program Files\Microsoft Dynamics CRM\Trace"

$setting.FileSize=10

Registry entry locations

The Microsoft CRM server tracing registry entries are located in the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSCRM
The Microsoft CRM client for Outlook tracing registry entries are located in the following registry subkey:
HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\MSCRMClient
The Microsoft Dynamics CRM SSRS Data Connector tracing registry entries are located in the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSCRMBidsExtensions
The Microsoft CRM Data Migration Manager tracing registry entries are located in the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\DATA MIGRATION WIZARD


source
Labels:

Comments

Post a Comment

Popular posts from this blog

What is release, and what is a deployment?

T o understand the concepts and the technical implementation in many tools, you need to know how tool vendors define the difference between a release and a deployment. A  release  is a package or container containing a versioned set of artifacts specified in a release pipeline in your CI/CD process. It also includes a snapshot of all the information required to carry out all the tasks and activities in a release pipeline, such as: The stages or environments. The tasks for each one. The values of task parameters and variables. The release policies such as triggers, approvers, and release queuing options. On the other hand,  Deployment  is the action of running the tasks for one stage, which results in a tested and deployed application and other activities specified for that stage. Starting a release starts each deployment based on the settings and policies defined in the original release pipeline. There can be multiple deployments of each release, even for one stage. ...
Post a Comment
Read more

Considerations for deployment to stages

When you have a clear view of the different stages you'll deploy, you need to think about when you want to deploy to these stages.  Continuous Delivery is about deploying multiple times a day and can deploy on-demand. When we define our cadence, questions that we should ask ourselves are: Do we want to deploy our application? Do we want to deploy multiple times a day? Can we deploy to a stage? Is it used? A typical scenario we often see is continuous deployment during the development stage. Every new change ends up there once it's completed and builds. Deploying to the next phase doesn't always occur multiple times but only at night. When designing your release strategy, choose your triggers carefully and consider the required release cadence. Some things we need to take into consideration are: What is your target environment? Does one team use it, or do multiple teams use it? If a single team uses it, you can deploy it frequently. Otherwise, it would be best if you were a ...
Post a Comment
Read more

Explore Release Pipeline

A release pipeline takes artifacts and releases them through stages and finally into production. The first component in a release pipeline is an artifact: Artifacts can come from different sources. The most common source is a package from a build pipeline. Another commonly seen artifact source is, for example, source control. A manual trigger, where people start to release by hand. A scheduled trigger, where a release is triggered based on a specific time. A continuous deployment trigger, where another event triggers a release. For example, a completed build. Furthermore, a release pipeline has a trigger: the mechanism that starts a new release. A trigger can be: Another vital component of a release pipeline is stages or sometimes called environments. It's where the artifact will be eventually installed. You can have many stages (environments); part of the release strategy is finding the appropriate combination of stages. Another component of a release pipeline is approval. People ...
Post a Comment
Read more