I have added this to my TO-DO list. I will (try) to fix the netmask issue when my schedule allows it. Note that it will not be fixed in RDP Discovery but in RemoteDesktopManager (if you don’t want to use that tool, just do a discovery in it once and then export the connection files).

the subnet is 255.255.254.0 and my host ip is 172.20.31.221, which means a net 172.20.30.0-172.20.31.255 but RDP Discovery starts scanning at 172.20.0.0

Please correct the problem !

TNX
apos

Ik stuur je de broncode per email.

mvg Evert

En het klopt dat het HASH commando de verbinding niet verbreekt daarom zet ik de mbNoopThreadPaused boolean tijdelijk op true (en in de finally weer op false).

Overigens staat als het goed is op de VMWare servers de idle timeout in de FTP server ingesteld op iets van 30 minuten, dus is de NOOP thread eigenlijk niet meer nodig.

Ik denk dus ook niet dat het verwijderen van de NOOP thread iets uithaalt. Het zal niet verbeteren en niet verslechteren is mijn theorie.

Maar ik ben erg benieuwd naar de bevindingen en ook wat je zoal in de logs tegenkomt, want als een image niet gestart wordt dan moet je iets in de logs zien. Sluit ook vmrun.exe niet uit als boosdoener, die tool kan soms erg gevoelig zijn en mijn ervaring is dat nieuwere versies niet altijd beter werken.

hoe istie er mee?

even een post op je website ivm de vmwarecopytool.

we hebben regelmatig vmimages die niet goed worden gebackupped…. en vervolgens niet in de lucht zijn.

dus heb ik je sourcecode gedownload en bekeken…

ik kan me niet zo goed voorstellen dat die NOOP thread veel goeds doet.. mocht de ftpclient gedisconnect worden (staat ook in je code) dan komt die in een wel hele snelle while(true) loop. dat lijkt me niet best, of zie ik iets over het hoofd.

verder staat op je website dat de NOOP thread is voor de “writing directory xml”. dat zou toch wel zonde zijn want je kan best zonder ftp connectie tijdens het maken van de directory xml. Je doet dan toch nog niets met de ftp verbinding. Volgens mij zou je alleen de NOOP nodig hebben voor de fileupload en hash berekening. Die laatste kan namelijk lang duren, maar dat is wel weer een ftp commando, dus waarom zou die dan de verbinding verbreken….

Toch heb ik je noop thread verwijderd, en een aantal “try catch {ignore}” commando’s aangepast. We willen natuurlijk alle meldingen in het log zien… anders zien we nog zaken over het hoofd.

we hebben een update op de server gezet en kijken even aan hoe die loopt. ik zal je mijn bevindingen wel sturen.

(sourcecode stuur ik je als ik klaar ben met testen..)

groetjes Evert

Saving the password would require some reverse engineering of the MSTSC tool from microsoft. If I can make a suggestion: upgrade the RDP client: http://support.microsoft.com/kb/925876 . The new MSTSC has a lot of new features and the security model in completely rewritten. It is still not possible to save from within RDM, but the process of storing the passwords in MSTSC works more logically (to my opinion).
You only have to install the new MSTSC once after that you can copy mstsc.exe and mstscax.dll from system32 to the RDM folder.

So hopefully this info is of any help to you.

Update: The new MSTSC is portable, but you need some more files to make it work. In System32 there is a map en-us with the files mstsc.exe.mui and mstscax.dll.mui. Copy those files (including the en-us directory) to the same location a you put mstsc.exe en mstscax.dll.

At present, there doesn’t seem like there’s an option to do this, so getting the password saved is a case of creating the connection in RDM, then creating it from the standard RD tool with the password and save password option checked, and then saving the rdp connection file over the one created by RDM in the connections folder.

Another useful feature would be to import existing connections from RDP files, or perhaps even go as far as to build the tree from the RDP files in the connections folder. That way we could just copy existing RDP files into the folder and name them using the Group-Name format.

Overall though, looks like a useful tool and will help to avoid the clutter of having lots of icons for different remote desktops

with my all respects.