ivorycruncher

Oh, wait a minute. I apologize, I completely missed what you said about the credentials setting for the tools in the session config. I just changed that from default to session, and now it works. Today seems to be one of those days where I skip half of everything I'm supposed to read. Anyway, sorry for the confusion, and thanks for the help!

From what I'm seeing, that does not seem to be the case. I have RDP connections set to inherit credentials set via user-specific override on a parent folder, and I'm getting access denied errors on the management tools. I also tried setting user-specific override credentials directly on one of the RDP connections, and get the same result.

In case it matters, I'm just using the Custom option when specifying override credentials, and again, the Security setting on all RDP connections is set to Inherited.

RDM Enterprise 10.6.7.0

I've noticed that the remote management tools on the dashboard for RDP connections don't honor the specified credentials for said RDP connections. It seems they only pass through the credentials from the Windows session in which RDM is running. For the majority of the servers my company manages, this is fine, but there are a handful of environments for which there is no domain trust for various technical and security reasons, as well as several that are not connected to any domain, and the remote tools don't work for any of those servers.

So, is it possible to change things so that the management tools push through the credentials that apply to the RDP connection, instead of current Windows session credentials, or are there technical limitations making that impossible?

FWIW, in the scenario where I'm manually connecting management tools (compmgmt.msc, services.msc, etc.) to a remote server that's not in a trusted domain, I first browse to \servername to get a credentials prompt and supply the appropriate credentials, after which the management tools will piggyback on that connection and connect to the remote server successfully.

Great news, thanks David!

Oh, sorry. Latest non-beta version, 10.6.7.0. Also saw this while testing 10.6.4.0.

I have noticed that when right-clicking on a folder in the navigation panel, I often get a right-click menu for the current server shown in the Dashboard tab, instead of for the folder I right-clicked on. I then have to left-click on the folder name once or twice and then right-click it again to get the menu for the folder. Unfortunately I cannot seem to reproduce the issue reliably, but it does happen frequently.

As a disclaimer, I did not have the "Show group details/descriptions" check box checked, so when right-clicking on a folder, the Dashboard would switch to the first server within that group, which makes me wonder if there was a timing issue where where the menu would appear for the server being selected instead of the group. Now that I have checked that box, I will see if the issue continues to happen or not.

The option to manually enter LDAP filter strings already exists in the current version. That's what I'm currently using to filter out disabled accounts. However, the string for this is rather cryptic compared to strings for filtering other parameters:

!(UserAccountControl:1.2.840.113556.1.4.803:=2)

Granted, this can be found by a web search, but I can imagine this being intimidating to people who are unfamiliar with LDAP filter strings. The need to filter other parameters will vary widely from client to client, but the need to filter out disabled accounts seems like it would be a very common thing that most people would probably want, so the check box (and a corresponding parameter to set true/false on in PowerShell) would make this particular filter much easier to configure.

As for the update and removal functions, I've been familiarizing myself with the PowerShell snap-in cmdlets available, and believe I can write a script to both run all synchronizers and move/delete/update existing RDP connections as needed based on the LDAP filter search results. If the features get added to the synchronizer though, that would eliminate the need for a custom script, other than one to run the synchronizers periodically.

Sure, I completely understand. I never expect instant turnaround on feature requests, just glad you actually listen to them. :)

Auto-delete RDP connections

I know this has been requested many times already, but just to offer my vote as well, I would like to see the ability to auto-delete RDP connections for computers no longer found by a current sync. The deletion would of course need to be confined to the group structure defined in the synchronizer settings, so as to not affect anything else in the same database.

Update existing RDP connections

The synchronizer can be set to create groups based on the OU structure in the AD domain, and also to importing computer account descriptions from AD. However, these pieces of information are only honored on initial import. I would like to see this data re-parsed for existing RDP connections matching computer accounts found in the current sync, so that the RDP connections can be updated accordingly. In other words, computer account descriptions would be checked and updated as needed every time, and if they get moved to a different OU in AD, they will be moved to the appropriate matching parent group in RDM, assuming the option to replicate the OU structure is enabled.

Option to exclude disabled computer accounts

I don't see any point in creating RDP connections for disabled accounts, as that generally means that those computers no longer exist, or are at least purposefully offline for an extended period of time. I would like to see a check box that would easily allow admins to select whether or not to include disabled computer accounts in the search. Yes, it is possible to add an LDAP filter string to exclude them from all the domains I manage, but to me something so basic would be better served by a user-friendly check box. Preferably this would be set to exclude them by default, but just having the check box (and a property to easily set true/false on via PowerShell) would be much appreciated.

