HI. there is any option in Dameware mini remote control to perform operation on other machine in invisible mode(without his knowledge)?

Hi,

we've enabled Microsoft's Security Baseline via GPO to our Windows 10 computers. If we now like to use dameware 12 to  remote control a computer the authentication is not working through.

No matter which protocol from the dropdown list (Windows NT Challange / Response, Encrypted Windows Logon, ...)  is used it all fails.

Somebody meet this situation and knows what to do? Is there a configuration in dameware that can be changed to work with the basline or did u change a setting on the baselines?

Windows Security Baselines | Microsoft Docs

I have checked the application log of the remote machine and found these events:

I know that NTLM version 1 is deactivated via Security Basline, but I assume Damware is using Version 2?

Thanks in advance

Ruben

Until recently, DRS has been working great. Then I applied the November update to Windows 10 and no the Microsoft Windows Network no longer displays anything in DRS.  I am using version 12 with both hot patches applied.  Other than applying the update nothing had changed in our environment.  I can still find computers through the Active Directory, but it isn't nearly as convenient.  It is particularly troublesome to find the few computers that are not part of the domain.

Any suggestions for a fix?

Thanks,

Chris

I have been running on Windows 10 for quite a while (since last fall) and using Dameware Remote Support (11.0.0.1003).  Recently I upgraded to the latest W10 version (1607).  Unfortunately, this broke the remote clipboard.  I have a co-worker who had the same experience.  The only difference between the two was that his mini-remote worked fine, then he upgraded to the "full-version" (as we call it).

Any ideas about how to fix this?  I would have thought a reinstall of the application, but with the fresh install that was broken that didn't seem like a solution.  Any thoughts?

I’m thrilled to announce that Dameware 12.0 is now publicly available. In this release we focused all our efforts to finalise the remote support story with unattended over the internet sessions. Dameware now allows to assist remotely without presence of the end-user, who is not in the intranet but travelling. Technicians can now support end-user in company network as well as in Internet anytime.

This release brings several bigger and smaller improvements, so let me highlight a few of them:

• Over the Internet (OTI) unattended sessions for Dameware Centralized users
  • Allows you to remotely support users on the move, and assist remotely without the presence of the end user
  • Deploy agents with OTI unattended support to end-points
  • Manage agents for OTI unattended sessions to maintain high security and control
• Search Hosts in Mini Remote Control
• Support for Windows 10
• Ability to switch between the Standalone and Centralized versions without reinstallation
• And many other improvements and bug fixes

Dameware 12.0 is available for download on your customer portal for those customers under current maintenance.

If you are not a Dameware user yet, now go and download new version from www.dameware.com now!

Hi all,

I am having issues authenticating to a client machine. I am using Dameware Mini Remote Control version 7.5.9.1. I have attached a picture so you can see the exact error I am receiving. I can log onto the remote machine via the Windows NT Challenge/ Response option. It won't seem to authenticate the smart card for whatever reason. I have checked for the DWRCSS.dll in %systemroot%\DWRCS on the local and remote machines. It is in both locations. Any help on this issue would be greatly appreciated.

Running windows 7 Pro and when I try to connect to a new system to send the client I get the following error.

Winsock connect error.10060

System message

A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

Running dameware 11.2.0.91

I have turned off firewall that didn't solve the issue same error.

Reinstall  dameware same issue.

You seem to have a strict "no public timelines" policy which while very unhelpful to begin with, is becoming a big problem for us with the TLSv1.2 issue and our need to comply with PCI. Can you tell me if you will have support for TLSv1.2 completed prior to June 30th of this year per PCI requirements? If this is not something you can answer then we need to start shopping for a new remote support tool now. If you are able to answer this question, I do hope that your time-frame is much sooner than end of June so we have time to upgrade. This really should have been done a long time ago but we like the product enough that we've patiently waited. Out patience is now running thin and with the 1709 issues, it's even thinner now. Please provide your customers with the information they need to make decisions or you will start losing them.

Note: This is a topic brought over from DameWare Forums which has been closed. If you wish to engage in this discussion, just comment here.

