top of page
Search
cherryvian998frhn

Dameware Mini Remote Control 9 15: A Review of Features and Performance



Easy-to-use remote control for Windows, Linux and Mac OS X DameWare Mini Remote Control lets you remotely connect to Windows, Linux, and Mac OS X computers, laptops, and servers. Use the built-in Mini Remote Control viewer, RDP, and VNC viewers to gain remote access of computers running different operating systems.


Powerful remote control and desktop sharing capabilities Conduct simple remote IT support sessions from one centralized console. You can enhance the quality of support during remote sessions using built-in features such as chat, screenshot capture, file transfer, keyboard and mouse lock, print, etc.




dameware mini remote control 9 15



Interactive Smart Card login and remote Smart Card authentication DameWare Mini Remote Control offers secure remote connectivity with the help of interactive Smart Card login and remote Smart Card authentication. DameWare is the first remote administration software to offer these Smart Card options.


Centralized administration and account management When installed in the centralized deployment mode, DameWare Mini Remote Control allows you to centrally manage DameWare users and permissions, control and activate all DameWare licenses from a single location, and share global host lists with all DameWare users (IT technicians).


DameWare Mini Remote Control (MRC) is the best value in remote control software and has been used for more than 10 years by thousands of IT admins to seamlessly connect to remote servers, desktops and notebooks. DameWare MRC provides remote control for Mac OSX X, Windows and Linux systems. MRC is included in the more comprehensive systems administration tool, DameWare Remote Support (DRS). In addition to MRC, the DRS software package includes DameWare Mobile, Windows administration, Active Directory management, and configuration exporting tools in one easy-to-use software console.


Sometime when connecting to high resolution clients, my dameware mrc does not let me move the window on my screen. I am connected to two clients right now for example. One is at 1024x768. The dameware "window" has a menu bar (File, Send, Monitor...) and buttons, and the display of this remote machine is integrated within this window. I can minimize, maximize, close or drag this window around no problem.


The other machine I am connected to is 1920x1080. The view of this remote machine is separated from the dameware toolbar in the top middle of my screen. The window border around the view of the remote machine is so thin that there is nothing to grab ahold of to move this window around my screens. I can only really awkwardly resize it to move it to another monitor or another place on my screen. How could I get the view of this remote machine attached with the menu bar and tool bar, like the other machine? There's no way to disconnect either. Well one would have to close it from the taskbar. If you click the little X in the top anchored, centered toolbar that is detached from the remote PC view, that toolbar goes away permanently . unless you close dameware and reopen it.


Ok I figured out the "view full screen" toolbar icon will make it windowed (Menu bar, toolbar and remote view all in one window). This was misleading to me because "view full screen" makes me think of Remote Desktop if you maximize it. View full screen in dameware simply to me could have been called detach toolbar from remote view.


DRS crashes if you use a user without remote access permissions for Intel AMT power tasks. If you provide credentials for an AMT user without remote control permissions for the Intel AMT Power task in DRS, the program crashes. This is an uncommon use case, and using credentials with remote control permissions resolves the issue.


Also, just FYI, DNTU uses a completely different set of ports & protocols and wouldn't have anything to do with your behavior via MRC. Microsoft's APIs used within DNTU use what's called NT "Pass-Through" authentication. Therefore, if you receive Access Denied errors using Remote Command View or Event Log View, this means your current O/S logon credentials don't have sufficient rights within the O/S security on the remote machine. Therefore, you would have to establish an authenticated connection to this remote machine using sufficient credentials (i.e. Administrator), either within the O/S itself or by using DNTU's LogonAs feature.


- What rights do you have within the O/S security on the remote machine?Administrator rights in theory..- What O/S and Service Pack level is installed on both the local & remote machines? If it's XP or Vista, also distinguish the exact version of the O/S as well (i.e. XP Home, XP Pro, etc...).Both XP Pro- Are these machines located on the same LAN, over the WAN, accross the Internet?Across the Internet- Can you access the Admin$ share on the remote machine (net use \\remotemachine\Admin$) via a CMD prompt on your local machine?No.. Error 1219


Try as I might, I have been unable to get non-admin users to be able to remote controlcomputers. I am running Windows Vista Enterprise SP2 and MRC 6.8.1.4. I have read a lot of posts on the subject and understand that the default dwrcs.ini settings need to be altered during MSI creation so that non-admins will be able to connect (after permission is granted) and i'm pretty sure I've got the settings correct, but only users with admin rights are currently able to connect successfully.


I have tried both Encrypted Windows Logon and Windows NT Challenge Response authentication methods without success. I'm pulling my hair out now as I really need some users who can't have local admin rights the ability to remote control with MRC.


