Antivirus and EDR Exclusions

Antivirus and endpoint-protection (EDR) tools are one of the most common causes of OmegaAI Link problems, CD-burning failures, and browser sign-in issues. Scanning or blocking RamSoft's traffic or components can slow transfers, stop the Link service, block CD burns, or silently log users out of the web app. Share this page with your IT/security team.

Browser and sign-in exclusions

Some antivirus and "internet security" suites inspect or block encrypted web traffic, which interrupts the background token renewal the web app relies on. The classic symptom is being logged out the moment you open a study, on one specific computer - see Logged out the moment you open a study, on one computer for how to recognize and confirm it.

If your antivirus, firewall, or web-filtering product supports an allowlist (also called a whitelist, exclusions, or trusted sites), add these OmegaAI domains so it stops inspecting their traffic:

Domain	Purpose
*.omegaai.com	The app, APIs, and image/service subdomains (covers your app URL plus api, blume, breeze, and syscheck).
omegaai.b2clogin.com	Sign-in and background session (token) renewal. Interference here is the classic cause of "logged out when I open a study."
omegaaiuserflow.blob.core.windows.net	Hosts the sign-in page content. If blocked, login fails with a script error (AADB2C90047).

Note: allow the whole domain, not an IP

OmegaAI is a cloud service and its server IPs change - always allow by domain name, never a fixed IP. Blocking or SSL-inspecting these domains is what breaks token renewal and causes the automatic logout.

The sign-in page also loads assets from these third-party CDNs. If your web-filtering product blocks unlisted domains by default rather than just inspecting known ones, allow these too, or the sign-in page can render broken or unstyled:

Domain	Purpose
maxcdn.bootstrapcdn.com	Page layout styling
cdn.jsdelivr.net	Icon set
unpkg.com	Sign-in page animation
fonts.gstatic.com, fonts.googleapis.com	Web fonts (the Blume and Breeze sign-in pages use these too)

If your organization uses social sign-in, also allow whichever provider you use: accounts.google.com (Google), appleid.apple.com (Apple), or facebook.com (Facebook). If your organization uses its own federated SSO instead, allow your own identity provider's domain, whichever was set up when your organization was onboarded.

Blume patient portal only: Canadian and Indian deployments use regional domains that the *.omegaai.com wildcard doesn't cover: blume.omegaai.ca and blume.omegaai.in. Some dedicated Canada/India deployments also run staff sign-in on a country-code domain (omegaai.ca / omegaai.in) rather than omegaai.com, if your organization is on one of these, confirm your actual sign-in domain with RamSoft Support rather than assuming omegaai.com applies.

Tip: if sign-in still fails, allow Microsoft's endpoints too

OmegaAI signs in through Microsoft's identity platform. If problems remain after the domains above, also allow login.microsoftonline.com, login.live.com, *.msftauth.net, and *.msauth.net (plus their *authimages.net counterparts, used for branding images on the Microsoft sign-in page). (General Microsoft guidance, not specific to any one product.)

Where to set this: in your antivirus, open Settings (or Protection / Privacy), find the web protection area (names vary: Web Shield, Web Protection, HTTPS/SSL scanning, Safe Browsing), and add the domains to its exceptions / allowed sites list; ensure any firewall module allows outbound HTTPS (443) to them. Consumer Microsoft Defender Antivirus does not inspect HTTPS content, so it's rarely the cause on its own. Enterprise Microsoft Defender for Endpoint, however, can still block these domains outright through its Network Protection / Web Content Filtering features, if your organization manages Defender for Endpoint centrally, check those settings too.

OmegaAI Link exclusions

Add these exclusions in your antivirus/EDR product on every machine running OmegaAI Link:

Process exclusion

• RamSoft.OmegaAILink.exe (the Link service process)

Folder exclusions

• The installation folder: C:\Program Files\RamSoft.OmegaAILink
• All Link image-processing folders, wherever they live:
  • OmegaAILinkImages*
  • OmegaAILinkReceivedImages*
  • OmegaAILinkProcessingImages*
  • OmegaAILinkReceiveFailedImages*
  • OmegaAILinkCachedImages*
  • OmegaAILinkCouchbase*
  • OmegaAICertificateFolder* (holds the Link's certificate files)

On a machine hosting more than one Link, the service names, install folders and data folders are all numbered - add exclusions for every instance, not just the first. Additional instances install to a numbered folder (RamSoft.OmegaAILink_2, RamSoft.OmegaAILink_3, and so on) alongside the first, and their services are numbered to match (...Service 2, ...Service 3).

Firewall or proxy allowlisting: if your network filters outbound traffic by domain, the Link also needs to reach OmegaAI's cloud services over HTTPS (443) to function. The exact hostname can vary by deployment, contact RamSoft Support for the specific domain(s) to allow for your Link installation.

Common mistake: check the drive the folders are actually on

If the image folders were moved to a data drive (for example F:\), the exclusions must point at that drive. Exclusions left on C:\ while the folders live on F:\ are the single most frequent cause of "we added exclusions but it's still slow".

CD burning exclusions

The RamSoft CD-burning components are digitally signed by RamSoft's publisher certificate. In environments with application-control tools (ThreatLocker, AppLocker, or similar EDR), allowlist the signed binaries:

• DiscImageBurner.ps1
• RamSoft.DiscImageBurner.exe

Allowlisting by publisher certificate is preferable to path rules, since it survives updates, ask RamSoft Support for the exact certificate name your application-control tool should match.

After adding exclusions

1. Restart the RamSoft Omega AI Link Service in Windows Services. On a machine hosting more than one Link, restart every numbered instance (...Service, ...Service 2, ...Service 3, and so on), not just the first.
2. Confirm the Link shows Online in OmegaAI and run Test Connection on your stations.
3. Re-send any studies that failed during the affected period from the Worklist (Send > Send Study), using the DICOM log to identify which ones failed.

Disk housekeeping: leftover update folders

Over time, the Link machine can accumulate RamSoft Omega AI Link Service_update folders from past auto-updates, and these can fill the C: drive (which also stalls transfers - see the disk-space symptom in DICOM and Image Transfer Issues). On a machine hosting more than one Link, the numbered instances get their own leftover folders too (for example RamSoft Omega AI Link Service 2_update). These leftover update folders are safe to delete. Do not delete the active installation folder or the image-processing folders.

Related: DICOM and Image Transfer Issues