Damware Remote on Windows PE?
by guy on Wed Feb 24, 2010 5:01 am

Hello,
Over the last few days I have been trying to get Windows PE to run Dameware.
What I have done is install the client onto a base PC, copy off the drivers I think are required (below) copying them to PE in X:\Windows\System32\ and then started DWRCS.exe - install /-service.

DWRCK.dll
DWRCS.exe
DWRCSET.dll
DWRCSI.dll
DWRCST.exe

I can ping the PC with PE (firewall switched off on both computers) and it authenticates and it even tells me the keyboard set is in a different language but it then gets stuck on "initializing desktop, please wait"

Can anyone help me? I'm using Windows PE 3 with all packages installed WMI etc. 

Many Thanks!

Re: Damware Remote on Windows PE?
by guy on Wed Apr 07, 2010 9:04 am

Bump...
Anyone have any ideas at all?

Re: Damware Remote on Windows PE?
by dcolpitts on Sun Apr 25, 2010 8:15 am

You didn't make mention of whether you are using x86 or x64 of WinPE... As of 6.8.1.4, the Dameware client was 32 bit only, so it wouldn't work with the x64 builds of WinPE. You may want to have a look at my posting here: http://forums.dameware.com/viewtopic.php?f=9&t=469

Also, since my last posting there, I found a somewhat simplier way to do things. Use the "DameWare Mini Remote Package Builder" to build an MSI, including configuration for Proprietary Challenge/Response, then extract that resulting .MSI with 7-Zip, and then within there, you will find a Cabs.dwrcs.cab. Extract that to your WinPE's \windows\system32 folder. That contains everything you need to run the client. Lastly, you will need to add a line to run "\windows\system32\DWRCS.EXE -install" within WPEINIT.

And just to be perfectly clear, I have not tried what I suggested above yet with WinPE 3, but I believe it should work.

dcc

Re: Damware Remote on Windows PE?
by rotot on Tue Apr 27, 2010 7:47 am

mmm...thanks for info

Re: Damware Remote on Windows PE?
by guy on Tue May 11, 2010 11:31 am

Sorry I was not clear and the delay.
my WinPE is currently 32bit.
I will test the install and let you know.

Re: Damware Remote on Windows PE?
by guy on Tue May 11, 2010 11:55 am

Thanks for your help so far!

Ok so I've done the follows:
Made a Windows Vista (32-bit) MSI with proprietary challenge/responce
Build the MSI
Extracted the MSI
Extracted Cabs.dwrcs.cab
Copyed the files: DWRCK.dll,DWRCS.exe,dwrcs.ini,DWRCSET.dll ,DWRCSh32.dlx,DWRCSh64.dlx,DWRCSI.dll,DWRCST.exe to X:\Windows\System32\ (X: being the standard drive letter PE sets)
Launched "X:\windows\system32\DWRCS.EXE -install"
It connects to the point saying Initalzing Desktop. Please wait...." and thats it nothing more I have turned off the mirror driver as well.

Any Ideas

Re: Damware Remote on Windows PE?
by dcolpitts on Tue May 11, 2010 12:37 pm

Not right off... I just tested it and get the same result you do. I fear you may SOL unless someone from Dameware wishes to point us in the correct direction.

dcc

Re: Damware Remote on Windows PE?
by guy on Wed May 12, 2010 4:48 am

Thanks for that...
At least I know I'm not being stupid now if someone else can replicate the issue I have.
It's as shame as I'm sure it's something fairly simple to fix as it's -almost- working....
Anyone from Dameware - Are you reading ?

Re: Damware Remote on Windows PE?
by guy on Wed May 12, 2010 7:56 am
Just to update further.... It seems that becuase Dameware required Terminal Services this will never work....
PE is just too stripped down to allow anything like this to work 
I guess it's time to look at an open source application for PE.... 

Re: Damware Remote on Windows PE?
by dcolpitts on Wed May 12, 2010 9:38 am

I'm not sure that is the issue... My BartPE (with Sherypa's XPE based on Windows 2003 SP1) works fine with Dameware, and it does not have RDP support in it.

