Case #07327200 — Restore-VEORDatabase errors out on Windows 2022

[dnumrich]

Case #07327200 — Restore-VEORDatabase errors out on Windows 2022

Hi guys, I was referred to the forums for this one. I'll just copy my initial opening remarks from my support ticket:

"I have a PowerShell script that performs restores. Since we upgraded one of our Windows servers hosting Oracle database to Windows Server 2022, we get the following error when attempting to use the PowerShell script:

Restore-VEORDatabase : The security identifier is not allowed to be the owner of this object.

Based on what I have seen online for this error, it is an error generated when PowerShell attempts to change attributes on a file or folder. The "Get-ACL" command seems to be the culprit in the majority of these cases.

I don't know if that's what's happening here, but my guess is that Restore-VEORDatabase might contain the Get-ACL command and that is why it's erroring out.

However, this all worked fine on a previous version of Windows, so I'm not sure why it's failing after upgrading to Windows 2022. I should add, in the spirit of full disclosure, that we had other permissions issues after the upgrade, too - I could not even edit files on the upgraded server until some changes were made."

It was determined by support that my script is "custom code", and is therefore unsupported. I did try my best to strip my script down to only the commands immediately necessary to provide the data required by the Restore-VEORDatabase cmdlet, but I could not simplify things enough to the point where my case was considered supportable.

At any rate, this is almost certainly a problem with Windows, as it occurred after an update, along with other issues not directly related to the restore. What I'm hoping to get from you is some direction as to where you think the problem might reside. I have worked with my server team on this, but we have not been able to clear this error even after messing around with our local security policies, file and folder permissions, etc.

Have any other users encountered this? Is Windows 2022 going to break Veeam PowerShell scripting for everyone, or am I just lucky? Thanks for any assistance you can provide. I'll even accept baseless speculation at this point

Duane Numrich, DBA
Saskatchewan Liquor and Gaming Authority

[PetrM]

Hi Duane,

Please give me have some time to clarify the situation with the support management. I'll update the topic as soon as I hear back from my colleagues.

Thanks!

[dnumrich]

Hi Petr. We had a successful restore today using the Restore-VEORDatabase cmdlet - solution seems to be to turn of UAC. We had thought this setting was already disabled. I logged in today and tried another test, which failed, but during the test I got a pop-up saying I had to restart to turn off the UAC. I restarted and my next attempt was successful. I know my server guys were doing stuff in the background too, so I'm not sure what the magic bullet was.

We will test some more to prove out whether it was UAC or something else, and I'll update this forum with whatever we find in case it can help someone else.

[dnumrich]

Yeah, this was a thing with UAC. I'm not entirely sure which security policy was adjusted to resolve this, but it's neither a Veeam issue nor an Oracle issue, it was a Windows security configuration problem.

[dnumrich]

Final note on this, it is a local security policy that allows members of the local admins group to run natively in elevated mode.

Implicated Policy:
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

Required Option:
Elevate without prompting

When we set the required option on the implicated policy things went back to normal - ie: everything worked the way it did prior to upgrading to Windows 2022. This setting was a choice we made on Microsoft's advice, but was not automatically set by the upgrade itself.

[dnumrich]

Even more final note, that above setting must be combined with:

Policy:
User Account Control: Turn on Admin Approval Mode

Option:
Disabled

I think this is actually the setting that was causing the issue. We had enabled this as recommended by MS, but it caused all sorts of problems for us.

[PetrM]

Hi Duane,

Many thanks for keeping us informed!

Thanks!