Here is my INI file (I am not using registry settings), can anyone spot anything wrong with it?CODE: SELECT ALL[Settings]Port=6129Adgang NTLM=YesAdgang 1=Adgang 2=Adgang 3=0Notify On New Connection=YesNotify On Disconnection=NoNo Notify Sound=NoNotify On New Connection Timeout Value=30Notify Dialog Caption=Remote ControlNotify Dialog Text 1=Remote Control NotificationNotify Dialog Text 2 Remote Control=The following user has connected viaremote control.Permission Required=YesCenter Permission Dialog=NoPermission Dialog Set Focus On Decline Button=NoShow SysTray Icon=YesEnable User Option Menu=NoOption Notify On New Connection=YesOption Notify On New Connection Dialog Timeout=YesOption On Disconnect Logoff Desktop=YesOption On Disconnect Logoff Desktop Force Applications Close=YesOption On Disconnect Lock Workstation=YesOption Logon At Logon Desktop Only=YesOption Logon At Logon Desktop Only Timeout=YesOption Enable File Transfer=YesOption Enable Chat=YesOption Enable Chat Allow Anyone To Initiate=YesOption Permission Required=YesOption Enable Add Client Connection Menu=YesOption Enable DisConnection Menu=YesOption Enable Email Notification=YesOption Enable Email Notification Change Email Address=YesPermission Required for non Admin=YesPermission Required for non Admin Disconnect If At Logon Desktop=NoPermission Required for non Admin Force View Only=NoOn Disconnect Logoff Desktop=NoForce Applications Close=NoOn Disconnect Lock Workstation=NoLogon At Logon Desktop Only=NoLogon At Logon Desktop Only Timeout=YesLogon At Logon Desktop Only Timeout Value=20Enable Add Client Connection Menu=YesEnable Disconnection Menu=YesEnable Settings Menu=NoAbsolute Timeout=0Requires Explicit Remote Admin Rights=NoAllow Only Administrators To Connect=NoRequires Logon Locally Privilege=NoMust Be Member Of This Local Group=NoLocal Group Name=Must Be Member Of This Global Group=YesGlobal Group Name=DameWare Desktop Remote Control AccessEnable Email Notification=NoEmail Notification Address=Email Notification Server=Disable Host Lookup=YesSocket Logon Timeout=90000Authentication Type=2Must Have Logon Locally Rights with Windows Logon=NoSFT: Enable Simple File Transfer=YesSFT: Append Host Name=NoSFT: Upload Folder=%SYSTEMROOT%\DWRCS UploadsSFT: User Response Time Out=6000Disable Version Downgrade=NoGlobal Group Machine 0=[IP address of Domain Controller 1]Global Group Machine 1=[IP address of Domain Controller 2]Global Group Machine 2=[IP address of Domain Controller 3]Global Group Machine 3=Global Group Machine 4=Global Group Machine 5=Allow All Administrators To Have Control=YesUpgrade Information=Downgrade Information=Max Access Log Size=10240000Force Encrypt Data=NoForce Encrypt Images=NoForce Encrypt Files=NoConfiguration Version=5.5[Proxy]Enable Proxy=NoRequire Shared Secret=NoDisable Remote Control=No[IP Filter]Enable Filter For Remote Control=NoEnable Filter For Proxy=NoAccess Granted=Yes


I am having a similiar issue - I have 45 domain controllers and have a group assigned to "Account Operators" so they can remotely access these machines with DMRC. They can access 44 of the 45 but they seem to be in view only mode on the 45th. They cannot connect even when the server is at the login window. The dwrcs.ini file looks the same as all the others, Is there a particular setting I should be looking for that would cause this behavior?


A tip: don't get fooled by the PDC/DC list requirement here, better use the domain names. (6 max)let DNS find the nearest DC instead of hardwiring nodes here.We recenly retired a bunch of old DC's and this nuked the authentication process at the clientsYou have to force new settings by removing the current remote control agent and installing the new builded MSI fileThe repair option does not restart the service for unknown reasons (I am local admin, but event log says cannot find file)


i just want to try Dameware and it would be important that I can offer remote support on client machines that are not in our lan. So I figured that Dameware Proxy could be the right solution, but unfortunatetly I find the provided documentation is lacking some practicable examples on how to setup the firewall properly. I found some kind of documentation -mini-remote/technikhowtofaq-s/497-dameware-server-11-installation-und-konfiguration in which it says, that all traffic on port 443 and 80 must be forwarded to the server which ist hosting dameware proxy. Well, our firewall itself ist listening on port 443 and 80 so I suppose it would not be advisable to redirect that traffic to the Dameware Proxy, wouldn't it? What about ports 6132 and 6133? Must they be redirceted too? 2ff7e9595c


0 views0 comments

Recent Posts

See All

Comments


bottom of page