Re: Damware Remote on Windows PE?
by guy on Thu May 13, 2010 8:13 am

in your BartPE if you type Net Start do you have Terminal Services running?!

Re: Damware Remote on Windows PE?
by dcolpitts on Thu May 13, 2010 8:50 am

Nope. These Windows services are started:
Audio Windows
DameWare Mini Remote Control
DCOM Services
DHCP Client
EventLog
Network Connections
Network Location Awareness (NLA)
Plug and Play
Protected Storage
Remote Procedure Call (RPC)
Security Accounts Manager
TCP/IP NetBIOS Helper
Workstation

dcc

Re: Damware Remote on Windows PE?
by nhelp4k6 on Wed Jun 02, 2010 12:51 pm

Read both the WAIK documentation (msdn or technet) and the Technet forums; PE stands for Preinstallation Environment - as in completing tasks so that the *full* system can be loaded. If you are interested in a windows "slackware" style session there is a convuluted method of building XPe to CD size. Disadvantages of the XPe method are several, to begin with it's a lot of work for limited (based on your description) payback, targeting tends to be specific to machine hw config, and you need the target designer - last I checked it ran ~$1K.
Better question, why do you want to use dwmrc inside PE/slackware?

Re: Damware Remote on Windows PE?
by guy on Tue Aug 10, 2010 5:55 am

The reason for wanting Dameware in PE is for remote rebuilding/repair.
PCAnywhere has "thin host" which works but it's very expensive and not really helpful as we have Dameware in many places.
The idea is that you boot into PE (remotely) connect into the PC with Dameware start the process you need i.e. A build and off you go.

Note: This is a topic brought over from DameWare Forums which has been closed. If you wish to engage in this discussion, just comment here.

Granting remote control rights to non-admins
by abentley on Wed Sep 09, 2009 4:38 am

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.

What I want is for members of a specific domain global group to be able to connect to any MRC client. All of the members of this group are at the very least members of the local 'Users' group on each computer (becuase they are members of Domain Users which is in-turn a member of the local Users group). Some members of the domain group have local admin rights on computers, and it is only these accounts that are able to authenticate and connect.

I require all connection attempts to prompt for permission when someone is logged on to the target computer, and for any connection to a locked or un-logged-on computer to be automatically accepted.

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=6129
Adgang NTLM=Yes
Adgang 1=
Adgang 2=
Adgang 3=0
Notify On New Connection=Yes
Notify On Disconnection=No
No Notify Sound=No
Notify On New Connection Timeout Value=30
Notify Dialog Caption=Remote Control
Notify Dialog Text 1=Remote Control Notification
Notify Dialog Text 2 Remote Control=The following user has connected viaremote control.
Permission Required=Yes
Center Permission Dialog=No
Permission Dialog Set Focus On Decline Button=No
Show SysTray Icon=Yes
Enable User Option Menu=No
Option Notify On New Connection=Yes
Option Notify On New Connection Dialog Timeout=Yes
Option On Disconnect Logoff Desktop=Yes
Option On Disconnect Logoff Desktop Force Applications Close=Yes
Option On Disconnect Lock Workstation=Yes
Option Logon At Logon Desktop Only=Yes
Option Logon At Logon Desktop Only Timeout=Yes
Option Enable File Transfer=Yes
Option Enable Chat=Yes
Option Enable Chat Allow Anyone To Initiate=Yes
Option Permission Required=Yes
Option Enable Add Client Connection Menu=Yes
Option Enable DisConnection Menu=Yes
Option Enable Email Notification=Yes
Option Enable Email Notification Change Email Address=Yes
Permission Required for non Admin=Yes
Permission Required for non Admin Disconnect If At Logon Desktop=No
Permission Required for non Admin Force View Only=No
On Disconnect Logoff Desktop=No
Force Applications Close=No
On Disconnect Lock Workstation=No
Logon At Logon Desktop Only=No
Logon At Logon Desktop Only Timeout=Yes
Logon At Logon Desktop Only Timeout Value=20
Enable Add Client Connection Menu=Yes
Enable Disconnection Menu=Yes
Enable Settings Menu=No
Absolute Timeout=0
Requires Explicit Remote Admin Rights=No
Allow Only Administrators To Connect=No
Requires Logon Locally Privilege=No
Must Be Member Of This Local Group=No
Local Group Name=
Must Be Member Of This Global Group=Yes
Global Group Name=DameWare Desktop Remote Control Access
Enable Email Notification=No
Email Notification Address=
Email Notification Server=
Disable Host Lookup=Yes
Socket Logon Timeout=90000
Authentication Type=2
Must Have Logon Locally Rights with Windows Logon=No
SFT: Enable Simple File Transfer=Yes
SFT: Append Host Name=No
SFT: Upload Folder=%SYSTEMROOT%\DWRCS UploadsSFT: User Response Time Out=6000
Disable Version Downgrade=No
Global 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=Yes
Upgrade Information=
Downgrade Information=
Max Access Log Size=10240000
Force Encrypt Data=No
Force Encrypt Images=No
Force Encrypt Files=No
Configuration Version=5.5
[Proxy]
Enable Proxy=No
Require Shared Secret=No
Disable Remote Control=No
[IP Filter]
Enable Filter For Remote Control=No
Enable Filter For Proxy=No
Access Granted=Yes

