Advanced Connection Center Configuration
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
There are a few different methods of enabling proxies depending on your requirements.
Per Connection Proxy
Every connection type that supports web proxies has a 'Use a proxy' checkbox that allows you to enter your proxy address.
This only supports http proxies so please ensure that you only enter this in the correct format. For example:
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
If your Management Servers receive their proxy settings via the 'Internet Options' control panel menu (either manually or via policy) Connection Center will usually honor these settings. WikiHow has a good tutorial on setting this manually here.
Per Connection Proxy settings will override this if configured.
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 settings specified in the registry will override both System proxy and Per Connection proxy settings.
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.
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.
If you’re modifying the registry chances are you know what you’re doing. However, we have to point out that using the Registry Editor incorrectly can cause serious, system-wide problems that may require you to re-install Windows to correct them. Take a backup and make any modifications carefully. You do this at your own risk.
Here be dragons.
Server settings are applied to the HKEY_LOCAL_MACHINE\Software hive via the key HKLM:\SOFTWARE\CookdownManagementPacks\ConnectionCenter
Default (including absent) setting
Take settings from connection configuration
Any valid HTTP proxy URI
Overrides any UI configured proxy address for the Management Server.
If you have a single Management Server in a remote location using a different proxy for example, you may wish to set this registry key on that one server.
Ignore the proxy server for local connections.
You may wish to set this if you have some assets in the cloud and some assets on premesis.
1 - 30
Sets a limit on the number of alerts that would be processed by a connector based Outbound Notification connection.
You may wish to set this if you need to slow down processing on a specific management server.
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.
Default (including absent) setting
Enables additional options in the SCOM console.
For example the ability to choose between connector or subscription based connections.
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.
Default (including absent) setting
Whether or not you wish to allow Cookdown to collect anonymous telemetry.
There are elements of telemetry collected from both the client and server processes so you may wish to set this across your management servers and clients.
Sends debug messages to the Operations Manager event log.
These are very verbose and should only be enabled for troubleshooting purposes. You may also wish to increase the size of this event log as these can quickly overwhelm the default size.
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.
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.
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:
What Does Cookdown Collect?
Randomly generated session IDs
Anonymized user IDs
Anonymized Management group IDs
Connection Center version
The operating system running the console.
Transitions between UI elements
When an exception has occurred
Cookdown does not collect any information that could be used to identify a user, server, or organization.
When we collect information about actions performed or if an error has occurred we do not collect any specifics.
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.
Note that if you have the SCOM console installed on multiple machines, each machine will need to have telemetry disabled.
Each Server in the resource pool will also need to have telemetry disabled.
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:
Running the SCOM console 'As Administrator' will allow you to set this for all users of the machine
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.