Thanks for the info. Just to clarify on point 1, does the 30-second sync happen within every active RDM session? If so, that seems excessive, so we may want to instead schedule that. Also, does the auto-sync still happen even when the Silent option is not enabled?

On point 2, that's what I was afraid of. I also was hoping for the auto-delete functionality, but rather than delete/recreate when a computer is moved to a different OU, I would prefer it be moved in RDM as well, because there could be custom settings set on specific connections that would then be lost. Given that the parent OU path and description are read on initial import, I would think they could be read and have action taken to update existing connections as needed. I guess I'm basically looking for the ability to have the synchronizer fully manage the connection list. I realize that's out of the scope of this forum though, so I will re-post in the feature request forum. Thanks!

I'm currently evaluating RDM 10, and after working with the Active Directory Synchronizer feature, I have a couple questions:

1. There's a "Synchronize automatically" check box selected by default. How does this work? Do the domains re-sync periodically in the background, or every time somebody launches the application? Or are scheduled tasks required to actually automate the sync? I have 100+ domains I need to sync with, so would need this to be manageable.

2. It does not appear that the sync actually does anything other than a one-time RDP setup of any computer account it finds given its filtering criteria. For example, I have it set to import descriptions, but changing a description on a computer account and re-running the sync just says "No new computer found" and does not update the descriptions already set on the RDP connections already in RDM. It seems this data is not compared and updated as needed during every sync. Also, I have not tested this yet, but my guess is that if a computer changes parent OUs, that will also not be reflected in RDM, even when configured to create groups that match the OU structure of the domain. Are these features not feasible to implement, or have they simply not been thought of and/or requested? Or is this functionality already supposed to exist, and just doesn't work for me for some reason?

edited by ivorycruncher on 6/30/2015

I would rather not send our connection list for privacy reasons. However, I generated a new SQLite data source with 150 randomly-generated Microsoft RDP entries, and can produce the same symptoms with that, so it's nothing specific to my connection list. I also tried with a list of around just 10 randomly generated names, and the same problem exists, so it's not the size of the data source either.

In detail view, if you hold down the down arrow key, it just gets really bogged down trying to scroll down the list, and trying to type a name in the list doesn't work very well, if at all, as the lag seems to hinder proper interpretation of the keystrokes. Even highlighting a section of group of entries in the list (click one, hold Ctrl+Shift, click another one) results in visual lag, as it doesn't instantly highlight all selected entries, but instead highlights them in chunks, or in sort of cascade fashion.

In tree view, while holding the down arrow, it will just fly through the list, and typing a connection name to navigate directly to that entry will work perfectly every time. Also, highlighting a large section of list entries results in instant highlighting of all, no laggy screen-painting effect. Whatever the issue is, it almost seems to be a visual rendering lag issue.

I'm out of town the rest of this week after today, but I think my next step, whenever I get a chance, will be to go back and install an RDM 8.x version and see how that compares.

Well, the act of switching views also takes a few seconds, but yes, in anything other than tree view, navigating the connection list is slow. This includes typing the name of a connection and having it auto-navigate to it. In tree view, very fast, in details view, very sluggish.

edited by ivorycruncher on 11/8/2013

List view, same problem. Tried completely uninstalling, removing all appdata, and reinstalling and re-importing the connection list from scratch, in the hopes that any issues caused by upgrading over 6.0 would be resolved, but the list is still slow. HOWEVER, after going through all the display modes, I found that the problem seems to disappear in tree view. That's the only view that's not slow though. Oh, and btw, the test with RDM 8.2 was in detail view.

I started the profiler, but just navigating the connection list doesn't generate any logs in that window. Opening the Options dialog and clicking OK did, however, and apparently caused a refresh of the connection list:

LoadConnections [Xml : Test]...

LoadConnectionsFromDataSource...

LoadDataSourceSettingsFromDataSource...

GetDataSourceSettings : 0 ms

LoadDataSourceSettingsFromDataSource : 1 ms

GetConnections...

Xml.GetConnections...

Xml.GetConnections : 30 ms

GetConnections : 33 ms

DoSetConnections...

DoSetConnections : 1 ms

LoadConnectionsFromDataSource : 44 ms

LoadConnections [Xml : Test] : 53 ms

FWIW, I had an old Windows 8 (classic, not 8.1) VM with a trial copy of RDM 8.2 running in it, so I fired that up and loaded in the same connection list, and it does not appear to be suffering from the lag issue at all.