Questions: Can 'Global Group Name' contain spaces and does it need to be prefixed with 'DOMAIN\' ?

Many thanks in advance

Re: Granting remote control rights to non-admins
by switbro on Wed Sep 09, 2009 6:21 pm

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?

Thanks
Scott

Re: Granting remote control rights to non-admins
by abentley on Tue Sep 15, 2009 2:07 am

Hi, is anyone able to advise on this issue? Thanks

Re: Granting remote control rights to non-admins
by bryan on Fri Sep 18, 2009 1:24 pm

Exactly what error message are you receiving when you try to connect? Because it looks like everything is setup correctly. Spaces in the Global Group name should also be fine (i.e. Domain Admins).

Permission Required=Yes
- all users, even Admins, will require permission from the desktop user
- unless remote machine is at Logon Desktop or Lock Screen

Permission Required for non Admin=Yes
Permission Required for non Admin Disconnect If At Logon Desktop=No
Permission Required for non Admin Force View Only=No

- non-Admins will require permission from the desktop user, unless @ Logon Desktop or Lock Scr.

Please also look for DWMRCS entries in the Operating System's Application Event Log on theremote machine. Copy & paste the entire text from each of these entries back to our support team so they can review them. There should be at least two entries for each failed login attempt.

Once we have this information we whould be able to assist you further.

I hope this helps.

Bryan Brinkman
Support Engineer
DameWare Development, LLC.
http://www.dameware.com
 

Re: Granting remote control rights to non-admins
by abentley on Mon Sep 21, 2009 3:14 am

Thanks for the response Bryan. When any non-local admin attempts to connect they get this error immediately:

Authentication failed:
System Error: 5
System Message: Access denied

Event log entries:
CODE: SELECT ALL
Error:
DameWare Mini Remote Control
System Error: -2146893044
Failed to establish a security context. OS Error Code: [SEC_E_LOGON_DENIED] The logon attempt failed. : (srv)

