Hi Darren Williams here are the essentials I've found necessary for this all to work:  To be safe I ensure both the SQL service can write to the SITE folder and ensure I'm running Database Setup as Local Admin the first time so it can write anything it needs.  Always perform these steps as a Domain Admin or as a Domain user with Local Admin rights, and perform it on the Sage 300 App server itself, not a workstation.  If you need to as well, set the permissions to the Sage 300 share as "Everyone" just for this step with full control, then immediately remove this insecure permissions once its setup.

When the error occurs, check the Event Viewer as the entries in there under Error will show the true problem causing the issue.  In my cause it was a permissions error hence I was able to come up with the above to ensure it works.

There is a known activation bug on Windows 11, so perhaps there is another - so make sure you're not doing this from Windows 11 and again try it from the Sage App server itself.

Good luck!

I've done most of the above. I haven't checked to see if SQL service has rights to the SITE folder yet. Running as a user with full admin rights and running database setup with run as admin. Also running this from the Sage App server running a server OS. The App server, shared data and SQL are all on different machines. Question: Would simply manually creating the VAULT folder and VaultSettngs.ini work?

I've never tried it so I'm not sure but if I had to guess I'd say likely not.  The problem is even when you install a fresh copy of 2024, essentially you're installing regular Sage 300 then performing the enhanced security update the first time you open Database Setup.  So if something goes wrong, you have to blow away the entire Sage 300 install (I would delete the registry key and the works and load fresh data because I have no idea what changes there too) then attempt the migration to Enhanced Security again.  I'm guessing you've already submitted a query to Sage support for guidance and haven't had any luck?  The process I would follow is:

1. Start with a fresh VM or roll back to a checkpoint before the install of PU5.
2. Delete all PU5 related materials from the new SQL server - the Sage30VaultOwner account, all the new user accounts - anything not related to the PU1 version.  Clean it all up.  Maybe PU5 is trying to create users which already exist from previous attempts that are confusing it.  If a new SQL server, blow it away if you have to then snapshot/checkpoint it after initial setup for future rollback.
3. Copy your Sage 300 2023 PU1 Programs and Shared Data to the new server
4. Install Sage 300 2023 onto the new server selecting the same paths.
5. Install PU1 onto the new server.
6. Check you can login to your company databases and everything is working well.
   1. At this stage you have an exact copy of your existing server.
7. Take a snapshot/checkpoint of the VM so you can rollback immediately if it doesn't work.
8. Install PU5.  Restart if prompted.
9. Ensue your Local Security Policy on SQL Server has 0 for minimum password age, 0 for maximum password age.
10. Setup your Vault and Store databases, create a Sage300VaultOwner SQL account and ensure it has db_owner permissions to the new databases - I forget what the enhanced security guide says but follow it verbatim.
11. Open Database Setup and follow the steps to migrate.

Essentially I've only had an issue when not starting from a clean base and Sage haven't provided a site reset tool for this new architecture.

Cheers...Tim

There is an open case with Sage. I didn't go through all those steps as the enhanced security never made it far enough to make any changes as far as I could see. I simply did a 2023 base product repair install, then re-ran PU1. Everything is working fine.

I'll see what Sage comes up with and if it works I'll post it here. I suspect it's some sort of permissions issue with the SITE folder as it's on a different server, even though the user I'm installing with has full admin rights. I might try the temp "read/write" permission for all users suggestion, I just really don't want to have to go back to another restore after a failure.

Hi Darren, do you mean the SharedData and Programs are on different servers?  That should be fine if they're both on the same domain, and more importantly, that the SQL server is on the same domain, and your're running as a Domain Admin.  The SQL server plays a critical role now and the Local Security Policy on the SQL server drivers the Sage 300 password rules with Enhanced Security.  Again, if all three of these servers are on the same domain, and you're running as a Domain Admin, I agree all should be OK.  Have you double-checked that none of the PU5 components (i.e. ##S3_LOGIN_***##SAGE300VAULT) were added on the SQL server?  And was your Sage300VaultOwner SQL Auth account given high privileges to do all the things it needed i.e. sysadmin?  All the best.

Yes. Programs on Server A, Shared Data on Server B, SQL on Server C. Same domain. None of the PU5 components are installed in SQL. SageVaultOwner has dbcreator, public, securityadmin, serveradmin, sysadmin rights. 

The ONLY thing I am not sure of is if the user I am using has domain admin rights on the Shared Data server, but it does have full read/write permissions on the SharedData folder and all sub folders

Hi Darren Williams Domain Admin = Admin across all serves, computers, users and other objects across anything on the domain, so that would definitely include the Shared Data server.  Unless you mean you have a Domain Account with selected Local Admin rights to relevant Sage related objects across the domain, though this wouldn't be a Domain Admin in that case.  So that means you're installing the Sage server software onto Server A with SharedData pointing to a path on Server B and databases on server C?  Yeah that should work as Server B in this case is simply acting as a glorified NAS or storage device - no services, computing or anything else going on there.  Well good luck, sounds like you're on top of it, just very unlucky.  Cheers.