Version 2024.1.4.0 (March 5, 2024)

After creating a DVLS standby instance to test the upgrade from 2023.3.14.0 to 2024.1.4.0, the upgrade goes horribly wrong.
After the upgrade completing, authenticating to the website, errors are automatically generated.
I can reproduce this 100% of the time
Rolling back to previous version

resetting the domain cache seems to have resolved he errors. Wil continue to test

Hello,

Thank you for your feedback, and glad that resetting the domain cache seems to have solved the issue.

Let us know if there is any other issue with your DVLS 2024.1 staging instance.

Best regards,

upgrading standby instance was successful after a couple of small errors.
Attempting to upgrade production instance ends in error.
System.UnauthorizedAccessException: Access to the path 'C:\inetpub\wwwroot\dvls\Devolutions.dll' is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.InternalDelete(String path, Boolean checkHost)
at System.IO.File.Delete(String path)
at Devolutions.Utils.FileUtils.DeleteDirectory(String path, Boolean deleteStartingDirectory, Boolean recursive, Boolean deleteSubDirectories, Boolean throwError, String[] excludingFiles, String[] includingFiles, String[] excludeDirectories)
at DPS.Console.Common.Business.Action.Server.Upgrade.Steps.DeployContent.Run()

Upgrade automatically roles back to previous version

Hello Sonny,

I opened a ticket on your behalf and sent you an email.

Keep an eye out.

Best regards,
Marc-Antoine Dubois

Hello,

after the update if I access the servers I get these errors:


The following error
was received by admin at 03/10/2024 15:49:26


Error:

NullReferenceException
- Object reference not set to an instance of an object. at
Devolutions.Server.ConnectionLogManager.LogUserRoleAssignmentChange(ISessionContext
context, Nullable`1 contextId, UserEntity beforeUser, UserEntity afterRole)
at Devolutions.Server.UserManager.SaveUser(ISessionContext context,
UserEntity userToSave, SaveUserElement savedElement, LicenseUserService
userLicenseService, Boolean clearLinkedAccount) at
Devolutions.Server.RoleManager.UpdateRoleUsers(ISessionContext context, Guid
roleId, RoleAssignment[] assignments) at
Devolutions.Server.Controllers.APIControllers.V2.SecurityController.UpdateRoleAssignments(Guid
roleId, RoleAssignment[] assignments) at lambda_method2633(Closure, Object,
Object[]) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeActionMethodAsync()
at
Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State&
next, Scope& scope, Object& state, Boolean& isCompleted) at
Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeNextActionFilterAsync()
--- End of stack trace from previous location --- at
Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed
context) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State&
next, Scope& scope, Object& state, Boolean& isCompleted) at
Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location --- at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextExceptionFilterAsync>g__Awaited|26_0(ResourceInvoker
invoker, Task lastTask, State next, Scope scope, Object state, Boolean
isCompleted) --- Default

Source:

Devolutions.Server.Common

Hello,

What authentication type are you using in DVLS?

If it's Domain or Microsoft, is the Enable Cache feature option enabled?



If so, please try to disable it and reset the DVLS cache in Administration - Reset Server Cache on the DVLS web UI.

Best regards,

Hello.
before the update I saw only privileged accesses associated with me.
After the update I see all accounts. Not having the rights generates errors.

Hello,

Thank you for reporting this behavior.

We will investigate and keep you updated.

Best regards,

Hello,

What permissions are set on the PAM accounts you should not see?

Is it possible that you get Reader permissions on the Vault's root record and that the PAM accounts have Reader permission set to Inherited?

If so, then set the Reader permission to Custom without setting any account or group like this.



Let me know if that helps.

Best regards,

Hello Erica,
thanks for your interest. I did several tests, and I tried again as you recommended. On the Vault's root record I only set custom.


the accounts are all set up custom without setting any account or group like this, with the exception of Contributor, only the user who must use it is configured.


when I go to select the account to use I see them all. If I select my account where I have rights, when I start rdp I get this error.

this is after the update. To get around the problem I have to make all users administrators. They cannot work with this privilege: today I restore the previous version.

If it helps, this was the configuration before the update, on the Vault's root record:


Every single user had this setting:


If I connect I get the same error, and I see all the accounts entered.

thanks, see you soon.

Hello,

Thank you for your feedback.

We were able to reproduce this issue. A ticket has been submitted to our developer's team.

Once an update will be available, we will let you know.

Thank you so much for being so patient.

Best regards,

Hello,

@Aviola, we have released DVLS 2024.1.8 an hour ago. This version contains the fix for the PAM Permissions issue.

Let us know if that works as expected.

Best regards,