CODE: SELECT ALL
Error: Failed Authentication.
Using Windows NT Challenge/Response.

  
Date: 09/21/2009 09:02:59  
Computer Name: [computername]  
User ID: [logged-in username]  
Logon As ID: [login credentials username - not the same as username above]  
Domain:   
Desktop User ID:   
Desktop Name:   
System Settings Using: INI-File  
Desktop State: Unknown  
Permission Required: Yes  
Access Approved By: N/A  
Access Declined By: N/A  
Access Request Timeout: N/A  
Access Request Disconnected: N/A  
OS Product ID: [product id]  
OS Registered Owner: [registered owner]  
OS Registered Organization: [registered org]  
Host Name from Peer: [computername]  
IP Address(es) from Peer: [ip address]  
Peer Host Name:   
Peer IP Address: [ip address]  
Protocol Version - DWRCC.EXE: 6.800000-0.000010  
Protocol Version - DWRCS.EXE: 6.800000-0.000010  
Product Version - DWRCS.EXE: 6.8.1.4  
Product Version - DWRCC.EXE: 6.8.1.4  
Proxy Host Used: No  
Proxy Host:   
Proxy Destination Host:   
Proxy Destination Port: 0   
Proxy Callback Port: N/A   
Authentication Type: NT Challenge/Response  
Last Error Code: -2146893044  
Last Error Code (WSA): 0  
Host Port Number: 6129   
Host IP Address: [ip address]   
Host Name: [computer name]   
Absolute timeout setting: 0 minutes  
Connect/Logon timeout setting: 90000 milliseconds  
AccessCheck:   
Registered: No  
WTS Session: No  
Used RSA Public-Key Key Exchange (1024 bit keys).  
Encryption IDs: 26128 (24576,1536,16) [256].  
Hashing IDs: 26128 (24576,1536,16).  
Used Shared Secret: No  
Registration: [registration code]

Re: Granting remote control rights to non-admins
by mbernards on Tue Sep 29, 2009 4:32 am

We have added all global groups in our forests and domains with one name: UG_DWMRC
Universal groups does not seem to work here.

In those groups reside all support personal.

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 clients
You have to force new settings by removing the current remote control agent and installing the new builded MSI file
The repair option does not restart the service for unknown reasons
(I am local admin, but event log says cannot find file)

I also enabled a central log server ( needs a active DWMRCS service )

Domain and enterprise administrators are also allowed to take over machines.

Works great here.

Re: Granting remote control rights to non-admins
by abentley on Wed Oct 07, 2009 5:04 am

Hi, any update on this issue from DameWare support? Thanks

Re: Granting remote control rights to non-admins
by bryan on Fri Oct 09, 2009 9:54 am

See this post for additional information:
http://forums.dameware.com/viewtopic.php?f=8&t=1189

Do those non-Admin credentials have sufficient right to login at the console of this remotemachine? In other words, can these non-Admins physically walk up to this machine and sit down at the console and use their credentials to login? If not, then they won't be able to use those credentials to connect via our software either.

SEC_E_xxxxx errors are produced by Microsoft's SSPI (Security Support Provider) interface within the O/S, which is only used when using NT Challenge/Response authentication. Our software simply passes the necessary information to Microsoft's SSPI interface and the O/S takes over and performs all authentication.

This specific SSPI Error, "Failed to establishing a security context" - SEC_E_LOGON_DENIED, implies there may be some setting within your O/S that's preventing "LAN Manager Authentication" on this machine, possibly a Policy setting (i.e. "Send NTLMv2 response only\refuse LM & NTLM" , etc.).

Therefore, you might want to try using the Encrypted Windows Logon authentication method instead. Using the Encrypted Windows Logon authentication method may resolve your issue, or it may actually generate another error message which may point us in the right direction with regard to this issue. However, presently this behavior appears to be related to some type of O/S configuration issue.

Here are some other things you can check:

- For machines in a Domain, make sure the Net Logon Service is running.
- Make sure the credentials you're using to connect do not have an expired password.
- Check your LanManager Authentication Level policy.
- Try using the Encrypted Windows Logon authentication method instead.

I hope this helps.

Bryan Brinkman
Support Engineer
DameWare Development, LLC.
http://www.dameware.com

Re: Granting remote control rights to non-admins
by abentley on Mon Oct 12, 2009 3:03 am

Thanks Bryan,

I did read the article above and have tried Encrypted Windows Logon before. I have just tried again on several computers and still no joy...

1. The NETLOGON server is running. Confirmed on all computers. All other domain-based authenticaion would fail without this service, so it's definitely running OK.

2. The credentials I am testing with are definitely OK. The account is not expired, locked out and does not require a password change. I can logon interactively at the console of any computer with this test account.

3. LAN Manager Authentication Level is configured using Group Policy to: Send LM & NTLM - use NTLMv2 session security if negotiated. I have also set this to 'Not Configured' so that the default Vista setting (Undefined on workstations) takes effect, this does not help either.

