Overview

On this page, we discuss SCOM based advanced settings that you can use to modify how Connection Center works. Usually, there is just a registry component to this, however, sometimes there is a UI/console aspect as well.

If you are looking for tool-specific settings, you can find these on the child pages:

• Advanced ServiceNow Configuration - Post Processing
• Advanced ServiceNow Configuration - Advanced Creation Rules
• Advanced ServiceNow Configuration - Maintenance Mode
• Advanced Webhooks

Back to top

Proxy Configuration

There are a few different methods of enabling proxies depending on your requirements.

Per Connection Proxy

Per Management Server

If you need to configure your management server(s) to talk to different proxies (if they are based in different physical locations, for example) you can do this in a couple of different ways.

Using System Proxy Settings

Using Registry Values

You can also set the proxy to use with a Registry Value on individual management servers. This is mostly useful in scenarios where you want a single management server to use a different proxy connection. This is mainly covered under Server settings below.

Proxy Authentication

If your proxy requires authentication we provide you with a Run-As profile that you can use to pass credentials to your connections.

Set up and distribute a Run-As account to the relevant management servers in the same way as you did this for your main Run-As account(s) making sure to link your Run-As account to this Run-As Profile.

Back to top

Registry Values

Connection Center uses a number of different registry values to specify some of the more advanced settings you may wish to control. These, generally, fit into two broad categories Console and Server settings. Console settings typically control aspects of the SCOM console and the Connection Center UI. Server settings typically control the connections that you set up.

Here be dragons.

Server settings

Server settings are applied to the HKEY_LOCAL_MACHINE\Software hive via the key HKLM:\SOFTWARE\CookdownManagementPacks\ConnectionCenter

Console

Console settings can be applied to either the HKEY_LOCAL_MACHINE\Software or HKEY_CURRENT_USER hives. When using HKLM these settings are applied to all users of the machine, when using HKCU they are applied to only the current user. These are applied using the keys HKLM:\SOFTWARE\CookdownManagementPacks\ConnectionCenter and HKCU:\SOFTWARE\CookdownManagementPacks\ConnectionCenter respectively.

Both

There are some settings that effectively apply to both categories. Much like the console settings, these can be applied to either the HKEY_LOCAL_MACHINE\Software or HKEY_CURRENT_USER hives. When using HKLM these settings are applied to all users and processes of the machine, when using HKCU they are applied to only the current user.

Back to top

The Differences Between an Internal Connector and a Subscription

When you enable the AdvancedUi console option you are given the option to select either Connector or Subscription-based Outbound Notification connections via the 'Sourcing Method' tab.

Under the covers an internal connector and a subscription function virtually identically, however, there is one important difference in how they source their alerts and what this means for the alerts lifecycle.

Once an internal connector is assigned to an alert it remains attached to that alert for the rest of the alerts lifecycle and all changes to the alert are sent through the connector regardless of the initial criteria set.

However, only one connector can be assigned to each alert. If you are very careful with your criteria and ensure that they can never overlap, you can in theory have multiple connectors each serving a separate purpose. If there is any overlap between the criteria it can be unpredictable which connector will get assigned the alert.

Subscriptions are much more flexible with their overlap and can share alerts with connectors and other subscriptions allowing you to send the same alert to multiple destinations. However, they will only send alerts that match the criteria assigned to them at the point of evaluation. Where connectors only have to match the criteria at assignment, a subscription has to match the criteria throughout the life of the alert.

For example, let’s assume we have a common criterion assigned to both a connector and a subscription: All alerts that are not closed.

For our example an alert comes in ‘New’, is then set to ‘Assigned to Engineering', and finally the alert is ‘Closed’ when it has been resolved. The Connector will send all three states to the destination, the subscription will only send the first two. The final update sets the Resolution state to closed which then puts it out of the scope of the subscription.

If you are looking to exclude historical data for a subscription connection you might be better served using a 'Created after' criterion, or if using Inbound Notifications as well setting up a subscription for all alerts that have a ticket number set (or matching a specific format).

Connectors are also slower, but more resilient. If you have a slow-paced environment with an unreliable connection, a connector may be the better choice.

By default, Connection Center uses Subscription-based Outbound Notification connections, however, should you wish to use a connector-based connection you can once you have enabled the AdvancedUi console option.

Back to top

Telemetry

Overview

Cookdown collects telemetry data about Connection Center use to help us solve problems and keep everything operating smoothly. It also helps us plan upcoming features and product improvements based on real-world use, ensuring that Connection Center remains an effective tool in even the most rapidly changing Enterprise monitoring landscapes. This data empowers each user to shape our ongoing development, to help us understand how our product behaves in the real world, and to help us to make informed decisions to improve your experience.

Back to top

How Does Cookdown Do This?

Cookdown uses Azure Application Insights from Microsoft to collect this data and is transported using HTTPS.

At the time of writing the logs are stored in the Azure East US data-centers and the endpoint is:

https://dc.services.visualstudio.com/v2/track

Back to top

What Does Cookdown Collect?

Cookdown collects:

• Randomly generated session IDs

• Anonymized user IDs

• Anonymized Management group IDs

• Connection Center version

• The operating system running the console.

• Actions performed

• Transitions between UI elements

• When an exception has occurred

Can I See What Cookdown Collects?

We don’t provide a native method of viewing what we collect, however as these are all HTTPS POSTs you can use an SSL/TLS Inspection tool (such as Fiddler on the host itself) to intercept and view this telemetry.

How Do I Disable This Telemetry?

There are a few different methods of disabling this telemetry.

Through the About Menu

You will be presented with the option to disable client telemetry via the 'About Connection Center' interface via a checkbox:

When changed using this method you will be prompted (but not forced) to restart your console to get this to take effect.

You can get to the 'About Connection Center' interface via the help tasks:

Through the Registry

Ultimately Connection Center gets the current telemetry from the registry. The details for what values to set and where can be found above.