Stephen

Thanks Hubert. I have created a profile and sent it through to support with this Forum post linked.

Not sure on the best place to give this feedback but my initial test of this 2026.3 install with a Devolutions Server backend is feeling very sluggish when swapping vaults when compared to 2026.2. Currently our large 2026.2 vaults take approximately 2 seconds to swap while on this version of 2026.3 I am seeing 5+ seconds to make the same swap.

Both duplicate folders and Virtual folders are empty. Summary is showing green ticks for both.

Extracting each entry separately shows no errors while attempting to extract them all at once is giving the XML error.

The script I used to extract all entries separately. (No errors)

$Sessions = Get-RDMSession
Foreach($session in $sessions){
        Export-RDMSession -Path ("D:\Configs\DVLS-PR\Test Extract\" + $Session.Name + ".zip")  -Sessions $Session -Password $Pass -CSV
}

Script I used to try do it all at once that gave the error. (this shows the error)

$Sessions = Get-RDMSession
Export-RDMSession -Path ("D:\Configs\DVLS-PR\Test Extract\test.zip")  -Sessions $Sessions -Password $Pass -CSV

I was incorrect it appears to be a single vault causing it now, not a Datasource. It just happened to be the first vault the script connected to when it hits the datasource. When doing a full export of the vault to csv or xml I am seeing an invalid character error. Could this be causing the timeout on connection if it cant read that character?

This is a reasonably large vault (approx 4k entries) is there an easy way to find out which entry is causing this?

Error : System.InvalidOperationException: There was an error generating the XML document.

 ---> System.ArgumentException: '', hexadecimal value 0x18, is an invalid character.

   at System.Xml.XmlUtf8RawTextWriter.WriteElementTextBlock(Char* pSrc, Char* pSrcEnd)

   at System.Xml.XmlUtf8RawTextWriter.WriteString(String text)

   at System.Xml.XmlWellFormedWriter.WriteString(String text)

   at System.Xml.Serialization.XmlSerializationWriter.WriteElementString(String localName, String ns, String value, XmlQualifiedName xsiType)

   at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterConnection.Write465_Connection(String n, String ns, Connection o, Boolean isNullable, Boolean needType)

   at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterConnection.Write466_Connection(Object o)

   at InvokeStub_XmlSerializationWriterConnection.Write466_Connection(Object, Object, IntPtr*)

   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)

   --- End of inner exception stack trace ---

   at System.Xml.Serialization.XmlSerializer.Serialize(XmlWriter xmlWriter, Object o, XmlSerializerNamespaces namespaces, String encodingStyle, String id)

   at Devolutions.RemoteDesktopManager.Managers.SerializationManager.SaveObjectToString(Object value)

   at Devolutions.RemoteDesktopManager.Managers.VariableManager.ApplyVariables(Boolean isUri, Boolean isAddhoc, Connection connection, Int32 nesting)

   at Devolutions.RemoteDesktopManager.Managers.ImportExportManager.<>c__DisplayClass16_0.<ExportConnectionToCsvFile>b__3(Connection c)

   at Devolutions.Utils.ExtensionUtils.ForEach[T](IEnumerable`1 list, Action`1 act)

   at Devolutions.RemoteDesktopManager.Managers.ImportExportManager.ExportConnectionToCsvFile(IEnumerable`1 connections, String fileName, String password)

   at RemoteDesktopManager.PowerShellModule.ExportRDMSessionCommand.ProcessRecord()

   at System.Management.Automation.CommandProcessor.ProcessRecord()

I am seeing the errors on both large an small vaults so don't believe its the number of entries. Went a bit deeper into our scripts and it does appear to be mainly after running "Update-RDMUI" or jumping between data sources. I've removed Update-RDMUI and it seems to have quietened it down quite a bit but am unsure if this command still needs to be run to get accurate data back.

Both RDM connection logs and DVLS logs are showing no issues.

Hi, Since updating to DVLS version 2022.3.13.0 and RDM PS version 2022.3.1.6 I have noticed that many of the scripts we are using are retuning "[Error] The operation has timed out." messages. Currently the scripts do work and we have not experienced any issues with the data we are getting abck but the message is filling up our logs.

We are using PS version 7.3.2 and I have tried to increase the timeout property on the datasource from 15 to 60, but the error continues to happen.

The new system Dashboard shows the schedule of being down. Reinstalling or stop\starting the scheduler just causes another down notification.

The console does show that the scheduler is running though.

This was an upgrade from 2022.3.13.0. After following the steps to increase timeout to 500 we seem to be good. However I am seeing this error appear in the DVLS console error logs

SchedulerId is empty. Please restart the scheduler with a Console 2023.1.0.0 or greater.

Attempted to install DVLS 2023.1.0.0 but am unable to access the DVLS site after the update. Site gives a "HTTP Error 500.37 - ASP.NET Core app failed to start within startup time limit" error. DVLS Console says everything is running and No errors in the DVLS logs or IIS logs.

Hi,

The new RDM PowerShell module is available on PSGallery.

https://www.powershellgallery.com/packages/RemoteDesktopManager/

Regards

Thanks Jonathan, The PSGallery link only has up to version 2022.2. This version does not seem to connect to either a DVLS or RDM datasource that is on version 2022.3. You just receive "ERROR SILENT WebAPI returned null" messages in the log. Is there currently a Beta version that is compatible with the 2022.3 beta?

Is there a Beta version of the new Powershell module available as this is no longer packaged with RDM?

When restarting the App pool the issue appears immediately after the restart (while DVLS is running through the start-up process) but seems to come back promptly after that finishes. I was curious and left everything untouched after a recycle to see what happens after a longer time and it appears that it does come back online but it takes 10 minutes. If you are unable to replicate I suspect that this could be something with our environment.

I have been able to get a work around implemented that runs a Invoke-WebRequest after the nightly recycle. This seems to bring everything back online a lot faster than just leaving it.

Thanks Erica, yes I have both of those settings implemented. In theory I could write a task to automatically hit the URL after its recycled to wake it up again.

Updated to :

DVLS Version : 2022.1.9.0

RDM Version : 2022.1.12.0

Same issue is still occurring. This is not a major issue and is more of just an annoyance as the first user to login each morning is hit with this error as we need to recycle the IIS App pool overnight to retain performance. The first time the DVLS URL is hit after it has been recycled, it will cause the Data source to "wake up" triggering the "Application has started" message in the datasource logs.

We expect this first connection to take longer as the datasource does take time to start up again. When connecting via the Web URL it can take 30-40 seconds to receive a response but we do not receive an error during this time. In previous version of RDM (prior to 2022) the same would happen in RDM as the web UI. RDM would be slower to connect but would eventually connect without any errors being displayed.

You should be able to replicate the issue

1. Set RDM to Offline

2. Log into the DVLS server and Recycle the Application Pool for the DVLS instance

3. Wait 60 seconds for the Refresh to take affect

4. Set RDM to online (RDM will error after about 10 seconds)

DVLS Version : 2022.1.6.0 (Beta)

RDM Version : 2022.1.10.0 (Beta)

RDM Authentication times out when attempting to wake the DVLS IIS site after the IIS Site has been recycled.

Error : Devolutions.RemoteDesktopManager.Business.TryGoOfflineException: DVLS server did not respond in time. Check your connection or try increasing the connection timeout.

In previous versions this timeout would not occur when waking the IIS site. It would only occur if the site had no response at all.

DVLS 2022.1.7.0 & RDM 2022.1.12.0 seems to have stopped the ArgumentNullException - IDX10000 error and it is no longer requesting a password every time. However we are still receiving a notification every 20 minutes stating that RDM is waiting for authentication. During this time the app is frozen and unusable.

No 2FA is currently configured on our Environment but we are linked to Active Directory.

DVLS Version : 2022.1.6.0 (Beta)

RDM Version : 2022.1.10.0 (Beta)

We appear to be having an issue with the latest DVLS\RDM setup that is casuing RDM to need to re-authenticate (Launch the DVLS website and enter login details) every 20 minutes. As a note the Idle timeout settings in the DVLS Advanced Settings is currently set to 60, so this appears to be unrelated.

The DVLS Server logs the below error just prior to the re-authentication request.

Error:

ArgumentNullException - IDX10000: The parameter 'token' cannot be a 'null' or an empty object. Parameter name: token at Sys-tem.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.ValidateToken(String token, TokenValidationParameters validationParameters, SecurityToken& val-idatedToken) at Devolu-tions.Server.Handler.OAuthHelper.LoginWithOAuth(String bearerToken) --- Login

DVLS Version : 2022.1.6.0 (Beta)

RDM Version : 2022.1.10.0 (Beta)

Having a blank Username field in the datasource settings when attempting to authenticate/login to a datasource will cause you to get into an infinite login loop on the DVLS web page rather than allowing authentication.

How to replicate:

Create a new datasource entry on RDM and leave the username field blank Or Edit a current datasource entry and blank the username.

What happens:

Upon selecting ok or selecting "test Connection", the waiting for authentication progress bar will appear in RDM and a DVLS webpage will appear. When entering the correct details the webpage will then show the progress image then revert back to the Username and password screen.

Do we have any update on when we can expect DVLS 2022 beta will be released?

Yes the user that was attempting to access the vault was an administrator. I have not tested this on a non admin account.

I can confirm that setting the Maximal Version via RDM rather than the web interface also seems to have no different effect.

Tested with :

RDM Version : 2021.2.27.0

Devolutions Server Version : 2021.2.14.0, 2021.2.10.0 & 2021.1.20.0

It looks like RDM version 2021.2 is bypassing the version management rules on DVLS. When connecting to a datasource with an RDM version that is higher than the accepted version in the DVLS version management settings, the error message appears stating the it cant connect but, after selecting ok in the error box, the connection will go through. Once you are connected tot he vault, this also occurs when you attempt to make any changes to the vault. When adding an entry it will prompt twice that it is not allowed, but the new entries will go through.

How to replicate the issue

1. On DVLS 2021.2.14.0 set the Maximal Version under Version Management to 2021.2.20.0

2. Set the "Maximal version custom message" to "Not Supported"

3. Connect to the datasource with RDM version 2021.2.27.0

4. Select ok on any 'Not supported' messages

Had a freeze today with version 2021.1.32. I sent a profiler trace through with the subject "Attn:Stefane Forum: 35560" prior to the freeze happening. I also have a minidump if you want more of those.