Issue: Access is Denied Error for the Outlook Console

Are you receiving permission errors when trying to perform tasks within the Outlook Console? Please follow the steps below to troubleshoot this issue.

  • Please ensure you have the SCSM Console installed that matches the same version as the Management Server versions.
  • Ensure you are running the latest version of the OC MP imported with the corresponding add in installed. 
  • Enable logging. Some customers appear to have issues especially if they have setup queues in a certain way. There are some slight differences between committing new objects in the console vs the pure SDK outside of the console such as the OC uses so they see these differences.

One thing you can do is to enable commit debugging which requires the latest version available for download using this Registry DWORD value:

HKCU\Software\Cireson\SCSM Outlook Addin\DebugCommit=1

When you save this you probably won’t see the error with this set, however a log file will be created:

"%TEMP%\Cireson.Outlook.Console.log

It is likely a relationship fails to be set such as the file attached added by user relationship which is the usual suspect here.

Verify Permissions

One way to rule out queues and groups is to create a new user role based on the same role your users are currently in. Grant access to all queues and groups in this role and add a test user to it. Next, restart the console and try again. If the error goes away, it is related to your queue/group configuration. If the error persists, it is more than likely either:

  • The file attachment has user relationship
  • One of the reviewer relationships

You may adjust permissions using our Asset Management Permissions App tool found on the Cireson downloads page. This tool updates the ServiceManager ProfileOperationImplicitScope table and adds rows with IsCustomized=1.

Before running the tool run this query on the ServiceManager database:

select * from ProfileOperationImplicitScope where IsCustomized=1

If no rows are returned, you have no custom permissions. In this case, after running the tool then simply delete all rows where IsCustomized=1 to undo what the tool did if required.

If you do have existing custom permissions (which may actually be causing the problem) then save the output so you know which ones to remove if required.

Now that you have the current settings saved, run the tool and make the required changes to the permissions for your user roles. Here are a couple screenshots below of examples that have resolved this issue by updating these permissions:

 

Â