4. Both Windows NT Challenge Response and Encrypted Windows Logon consistently fail for all users who do not have local admin rights. I changed the 'Authentication Type' in the ini file (restarting DameWare service after each change) to 2,4 and 6 to test the different scenarios.

Here's the event log of a failed Encrypted Windows Logon attempt:

Error: Failed Authentication.
Using Encrypted Windows Logon.
CODE: SELECT ALL
Error:
DameWare Mini Remote Control
System Error: 1326
Failed to Logon User (srv)

CODE: SELECT ALL
Date: 10/12/2009 08:46:45  
Computer Name: [computername]  
User ID: [username]  
Logon As ID: [username]  
Domain:   
Desktop User ID:   
Desktop Name:   
System Settings Using: INI-File  
Desktop State: Unknown  
Permission Required: Yes  
Access Approved By: N/A  
Access Declined By: N/A  
Access Request Timeout: N/A  
Access Request Disconnected: N/A  
OS Product ID: 89579-236-0200203-71402  
OS Registered Owner: [owner]  
OS Registered Organization: [org]  
Host Name from Peer: [client computer name]  
IP Address(es) from Peer: [client ip address]  
Peer Host Name:   
Peer IP Address: [client ip address]  
Protocol Version - DWRCC.EXE: 6.800000-0.000010  
Protocol Version - DWRCS.EXE: 6.800000-0.000010  
Product Version - DWRCS.EXE: 6.8.1.4  
Product Version - DWRCC.EXE: 6.8.1.4  
Proxy Host Used: No  
Proxy Host:   
Proxy Destination Host:   
Proxy Destination Port: 0   
Proxy Callback Port: N/A   
Authentication Type: Encrypted Windows Logon  
Last Error Code: 1326  
Last Error Code (WSA): 0  
Host Port Number: 6129   
Host IP Address: [host ip address]   
Host Name: [host computer name]   
Absolute timeout setting: 0 minutes  
Connect/Logon timeout setting: 90000 milliseconds  
AccessCheck:   
Registered: No  
WTS Session: No  
Used RSA Public-Key Key Exchange (1024 bit keys).  
Encryption IDs: 26128 (24576,1536,16) [256].  
Hashing IDs: 26128 (24576,1536,16).  
Used Shared Secret: No  
Registration: [reg code]

Hello everybody,

we are running the actual version of DameWare 11.1.0.170 for our Administrators to have some smooth remote support ability.

There is only one problem/missed function, we want to have.

We want to see which user is logged into a machine, when we are checking our "Active Computer list" in DameWare.

Also I know this can be done via the Active Directory (add to the description field on the computer), but then we have some double maintenance.

Is there any functionality on DameWare to check which user is logged into. For example is DameWare able to readout the "User and Groups" of Windows or the registry to check whether which user has logged in today?

Thanks for any answer.

Hopefully you can help me.

Best Regards,

Philipp

So after upgrading my M.2 240ssd to a 1TB m.2 I figured I would reinstall windows 10 and go with the latest creators version 1709. After installing Dameware Remote Support 12.05.6002 I no longer saw the MS network section expanded in the master browser with all my windows devices like it had in previous versions of windows, including previous windows 10. 1703

Well after contacting solarwinds support and working through the issue, as well as searching on google for this issue. I came across  Microsoft disabling smbv1 in windows 10 1709 by default. After I went in to contol panel, add/remove programs, and windows features turn on/off I renabled the smbv1 protocol and now the MS windows network section is once again populating.  Ive attached a screen shot of the place to check.

Can anyone help us. We are running dameware version 12.0.0.509 and when we remote into a Windows 10 Device (1703) and its at the login screen it is extremely slow to respond. Once we get logged in its fine however the login screen is extremely slow. How can we fix this.

Welcome to the DameWare DRS space on thwack!  If this is your first time here, you’ll find a wealth of information available to you on DameWare DRS as well as other SolarWinds products.  thwack is an active community where SolarWinds customers can share ideas and tips, ask questions, discuss feature requests, and find out what’s in the latest release and what’s coming next.  SolarWinds Product Management, Development, and Support staff all regularly monitor and post to thwack.  We look forward to hearing your feedback and ideas!

