Dameware License Activation Failed
Melia Hazinski
It seems to happen when I try to use the miniremote to remote into some computers, not all remote clients. It seems to happen after a sudden disconnect or reboot of the remote machine. It doesn't matter where I do it, so it not computer/profile specific. And I can get co-workers to login to the same remote system w/o issue, so it seems to be my issue.
I can use dameware NT utilities to access all the tools for the respective computer but a soon as I try to use MiniRemote and try to login I get the error. I can use other remote desktop apps and windows RDP w/ smart card authentication w/o errors.
I've tried uninstalling and reinstalling the program on my pc, the service and drivers on the remote PC w/ Dameware software. I've tried manually adding and removing the conents %windir%\dwrcs folder on the remote system w/o issue.
We are having the same issue in our environment aside from the smart card being seen as JavaCard #2. We are thinking it has something to do with certificates since the majority of the users having issues were just recently issued a new smartcard token. We have not found a solution as of yet.
I was given this work around from Solarwinds and it is working for us maybe it will work for you as well ''If you remove the Smart Card before clicking Connect in the Remote Connect Window, then re-inserting the Smart Card when the Smart Card Remote Logon window appears"
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 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.
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?
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).
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.
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)
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.
- 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.
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.
I did a fresh install of Windows 8.1 and tried to install DW9. The installation goes all the way through until it seems to start modifying registry keys. It throws an error that "There is a problem with the Windows installer package. A program required for this install to complete could not be run."
I've installed every vc++ redistributable known 2005,2008,2010,2012, and I've installed .net 2, 3.0, 3.5, and 4.0 - 3 - 4.5 is installed via Programs and Features. I've also installed various versions of DirectX just to see if it had something to do with that and no-go. I've got full admin rights on this box, and another person that I work with is having the same problem. The users that upgraded from Windows 8.0 to 8.1 are not having an issue, so it looks like Windows 8.0 may have something that 8.1 doesn't have? What in the world is it??
Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: APPDIR, location: C:\Program Files (x86)\SolarWinds\DameWare Remote Support 9.0\, command: ""
I am setting up Dameware 10 Remote Control Tool on a few systems and am having an issue getting connected to remote systems using my CAC. We have both admin and regular certs on the CAC but will be using the admin cert to do the remote control assistance.
After inspecting the security logs on the client system I see that the error is because its attempting to use my regular user account, not my admin account. Even tho we are running the MRC tool using admin cert credentials.
The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
Error 0xc02020a1: Data Flow Task 1: Data conversion failed. The data conversion for column "Description" returned status value 4 and status text "Text was truncated or one or more characters had no match in the target code page.".
(SQL Server Import and Export Wizard)
Error 0xc020902a: Data Flow Task 1: The "Source - DWRCS_csv.Outputs[Flat File Source Output].Columns[Description]" failed because truncation occurred, and the truncation row disposition on "Source - DWRCS_csv.Outputs[Flat File Source Output].Columns[Description]" specifies failure on truncation. A truncation error occurred on the specified object of the specified component.
(SQL Server Import and Export Wizard)
Error 0xc0047038: Data Flow Task 1: SSIS Error Code DTS_E_PRIMEOUTPUTFAILED. The PrimeOutput method on Source - DWRCS_csv returned error code 0xC0202092. The component returned a failure code when the pipeline engine called PrimeOutput(). The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing. There may be error messages posted before this with more information about the failure.
(SQL Server Import and Export Wizard)
I'm trying to find out if the "Encrypted Windows Logon" is using Kerberos as the underlying protocol. I'm assuming the "NT Challenge/Response" is using NTLM but it would be great to know if that is the case for sure.
Second part of the question would be if there is a way to turn on Pass-Through authentication for "Encrypted Windows Logon". It grays out the check box for "Use Current Logon Credentials" when I choose it.
SO we have been using Dameware Mini Remote Control for a couple months now on our fleet of about 400 PCs. My password has since then expired. Now I have to go back through and change my password on ALL of these computers one at a time in MRC. Is there not a way to mass update them???
ff7609af8f