Enable diagnostic logging and Access to Portal error logs !!

Please refer the docs link on Portal Diagnostic / Error Logging.

If you are unable to enable diagnostic logging due to “incorrect connection string”, please create a container called “telemetry-logs” in the storage account. This is a workaround option for a known issue.

Please note, at this point there is a provision to configure Azure Storage using connection string and there is no options to use SAS Key.

References: https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/view-portal-error-log

Restrict ability to update other’s personal settings/option.

Ability to restrict ability to update other’s personal settings/option for out of the box roles is not available; In technical terms, option to set “Basic” level of access for “User Setting” privilege in any custom or out of the box Security role is not present. Current options are None, Local(BU level), Deep( Parent Child BU) or Global (Organization). And for most of the out of the security roles default privilege is set to Local(BU level).

Local(BU level) access level allows an users to change personal options/setting for other users using D365 SDK or community tools. Currently there are no means to block an user to update setting for other users if we would like to keep personal option setting enabled.

This is a security issue/gap and here is a scenario –

We need to keep Personal Options enabled to use set configurations for out of the box features and Outlook Email Tracking using server side sync is enabled for user A and User B. In current out of the box behavior, User A can change the “Email Filtering” settings to “All email messages” for User B who would like to keep the setting as Email messages in response to Dynamics 365 email” which may potentially sync other users outlook emails to CRM.

Stub User !!

Stub user are unlicensed user records in Dynamics 365. Stub user can’t be logged into the system unless CRM license is assigned. While assigning a CRM license, email address in the Active Directory should match the User Name field in system user entity for the stub user to avoid a duplicate stub user creation. Stub user are very useful as “placeholder” for complex data migration scenario from CRM on-prem / other application to CRM online. Stub user concept may help customer to delay (during data migration / development phase) the license purchasing unless actual users start using the application.

Once CRM license is assigned, stub user started working as a normal user (tested in version 9.01). Please note, Stub users are completely different from interactive users and disabled users, disabled users can consume a license, and can still be a part of Office 365 or Active Directory.

When a stub user is created the Salesperson security role is assigned in a Dynamics 365 Customer Engagement instance and the Common Data Service User security role is assigned in a PowerApps environment. There is no known way to remove that role or assign a new role to any stub users. If need comes to provide additional privileges on custom or other entities that are not part of salesperson role then you will need to modify the SalesPerson security role to have those permissions.

Stub users can be created via Excel import, Create or Create Requests methods of the SDK and SSIS or other utilities. Primarily used in data migration scenario where some users are no longer within the organization however, we still need to keep track of the original owner. For stub user created by and modified by values cannot be set.

NB: During Aug- Sep ‘2018, in some minor version(9.0.2.1087) of CRM 9.0, salesperson role was not getting assigned for any new stub users. This issue was resolved in minor version (9.0.2.1468 , Oct 2018).