| Feature | Summary |
| Admin > Global Login - SAML logout no longer shows a server error when there is no active SSO session, and inbound sign-in certificate/configuration problems are now reported | Two improvements to SAML single sign-on, configured under Admin > Global Login.
Logout: When a user entered the portal through seamless SSO (already signed in to their identity provider, with no active federated session on record), clicking Logout could return a server error page instead of signing the user out. Logout now completes normally in this case: the user is always signed out of the portal locally, and if a federated sign-out cannot be sent, that no longer produces an error page.
Inbound sign-in: When an incoming SAML sign-in fails because of a certificate or configuration problem (for example a mismatched or expired identity-provider certificate, or an assertion that fails signature verification), the problem is now reported to administrators in the error log with a description of what to check, instead of failing silently.
No configuration changes are required. Sites using SAML SSO receive the improved behavior automatically. |
| Master > Content > Scheduled Tasks - notification emails no longer expose task credentials | Scheduled-task notification and error-notification emails support placeholder tokens that insert a task's saved settings into the message. Previously, if a notification template referenced a credential-bearing setting - for example a source database connection string - the email (and the process log appended to it) rendered that value in full, including the password.
Those values are now redacted before the email is sent. A connection string keeps its server and database but the password is replaced with REDACTED, and any setting named like a secret (password, key, and similar) is masked entirely. Normal, non-credential placeholders are unchanged, so existing notification templates render exactly as before apart from the credential values. This applies across all scheduled-task types that send notifications (including Data Update, Data Transform, Clean Up Files, and Report Builder email) and to the task error-notification email. |
| Content > GenericEnhanced modules - new PDF Pre-Generation module property converts saved files to PDF ahead of the first view | GenericEnhanced modules have two new module properties, Is PDF Pre-Generation Enabled? (default No) and PDF Pre-Generation Attributes. When enabled, saving a record queues the files in the listed attributes (for example FileUpload1,FileUpload2), and the Master application converts them to the cached PDF that the PDF flipbook viewer and other PDF tools use, so the first visitor does not wait for the conversion.
- The save does not wait for the conversion. Conversions run in the Master application one file at a time across the whole server, and a burst of saves, such as a Data Transfer with Use Console Utilities, is handled by a single run.
- Applies to saves in the Console and to Data Transfers that use Console Utilities. PDF files and unsupported file types are not queued.
- A file that fails is attempted up to 3 times and then kept as a failed entry; saving the record again queues it again. Queue entries are removed after 30 days.
- If the Master application is unavailable, the files wait in the queue for the next save or the next Temp PDF File Generator run.
- Conversions run during working hours and share the server with daytime traffic, so this option suits modules with light, steady saves. For large modules and bulk imports, the Temp PDF File Generator scheduled task is recommended instead.
- Results appear in
Master > Development > Process Log under PDF Conversion Queue.
Full details: Pre-Generating PDF Conversions
|
| Master > Content > Scheduled Tasks - new Temp PDF File Generator builds cached PDFs ahead of the first view | A new Temp PDF File Generator scheduled task builds the cached PDF that the PDF flipbook viewer and other PDF tools create the first time a document is opened, so no visitor waits for a large Word, Excel, PowerPoint, Visio, image, email or HTML file to convert. It is the recommended way to pre-generate PDFs, and is meant to run off-hours on a recurring schedule.
- Settings:
Web Site, Modules, Attributes (the attributes that hold relative file paths or Resource.ashx links, for example FileUpload1, FileUpload2) and Maximum Execution Time (Minutes). - 4-hour limit: a run never exceeds 4 hours (240 minutes;
0 uses the full 4 hours). Files a run does not reach are generated on its next run, because each run skips files that are already cached. - Process log: each failed file is logged with its path and error, and a
Sweep - Checked / Converted / Already Cached / Skipped / Failures summary is written every 25 files or 5 minutes and at the end. Before its sweep the task also processes files queued by the new PDF Pre-Generation module property (logged as Queue - ...). - Not pre-generated: PDF files (served as they are) and watermarked views (built when viewed). Files in a virtual directory are pre-generated only when the same virtual directory is also mapped on the Master application, to the same folder.
- Cached PDFs are removed by the monthly temporary-file cleanup, so the task should recur
Full details: Pre-Generating PDF Conversions |
| Master > Content > Scheduled Tasks - new Integrity Scan option on the Data Update task | The Data Update ("My Update") scheduled task has a new optional Integrity Scan. After the task moves Media Manager resources, when Integrity Scan is turned on it checks the content it maintains for attachments that are broken on the destination site - either the attached file is missing, or it opens a different file than the source site holds. It reports a summary (how many missing, how many wrong-file) and lists each flagged record to the task's process log and, when Notification is on, the notification email, so an admin can locate the article and replace the attachment. Module names for the flagged records and the full missing list are also available in the error system and via a SQL report.
The new options appear under Media Manager (Resources) on the task, when Resources is set to Yes:- Integrity Scan (Yes/No) - turns the check on.
- Integrity Scan Module Ids - optional comma-separated list of module ids to limit the scan (leave empty to scan recently changed content instead).
- Integrity Scan Date Offset (days) - when no modules are listed, how far back to look (default 90).
The scan is read-only: it reports, it does not change the transfer or the content. This release also improves Data Update reliability - it raises an alert when a run repeatedly cannot make progress (instead of silently retrying), and the resource move is faster on tasks with many attachments. |
| Data Transform > Data Transfer - a failed bulk transfer now records the affected records and the underlying error | When a Standard Module data transfer using the Bulk (insert-only) method hits an error while writing a batch of records, it previously reported only a generic failure and moved on, leaving no record of which rows were affected or why. It now records how many records the failed batch held and lists their DataIds (up to 40), and the transfer's execution log preserves the underlying cause of the error rather than only the outer "cannot access destination table" message. The failure alert also names the safe way to recover - delete the batch by its BatchId, then re-import - because a re-run can otherwise either duplicate content or collide on the primary key. This is a diagnostics and recovery improvement only - there is no configuration change, and a normal, fully successful transfer behaves exactly as before.
If you have a custom report or Data Source that filters the transfer execution log by its error-message text, note that the stored message now leads with the underlying cause, so a filter written against the old outer wording ("cannot access destination table...") may need updating. |
| Site-wide - document previews no longer share one cached copy when the file is stored outside the website folder | Document previews are cached so a file only has to be converted once, and that cache was organized by the document's folder path within the website folder. A document served from somewhere else - an IIS virtual directory such as a document library on a network share, a UNC path, or a mapped drive - had no such path, so its preview was stored under the file name alone. Two documents with the same file name in different folders therefore shared a single cached preview, and each could display the other's content. The file name shown on screen stayed correct, which is why this tended to read as an out-of-date document rather than the wrong one.
Previews for these documents now go in a folder named _External under the site's Temp area, organized by the path the document is requested from, so every document gets its own cached preview. A preview that already exists is moved into the new layout the first time the document is viewed rather than being regenerated, so a site with a large document library does not reconvert everything after the update. Documents stored inside the website folder keep their existing cached previews and are unaffected, with two rare exceptions noted below.
Three related fixes ship with it. The Download and Export options in the Excel viewer now work for documents stored outside the website folder; previously they returned an error for exactly those documents. And a preview that could not be delivered because the file was momentarily locked - typically an antivirus or indexing sweep touching a newly created preview - is now retried briefly instead of immediately showing the error document. Finally, thumbnail images for documents stored outside the website folder now generate at all; previously they came back blank, because the thumbnail generator looked for the file inside the website folder regardless of where it actually lived. Thumbnails follow the same _External layout described above.
Three situations can cause a one-time reconversion of previews that already exist. Rolling Centralpoint.Web.dll back after the update makes the moved previews invisible to the older code, so schedule a rollback on a document-heavy install for a low-traffic window. Custom code that asks only for a preview's storage folder, rather than going through the standard preview entry point, will not find previews it created before the update. And two uncommon site layouts re-key their previews rather than keeping them: a site whose website folder is not spelled Root exactly, and a site with a content folder of its own named _External. In every case the effect is that affected documents convert once more on next view, not that anything is lost.
|
| Word Add-In - attribute dropdown now lists upload fields and shows their friendly names | Changes Made: The Word Add-In's document save form reads a module's file-upload attributes to fill its attribute dropdown. Two fixes: the dropdown could come back empty for modules whose attributes use the standard layout, and it now lists the upload fields correctly; and each option now shows the attribute's friendly name (e.g. Wallpaper) instead of its system name (e.g. File). Where a module has a custom attributes file that renames an attribute, the picker now shows the custom name, matching what the Console editor shows. Options are sorted alphabetically. The same shared reader powers the Source Attributes picker under AI Governance > AI Indexing (Edit Configuration), which now shows correct attribute names and classifications for the same reason. The value stored on save is unchanged, so existing documents and integrations are unaffected. |
| Development > Process Log - process status text now HTML-encoded at display (stored-XSS fix) | The Process Log page and the process-monitor progress window now HTML-encode process status and step text when displaying it. This closes a security issue (stored XSS) where text shown in a process status — client names, file or column names, or error text — could run script in an administrator's browser. Status text is no longer rendered as raw HTML.
Standard status messages, and simple inline formatting (bold, italic, and line breaks), continue to display normally. Failure highlighting, download links, and read-only copy boxes are preserved through the built-in status helpers.
Custom code that builds its own HTML into a process status — for example alert-styled highlighting or a hyperlink — will now show that markup as literal text, and hand-built links will no longer be clickable. Such code should switch to the built-in status helpers: SetAlert for highlighted failures, SetLink / SetDownloadLink for links, and SetTextArea for read-only copy boxes. No change is needed for plain-text status. |
| Development > Errors - CpScript and Data Source timeouts are now detected reliably and name the record involved | Query timeouts raised by a CpScript, the DataSource module, or the Personal Dashboard Data Source gadget are now identified by the database error number rather than by looking for the words "timeout expired" in the message text. Two things improve as a result. A timeout that was wrapped inside another error was previously missed entirely, along with its diagnostic entry, and is now recorded. In the other direction, an unrelated failure whose message merely mentions a timeout - a full-text search engine failure lists "timeout" among its own possible causes - is no longer filed as a query timeout, so the entry under Development > Errors now reflects what actually happened. The diagnostic entry also carries the DataId of the data source involved, so the record can be identified directly instead of being tracked down by hand.
Separately, the Delete action on Development > Errors is now applied on the server as well as in the page. There is no change to what you can delete through the console - the Delete button and row checkboxes already reflected which entries are removable - but the same rule is now checked when the request is received.
|
| Site-wide - checkbox and radio button lists now encode stored text before display (security) | Following the recent update that encoded multi-select list labels, the remaining list controls now do the same. Checkbox lists (such as the tenant picker in the Data Transform > Data Transfer Fields editor and in Search All Modules, and the tiered audience/role selector used across the console) and radio button lists now encode any HTML or script characters in database-sourced item labels before displaying them, so the characters appear as literal text instead of being interpreted by the browser. No configuration change is required; the fix applies automatically once the update is in place.
Behavior change to be aware of:- Radio or checkbox option labels that intentionally contained HTML markup (a styled label, or a link inside an option) will now show the tags as literal text rather than rendering them.
- Client custom code that added its own HTML-encoding to radio/checkbox item labels should remove it, since the controls now encode once at display. A leftover manual encode shows literal
< characters (display only, not a security issue).
|
| Centralpoint 8.12.14 maintenance run #2 - CMS templates tolerate a stray brace, plus site search, document preview, relation population and Master sync fixes | CMS text used as a template no longer fails on a stray brace, and format codes now work. Several attributes are filled in by an administrator and then have values merged into them before they are sent or displayed. Previously a { or } typed anywhere in that text could stop the whole operation, and a format code such as {0:d} on a date was not applied. Both are fixed across the sign-in and account emails (MfaTotpHeaderContent, MfaEmailBody, MfaTextMessageBody, LoginPasswordEmailBody, SendPasswordChangeEmailBody), the Admin > Global Login OwaUsername mapping, module view ErrorItemContent, the details-page email form (EmailSubject, EmailBodyHtml), marketplace comparison emails, and record URL templates.
Site search results no longer break on a brace in content. On Site Architecture > Search Page Designer, the ResultsItemContent template and the record content merged into it shared a single formatting pass, so a brace in any title or abstract stopped the whole result list from binding. A brace in record content is now displayed as typed.
Admin > Settings no longer blanks the upload and data limits. When the underlying configuration could not be read, the upload and data limit fields were treated as empty and saving removed them. An unreadable configuration is now reported instead, and the existing limits are left alone.
Bulk file upload no longer fails after routine cleanup. The staging folder a bulk upload writes into is empty until files arrive, and the site's temporary-file cleanup removes any empty folder regardless of age. The folder is now recreated when the page posts back, so an upload started after a cleanup still succeeds.
Document preview is more reliable under load. Two people opening the same document at once each converted a full copy, and the slower conversion could replace the file the faster one was still sending. Conversions are now serialized per document. A conversion that hangs no longer holds later requests open indefinitely, and the memory used to coordinate them is now fixed rather than growing for as long as the site runs.
Relation population no longer produces duplicate rows. Two populations of the same module could interleave and duplicate each other's rows. They are now serialized per module, so unrelated modules sharing a table are unaffected. A population that waits on another and gives up is now reported as contention rather than as a damaged relation needing manual repair, which previously produced an urgent alert with repair instructions for a relation that was in fact correct.
Master > Content > Scheduled Tasks - a database outage no longer disables a working task. When the database was unreachable, the attempt to record the failure failed for the same reason and the task was reported as broken and disabled. Such a task is now left enabled and retried.
Master > Deployment > Synchronize - a Master that cannot build is now named as the cause. A Master whose code does not compile answered the sync call with an error page, which was previously reported as the sync endpoint being unreachable and sent people to check the URL. The message now says the Master does not build and points at the code, and skipped sync methods report their real status.
Master nightly cleanup completes when a SQL service account cannot be resolved. On a remote or named SQL instance the default service account does not exist locally, and trying to grant to it stopped the whole cleanup. It is now skipped with a clear message, the selection is saved so it is not reapplied, and the account used for impersonation is always restored afterwards.
Install and migrate no longer report every scheduled task as overdue. An imported database carries the next-run times it held when the package was captured, so a new install reported every built-in task as hours late. Past-due tasks are now made due shortly after startup, spread over a short window so they do not all run at once, and each task then returns to its own schedule.
Error reporting groups related failures correctly. SQL connectivity failures and Windows security-service outages now group under the errors that already cover those conditions instead of creating separate entries, and an API error that is recorded in Centralpoint no longer also fills the server's Windows event log.
The Centralpoint Agent and command-line tool are updated to 8.12.14.1. |
| Admin > Settings - required fields are now enforced on save, and invalid values are blocked before they reach web.config | The Settings page carried field validation that never ran. The page's fields were checked against a different validation group than the Submit button uses, so the checks were skipped on every save and the page reported success regardless. This affected both Admin > Settings in the console and Master > Admin > Settings.
Validation is now active, and applied only to the settings that are genuinely required. A setting whose value must be present for the site to start is now blocked when cleared, and in several cases the shape of the value is checked as well:
- Connection strings -
cpsys_Select and cpsys_Execute must have a value. - Machine Key - the Validation Key and Decryption Key must be present and must be valid hex values of the correct length. Entering
AutoGenerate is rejected, because it causes the key to be regenerated on every application start, which signs out every logged-in user. - Master Id - must be present and a valid GUID, in any of the standard GUID formats.
- Master Root - must be present. An empty value previously failed silently rather than raising an error, which made it harder to diagnose.
- Check Frequency Minutes - must be a whole number of 1 or more. A value of
0 caused the remote security check to run on every page request instead of disabling it. Values above 1440 are still accepted and treated as 1440 (daily).
Settings that may legitimately be empty on a given installation - such as the Telerik Skins Assembly, the email user name and password, and the error notification address - are deliberately not required, so they can still be cleared and saved.
A second check now runs at save time, immediately before the configuration file is replaced. If a value would prevent the site from starting, the save is refused and the existing configuration is left untouched. This is a safety net behind the on-screen validation, not a replacement for it. It does not apply when the configuration is encrypted (the Protected setting is yes), where the on-screen validation remains the only check.
The same corrections have been applied to the Master settings page. |
| Data Transform > Data Transfer - SharePoint list attachments can now be stored as role-protected Resources | A SharePoint List Attachments transfer stores each downloaded file under /Uploads/SharePointListAttachments and maps its path through the LocalPath column, which offers no way to restrict who can open the file by role. A new AttachmentToResource CpScript stores each attachment in the Media Manager instead, where access is checked against roles on every request.
To use it, open the attachments transfer's Fields tab and map the AttachmentToResource script to the destination attribute that currently takes the LocalPath column, in place of that column. The script downloads each attachment straight into the Media Manager and returns its /Resource.ashx link as the attribute's value, so existing pages that render the attribute keep working. The parent SharePoint List transfer is not changed.
The script has three properties:
- Resource Roles - a comma-separated list of role system names (found under
Admin > Roles) allowed to open the files. Left blank, every resource carries the Private role, which means any signed-in user can open it and anonymous visitors cannot. Naming roles restricts access further. Where the destination website has Role Filtration And Security turned on, a user must hold every role listed rather than any one of them. A name that does not exist is reported once and no resources are written for that run; the mapped attributes are left empty until the name is corrected and the transfer run again, which restores them. The public files are never removed while the value is unresolved. - Resource Audiences - audiences assigned to each resource. Defaults to All Audiences.
- Resource Url By System Name - returns the readable
?sn= form of the link. On by default.
The transfer keeps the matching Uploads directory clear on your behalf. Once a resource exists for every attachment the transfer tracks, it removes the copies it has replaced under /Uploads/SharePointListAttachments/{ListId} and reports how many went. This is not a one-time migration step; the directory is kept clear on every run. The cleanup is deliberately cautious, because deleting those copies cannot be undone: it runs at the end of a transfer, and only once every tracked attachment has a resource standing in for it. A run cut short by LimitWrites or SkipWrites, aborted from the console, or carrying any failed write leaves every Uploads file exactly where it is and says why in the status.
Applying the script also changes what the transfer removes. It begins deleting destination records for list items that are no longer in SharePoint, or that no longer carry attachments, along with the Resources belonging to them; without the script those records stay in place. Removing the script later does not undo this cleanly: the transfer returns to writing files under /Uploads, but every Resource already created stays in place, still reachable by its URL, and is no longer removed when its attachment leaves SharePoint, so those must be deleted by hand in Design > Media Manager.
Note that Resource Roles here takes role system names, while the identically named property on the existing FileDownloadToResources script takes role ids. Resource Url By System Name likewise defaults on here and off there. The two scripts are not interchangeable in this respect.
Two further behaviors are worth knowing before the first run. Where two attachments transfers pull the same SharePoint list into different modules they share one Uploads directory, so the run refuses and names the other transfer until it is converted as well. And roles and audiences are re-applied from the script properties on every run, so a role added by hand in the Media Manager is replaced the next time the transfer runs.
One behavior change reaches the existing FileDownloadToResources script as well, which shares the same resource-writing code. A download that completes but leaves an empty file is now refused: no resource is created and the transfer reports an error, where previously a zero-byte resource was created and its link returned. A source that legitimately serves empty files will see those rows reported as failures instead of written.
When an attachment disappears from SharePoint the resource follows it, whether a single attachment was deleted, the whole list item was deleted, or the item remains with no attachments left. A resource still referenced by a versioned or archived record is kept and reported rather than treated as an error.
The Help article for Data Transform > Data Transfer has been extended with a Storing Attachments as Protected Resources section covering setup, the properties, the Uploads cleanup and troubleshooting. Full documentation on this transfer and feature can be read there: SharePoint List Attachments.
|
| Data Transform > Data Transfer - clean Users transfers are no longer flagged as having errors | When a Users data transfer completed successfully it could still be reported as finishing with errors, even though nothing had failed. The run's health check was scanning the descriptive status text it writes during the run, and words like "Error", "Exception" or "Failed" appearing inside column or field names were misread as actual failures. The health check now ignores that descriptive text and looks only at real run outcomes, so a transfer that completes cleanly is reported as clean. Transfers that genuinely fail still report errors. No configuration change is required. |
| Site-wide - stored text is now encoded before display in the Data Transfer Fields editor, the process monitor, and multi-select lists (security) | Several places that display text drawn from imported data or stored records now encode that text before showing it, so any HTML or script characters in the text appear as literal characters instead of being interpreted by the browser. This covers three areas: the column names shown in the Data Transform > Data Transfer Fields mapping editor, the status text shown in the process monitor popup and on the Process Log, and the item and group labels in multi-select list controls used across the console and site (for example reviewer and module pickers). Behavior is otherwise unchanged and no configuration change is required; the fix applies automatically once the update is in place. |
| Master > Development > Utilities - site backups now make room before writing, check free space first, and stop the whole run on a full disk | Progress is now reported while a single large file is being added. The previous release added a running count of files and megabytes during the archive step, but that count only moved between files. A site containing one very large file could still go silent for the entire time that file was being compressed - long enough for a healthy backup to be treated as abandoned. The count now advances while a single file is being written, so the backup is visibly working throughout.
Retention now runs before the new archive is written, and free disk space is checked first. Previously the old backups were removed only after the new archive had been written, so the disk had to hold a complete extra copy at peak. Retention now removes the surplus first, always keeping at least one complete archive, and the backup then confirms there is enough free space before it starts - measured from the most recent archive plus the existing database backup, with headroom added. If there is not enough room, the backup names the shortfall and stops rather than failing part-way through. The new archive is also written under a temporary name and only takes its final name once it is complete, so a backup that fails leaves nothing behind that could be mistaken for a usable one.
Correction to the earlier backup note in this release. That note stated that if any file was skipped, the retention limit is not applied, so existing good backups are kept. That is no longer accurate. Because retention now runs before the archive is written, it has already reduced the retained backups to one below the configured limit by the time the outcome is known, so a run that skips a locked file keeps one fewer complete archive than it did before. The configured limit is still applied, and at least one complete archive is always kept.
A full disk now ends the whole run and sends one notification. When a master backs up many sites in one run, running out of disk space affects the server rather than one site. The run previously continued into every remaining site, each of which failed the same way, and sent a separate email for each failure. The run now stops at the first out-of-space failure, records the sites it did not attempt, and sends a single notification naming both the sites that failed and the sites that were skipped, each with a link to its Backup Exclusions settings. A failure affecting only one site still lets the run continue, as before. Backing up a single site from its own console is unchanged and still notifies immediately. |
| Site-wide - a failed save no longer deletes the document unless its own data caused the failure | When a record was saved and Centralpoint could not populate its relations afterwards, the record was deleted and the user was told that its attribute values were bad. That message was reported for every cause, including ones that had nothing to do with the record: a request that timed out, a dropped database connection, a relation table that had drifted from its definition, or a storage fault. In those cases a valid record was removed and the explanation pointed the user at the wrong thing.
Centralpoint now checks what actually failed before removing anything. A record is deleted only when its own attribute values caused the failure, which is the long-standing case where module configuration hides a required and validated attribute without a valid default. For every other cause the record is kept, and the message says plainly that the record was not deleted and that the save can be retried. The recorded error now also carries the underlying cause and a short triage note, so a repeated failure can be diagnosed without reproducing it.
A related change covers the education report data trigger, which previously removed a record without reporting anything at all when its relation update failed. It no longer removes the record, and the failure is now reported.
Error reporting is also more accurate: a save interrupted by a request timeout is now recorded as a timeout rather than as a relation problem, so these are no longer counted together. |
| AI Governance > AI Indexing - unenroll now shows progress and the module moves to Available immediately | Unenrolling a module from AI Governance > AI Indexing now gives feedback while it runs. Removing a large module deletes its chunks in batches and can take several seconds, during which the confirm button previously stayed live with no indication anything was happening - so the dialog read as unresponsive and a second click could start a redundant removal. The confirm button now disables and shows a spinner reading "Deleting...", and the dialog cannot be closed by the X, Cancel, or the Escape key until the removal finishes.
Both tabs now refresh when it completes, so the module visibly moves from Enrolled Modules to Available Modules without a page refresh. Previously only the enrolled list reloaded, so the module appeared to vanish and then reappeared under Available on the next visit, which read as "still indexed".
If the removal runs past the allowed time, the message now says the module was partly removed and to click Unenroll again to finish, and the enrolled list refreshes so the record count reflects what was actually deleted. The removal is safe to re-run and picks up where it stopped.
On a server that does not support vector indexing, the Available Modules tab now explains that indexing is unavailable instead of sitting on "Loading available modules..." indefinitely.
The Force Reindex confirmation now describes what actually happens - the work runs while the dialog is open, in batches of 200 records - and if it runs past the allowed time it now says the records already processed are saved and to click Force Reindex again to continue, rather than telling the user to wait for a background process.
Also on AI Governance > AI Data Source Tuner: pressing Ctrl+Enter twice in quick succession no longer sends a second request or leaves the Run preview button stuck showing "Matching...". |
| Site-wide - source-editor fields stay editable when the browser cannot run the code editor | Console fields that use the code editor rendered nothing to type into on a browser too old to run it. This affected Select Command and Attributes on Reporting > Report Builder, Tools > Actionable Select Command Builder, and Site Architecture > Search Page Designer. The field appeared on the page but would not accept typing or pasting, and nothing was reported to the user.
These fields now fall back to a plain text box whenever the code editor cannot run. The value is typed, pasted, and saved exactly as before, so console work is no longer blocked by the browser version. On a current browser the code editor loads as it always has and the plain text box never appears.
Two related corrections ship alongside it. AI summarization on these fields now reads what is currently typed rather than the value the page loaded with. The required-field checks on Tools > Actionable Select Command Builder no longer fail in the browser, so a missing Select Command is reported normally. |
| Master - password-expiry scheduled task no longer clears users' authentication source, group, and local-account settings | The scheduled task that expires user passwords was overwriting several account fields on every user it processed. Each time it ran against a website, it reset the affected users' authentication source link, stored authentication credentials, group assignment, and local-account flag — settings unrelated to password expiration.
For users who sign in through an external identity provider (SSO) or who belong to a group, this silently removed that configuration on every run, which could break their sign-in or group-based access until it was reconfigured.
The task now preserves these fields and only updates the password-expiration state. No configuration change is required; the fix applies automatically once the update is in place.
|
| Master > Content > Scheduled Tasks - lock now holds a live long-running task instead of restarting it, with new operator signals | Long scheduled tasks on a Master (the overnight Data Update, backups, cleanup) are guarded by a lock so two runs cannot overlap. Previously the lock was judged stale purely on age (1 hour), so a healthy multi-hour run — a Data Update can now take 4+ hours — could be treated as abandoned and restarted on top of itself if a second application worker appeared (for example during an app-pool recycle), with both runs writing the same databases.
The lock now stays in place while a run is still recording activity, and clears only once activity has stopped, so a long run is no longer restarted while it is working. A truly abandoned lock still clears and the next run proceeds, as before. A safety ceiling bounds how long a lock can be held.
This introduces new, self-explaining messages in Master > Development > Errors. What each one means:
- Scheduled task lock file held past 1h ... and ... is N hours old (past the 1h max age); an incomplete process last recorded activity ... Not orphaned. — Informational. A long-running task is being protected. No action. Expected during long runs.
- URGENT: Deleting a scheduled task lock file ... because it exceeded the 12h hold ceiling ... — Actionable. A run outran the 12-hour safety ceiling and its lock was cleared, so a concurrent run may start. Investigate why the task runs that long (or raise the ceiling for that install).
- WARNING: Deleting a scheduled task lock file ... because the liveness check could not run ... — The master database was unreachable/timed out during the check. Check database health if it recurs.
- WARNING: Deleting orphaned scheduled task lock file ... — Normal recovery. A previous run ended without cleaning up and no activity was seen; the next run proceeds.
|
| Design > Data Sources - report grids can now export to PDF | Data Source report grids can now produce a PDF. A PDF icon sits in the grid toolbar beside the column selector and the Excel export, and the document it produces holds every row the report currently matches, rather than the page on screen.
Where it is turned on. The export is configured through the pdf block of the cp_DataSourcesExtTable plugin configuration, in the Template Content attribute of a Data Source module record. The Select Command builder writes that block into the markup it generates, so a report built from this version on has the export already. A report built before this version does not gain the icon at upgrade; it opts in by adding pdf: { hasExport: true } to the plugin configuration in its own Template Content. Every available setting, including the orientation, the document title, the downloaded filename and the wording of the band above the table, is documented in Data Sources > Template Content > JavaScript Extension.
The export is for signed-in visitors only and an anonymous request is refused, so the generated configuration hides the icon from anonymous visitors rather than offering one that fails. A report on a public page gains nothing from enabling it.
What the reader has done to the grid carries into the document: the active search term, the sort order, any taxonomy or date-range filter, and the columns left visible in the column selector. Row selection checkboxes and similar controls are stripped out, and a column left with nothing in it once its control is removed is dropped, so a selection column does not print as an empty one.
A short band above the table states what the document covers. It names the report, the generation time in the reader's own time zone and date format, the row count against the unfiltered total, and the filters in force. The count is taken from the finished document rather than from the page, so it cannot claim rows the PDF does not contain.
The PDF is rendered against the site's own stylesheet, so the table arrives looking like the table on screen, with default row spacing and a light rule so an export reads cleanly before anything is customized. A Design styles record can restyle the printed version through the .cp-ds-pdf-export class without those rules reaching the report on screen.
A report with many columns does not produce a good PDF, and no setting changes that. Columns are squeezed to fit the page rather than cut off, so nothing is lost, but past roughly a dozen columns of real content the result is cramped. Where every column of a wide report is needed, the Excel export remains the better tool.
Building a PDF download outside a Data Source grid. The renderer behind the button is a general endpoint: it takes assembled table markup and returns a PDF, and nothing about it is specific to Data Sources. A Form, a custom page, or anything else that can build a table can use it directly. The fields it accepts, the two values it fills in, sample code and the styling hooks are documented in PDF Export Handler.
Download filenames have also been hardened against characters that could break a download, so a name taken from a record's title arrives intact rather than cut short.
|
| Master > Deployment > Web Sites - the Domain Rewrite step now finishes safely on a long restore, and names the column it stopped on | When restoring a web site with new domain values entered under Master > Deployment > Web Sites, the Domain Rewrite step updates every stored URL from the old domain to the new one across the site's content, audiences, and relational data. On a large site this can take a long time. Previously, if the step ran out of time before finishing, the restore could fail in a way that deleted the newly created web site. Now the rewrite stops itself safely before running out of time, reports exactly which table and column it was working on when it stopped, and the web site is preserved so the rewrite can be finished later. Progress is now shown as the rewrite runs, one line per table and column with the row count and elapsed time.
A new safeguard also applies when the new domain is longer than the old one: any stored value that would no longer fit its column after the rewrite is skipped and listed in the summary instead of causing an error or being cut short. This protection now applies consistently whether the rewrite runs through the Deployment page or through the migrate-site command-line migration tool.
|
| Master > Development > Utilities - Database Maintenance now reports progress and has more time to finish | Database Maintenance, run nightly and also available from Master > Development > Utilities, previously showed only a starting and an ending database size while it ran, with no indication of what it was doing in between - a long maintenance pass looked identical to a stalled one. It now reports each step as it happens, including transaction log checks and shrink progress. The maximum time allowed for a maintenance pass has also been raised, so an installation with a very large database is less likely to have its maintenance stopped before finishing. |
| Master > Development > Utilities - nightly Clean Up now updates only the statistics that changed | The nightly Clean Up task, also available from Master > Development > Utilities, previously refreshed every table's statistics in full every night, regardless of whether that table's data had changed. It now updates only the statistics on tables where a meaningful share of rows changed since the last update, and still uses a full sample when it does update one. This shortens the nightly run on installations with many large, mostly unchanged tables, with no loss of accuracy on the statistics that are refreshed. |
| Site-wide - database files no longer grow by a percentage | Some database files were configured to grow by a percentage of their current size rather than a fixed amount. On a large file this could cause an unexpectedly large, slow growth event that pauses activity on that database while the increase completes. Existing database files are now corrected automatically to grow by a fixed amount sized to the file, and a site created from a backup no longer inherits percentage-based growth from the source. |
| Master > Content > Scheduled Tasks - Data Update now enforces Uploads exclusions and surfaces skipped content | The Master Data Update scheduled task (Master > Content > Scheduled Tasks) has two behavior changes that fix silent failures during staging-to-production copies.
Uploads exclusions now take effect. Previously the exclusion list for the Uploads copy never matched, so every run copied the ModuleViews and SyncInvokeMethods folders even though they were meant to be excluded. These are now correctly skipped. Module Views still transfers either through its own dedicated step (when that option is enabled on the task) or through the Uploads copy (when it is not), so no task loses module-view files. SyncInvokeMethods is no longer copied by Data Update (it held only obsolete files and nothing depends on it). Any custom exclusion an operator enters with a leading /Uploads/ now matches as intended.
The task no longer reports success when content was skipped. Any skipped file or record is now reported to the Errors page and marks the run as having errors, so it stands out in the Process Log instead of showing a clean run. For skipped database records (Resources, Module Views), the run also holds its incremental "last run" marker, so the record is retried on the next run rather than being permanently missed. Operational note: if the same record fails on every run (for example one the destination rejects), the marker will not advance until that record is fixed, so incremental updates for the task pause until an operator addresses the record named in the error. To release it: fix the record (or disable that phase), or set the task's Start Date in the scheduled-task editor. A skipped file is reported but does not hold the marker (a permanently uncopyable file will not stall the task). |
| Centralpoint 8.12.14 maintenance run #1 - error triage fixes, security hardening, and the 8.12.14 Agent and CLI | This is the roll-up for the 2026-09-10 maintenance run. It covers the reported-error triage, a security review across Development and Master, and the redeployment of the Centralpoint Agent and CLI at 8.12.14.
Two changes need a QC step of their own. Both are described under "Important" at the end.
Error reporting- A scheduled task that only ran out of request time is no longer disabled. It previously switched itself off and had to be re-enabled by hand.
- The late-task threshold is now configurable and defaults to four hours.
- A SAML certificate fault is now reported rather than only suppressed, so a signing-certificate problem surfaces instead of appearing as a silent login failure.
- A transient database failure during Windows single sign-on falls through as an anonymous visit instead of throwing.
- A supplied PDF that cannot be read is reported as a content problem, not a platform fault.
- Database connectivity failures wrapped inside another error are now grouped with the rest.
- The error logger no longer throws while it writes a log entry.
- Repeated check-in and OAuth renewal notices are rate limited, the latter per authorization and user rather than for the whole site.
Content and document safety- A failure while repopulating a module relation table no longer deletes the user's document.
- A relation delete that fails now stops the repopulation, instead of reporting a duplicate-key symptom on the insert that follows.
- Replacing a resource file now retires the previous file aside rather than deleting it, so a file that is locked or in use is no longer lost. Replacing a file with one of a different extension retires the original correctly.
- Large bulk index deletes are queued through a list parameter, so the request is no longer rejected on size.
Reporting, data transfer and scheduled work- A Data Transfer targeting the Site Map module now matches that module correctly. The field map could previously be generated against the wrong table name, and the transfer then failed with an invalid object name.
- Generated SQL renders a MAX-length parameter as MAX, and quotes string and date types.
- A delete-only search synchronization reads only its own index.
- The scheduled task that downloads a file now runs under the process id its caller supplied, so its row appears in the Process Monitor with its status steps.
- Images loaded for template rendering and size checks are released immediately, so a source file can be renamed straight after a render.
- Stylesheets and scripts shipped with the platform now carry an automatic version stamp, so a browser picks up an updated file after a deployment.
Search and indexing- The vector upsert holds its lock on the content index for less time.
- A retrieval timeout now reports how many eligible chunks were in play.
Security review- Aborting a running process from the console is now signed and verified between the site and the master.
- Document preview conversion accepts a source file only from inside the site, in every accessibility mode.
- The document preview cache refreshes when its source changes, and two files with the same name in different folders no longer share one cached copy.
- The OneDrive download target is taken from the session rather than the address bar, so a download link no longer carries the credential to an address a visitor supplies.
- The console login return address is validated before the redirect.
- File and folder paths are checked against the folder boundary rather than the leading text. A sibling folder whose name merely started with the permitted one was previously accepted.
- Two pages that build a browser redirect from a supplied address now encode it.
- Uploads through the file browser validate the requested subfolder.
Agent and CLI
The Centralpoint Agent and CLI are redeployed at 8.12.14 and ship as a matched pair. The Agent consolidates the site-skip check used by its patch deployment steps. Both sync methods appear under Master > Development > Sync Methods after the sync.
Important - the console process abort requires the site and master to match
Aborting a running process from the console is now signed between the site and its master, and both sides must be on 8.12.14 or later. A site on this version talking to an older master, or an older site talking to a master on this version, reports "This process cannot be aborted." Abort fails closed rather than proceeding unverified. Confirm both tiers are synchronized before testing the abort.
Important - document preview no longer accepts a remote address
The document preview converter now checks that its source file is on the site itself, in every accessibility mode. It previously allowed an address outside the site whenever the module accessibility was set to anything other than Local Only. A saved or bookmarked preview link that pointed outside the site now returns "not found." Preview links to files on the site are unaffected. |
| Site-wide - SQL injection hardening across stored filters and query composition (security) | Changes Made
Several places in Centralpoint accept a filter typed by an administrator and add it to a larger query: the Source and Delete filters on a Data Transfer (Data Transform > Data Transfer), the custom filter on Admin > Search All Modules, module relation filters, scheduled task custom filters, and filter properties on list and validator controls. Those filters were added to the surrounding query without being checked, so a filter that was incomplete, or that was written to change the shape of the query rather than narrow it, could reach the database as written.
Stored filters are now validated before they run. A filter is refused with a message reading Invalid SQL fragment when it has an unmatched parenthesis, an odd number of single quotes, or contains ;, -- or /*. The most common legitimate case that now fails is an administrator who commented a filter out by putting -- at the front of it rather than clearing the field. On a refusal, the correct fix is to repair or clear the filter, not to work around the message.
Query composition was tightened alongside it. A number of queries combined an administrator's filter with the system's own enabled, date, role and audience filters in a way that let an OR on one side override the other, so a filter could return records the system filters existed to exclude. Each condition now stands on its own. This affects relation reads, taxonomy counts, console grids, the users service and the data transfer readers.
Search redirects now respect their own record settings, which is a visible behavior change. Search redirects were one of the queries affected by the composition problem above. When a site has the search redirect option enabled on the Search system page (Site Architecture > System Pages), a search term is matched against the records under Advertising > Search Suggestions. Those records were being matched without the enabled flag, the start and end dates, or the visitor's audience being applied, so a redirect could fire from a record that was switched off, outside its date range, or aimed at a different audience. All of those now apply, which is how the records are presented in the console and what the settings on each record imply.
A redirect that fires today from a disabled, expired or out-of-audience record will stop firing. That is the corrected behavior, but the records under Advertising > Search Suggestions are worth reviewing on active installs before the release, because a record left disabled while still being relied on will look like a regression.
|
| Master > Development > Utilities - site backups now report archive progress and stop instead of saving an incomplete backup, and a scheduled task that runs out of time stays enabled | Site backups report progress while the archive is being built. The archive step previously reported nothing between "Creating Archive File..." and the end of the backup. On a large site that silence could last long enough for the system to treat a healthy, still-running backup as abandoned and mark it as an orphaned process. The backup now reports a running count of files and megabytes as the archive is written, so a long backup is visibly working rather than apparently stalled.
A backup that cannot finish now stops, instead of quietly saving a partial one. When the server runs out of disk space part-way through, the backup previously treated the failure the same way it treats a file that is temporarily in use: it skipped ahead and finished, producing an archive that was missing content. It then applied the retention limit and deleted older, complete backups to make room for it. Only a file genuinely held open by another process is skipped now; anything else stops the backup. If any file was skipped, the retention limit is not applied, so existing good backups are kept.
A scheduled task that runs out of time is no longer disabled. A task that exceeded its allowed run time was automatically switched off, which stopped that work entirely until somebody re-enabled it under Master > Content > Scheduled Tasks - and because a disabled task never runs, nothing reported it again. Running long is a duration problem rather than a broken task, so the task now stays enabled and is rescheduled for its next interval. Tasks that fail for other reasons are still disabled as before, and the alert now names the task rather than only its ID.
Orphaned process reports say which phase each process stopped in. The report under Master > Development > Errors previously described only the single oldest orphaned process, so on a server with a backlog the relevant one was not the one described. It now lists the last recorded step for each process type it found, which is what identifies where the work actually stopped. |
| Broadcasts > Broadcasts - one-time sends no longer duplicate, and Scheduled broadcasts save again | Two fixes to the Data Broadcasts module (and the other scheduled-task modules that share the same scheduling: Data Transfer, Retention Policies, XML Conversion).
Duplicate sends on one-time broadcasts. A broadcast sent with "Send Now" (or scheduled to send once) could re-send repeatedly after its first send, because the task was not being marked as finished. It now sends once and then stops (Next Run shows "Never"). Recurring broadcasts set to repeat daily/weekly/monthly were never affected — they continue to send once per scheduled time.
Scheduled broadcasts would not save. When a broadcast was set to Send = Scheduled, the read-only "Next Run Date" field raised a "This field must contain a value" error that could not be cleared, blocking the save. The record now saves normally; the Next Run Date is calculated automatically on save. |
| Master > Development > Utilities - the nightly Clean Up task no longer checks database integrity | The scheduled Clean Up task, run nightly and also available from Master > Development > Utilities, no longer runs a database integrity check (CHECKDB) as part of its maintenance pass. This is a permanent change with no option to re-enable it - if your installation relies on Centralpoint for nightly database corruption detection and does not already run its own integrity check (for example, through a third-party maintenance solution), your database will no longer be checked for corruption automatically. We recommend confirming your own maintenance plan includes an integrity check, or contacting us to discuss options.
Three related reliability improvements ship alongside this:
- Clean Up's index and statistics maintenance step now reports its progress while it runs. Previously, a long-running maintenance pass on a large database could be misidentified as a stalled or abandoned process and closed out prematurely; it is now correctly recognized as active for as long as it is genuinely working.
- If a Clean Up is already running, a second attempt to start one - scheduled or manual - is now skipped rather than allowed to run at the same time, preventing duplicate maintenance work from overlapping.
- Process Monitor's detection of processes interrupted by a server restart or crash is more thorough. Some older interrupted processes were previously excluded from reporting entirely; they are now included in a single summary so a backlog is visible instead of hidden.
Separately, a public API used by custom site code to record long-running processes has been corrected so that processes it creates are attributed to the correct web site in Process Monitor rather than always appearing under the master site. Custom code using this API to track site-specific work will see its records properly scoped going forward. |
| AI Governance > AI Indexing - Available Modules can now be sorted by record count | The Available Modules tab under AI Governance > AI Indexing now has a Sort control beside the existing filter box. It offers three orders: Records (high to low), Records (low to high), and Name A-Z.
The grid now opens sorted by record count, largest first, instead of alphabetically. Enrolling a large module is the expensive operation, so the modules worth thinking hardest about before enrolling are the ones you see first. Modules with the same record count fall back to alphabetical order, so the list stays in a predictable order as counts change.
The sort applies to whatever the filter box has narrowed the list to, and both controls keep their settings while you enroll modules or move between tabs. The sort returns to Records (high to low) when the page is reloaded.
Two related corrections ship with this change. Changing the sort or the filter before the module list has loaded no longer replaces a load error, or the "vector indexing unavailable on this server" notice, with the message "All eligible modules are enrolled" - a failure to load is no longer able to display as a success. Record counts of zero are also now displayed consistently. |
| Design > Data Sources - Gamification Performance Enhancements | The Gamification data source type has been rewritten for performance. Each activity table is now read once per board rather than once per ranked row, and a Module Specific board now reads only the records belonging to its own module instead of every row in each activity table. Leaderboards that previously ran long enough to time out now return in about a second. The largest gains land on the sites with the most activity logged, which are the sites where these boards were slowest, so the gain grows with the size of a site's activity history rather than shrinking with it.
Alongside the performance work, several behaviors changed. Two of them change figures a client may have been reading, and four cover boards that previously failed outright.
- Revisions count. A record with no activity in the selected period now reports a revision count of 0 rather than -1, and no longer subtracts a point from its own total. This applies to any record whose activity all falls outside an active date filter, not only to records that were never touched, so it affects most rows on a typical board: in testing it moved about four of every five records. Because each affected record also gains a point, the ordering of a board can change wherever point totals were close. Point totals and ranking should be expected to differ from the previous release, and the new figures are the correct ones.
- Form submissions count. The count of form submissions per record was previously read from a shortened copy of the underlying data, so records referenced late in a large submission could be undercounted. That limit is gone, and the match is now made on the record identifier itself rather than by searching the submission's text, which also removes a dependency on the database's sort order settings. No change is expected on most sites, since the shortening only took effect on unusually large submission records, but sites that hit it will see submission counts and point totals rise to their correct values.
- Row ceiling. A gamification board now returns at most 1,000 rows, and its Excel and JSON exports are limited to the same. The
Limit attribute on the Gamification Configuration record can lower that ceiling but can no longer raise it. Previously an unset Limit allowed up to 10,000 rows, and a blank, non-numeric or zero Limit returned every matching row with no ceiling at all. No Gamification Configuration record currently in use sets a value the new ceiling would reduce, so no existing board is expected to truncate where it previously did not. The ceiling is there to stop a future misconfiguration returning an unbounded board and rendering it into the page. A Limit the ceiling rejects is now written to the page trace, so a board truncated against its own configuration can be diagnosed rather than guessed at. The ceiling applies to the leaderboard and Module Specific boards, which render every row into the page; a personal board is unaffected, as covered below.
- Personal boards now always show the signed-in user's own row. A gamification data source set to report on the current user only, rather than a full leaderboard, previously had to find that user inside the ranked rows it had already retrieved. A user ranked outside that set saw an empty panel with no explanation. The whole site is now ranked and the user's own row selected from that ranking, so a personal board reports correctly regardless of how the user ranks or how many people the site has. Sites large enough to have hit this will see previously blank personal panels start reporting.
- A misconfigured board now renders empty instead of raising an error. A gamification data source whose
GamificationConfiguration or GamificationModule attribute is missing, malformed, or points at a record that no longer exists now returns an empty board, with the reason recorded in Health Monitor. Previously this produced an entry in Admin > Errors. A board that stops reporting will now appear blank rather than announcing itself, so a blank gamification panel is the first thing to check, and Health Monitor is where the reason is recorded.
- Metrics whose module was never installed now report zero instead of failing the board. With no Gamification Configuration record every metric is treated as enabled, and the Logs, CE Reports and Forms metrics each read from a module that not every site has. On a site missing one of those modules the entire board previously failed to load. Those metrics now report 0 and the rest of the board renders normally.
- An empty board still returns its columns. A Module Specific board that cannot resolve its configuration now returns an empty result carrying the full set of columns, and the per-metric multiplier values a template may read are published on every path. A template that binds a column such as
Points, or reads a multiplier, no longer fails on an empty board.
- Module Specific author details. Each row shows the person who most recently touched that record. Where several entries share an identical timestamp, the name, email, last-login and photo are now all taken from the same entry, so a row can no longer pair one person's name with another person's photo. On those tied rows the person shown may differ from before.
- Date filters passed on the address bar. A
startDate or endDate supplied in the page address without a time zone is now interpreted in the viewer's own time zone and converted before filtering. Results for those links shift by the viewer's offset from UTC, and the new figures are the correct ones. A value that states its own time zone or offset is honored as given rather than being reinterpreted. A date falling outside the range the database accepts is now brought inside that range; previously such a value produced an error before the board ran, on a page that does not require sign-in. Date filters set on the Gamification Configuration record itself are unchanged, and continue to be compared exactly as stored.
- Module Specific boards now also return each record's identifier, auto-number and module, which allows the
ColumnFriendlyUrl script to build links to the ranked records. Templates that name their columns are unaffected; a template that lists every returned column will show three more.
|
| Master > Content > Web Sites - Web site restore now clears stale files and protects the shared Integrations content | Web site backup and restore have been improved. On the Master console under Content > Web Sites, open a web site to reach its Related Backups section: a "Create Backup" button creates a new backup, and a "Restore" checkbox beside each listed backup restores it. A web site can also be backed up from its own console under Development > Utilities > Backup Web Site.
When restoring a web site from a backup, the restore now correctly clears out old top-level folders before laying down the backup, so leftover files from removed modules no longer linger afterward.
The shared Integrations content is now protected across the entire backup/restore flow: it is excluded from a web site's backup, is never removed during a restore, and is left untouched by the post-restore configuration step. As a result, backing up or restoring one web site can no longer delete or overwrite the shared Integrations content that other web sites rely on. Restoring an older backup can likewise no longer overwrite these preserved folders.
Folder matching during backup and restore is now case-insensitive, matching how Windows treats folder names. Finally, if a restore cannot finish while extracting files, it now reports a clear message noting that the backup was preserved and that the extraction error should be resolved before re-running, instead of ending without explanation. |
| Master > Content > Scheduled Tasks - Database Maintenance no longer reports a healthy database whose transaction log your own backup schedule manages | The Database Maintenance scheduled task reported an error for every database not set to Simple recovery, on every run, no matter how small its transaction log was. On an installation where the database administrator deliberately runs Full recovery with a log-backup schedule, that produced one error notification per database per run for a condition nobody needed to act on, and which Centralpoint deliberately does not change.
The task now decides by recovery model:
- A database in Full recovery with an active log-backup chain is reported only when its transaction log is above the maintenance threshold of about 1.5 GB. Below that, the log is healthy, its owner manages it, and nothing is reported. An oversized log still reports, because at that point there is space to reclaim and only the database administrator can reclaim it.
- A database in Bulk-Logged recovery is reported at any log size. That setting is usually left behind by accident rather than chosen, and a routine log-backup job picks the database up either way, so size alone cannot tell the two apart.
- Maintenance that is deferred because a backup is running follows the same rule, so a database whose maintenance window always overlaps its own backup can no longer defer without ever being seen.
In every one of these cases the transaction log and the recovery model are left untouched, exactly as before. What changed is only whether the condition is reported.
Two further corrections ship with this:
- These maintenance messages no longer go to the site's Error Notification email. They are still recorded for review, so nothing is lost - they simply stop arriving in the inbox as though they were site errors.
- Each database in a run is now reported on its own. Previously the first database to report could suppress every other database's message for the following hour, so a genuine finding on a later database went unrecorded.
On an installation with more than one transaction log file, the log-shrink step now measures the file it is actually shrinking, instead of possibly measuring a different one and stopping early. |