locked
unable to update from CM 1902 to CM 1910 RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi All,

    I am using SQL Always on HA....

    HQ has 2 node cluster for HA (sql1 and sql2) Default Instance

    SQL Cluster Name: SQLCluster

    DR has one standalone node (DRSQL1) for Secondary copy. Named Instance

    We have added file share witness for HQ because it has 2 node only.

    while trying to update to 1910, prerequisites passed successfully but getting error in cmupdate.log

    successfully failing over to secondary but while failing back to original primary, there is error sqlcluster\ConfigMgr_DViewAccess not found.

    failed to create group for distributed view access.

    failed to apply update changes 0x87d20b15.

    Thanks

    Manish

    Manish

    Wednesday, December 25, 2019 8:46 AM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    as prerequisites of configmgr update. If you have SQL configured HA, you have to switch to manual failover before the upgrade. 

    check the checklist before the upgrade 

    https://docs.microsoft.com/en-us/configmgr/core/servers/manage/checklist-for-installing-update-1910

    Set SQL Server AlwaysOn availability groups to manual failover

    If you use an availability group, make sure that the availability group is set to manual failover before you start the update installation. After the site has updated, you can restore failover to be automatic. For more information, see SQL Server AlwaysOn for a site database.

    Disable site maintenance tasks at each site

    Before you install the update, disable any site maintenance task that might run during the time the update process is active. For example, but not limited to:

    • Backup Site Server
    • Delete Aged Client Operations
    • Delete Aged Discovery Data

    When a site database maintenance task runs during the update installation, the update installation can fail. Before you disable a task, record the schedule of the task so you can restore its configuration after the update has been installed.

    Thursday, December 26, 2019 1:02 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Dear I have applied the suggestion but still getting the same error. 

    failed to create group for distributed view access.

    ConfigureAOReplica (AG) - failed to create distributed view local group.

    Failed to configure the replica.

    Thanks

    Manish

    Manish

    Sunday, December 29, 2019 6:12 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    if the group isn't created try to created manually then retry the upgrade, it seems configMgr is having a trouble creating this group on site database server, check this article for more details.

    https://docs.microsoft.com/en-us/previous-versions/system-center/system-center-2012-R2/hh427337(v=technet.10)?redirectedfrom=MSDN

    ConfigMgr_DViewAccess

    This group is a local security group created on the site database server or database replica server by System Center 2012 Configuration Manager and is not currently used. This group is reserved for future use by Configuration Manager.

    Mohamed MCDST | MCSA | MCSE | Azure solutions Architect.

    Sunday, December 29, 2019 7:23 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    this group is already created there on all SQL nodes...but its looking for SQL Cluster NAME\ConfigMge_DviewAccess...

    it looks strange to me..

    Manish

    Sunday, December 29, 2019 9:53 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi,

    May we know the current status of the problem? Is there any other update?
    If the issue is urgent for you, then it is recommended that you contact Microsoft Customer Support Services (CSS) for a dedicated Support. 

    Regards,
    Allen

    Please remember to mark the replies as answers if they help.

    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, January 2, 2020 6:56 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    still issue persist but not that urgent, i would like to solve with the help of support forum..

    thanks

    Manish

    Manish

    Thursday, January 2, 2020 9:06 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Still no luck...is there anyone...for help

    Manish

    Saturday, July 18, 2020 8:45 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Additional error you will see in the CMUpdate.log is:

    "[SQL Server Native Client 11.0][The login has an account under a different user name."

    We are experiencing the same problem with an upgrade from 1910 to 2002. The SQL Logins <SQLServer>\ConfigMgr_DViewAccess may be mismatched with the database login name.

    On the 1st node, it should be Username: node1\ConfigMgr_DViewAccess with Login name: node1\ConfigMgr_DViewAccess

    and on 2nd node, user name: node2\ConfigMgr_DViewAccess with login name: node2\ConfigMgr_DViewAccess

    somehow, one of those logins is miss-matched between the user name with login name, so it cannot be corrected during the upgrade. Working with Microsoft on a supported fix....

    As suspected, the sql logins and database users became mismatched and there was a SID conflict caused by a SQL replica being improperly restored, which caused a SID for ConfigMgr_DViewAccess local group on one node being used on another node.

    We basically deleted the node(n)\ConfigMgr_DViewAccess sql login and database user accounts on all nodes and deleted the node(n)\ConfigMgr_DViewAccess local groups on each.

    As noted above, be careful making database changes without Microsoft Support, as this could potentially put you in an unsupported condition.

    When standing up Endpoint Configuration Manager using SQL Always On availability groups, be sure to following the process outlined here. https://docs.microsoft.com/en-us/mem/configmgr/core/servers/deploy/configure/configure-aoag#bkmk_configure

    Joe Thompson



    Wednesday, July 29, 2020 8:08 PM