SharePoint Online – BLANKINTERNET#0 Publishing Portal and Modern Pages
Hi everyone, I’m trying to understand the recommended approach for an existing SharePoint Online site based on the BLANKINTERNET#0 template (Publishing Site / Publishing Portal). The site is still based on the classic SharePoint architecture and currently uses: a custom Master Page; Publishing Pages; custom Web Parts developed with SharePoint Framework (SPFx); the SPFx Web Parts also communicate with a backend/API developed using .NET Framework 4.8. I’ve read Microsoft’s recent announcement regarding the deprecation of classic publishing sites and classic user-created pages. As I understand it: starting March 1, 2027, the creation of new classic publishing sites and activation of the classic publishing features will be disabled; starting October 1, 2028, existing classic user-created pages, including Publishing Pages, will become read-only; existing pages will not be deleted, but users will no longer be able to create or edit them; Microsoft recommends assessing and gradually modernizing classic content to modern SharePoint experiences. However, I’m confused about the recommended modernization path for an existing Publishing Portal. The deprecation announcement made me think that one possible approach would be to progressively replace the existing classic pages with Modern Pages. However, in Microsoft’s documentation about modernizing classic publishing portals, I found the following statement: "For publishing portals (sites based upon BLANKINTERNET#0, ENTERWIKI#0, SRCHCEN#0, SRCHCENTERLITE#0, BICENTERSITE#0, POINTPUBLISHINGHUB#0, POINTPUBLISHINGTOPIC#0 or sites using the “Pages” library) it's not currently supported to connect these to a Microsoft 365 group or to use modern pages. If you want to modernize your publishing portal it's recommended to start from a new communication site and configure that one accordingly." This raises an important question for my scenario. My question For an existing BLANKINTERNET#0 Publishing Portal, is it currently supported to: A) Keep the existing Publishing Portal and progressively create/use Modern Pages within the same site, migrating the content from the existing classic Publishing Pages to Modern Pages so that the content remains editable after 2028? Or: B) Are Modern Pages actually not supported in an existing BLANKINTERNET#0 Publishing Portal, meaning that the supported modernization path is to create a new Communication Site and migrate/configure the content there? I would particularly like to understand what Microsoft currently considers the officially supported approach. In other words: For an existing BLANKINTERNET#0 Publishing Portal, can I progressively replace the classic Publishing Pages with Modern Pages within the same site, or do I need to create a new Communication Site and migrate the content there in order to move away from the classic Publishing architecture? I would like to avoid a full migration to a new Communication Site if it is not necessary, but at the same time I want to make sure that I’m not implementing an approach that Microsoft considers unsupported. Thanks in advance for any clarification!
Publisher ExportAsFixedFormat ignores “Publication Page” while manual PDF/XPS export works
I am migrating a large archive of Microsoft Publisher files to PDF before Publisher is retired. We have isolated a repeatable problem in older publications. Example publication: Publisher page size: 210 x 148 mm, landscape • Manual export through File → Export → Create PDF/XPS → Options → Print Options • Settings shown by Publisher: • One page per sheet • Paper size: Publication Page • 210 x 148 mm • Landscape • Resulting PDF: 210 x 148 mm — correct However, both PowerShell/COM and VBA using Document.ExportAsFixedFormat produce a 215.9 x 279.4 mm portrait PDF. Explicitly using: PrintStyle:=pbPrintStyleOnePagePerSheet does not fix the problem. We tested the same publication using: Application.CommandBars.ExecuteMso "FileSaveAsPdfOrXps" This opens Publisher’s own PDF/XPS dialog. The dialog still shows Publication Page, 210 x 148 mm, landscape, and when published through that UI the resulting PDF is correct. We analysed 349 Publisher files: •120 exported with the correct page size • 229 exported with the wrong page size • all 229 failing files opened with an Adobe PDF / A4 portrait printer context The Publisher PageSetup.PageWidth and PageHeight values themselves remain correct. Question: Is there any documented or undocumented Publisher VBA/COM property, parameter, registry setting, or command that corresponds specifically to the PDF/XPS Print Options setting “Paper size: Publication Page”? In other words, how can ExportAsFixedFormat be made to reproduce exactly the same page-size behaviour as Publisher’s interactive PDF/XPS dialog? If this is not exposed through the Publisher object model, is automating the built-in FileSaveAsPdfOrXps command the only reliable approach? Publisher: Microsoft 365 desktop version on Windows.
Join Microsoft and M-Files on Sept 23: Content readiness for AI and Agents webinar
What does it take to get your content ready for Microsoft Copilot and Agentic AI? Join M-Files and Microsoft for the “https://aka.ms/SPEmbedded/Webinar/M-Files-20260923” webinar on September 23, 2pm ET, to find out. Ian Story, Principal Product Manager, Microsoft, will be presenting with Cheryl McKinnon (Principal Analyst, Forrester) and Ryan Barry (Vice President of Strategic Operations & Corporate Development, M-Files). Together they'll explore what it takes to make enterprise content ready for the next generation of AI-powered applications and agents. https://aka.ms/SPEmbedded/Webinar/M-Files-20260923 In this webinar, you’ll hear practical perspectives on how to: Assess content readiness: Identify the quality, governance, access, and discoverability gaps that can limit Copilot and agent outcomes. Build a trusted knowledge foundation: Keep content secure, compliant, and permission-aware while making it easier for AI to retrieve the right information. Reduce fragmentation: Bring content and context together so users and agents can work with higher precision. Prepare for agentic workflows: Move beyond static document storage toward intelligent, adaptive content experiences that support reasoning and action. See you there!
Setting app page is not getting localized in windows server OS 2025 with official language pack ISO
We created a VM on ESXi with Windows Server 2025 and installed the language packs offline using the official language pack ISO for Windows Server 2025. Most of the UI was localized successfully, but the Settings app was not localized. We tested this with the Japanese language pack and also tried installing it using both PowerShell and DISM. Is this a known issue? Has anyone else encountered the same behavior? If so, is there any known solution?Sharepoint view level permissions
Hello, I’m facing an issue in SharePoint. I have a main list where I need to create two views one for “A” users and another for “B” users. What should change is, for example, that “A” users can only see column “A” and “B” users can only see column “B”. And being sensitive data, they shouldn't be able see each other's columns. Using different lists is the only viable way I currently see this working, which i don't really want since this requires a lot more of work, unless someone can suggest a better solution. Note that currently I'm using two different pages inside the same website for user's "A" and "B". Thank you very much.I'm looking for a practical way to calculate Pakistan salary income tax in Excel.
The goal would be to enter a monthly salary and have the spreadsheet estimate the applicable tax and resulting take-home amount. Ideally, the calculation should be easy to update when the applicable tax slabs or salary-related rules change. For someone building this in Excel, would you recommend keeping the tax slabs in a separate lookup table and using formulas against that table, rather than hard-coding the rates into one large formula? I'm particularly interested in approaches that make the spreadsheet easier to maintain when tax rules change.Invoke-PnPSiteTemplate slower than it used to be
Hi everyone, Since last Friday, our provisioning engine has become noticeably slower than usual, and it's now blocking site creation for one of our customers. Setup Azure Function App (Windows OS, Consumption plan, hard 10-min timeout) Provisioning engine applies a PnP site template to newly created SharePoint sites via Invoke-PnPSiteTemplate PnP PowerShell: 2.12.0 PowerShell: 7.6 What changed Previously, if a run went over the 10-min limit, it wasn't a real problem: our retry mechanism kicked in, and the second pass was much faster because a large part of the template had already been provisioned. Now, however, every run stays slow and consistently hits the 10-min timeout, so the retry never gets far enough to complete. The result is that the customer's sites are no longer being created. My question Has anyone else seen this same slowdown since last Friday? Could this be related to the recent CSOM issue with Invoke-PnPSiteTemplate / Set-PnPDefaultColumnValues? (Invoke-PnPSiteTemplate AND Set-PnPDefaultColumnValues error since this morning | Microsoft Community Hub) Any confirmation or workarounds would be greatly appreciated. Thanks!