Sorry if I'm not being clear. It's navigating the list itself that is slow. Without any sessions even open, if one session in the list is highlighted, and I click on another, it doesn't instantly highlight, but takes about a half a second or so to show as selected. Also, if I try to navigate through the session list using the up and down arrow keys on my keyboard, it will not go up or down quickly, but instead take about a half second to change selection every time.

Tried both 32-bit and 64-bit in 9.0, problem also existed in RDM 6.0, which I upgraded over to 9.0 for testing. I have also tried forcing RDM to run as admin via UAC prompt, but that didn't help either. Problem didn't start until Windows 8.

Access version is 568 KB, XML version is 145 KB.

I am using the 32-bit version currently. Intelligent caching is only available for remote data sources. As stated, I'm using local data sources for now, because I don't want to mess up the SQL database we have, which is currently on version 6.0.

The diagnostic shows I have 147 entries in the session list. A few of those are web URLs, but almost all are RDP entries for connections to the terminal server farms we host for our clients. I had the same list in 6.0 without the lag.

Since upgrading to Windows 8, and subsequently 8.1, RDM no longer updates my registry with the last username used for each server address. These values are found under HKCU\Software\Microsoft\Windows\Terminal Server Client\Servers. There is a subkey under there for each server address, containing a string value named UsernameHint.

On Windows 7 and older, RDM updated the username hint with the last credentials used to log into a server, but on Windows 8 and later, it reads the existing values from the registry, but does not create them when not present, nor update them when different credentials are used at the login screen. Credentials for the connections are not stored with the connections or in any repositories.

I ran Process Monitor and can see where it reads these values, but don't see any failed attempts to write back to the registry, so I'm not sure why this is happening. I'm wondering if it has something to with the updated RDP ActiveX control in Windows 8.x, as the username hints are updated properly when using the standalone mstsc.exe.

Can this be fixed or worked around somehow in RDM?

I am running on a fresh install of Windows 8.1 x64. First installed RDM 6.0, as that's the newest version my company is licensed for (haven't had a need to upgrade). I then decided to download the latest version to run some comparisons and see if there are new features that will make the upgrade worthwhile, but so far I'm quite disappointed.

I upgraded to 9.0.5.0 over 6.0.0.0. Not wanting to break the database with an accidental upgrade, I imported all connections into a local data source and removed my SQL data source before the upgrade. After upgrading, my experience so far as been that the application loads very slowly, both 32-bit and 64-bit versions, and also any attempt to click on different entries in the connection list is extremely slow, almost as if the application is laboring to load data about the entry being selected.

I have gone through the settings to try and find optimizations, even going so far as to put the application back in classic mode, and while that did help slightly, it's still quite slow. In 6.0, I could click in the connection list in details view and start typing the name of the connection I wanted (we have around 100) and it would be very snappy in navigating to the desired selection. Also, in 9.0, trying to launch a new session, or edit a session, or pretty much any action, seems to result in several seconds of laggy behavior. I did try switching from Access to XML as the local data source, and that did not help at all.

My PC is pretty healthy, running a quad-core AMD processor and 8 GB of RAM, with plenty of free disk space, and no other application runs anywhere near as slow. Any ideas on what's wrong here? Is RDM 9 not liking Windows 8.1 for some reason? Is there junk left behind from the 6.0 installation that's causing trouble?

My organization is in the process of starting to roll out Citrix for our hosted clients, but we're using something called the Citrix Receiver, as opposed to the more traditional ICA client. I've downloaded a trial edition of RDM 8.2, but after trying the two Citrix session options available, I can't seem to make things work as expected. Using a Citrix Web connection, I can open a connection to our Citrix web portal in an embedded tab, but clicking on any published apps or full desktops results in a file download that then launches the apps or desktops in separate, standalone windows.

At the very least, it would be preferable to have the full desktop sessions load in embedded tabs. Is there any chance this functionality can be added to RDM, or is this new connectivity method too proprietary to integrate?

Is there any way to install an older version of the activex files and force RDM to use those instead of the primary ones?

Well, as I said, Windows 8 uses the new RDP 8.0 protocol, so I'm wondering if something changed in the APIs regarding virtual channels in the new version. Unfortunately I can't seem to find much detailed technical info about the new RDP version as of yet. If it is a bug, not an API change, hopefully the problem is found and corrected soon by Microsoft. Thanks for your help with this.

Same result with RDCMan. However, I see that it's not listed as compatible with Windows 8, and was released a couple years ago, so it's possible there is a compatibility issue.