• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 13 subscribers
  • Views 1730 views
  • Users 0 members are here
Options
Related

SP2023 in AD domain - WinPlatform deployed but can't go on-scan. Are there special requirements for network account, global/local security policies?

Evheniy

Hello to everyone,

We have small domain for testing SP2023 on Windows Server 2022 Standard which contains domain controller (AD DS, DNS, Hyper-V) and two Hyper-V VMs also with Windows Server 2022 Standard (no server roles). Domain was installed and functioning, any settings of global/local policies were did. The only additional action - we copied domain administrator account to SP administrator account in AD users and computers. First VM we are planning to use as GR (All-in-One-Node), second one - as AOS . During installation we indicate SP administrator account as network account and got message which warns that this account by group policy can be expired or password can be changed but we agree with that and installation continues.

After installation Configurator was not able to configure System Monitor Manager on GR (Error code - InternalServerError) but we left it for later. GR node was configured as SMS and AOS node was connected and registered successfully.

Firewalls are disabled, no MS updates were installed on Windows Server.

After we created new simple Galaxy from GR and AOS WinPlatform, deployed them. GR was deployed and started on-scan, but AOS started off-scan and any attempts put it on-scan has no success. During deploy and starting AOS on-scan Logger shows a several warnings and errors:

Warning MessageChannel Failed to communicate with target node, GR. This may be because it is not connected to the same System Management Server as this node (https://smdugr). If that is the case, use the Configurator on the target node, GR, and point it to the same Syste...

This is really strange as Configurator on AOS shows connection to GR

Info xxSecurity CSecurityChecker::internalLoadUserProfileInfo - failed to load security schema from user profile data
Error xxSecurity The CheckOperation Permission call is made to xxSecurity, but security information is not initialized
Error BaseRuntimeComponentServer INVALID HRESULT LINE 1658 FILE D:\ADO\Work\8\s\src\BaseRuntimeComponentServer\CBaseRuntimeObject.cpp hResult 80004005
Info xxSecurity CSecurityChecker::internalLoadUserProfileInfo - failed to load security schema from user profile data

Info aaBootstrap ManageRunningProcess Process 4536 seems to be not responding. It has a status 6. It hasn't notified the watchdog for 120234 ms. The process must respond to the watchdog within 90000 ms to be considered responsive
Warning aaBootstrap This process failed to send heartbeat and it exceeds maximum WatchdogFault.. This process will be restarted.
Warning aaBootstrap Pid:4536 Path:C:\Program Files (x86)\ArchestrA\Framework\Bin\aaEngine.exe Cmd:Deploy=False,Restart=True,ScanState=Last,CheckpointPath=,ClsId={BE4A11B6-86C2-49C6-883E-ABA501A6BCC7},EngineId=1,EngineName=AOS,EngineSignature=0,IsPlatformEngine=-1,Platf...
Info SoftwareControllerManager The process with id 4536 was terminated by the bootstrap because it failed to shutdown within 120.000 seconds
Warning aaBootstrap Platform with process ID 4536 was terminated abnormally

For me it looks like inconsistency in network account domain user settings, local or group policies, probably some DCOM questions.

Anyone can help?

Thanks in advance.

Parents
  • 0

    Hi

    Make sure that both GR and AOS nodes are configured with the identical account (either domain or local account) for System Platform Network Account on installation. You can launch the following utility from Windows Start Menu\AVEVA on both nodes to confirm if they are configured to use the same account. Changing the network account will require the restart of machines.

    You can also launch Common Service Portal from the same menu folder and then run "SCAN" to confirm if SMS is configured correctly on both nodes.

    Hope this would hep.

  • 0 in reply to Jacky Lang

     Hello Jacky,

    Thanks for reply. Network account is same for both nodes and is domain user, which was copied from administrator.

    Common Services Portal shows that no one of services is not running, list of Endpoints is empty.

    I think that problem somewhere outside, in OS or user settings.

  • 0 in reply to Evheniy

    Hi  Evheniy,

    The mismatched network account is a primary contribution to this issue. Another option is to temporarily modify Local Group Policy - Enable "Elevate without prompting" on the deployment target machine.

    In addition, check if both .Net 6 and 8 are installed on the target machine. I came across a case where .Net 6 components were not installed, which caused a lot of error messages in OCL.

    Hope this would help.

Reply
  • 0 in reply to Evheniy

    Hi  Evheniy,

    The mismatched network account is a primary contribution to this issue. Another option is to temporarily modify Local Group Policy - Enable "Elevate without prompting" on the deployment target machine.

    In addition, check if both .Net 6 and 8 are installed on the target machine. I came across a case where .Net 6 components were not installed, which caused a lot of error messages in OCL.

    Hope this would help.

Children
  • 0 in reply to Jacky Lang

    Hello Jacky,

    Thanks a lot for your reply.

    .NET 6 is installed, .NET 8 is not installed. Does .NET 8 absolutely needed?

    I did "Elevate without prompting" in Local Policies\Security options\User Account Control:Behaviour of the elevation prompt for administrators (before this setting was: Prompt for consent for non-Windows binaries). Sorry, it did not help. After I changed Network account from domain user in Administrators group to a local user which exists on both nodes with same name and password and also in Administrators group. It is also didn't help.

    So, current state - when both nodes are started the message appeared in AOSA logger:

    Warning MessageChannel Connection request from node AOSB failed. This may be because it is not connected to the same System Management Server as this node (https://aosa.domain.local). If that is the case, use the Configurator on the requesting node, AOSB, and point it ...

    and same in AOSB logger:

    Warning MessageChannel Failed to communicate with target node, AOSA. This may be because it is not connected to the same System Management Server as this node (https://aosa). If that is the case, use the Configurator on the target node, AOSA, and point it to the same...

    Don't how it is possible as far AOSA is SMS, AOSB is registered on AOSA through Configurator.

    After in Platform Manager I initiated Start on-scan of WinPlatform deployed at AOSB I got a lot of messages AOSB's log:

    Info xxSecurity CSecurityChecker::internalLoadUserProfileInfo - failed to load security schema from user profile data

    with following errors:

    Error xxSecurity The CheckOperation Permission call is made to xxSecurity, but security information is not initialized
    Error BaseRuntimeComponentServer INVALID HRESULT LINE 1658 FILE D:\ADO\Work\8\s\src\BaseRuntimeComponentServer\CBaseRuntimeObject.cpp hResult 80004005

    This messages appeared with both Network Accounts - and domain and local. What user is mentioned in Info message - Network Account? What is possible to do to "unblock" user profile data?

    Also when starting on-scan on AOSB I see messages:

    Warning xxSecurity CUserAuthenticatorImpl::LoadSecurityInfo - IGlobalDataCache::GetFile GalaxyData\data1.txt FAILED OperationResult 2

    I have file data1.txt at GlobalDataCacheSecure\GalaxyData on AOSA (GR) but it is not shared. Which sharing is expected - GalaxyData or Archestra Galaxy Data or GlobalDataCacheSecure\GalaxyData? On AOSB I do not have data1.txt file at same path.

    Thanks!

  • +1 in reply to Evheniy

    Hi  

    Oh, I just realized you are using SP2023 not SP2023R2. So, .NET 8 is not required.

    Warning MessageChannel for SMS can be ignored if it occurs one-off. I am guessing that it is due to a failure of the first attempt in encrypted connection. I also observed that this warning occasionally occurred in my testing system on deployment.

    Changing network account should reapply ACL to the system platform environment. As for the error code 0x80004005, an unspecific error (a cause for a failure in security), it is hard to narrow down. In your original report, you mentioned that no MS updates were installed on Windows Server. Could you try to install the updates? This could resolve the .NET 6 out of sync issue. For example, one of Windows Server Hosting, Windows .Net Runtime and Windows ASP.Net Core is missing.

    Sorry, I ran out of ideas. If the problem persists, please reach out to Technical Support for further troubleshooting.

  • 0 in reply to Jacky Lang

    Hello  

    Thanks a lot for your reply.

    I also have no more idea what to check and set. It should work but it doesn't. I'm going to re-install hosts OS and create new VMs.

    Just to be sure - if requirements of TN "Wonderware System Platform FAQs for IT Professionals"

    softwaresupportsp.aveva.com/

    are actual and there are no other or specific requirements for SP2023 in Active Directory domain?

    Do I have include Network Account in BUILT-IN\Administrators + aaAdminisrtators (or only to one of this group) or Change Network Account application will do everything what is needed for this domain's account?

    If I will choose to use local Network Account on every node - do I have include this account in local machine Administrators group or domain's BUILT-IN\Administrators + aaAdminisrtators (or only to one of this group). Or Change Network Account application will do everything what is needed for this local account?

    Do I have uncheck Use Sharing Wizard (Recommended) in folder options?

    Thanks in advance.

  • 0 in reply to Evheniy

    Hi  ,

    According to the installation guide of SP2023, it supports both domain and workgroup as well as Windows Server 2022 LTSC Standard and Datacenter.

    As for the network account, it should be included in the local Windows User groups, aaAdministrator and ASBSolution on each node of System Platform. The same user (with the same password) must be used across the entire system regardless a domain or local user account. 

    I am not aware there is any issue with Use Sharing Wizard when System Platform is being used as it is for the permissions for remote nodes to access the local files.

    If you would like to rebuild VMs, why not try SP2023R2?

  • 0 in reply to Jacky Lang

    Hello  

    Many thanks for your reply.

    I checked if Network Account is in Local Groups aaAdministrators and ASBSolution - it is.

    SP2023 because I would like to re-create customer's architecture.

    Yesterday I rebuilt VMs. The only difference from previous installation is that there are no warnings about SMS. But on-scan still there - I can deploy and undeploy WinPlatform but not start on-scan.

    While deploying, everything is going well up to marked moment:

    After info and later errors from xxSecurity appeared in log. Errors appeared immediately with warning "Communication error. Request timed out" in IDE:

    Do you know what user is mentioned whose security schema from profile data has failed to load in above log records? Probably it is a source of problem?

    Info xxSecurity CSecurityChecker::internalLoadUserProfileInfo - failed to load security schema from user profile data

    with following errors:

    Error xxSecurity The CheckOperation Permission call is made to xxSecurity, but security information is not initialized
    Error BaseRuntimeComponentServer INVALID HRESULT LINE 1637 FILE D:\ADO\Work\8\s\src\BaseRuntimeComponentServer\CBaseRuntimeObject.cpp hResult 80004005

    Thanks.

  • 0 in reply to Evheniy

    Hello  

    Finally it's working now. I switched off the online protection of Microsoft Defender Antivirus. Thanks again for your help!

  • 0 in reply to Evheniy

    Hi  ,

    I am glad that you sorted it out, and thanks for your feedback that the online protection of Microsoft Defender Antivirus actually caused the problem.

© 2024 AVEVA Group Limited or its subsidiaries. All Rights Reserved.