********************************************
skybow Background Automation
Migrating existing event receivers
skybow 2026
********************************************

WHO NEEDS THIS

Only an installation that was already running before this version. A first-time installation
does not need it - there is nothing to migrate.

It is a ONE-TIME transition, done once per SharePoint farm. Later skybow updates do not
repeat it.


WHY

skybow reacts to list changes through SharePoint remote event receivers. Receivers registered
by earlier skybow versions carry no SharePoint application identity, because earlier versions
had no way to give them one.

From the November 2026 Public Update, SharePoint stops delivering events to receivers that
have no application identity. Every existing triggered action, aggregation and metadata
inheritance calculation on the farm then stops working - not only newly created ones.

This applies whichever SharePoint update you are on today. The August 2026 Cumulative Update
blocks creating new receivers without an application identity; the November 2026 Public Update
stops delivering to the ones you already have. Migrating covers both.


IS IT STILL NEEDED?

On a SharePoint server:

     Get-SPOrphanedRemoteEventReceiver | Where-Object { $_.ReceiverName -like 'skybowRER*' }

Nothing returned means the transition is already done, and you can ignore the rest of this
document.


BEFORE YOU START

Step 11 of readme.txt (configure_sharepoint.ps1) must be completed first, including the
iisreset on every SharePoint server. The migration re-registers receivers through the
application identity that step creates, so it cannot run before it exists.


MIGRATING

Run this on the same server as step 11 - elevated, as a farm administrator, in Windows
PowerShell 5.1 (PowerShell 7 cannot load the SharePoint snap-in):

     .\migrate_event_receivers.ps1

It CHANGES NOTHING on the first run. It reports how many receivers it found, how many belong
to configurations that still exist, and how many are left over from configurations that were
deleted. Read that, then run it again to carry it out:

     .\migrate_event_receivers.ps1 -Apply

It re-registers each live configuration's receivers through the application identity and then
removes the old ones - in that order, so an interrupted run leaves duplicates, which the next
run cleans up, rather than a list with no receivers at all.

Expect it to remove a large number of receivers. Earlier versions could leave duplicates
behind, and it is normal to find many more receivers than there are configurations.

Your automations keep running while this happens. Existing receivers go on firing until they
are replaced, and each list is switched over in one pass.

OPTIONS

     -MaxLists 1     Do one list only. Worth doing first on a production farm.
     -SiteUrl <url>  Limit to a single site collection.
     -Resume         Skip lists already completed, and retry the ones that failed. The run log
                     on your desktop records both.
     -LogPath <path> Write the run log somewhere other than your desktop.

     -DatabaseCredential (Get-Credential)
                     Read the skybow database with a SQL Server login instead of your Windows
                     account. Prompts for the password. See DATABASE ACCESS below.
     -ConnectionString "..."
                     Read the skybow database using this connection string instead of the one
                     in the skybow Web.config.


DATABASE ACCESS

The script reads the skybow database to tell which receivers still belong to a configuration
that exists. It only reads, and only one column of one table - it never writes to the database.

If the skybow connection string uses "Integrated Security=True" - the default - the connection
is made as the Windows account running the script, not as the skybow service account. The
account running this has to be a SharePoint farm administrator, and a farm administrator
normally has no rights on the skybow database, so the run fails with a login error naming that
account. The script prints which account it connected as before it fails.

The smallest fix is to grant that one account read access to the one table, on the SQL Server
instance named in the connection string. For a database administrator applying it, substituting
the account the script reported:

     USE [skybow.BackgroundAutomation];
     CREATE USER [DOMAIN\account] FOR LOGIN [DOMAIN\account];
     GRANT SELECT ON dbo.ChangeLogs TO [DOMAIN\account];

Nothing beyond SELECT on dbo.ChangeLogs is needed, and the grant can be revoked once the
migration is finished.

If changing database permissions is not an option, -DatabaseCredential takes a SQL Server login
instead, and -ConnectionString replaces the connection string outright. Either avoids touching
the Windows account's rights.


AFTERWARDS

Run the Get-SPOrphanedRemoteEventReceiver command shown above again. It should now return
nothing for the migrated lists.

Then change an item on one of those lists and confirm the automation still runs.

If anything is still reported, or an automation has stopped working, send the run log to
skybow support rather than re-running with -Apply.

********************************************
skybow 2026 - All Rights Reserved
********************************************