I just upgraded my centralized server to version 11.1 and I'm trying to get all of my techs client machines upgraded but the silent install isn't working.  It just hangs forever.  Any idea if there are some changed arguments for version 11.1 .exe install.

We are currently testing deployment of Dameware Mini Remote Control to the client systems.

With the previous version (11.1), we were able to add a new line to the registry location [HKEY_LOCAL_MACHINE\Software\DameWare Development\Mini Remote Control Service\Settings]

"UseCurrentLogonCredentials"=dword:00000001

This would automatically select 'Windows NT Challenge/Response' and check the 'Use Current Logon Credentials'

This is not seems to be the case with the new version 11.2. When I add the link, nothing seems to happen.

Can anyone suggest solution?

Thanks.

Hello. I'm very new to Dameware.  We have the centralized solution, using the MSI tool to create an msi package that's distributed via SMS.  Prior to this, my colleagues on the other side of the world had been using the stand-alone version. Apparently IT Security had advised on security settings, one of which I'm not sure I understand how it works, specifically the 3 options under Install Options in Default Host Properties in Mini Remote Control. All of these were checked.  My questions regarding this are:

1. If 'Remove service on disconnect' is selected, wouldn't that basically nullify the other two options, Stop service on disconnect and Set Service Startup type to "Manual" default is automatic'?  IOW, If the desire is to remove the client on disconnect, wouldn't selecting the single option negate the need to select the other two options?

2. How do you control these settings since it seems that this is set in MRC?  So, for example, the MRC client is rolled out via SMS and installed on the remote PC, would each tech using MRC have to edit these settings for their own installation, in order to remove the client on disconnect?  Is there a way to make this setting global? How do you enforce something like this (i.e., all techs have this option either ENABLED or DISABLED)?

3. Is there a best practice with regard to the client and if it should remain installed?  Should it be removed after every disconnect? If so, why?

Thanks for any feedback.

-Rob

So after upgrading my M.2 240ssd to a 1TB m.2 I figured I would reinstall windows 10 and go with the latest creators version 1709. After installing Dameware Remote Support 12.05.6002 I no longer saw the MS network section expanded in the master browser with all my windows devices like it had in previous versions of windows, including previous windows 10. 1703

Well after contacting solarwinds support and working through the issue, as well as searching on google for this issue. I came across  Microsoft disabling smbv1 in windows 10 1709 by default. After I went in to contol panel, add/remove programs, and windows features turn on/off I renabled the smbv1 protocol and now the MS windows network section is once again populating.  Ive attached a screen shot of the place to check.

Hello everybody,

we are running the actual version of DameWare 11.1.0.170 for our Administrators to have some smooth remote support ability.

There is only one problem/missed function, we want to have.

We want to see which user is logged into a machine, when we are checking our "Active Computer list" in DameWare.

Also I know this can be done via the Active Directory (add to the description field on the computer), but then we have some double maintenance.

Is there any functionality on DameWare to check which user is logged into. For example is DameWare able to readout the "User and Groups" of Windows or the registry to check whether which user has logged in today?

Thanks for any answer.

Hopefully you can help me.

Best Regards,

Philipp

Please note we have released Hotfix 1 for Dameware version 12.0. This hotfix is available on your customer portal.

Hotfix 1 addresses the following issues:

• ZDI-CAN-3125 vulnerability (Thanks to Andrea Micalizzi aka rgod, working with HP's Zero Day Initiative, for identifying this issue.)
• Upgrading MRC agents on remote machine failed.
• MRC was not able to connect to remote machine using "MRC Ping" feature.
• DRS Service installation failed in DRS.
• Event log does not show content in DRS.

Hotfix 1 requires SolarWinds DameWare Mini Remote Control version 12.0.0.509. Hotfix 1 can be applied to both 32-bit and 64-bit installations or SolarWinds DameWare Remote Support version 12.0.0.509.

You can find more details in README file included in hotfix.

Now go and download the hotfix now.