When using the Microsoft-provided PowerShell scripts to assist with an upgrade from Portals v7 to v8, there are a few known issues that could still leave your data in an undesirable state. We’ve released an XrmToolBox plugin to help address a couple of those items.

The End is Nigh

We’re now less then two weeks away from the official end-of-life of Adxstudio Portals v7, which occurs on August 1, 2018. If you haven’t considered upgrading to either the Microsoft-hosted version of the Portal Capabilities for Dynamics 365, or xRM Portals Community Edition, now is the time!

If you follow the “upgrade” option described in the official Microsoft migration document, you are able to leverage all of your existing web page and web file data. However, the document highlights a few items that might still cause issues even after following the upgrade steps. Engineered Code has released an XrmToolBox plugin to help address a couple of those items.

Inactive Root Web Pages with Active Localized Pages

One of the major schema changes between v7 and v8 was the introduction of the concept of “root” web pages, used for the multi-lingual implementation. In v8, multi-lingual is implemented by having a “root” Web Page record that acts as a non-language-specific placeholder/container, and then one Web Page record for each enabled language, which we refer to as the localized web page. The “root” Web Page is identified by having the Is Root (adx_isroot) field set to true, and the localized pages are all related to this root web page by a self-referential 1:N relationship.

Of course, if you currently have a v7 data schema, you’ll only have one Web Page record per page. To leverage the new v8 code, you need at least two records per page – the root webpage, and one language-specific localized page. Thankfully, Microsoft has provided code as part of their upgrade PowerShell scripts to automatically create these extra records for you. However, there is at least one known situation where after using the scripts the data get into an undesirable state, and that’s if you have any inactive web page records.

When you “delete” a record using the front-side editing capabilities of Portals, the record isn’t actually deleted; instead, it is just deactivated. The upgrade script marks existing web page records as the “root” web page by checking the Is Root field, and then creates a copy of the record for the localized page. However, the localized web page it creates is always active, even if the original record, now the root web page, is inactive. This leads to the situation where pages that you previously deleted reappear in the sitemap of your Portal, but when clicking the links, you get a Page Not Found error.

Our XrmToolBox plugin identifies any inactive root web page records associated to active localized web page records, and allows you to deactivate the localized web pages.

Web Files with Spaces in the Partial URL

This issue isn’t related to data being upgraded via the scripts – instead, there is a difference in some of the code that handles URLs in v8 as compared to v7. Specifically, spaces are no longer allowed in the Partial URLs for Web Files. This includes the actual space character (” “), as well as the encoded representation of a space, %20.

In v7, if you uploaded a file to a web file that contained a space in the filename, the system automatically replaced spaces with %20. This is no longer valid in v8.

Our plugin identifies any web file where the Partial URL contains a space or %20, and allows you to remove those characters. It also searches through the Copy and Summary attributes of Web Page entities and looks for any references to that web file, identifying them in the log.

Originally, we did have code that would perform a find-and-replace of the partial URL of those web files in the web page records, but we determined it was too risky to be used in anything but the most trivial situations. Since web file partial URLs can be almost anything, including without any file extension, performing an automatic find-and-replace could have led to content being unintentionally updated – for example, if you have a web file with a URL like some file, real content that contained that text would see the spaces removed. So we decided to remove those capabilities, and just provide the report so that the records that may possibly need to be updated are identified, but manual intervention is required to make the changes.

The plugin is available in the XrmToolBox Plugins Store, and is called Portals v7 to v8 Cleanup.