Upgrade failed from WMS 3.3.1 to 3.5

Hey,

same problem here. Also on a domain controller, same error in log.
Reverting back the changes after the failed upgrade did not work, so restore from backup to get the 3.3.1 Version working again was necessary.
I tried to edit the User manually and disabled the password expiration, but then the Setup complains about User already exists.
At the moment I don't have any more ideas about it.

Regads,
Daniel

Hi again,

Same issue when trying 3.5.1 (released yesterday from what I can see.)

2021-12-14 T13:10:09::Upgrade::2829::Running Action: ConfigureJavaForUpgrade
2021-12-14 T13:10:09::Upgrade::2833::Copy C:\Program Files\DELL\WMS\Archive\OpenJDK-11.0.12\lib\security\cacerts toC:\Program Files\DELL\WMS\OpenJDK-11.0.12\lib\security
2021-12-14 T13:10:11::CustomFunctions::5976::szFormattedVersion1: 3.3.1.0
szFormattedVersion2: 3.5.0.0
2021-12-14 T13:10:11::CustomFunctions::6118::In function createwmsuser
2021-12-14 T13:10:12::CustomFunctions::6129::User Created Successfully: The operation completed successfully.

2021-12-14 T13:10:21::CustomFunctions::6141::Failed to set change password policy
2021-12-14 T13:10:40::Upgrade::634::User creation failed, hence restoring...

Please advise, issue still persists on domain controller. Have tried this in 2 DC's, in 2 different environments.

Thanks,

Ted Tsoukas

I KNOW THE ISSUE!!!!  Just battled as we speak.  It is trying to create a local account during the installer.  If you have a Domain Password Policy applying to this server, it will fail.  Here is the work around.  Throw this server in deny policy for that GPO temporarily.  It will then be able to create the lame local user for that server and use it for all services once going to 3.5.  Then the installer will complete.  Go into the services and stop them, change to a domain service account that has access to the installer and repo share.  Then you can upgrade to 3.5.1 just fine.  Also you can double back and remove the temp GPO deny and delete the local user account that was created.  Hope that helps!

This indeed seems not fixable directly on a Domain Controller or someone from Dell needs to read this and fix this issue. What you can however do to mitigate the LOG4J vulnerability is to upgrade to version 3.3.1 and then goto [WMSInstalldir]\Tomcat-9\bin\ and run tomcat9w.exe. Goto tappage Java and add the following option in a new line to the Java Options:
-Dlog4j2.formatMsgNoLookups=true

Just to double it up (better twice the once) you can in Windows Server also add an Environmental Variable. Goto Control Panel --> System --> Advanced System Settings --> Environmental Variables --> Under System Variables add a new entry:
Variable name: LOG4J_FORMAT_MSG_NO_LOOKUPS
Variable value: TRUE

According to: https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

Hey Drewsky,

Thanks for providing some info about the issue.

I tried following your guide but could never get past user creation:

2021-12-17 T02:57:25::CustomFunctions::6139::Failed to set change password policy
2021-12-17 T02:57:35::Upgrade::598::User creation failed, hence restoring...

The server I am trying to upgrade WMS on is running Windows Server 2019 Build 17763.2366 and is a domain controller.

yigitcan.killik in this post has the extact same issue: https://www.dell.com/community/Wyse-Management-Suite/upgrade-failed-3-3-1-to-3-5-Failed-to-set-change-password-policy/m-p/8104910#M544 

I have tried adding deny delegation to the default domain policy, creating a new GPO to set specific password requirements, running upgrade as administrator, upgrading from 3.3 to 3.3.1 then to 3.5.

Are you able to provide some more detail about your setup and as to how you were able to get past the user creation error.

Cheers,

Simon

I experienced the same issue and error in WMSInstall.log. I was running the installer from a domain user account with administrator permissions. After trying several things I eventually found a work around. It didn't require removing it from the domain or disabling the default domain policy for password complexity as other have mentioned. What I did was login to the server with a local server admin account and ran the install. It completed the setup from 3.3.1 to 3.5. I then did the same process from 3.5 to 3.5.1.

So the issue seems to be connected to running the install from a domain account. Just trying using a local server account and it should work.

Was able to get past the "failed to set password change policy" issue by temporarily blocking inheritance on the OU our on-prem WMS server was in, so that the domain password policy wasn't applying, then re-running the install (kudos to @Drewsky25 there). Had another issue where it failed out for "failed to grant folder level permission for LocalRepo", the fix there was to add the path for the local repository to the Uninstall key for WMS (HKLM\software\wow6432node\microsoft\windows\currentversion\uninstall\{guid-for-wms-install}\, reg_sz "LocalRepository" = "C:\path\to\repo") in case anyone runs in to that one.

I am having this issue as well but am NOT using a DC

I was able to resolve my issue. The fix is as follows:
 

Move Computer object to OU with no GPO policies applied (specifically password policies but this is easiest overall)

run gpupdate /force /boot

Sign into machine using LOCAL admin - DO NOT use Domain admin account

Process the update

Optional (Best practice)
Create a domain service account for the following services and add to Administrators group on local machine hosting WMS

Go into services and associate the following with the service account:

Dell WMS: Software Vault
Dell WMS: Maria DB
Dell WMS: Memcached
Dell WMS: MongoDB
Dell WMS: MQTT Broker
Dell WMS: Tomcat Service

Delete the local account created during 3.5 upgrade (wmsuser by default)

Reboot and test

After testing move computer object to Appropriate location and test again to ensure everything is working. 

@KRoyalthat would be a good idea but won't recommend doing so if the machine is a domain controller. Dell should just come up with a new installation where the user can choose and let the installer create the service account or the user can browse for custom service account...

So Dell, when can we expect an update?

Hello,
when we start the upgrade from 3.3.1 to 3.5 (or even newer 3.5.2) we always get the following error:
"Current MongoDB is 4.2.12. WMS requires 4.2.16”....
Anyone experienced the same error and has a solution for this?

Hi PDGROOTE65,

please see this article on updating the MongoDB version ive just done it and it worked ok

https://www.dell.com/community/Wyse-Management-Suite/MongoDB-upgrade-needed-to-go-from-3-31-to-3-5-and-beyond/td-p/8104061

although ive got other issues with the portal not working after installing 3.5.2 

regards

Founded the solution.

You must enter a password that corresponds to your internal password rule (for me imposed by GPO). I generated a password of 16 characters, digit, uppercase, lowercase, special character) and it passed.

The installer for version 3.5 blocks and only gives the message at the very end of the installation, so a lot of wasted time.

In the installer of version 3.6, the user verification is done at the beginning, it is much more convenient.

If you're experiencing an upgrade failure from WMS 3.3.1 to 3.5, here are some troubleshooting steps you can try:

Check system requirements: Verify that your system meets the minimum system requirements for WMS 3.5. Check the system requirements listed in the WMS 3.5 release notes, and ensure that your system meets all the requirements.

Review error logs: Check the error logs generated during the upgrade process. The error logs can help you identify the cause of the upgrade failure. Look for any error messages or warnings in the logs, and use them to troubleshoot the issue.