Home Server Server Troubleshooting Migrating to 4.6

Migrating to 4.6

This article applies when migrating to P2 Explorer v4.6.0 and later.

Relationships Between “Objects”

  • If one object doesn’t migrate (e.g. a user) then anything attached to that object (e.g. user) will not be migrated. Therefore, it’s common to have one failure to migrate, that will result in many failures from of all the attached data (roles, displays, workspaces, etc.).
     
  • Some of the time, this will result in a broken relationship (e.g. if a User isn’t migrated, the user won't be added to the role, but the role will still there).
     
  • Otherwise, it will result in a failure to migrate another object owned by that user (e.g. the user's private workspace and displays won't be migrated).

Authentication Types (Identity Providers) and Users

  • In previous releases of P2 Security, there were 3 authentication providers: Plain Text Password, Implicit Domain, and Explicit Domain. In this release, there are only two: Forms (equivalent to Plain Text Password) and Windows (equivalent to Implicit Domain and Explicit Domain).
     
  • After migration, the type of authentication used by the system is determined by what was set in the Is Enabled field in the P2.Security.Connect Authentications page, and is reflected on the new Login page:

  • If Implicit Domain Authentication was enabled, then users will be able to log in automatically, using their domain credentials (green button).
     
  • If Password Authentication was enabled, then users will be able to log in using a user name and password (blue button).
  • Explicit Domain Authentication was phased out a while ago, so users that have only an Explicit Domain Authentication login will not be migrated.
     
  • Users that don’t have a Login name will not be migrated.
     
  • In P2.Security.Connect, a Forms user could have a blank password. This is no longer possible. Anyone with a blank password will receive the password ‘password’.
  • In P2.Security.Connect, users could have multiple authentication types (now known as Login Method). In this release, users can only have one: Forms or Windows. This can be seen by the Login Method specified for a user in Server Management.
    • If a user had multiple authentication types, they will be migrated as a Windows user if their user name contains a forward slash, otherwise they will be migrated as a Forms user.
  • In P2.Security.Connect, user names did not need to be unique. In this release, users must now have unique user names, however display names do not need to be unique.
    • If multiple users with the same user name are encountered during migration, the user with the most recently created user name will be assigned that name, and will be assigned all the roles assigned to duplicate users. Other users with that user name will not be migrated, and must be manually created.
    • The “Login” field for the authentication method provides the user name. If the Display Name is blank, the Name field will be used as the display name.
  • The default Security Administrator user in In P2.Security.Connect will be mapped to the new seeded default Administrator user. This new Administrator user will have the default Administrators role, which will have Admin privileges for the Security, Server, and Explorer modules. It will be also given any extra roles it had in the previous version. If the default password was not changed, the account will be given the new default password, which is more secure.

Explorer Users and Roles

  • Previously, Security and Explorer were separate databases. Explorer would keep a reference (copy) to a security user and role via an identifier. So if a user was deleted from Security, it would still persist as a reference in the Explorer database. During migration, that user is unable to be found for migration, so it is common to see in the migration logs Explorer users that can’t be found. This also happens with Explorer roles.
     
  • Explorer 4.6 is one database, so no copies of users or roles are required to link to objects or provide security, users and roles are now referenced directly.
     
  • Previously, Explorer copies of roles were used to provide security to workspaces and pages/trends, and Explorer copies of users were used to link to explorer objects such as workspaces, pages/trends, snapshots, etc. 

Roles

  • The default security Administrators role will be given Admin module-level privileges to Security, Server, and Explorer, regardless of what they had before.

Application Roles

  • Application Roles in P2.Security.Connect are equivalent to certain privileges in the new system, as the following table shows:
Application Role In English Privilege In English
Administrator Security administrator Security Admin Can view/edit all security-related settings
Editor Server administrator Server Admin Full access to all Server (DataDictionary) objects
Image Editor Server image editor Images view/edit/delete Full access to all Server images
Tag Editor Server tag editor Datasources view/edit/delete/write Full access (including write to tags) for all Datasources and Tags
Calcs view/edit/delete Full access to Calculations
ExplorerAdministrator Explorer administrator Explorer Admin Full access to all Explorer objects
ExplorerStyleAdministrator Explorer style administrator Styles view/edit/delete Full access to Styles
ExplorerWorkspaceAdministrator Explorer workspace administrator Workspace view/edit/delete Full access to Workspaces (all public ones and your private one)
  • In P2.Security.Connect, Application Roles were mapped to actual Roles (global role mapping). The role that was mapped to the Application Role will receive the above privileges as well as their migrated privileges.
     
  • In order for any of these to be migrated, ensure that the names of the previous Server and Explorer "applications" (as defined in the old config tools under the Security tab) are specified in the Migration Utility.

Write Tag Privilege

  • Any datasources with the Write Tag check box selected (in Server Management) will receive the Write privilege for the Everyone role.
     
  • The Write Tag check box for datasources will now be used as a method of turning off the Write Tag feature for a datasource (making it read only). If not selected, no user will be able to write to the datasource.
     
  • In order for the Write privilege to work, the Write Tag check box for the datasource must be selected.
     
  • When it is not selected, the UI still allows you save Write privileges, however this will not work unless the Write Tag check box is selected on the datasource.

Comments

A comment will not be migrated if:

  • The comment text is empty.
     
  • There is no attached object (which is either a tag, entity, or entity attribute) or it is blank.
     
  • It can’t resolve the attached object. Note that the entity attribute is time-aware.
     
  • It can’t resolve the entity attribute at the Start Time of the comment. If the Start Time is null, it will try the End Time; if the End Time is null, it will try the comment Time (creation time).
     
  • Other cases where the data might have to change:
     

    • It can’t find the user that made the comment. If this happens it will assign the default Admin user.
       
    • The Last Modified time is less than the Creation time of the comment. If that happens, it will make the last modified time the same as the creation time.

Styles and Style Constants

  • The GUID identifier has to be unique in the database. If it is not, it will take the first one with that GUID. The GUID is the identifier that Explorer uses to specify styles in their pages.
     
  • Name has to be unique. If it is not, it will be given a different name such as “OriginalStyleName (1)”.
     
  • Name has to be less than 200 characters. If it is not, it will be truncated.
     
  • The style property must have either a link to a Style Constant or a value. The value can’t be blank. If both are specified, it will use the Style Constant.
     
  • Styles and Style Constants will be migrated with the same GUID, which will be their GlobalId (to be used for import/export when it is eventually added). This also ensures the pages get their styles.
     
  • Styles will no longer be referenced by GUID. The migrator will replace all style GUID in pages with the style name. If the style cannot be found (it is missing or wasn’t migrated), the reference to the GUID will stay in the HTML, but the style won’t be applied. If the page is edited later and a different style is applied it will overwrite the value.

Ribbon Config

  • Name has to be less than 200 characters. If it is not, it will be truncated.

Display states

  • Page/trend states will be migrated across with their original database IDs. This ensures links will still work, as they reference the database ID to identify a state.

Workspaces

  • If the user of a private workspace cannot be found (it doesn’t exist or wasn’t migrated) then the workspace and pages won’t be migrated.
     
  • Privileges for the workspace are migrated. However, individual page/trend privileges are not migrated. Be sure to check security after migration, as it may have changed as a result.
     
  • If the workspace security was set to “Allow All”, the Everyone role is given View, Edit, and Delete for the workspace.
     
  • The “Modify” privilege in the previous system gives a role View, Edit, and Delete privileges in the new system. “View” is the same as “View” in the new system.

Analytics Events

  • Some of the names of events have changed (see below).
     
  • Some events are no longer valid (not likely to occur on a customer site), so these won’t be migrated.

Valid event names

  • Load Explorer
  • Open Page
  • Open Page Direct
  • Open Trend
  • Open Trend Direct
  • Open Page Snaphsot
  • Open Trend Snapshot
  • Created Page
  • Deleted Page
  • Saved Page
  • Added Component
  • Moved Component
  • Deleted Component
  • Added Comment
  • Published Display
  • Published Display Overwrite

Changed event names

From To
Open Page Share Link Open Page Direct
Open Trend Share Link Open Trend Direct
Save Page Saved Page
Save New Page Created Page
Delete Page Deleted Page
AddedComponent Added Component
Published Over Page Published Display Overwrite

Displays (pages/trends)

  • If a user cannot be found, it will assign the default Admin as the Last Modified user.

Page specifics

  • Blank page content will be given the basic HTML needed for Studio. These are impossible to get except in raw mode, and no difference will be seen.
     
  • As mentioned, style references will be converted from GUID to name.

Trend specifics (also applies to snapshots)

  • If there is no state associated with a trend, the trend will not be migrated.
     
  • Trends with a blank state (blank trend) will be migrated.

Tags associated with a display

  • Duplicates will be removed (doesn’t make any functional difference).
     
  • If the tag doesn’t exist it will be removed from the display.

Display publishing submissions history

If a submission doesn’t have the fields required in the new system, it is not migrated because it is historical information. The following won’t be migrated:

  • Submitted user is missing.
  • Display is missing.
  • Status is not one of “SubmittedForApproval”, “Approved”, or “Rejected”.
  • Submission is Approved or Rejected, and either outcome user or outcome date is missing.

 

Comments are closed