Quantcast
Channel: THWACK: Document List - DameWare DRS
Viewing all 25 articles
Browse latest View live

How to: Use DameWare Remote Support's batch processing to install DameWare Client Agents in multiple hosts

$
0
0

This is a brief guide that shows how to use the batch processing capabilities of DameWare Remote Support 9.0 in order to install the MRC Client Agent in multiple computers. This should simplify the update process and will save you having to use GPO's to distribute the agent as an MSI package.


Additionally, the same procedure applies to installing the DRS Client Agent service (required for the RCMD Console, RCMD View, and ShutDown View).


-----------------------------------------------------------------------

Remember you must have credentials with the following permissions in the remote machines for this to work:


- Writing files into the Admin$ share folder

- Adding Registry Keys remotely

- Starting the service and placing the designated TCP port in a listening state.

-----------------------------------------------------------------------


- Launch DameWare Remote Support

- Select one of the machines you are going to uninstall the service from and open "Services View"


WIN7-02 2013-03-13 10.33.28.png


- At the bottom of this view, a pane appears named "Batch"


batch.PNG


- Drag and drop all the machines you want to uninstall the service from the "Browser" pane into the "Batch" pane


batch2.PNG


- Once you add all the machines, highlight them all (click on the first, scroll all the way to the bottom of the list and click on the last one while hold the SHIFT key)


batch3.PNG


- To install the MRC Client Agent, click on the green/blue screens icon. This will bring up the batch installation window. Here you can click on "Configure..." to set the client agent settings as you need.

- Once you are satisfied, click on OK


batch4.PNG


- To install the DRS Client Agent Service, you should click on the red/blue screens icons. Since that agent doesn't have any settings, you will just get a warning message. Just click on OK to start the installations


batch5.PNG


- The batch processing pane will display the status of the task. Once it's finishes it will display the results for each machine including error information for those that failed/


batch6.PNG


DameWare Version 7 Product History

$
0
0

Please note: this document was brought over from the old DameWare Forums and pertains to version 7.x of DameWare NT Utilities & Mini Remote Control. Similar documents for versions 8 and 9 can be found on thwack as well.


v.7.0.0.0 – Released – 01/12/2011


NT Utilities:

  • Various performance updates and enhancements.

 
Mini Remote Control:

  • Protocol Revision.Users will be required to update any older MRC Client Agent Service on the remote machine to this current version. Selecting No will disconnect the connection.
  • **Important note: Once you upgrade to version 7.x of the MRC Client Agent Service, you cannot downgrade back to any older version "on the fly". You will either have to manually remove this newer version, or provided the necessary ports are open between the local and remote machines, you may be able to select File / Remove Service from the MRC main menu to remove this newer version.

  Additional enhancements include:

  • Full 64-bit support
  • Full IPv6 support, including Teredo
  • Full Unicode support
  • NAT Traversal (via IPv6)
  • Added U3 Mode
  • Added Wake on LAN
  • Added Connection Invitations
  • Added MRC Peers
  • Added PNRP Peers
  • Updated FIPS Modules
  • Remote Clipboard enhancements
  • Settings Storage enhancements (no more DWRCS.INI file)
  • Email notification enhancements
  • XP/2003 session switching enhancements
  • Many more performance updates and enhancements

 

MSI Builder:

  • Added support for 64-bit MSI packages
  • Added support for installation of FIPS Modules
  • Added support for installation of Driver(s)
  • Added support for creating profiles

 
Exporter:

  • Various performance updates and enhancements.


For more detailed information on this new release please refer to the Help File within the software.

Bryan Brinkman
Support Engineer



v.7.0.1.0 – Released – 01/17/2011


NT Utilities

  • Host name population errors when MRC called via DNTU or via the command line. Fixed.
  • RDP Settings would not open via DNTU \ Settings \ RDP Tab. Fixed.

 
Mini Remote Control

  • No Protocol revision. Users will not be required to update the MRC Client Agent Service on the remote machine, provided it's already running v7.0.
  • Added new DWRCS.REG file functionality, so users could distribute initial settings to remote machines during MRC Client Agent installation.
  • Users could possibly receive "Bad_Data" error and MRC connection would fail, due to missing file in MSI Builder package. Fixed.
  • Unable to expand the Saved Host List tree within "Default Host Properties / Update Existing Entries" dialog after initial Host list database conversion. Fixed.

 
Exporter:

  • Version Revision.


MSI Builder:

  • MSI Packages created via MSI Builder sometimes would not reflect custom settings after being installed (including Proprietary Challenge information). Fixed.
  • MSI Packages created via MSI BUilder always included the FIPS modules, even when not selected. Fixed.
  • Various MSI Builder errors. Fixed.
  • MSI Builder missing files. Fixed.

Bryan Brinkman
Support Engineer



v.7.0.2.0 – Released – 01/19/2011


*Note: Please first remove your existing v7 installation via Add/Remove Programs and then install this current version of the software. This build will not automatically remove any previous v7 installations.

NT Utilities

  • TCP Utilities View. Ping & Trace Route functions did not work on Windows 7. Fixed.

 
Mini Remote Control

  • No Protocol revision. Users will not be required to update the MRC Client Agent Service on the remote machine, provided it's already running v7.0 or later. However, we strongly recommend you update the MRC Client Agent Service on the remote machine to the current version.
  • New Host List entries sometimes would not save to the Saved Host List. Fixed.
  • Group Lookups could fail under certain conditions. Fixed**
  • Log Reporting would not create DWRCS.CSV log file. Fixed**
  • "Use email authentication" setting could fail under certain conditions. Fixed**

  ** = Requires 7.0.2.0 MRC Client Agent

Exporter:

  • Version Revision.


MSI Builder:

  • Various MSI Builder errors. Fixed.
  • Temporarily removed 9x package build option in MSI Builder, and provided a default DWRCS9x.msi package on the Client Agent downloads page. This DWRCS9x.MSI package will install using all default settings, including Proprietary Challenge/Response authentication enabled with UserID: "admin" and Password: "1234" (without quotes). Please note this is only to allow you to establish an initial connection to this remote 9x machine. The Proprietary Challenge/Response information should be changed following your initial connection.

Bryan Brinkman
Support Engineer



v.7.0.3.0 – Released – 01/21/2011


NT Utilities

  • DNTU Batch MRC Client Agent Install could sometimes copy the wrong version of the Client Agent files (x86, x64) to the remote machine. Fixed.

 
Mini Remote Control

  • No Protocol revision. Users will not be required to update the MRC Client Agent Service on the remote machine, provided it's already running v7.0 or later. However, we strongly recommend you update the MRC Client Agent Service on the remote machine to the current version.
  • Added checkbox to prevent overwriting of existing Alias & Comments fields in the Remote Connect dialog.
  • File / Install Service feature could sometimes copy the wrong version of the Client Agent Files (x86, x64) to the remote machine. Fixed
  • MRC Saved Host list entry was not always saved when invoked via DNTU or the Command Line. Fixed.

 
Exporter

  • Version Revision


MSI Builder

  • Version Revision

Bryan Brinkman
Support Engineer



v.7.1.0.0 – Released 02/03/2011


NT Utilities:

  • Version Revision.

 
Mini Remote Control:

  • Minor Protocol Revision. Current v7.x users will not be forced to update the MRC Client Agent Service on the remote machine, provided they are already running version 7.0 or above. However, we recommend you update the Client Agent on the remote machine as soon as possible. Otherwise, some features may not work properly (i.e. Proxy, Reverse Connection, etc..). Version 6.x Clients will require an upgrade.
  • Added stand-alone Proxy Service (DWRCSPX.EXE), & Proxy Configuration Utility (DWRCSPC.exe).
  • Added Reverse Connection (Connect To Client) option to Client Agent (requires 7.1.0.0 and above of MRC application and agent)
  • Added IPv6 Organizational Local, Proxy, and IPv4 connections to Invitations.
  • Added GUI for configuration of DWRCS.REG file during Service installation.
  • Added option to disable AutoSave, to prevent "New Host" dialog from automatically appearing when you start typing a new HostName or IP-Address. Setting is located on the Remote Connect dialog's Edit menu.
  • MRC Toolbar and Menu bar can now be combined on a single line.
  • Remote Clipboard sometimes would not work. Fixed.
  • Potential Slow Connection scenario on rare occasions. Fixed.
  • Intermittent crash in Mini Remote Client Agent User Interface (DWRCST.exe). Fixed.

 
MSI Builder:

  • Version Revision


Exporter:

  • Exporter would not show as registered. Fixed.

Bryan Brinkman
Support Engineer



V7.2.0.0 – Released – 02/09/2011


NT Utilities:

  • Version Revision.

 
Mini Remote Control:

  • Minor Protocol Revision. Current v7.x users will not be forced to update the MRC Client Agent Service on the remote machine, provided they are already running version 7.0 or above. However, we recommend you update the Client Agent on the remote machine as soon as possible. Otherwise, some features may not work properly. Version 6.x Clients will require a forced upgrade.
  • Added command line to open MRC Client Agent's Reverse Connect dialog: DWRCS -carc
  • Option to enable "Copy DWRCS.REG configuration file" by default, instead of having to enable the checkbox each time.
  • Enhancements to Encrypted Windows Logon & NT Challenge/Response authentication methods.
  • Saved Host List would not expand on Windows 2000. Fixed.
  • Failed Authentication using Encrypted Windows Logon for non-Admin users. Fixed
  • Non-Saved (temporary) Host entries not added to Reconnect List, even when "Only add Saved Host to Reconnect" disabled. Fixed.
  • Tray Icon's Settings Context menu could not be disabled, even when "Enable Settings menu" was turned off. Fixed
  • Connect via Invitation dialog, Browse (Open Invitation) would crash on 32-bit O/S. Fixed.
  • SFT Shell Registration issues. Fixed.

 
MSI Builder:

  • Fixed win9x package issues.
  • Created new MSI templates for both x64 and x86 packages.
  • Created new MSI templates for installation of the Proxy Service.
  • Added code to reduce the size of the output MSI package, when no driver installers selected.
  • Added functionality to remove Registry settings and application files on uninstall.
  • Added button to open the output folder after build is complete.
  • Added functionality to disable driver installer options when target is win9x.
  • Added functionality to name the output MSI the same name as the profile.
  • Added functionality to remember the location of the dialog and the selected tab.

 
Exporter:

  • Version Revision

Bryan Brinkman
Support Engineer



v.7.3.0.0 – Released 02/25/2011


NT Utilities:

  • Added "Configure" button for MRC Service install.
  • Added ability to remove DNTU's automation context menu from O/S Shell Menu (i.e. right-click/New/DameWare NT Utilities menu).

 
Mini Remote Control:

  • Minor Protocol Revision. Current v7.x users will not be forced to update the MRC Client Agent Service on the remote machine, provided they are already running version 7.0 or above. A red warning dialog will be displayed instead. However, we recommend you update the Client Agent on the remote machine as soon as possible. Otherwise, some features may not work properly. Version 6.x Clients will require a forced upgrade.
  • Changed Group Membership logic on Client Agent Access Tab to be "Must be a member of 1 or more groups", instead of "Must be a Member of ALL groups".
  • Moved Event Log message text to a separate DLL file, to prevent Event Viewer from locking DWRCS.exe during installation or upgrade of the Service.
  • Screen occasionally would not update after logon on Windows 7. Fixed.
  • In some rare cases, MRC.DBF would not convert properly and MRCCv2.db would be blank. Fixed.

 
MSI Builder:

  • Version Revision


Exporter:

  • Version Revision

Bryan Brinkman
Support Engineer



v.7.4.0.0 – Released – 03/09/2011


NT Utilities:

  • Version Revision

 
Mini Remote Control:

  • Minor Protocol Revision. Current v7.x users will not be forced to update the MRC Client Agent Service on the remote machine, provided they are already running version 7.0 or above. A red warning dialog will be displayed instead. However, we recommend you update the Client Agent on the remote machine as soon as possible. Otherwise, some features may not work properly. Version 6.x Clients will require a forced upgrade.
  • Added new "RDP Session" switching functionality on Send menu, which now allows Administrators to shadow any RDP/TS session on the given server.
  • Added new error messages when wrong binary for encryption is found (both FIPS and non-FIPS mode).
  • "Connect via Invitation" grayed out on XP. Fixed.
  • Reconnect list may not populate correctly. Fixed.

 
MSI Builder:

  • Version Revision


Exporter:

  • Version Revision

  Bryan Brinkman
Support Engineer



v.7.5.0.0 – Released – 03/16/2011


NT Utilities:

  • Version Revision

 
Mini Remote Control:

  • Minor Protocol Revision. Current v7.x users will not be forced to update the MRC Client Agent Service on the remote machine, provided they are already running version 7.0 or above. A red warning dialog will be displayed instead. However, we recommend you update the Client Agent on the remote machine as soon as possible. Otherwise, some features may not work properly. Version 6.x Clients will require a forced upgrade.
  • Increased speed in opening MRC Remote Connect dialog.
  • Added two new options with regard to RDP Session Switching on Additional Settings tab in MRC Client Agent. (1) "Disable RDP Session Switching", and (2) "Permission Required RDP".
  • System Error: 193 errors with wrong version of FIPS or DWRCRSA.dll file. Fixed.
  • Multiple MRC connections to the same 2003 Server could cause subsequent connections to hang on "Initializing Settings". Fixed.
  • Permission dialog may not be displayed for remote user and session immediately disconnected for certain O/S implementations. Fixed.

 
MSI Builder:

  • Found hard-coded reference to "C:\Windows\dwrcs" instead of "%windir%\dwrcs" in MSI Builder template. Fixed.


Exporter:

  • Version Revision

Bryan Brinkman
Support Engineer



v.7.5.1.1 – Released – 03/22/2011


NT Utilities:

  • Added Visual Styles and Font Smoothing Performance Options for RDP connections.
  • Intermittent crash when connecting via RDP. Fixed.

 
Mini Remote Control:

  • Minor Protocol Revision. Current v7.x users will not be forced to update the MRC Client Agent Service on the remote machine, provided they are already running version 7.0 or above. A red warning dialog will be displayed instead. However, we recommend you update the Client Agent on the remote machine as soon as possible. Otherwise, some features may not work properly. Version 6.x Clients will require a forced upgrade.
  • Added Visual Styles and Font Smoothing Performance Options for RDP connections.
  • Intermittent crash when connecting via RDP. Fixed.

 
MSI Builder:

  • Version Revision


Exporter:

  • Version Revision

  Bryan Brinkman
Support Engineer



v.7.5.2.0 – Released – 03/31/2011


NT Utilities:

  • Misc. performance improvements.
  • No Entry Point Found error when modifying User Dial-In properties in Standard Users View (non AD). Fixed.

 
Mini Remote Control:

  • No Protocol Revision. Current v7.x users will not be forced to update the MRC Client Agent Service on the remote machine, provided they are already running version 7.0 or above. A red warning dialog asking you to update the Client Agent will only be displayed for Client Agents older than v7.5.1.1.
  • Performance enhancements when loading MRC Remote Connect dialog.
  • Potential SxS (Side by Side) error when using FIPS Mode in MRC x64. Fixed.
  • Disconnect issue when multiple users connected to same machine at same time. Fixed.
  • DWRCS.Reg configuration file was not copied to the remote machine in certain scenarios. Fixed.

 
MSI Builder:

  • Modified O/S options on Proxy Tab to only allow WinXP and above (x86 & x64).
  • Modified MSI Templates to allow for automatic upgrade of most v6.x Client Agents.

 
Exporter:

  • Version Revision

Bryan Brinkman
Support Engineer



v.7.5.5.0 – Released – 04/14/2011


NT Utilities:

  • Drag/drop of a dwabin.txt file containing a DNTU license sometimes would not work in DNTU, but it would work OK in MRC. Fixed.

 
Mini Remote Control:

  • Minor Protocol Revision. Current v7.x users will not be forced to update the MRC Client Agent Service on the remote machine, provided they are already running version 7.0 or above. A red warning dialog will be displayed instead. However, we recommend you update the Client Agent on the remote machine as soon as possible. Otherwise, some features may not work properly. Version 6.x Clients will require a forced upgrade.
  • Potential disconnect when using Proxy. Fixed.
  • Updating Client Agent from v6.x to v7.x may not include the DWRCS.reg configuration file. Fixed.
  • *Potential socket timeout [Winsock 10060] when requesting permission. Fixed.
  • *Reverse Connection (Connect to Client) Host dialog & Proxy Host dialog may not display all characters. Fixed.
  • *Multiple connections to same machine at same time could distort text in Notify dialog. Also, 2nd connected user may not be able to obtain keyboard control. Fixed.

    *=requires 7.5.5.0 or above of MRC Client Agent Service.

 
MSI Builder:

  • Enhancements to both Service and Driver installation/removal processes.
  • Suppressed “DOS” windows from being displayed during optional Driver Installation via MSI Builder package.
  • Potential crash of MRC Client Agent when installed via MSI Builder package. Fixed.
  • Winsock 10091 or 10093 errors may be seen in Application Event Log when Client Agent installed via MSI Builder package. Fixed.

 
Exporter:

  • Drag/drop of a dwabin.txt file containing a DNTU license sometimes would not work in Exporter, but it would work OK in MRC.

Bryan Brinkman
Support Engineer


v.7.5.6.0 – Released – 04/20/2011


NT Utilities:

  • Version Revision

 
Mini Remote Control:

  • Minor Protocol Revision. Current v7.x users will not be forced to update the MRC Client Agent Service on the remote machine, provided they are already running version 7.0 or above. A red warning dialog will be displayed instead. However, we recommend you update the Client Agent on the remote machine as soon as possible. Otherwise, some features may not work properly. Version 6.x Clients will require a forced upgrade.
  • Improved load speed for the following Connect Dialog items: AD, SAM, MS Windows Network, & MRC Peers.
  • Additional enhancements for "Initializing..." scenario under 2003 Server.
  • No video when Client Agent running As Application on XP. Fixed.

 
MSI Builder:

  • MSI Packages built using the MSI Builder may not install properly in certain cases. For example: when UAC was running or when installing via Group Policies or other 3rd-party distribution software. Fixed.


Exporter:

  • Version Revision

  Bryan Brinkman
Support Engineer



v.7.5.8.0 – Released – 09/06/2011


NT Utilities:

  • Updated DNTU icons for Windows 7 & Server 2008.
  • Terminal Services Views not available for 2008 Server. Fixed.

 
Mini Remote Control:

  • Minor Protocol Revision. Current v7.x users will not be forced to update the MRC Client Agent Service on the remote machine, provided they are already running version 7.0 or above. A red warning dialog will be displayed instead. However, we recommend you update the Client Agent on the remote machine as soon as possible. Otherwise, some features may not work properly. Version 6.x Clients will require a forced upgrade.
  • Modified Windows Firewall Exception logic. FW exception now created on Service install and removed on Service uninstall (instead of Service Start and Stop).
  • Enhancements to Blank Monitor functionality when Logging on/off during a MRC connection.
  • SFT would not work during Reverse Connections. Fixed.
  • Some MRC Advanced Ping Options would not stick after being selected. Fixed.
  • Tray icon could reappear (even when configured to hide) for short period of time on Vista after reboot. Fixed.
  • File / Install Service and File / Remove Service would not work on Windows 2000. Would receive System Error: 127 – Module Not found. Fixed.

 
MSI Builder:

  • Version Revision


Exporter:

  • Version Revision

  Bryan Brinkman
Support Engineer



v.7.5.9.0 – Released – 10/14/2011


NT Utilities:

  • Modified creation of "DameWare.NTUtilities" object.

 
Mini Remote Control:
 

  • No Protocol Revision. Current v7.x users will not be forced to update the MRC Client Agent Service on the remote machine, provided they are already running version 7.0 or above.


MSI Builder:

  • Version Revision

 
Exporter:
 

  • Modified creation of "DameWare.Exporter" object to resolve "ActiveX cannot create object" scripting issues.

Bryan Brinkman
Support Engineer


NT Utilities:

  • Modified creation of "DameWare.NTUtilities" object.

 
Mini Remote Control:

  • No Protocol Revision. Current v7.x users will not be forced to update the MRC Client Agent Service on the remote machine, provided they are already running version 7.0 or above.


MSI Builder:

  • Version Revision

 
Exporter:

  • Modified creation of "DameWare.Exporter" object to resolve "ActiveX cannot create object" scripting issues.

Bryan Brinkman
Support Engineer

DameWare Version 8 Product History

$
0
0

Release Notes for Version 8.0 – Released 3/13/12

Why Install this Version

This version of NTU provides the following improvements:

  • Version 8.0 of Mini Remote Control
  • Multiple bug fixes
  • Maintenance

Note: Upgrading to NTU Version 8.0 imposes new licensing requirements. For additional information, see "Using the New Licensing System" in these release notes.


Known Issues

Mini Remote Proxy Service reflects the wrong version in Add/Remove Programs

DameWare Mini Remote Proxy Service reflects version 7.5.9.1 in Add/Remove Programs instead of the correct version number, which is 8.0. This is purely aesthetic and has no effect on the product's functionality.


MRC resizes some windows after disconnecting from multi-monitor computers

If you connect to a remote computer with multiple monitors using MRC, the program changes the size and position of any open window that spans more than one monitor on the remote computer. When you click Disconnect in MRC, it changes the size and position of these windows so they fit on the monitor that had the majority of the window when it connected.


Using the New Licensing System

After installing NTU Version 8.0, you are prompted to enter the licensing information for your product. If you choose to start with the 14-day evaluation, you can access the Licensing Information options by openingStart > All Programs > SolarWinds > DameWare NT Utilities 8.0 > Enter License Information on the computer you want to license.


To evaluate the software without a license, click Continue Evaluation.


To license the software on a computer with Internet access:

1. Click Enter Licensing Information.

2. Select I have internet access and an activation key.

3. Click the http://www.solarwinds.com/customerportal link to access the customer portal on the SolarWinds web site

4. Log on to the portal using your Solarwinds customer ID and password.

5. Click License Management on the left navigation bar.

6. Navigate to your product, choose an activation key from the Unregistered Licenses section, and then copy the activation key.

7. If you cannot find an activation key in the Unregistered Licenses section,     contact SolarWinds customer support.

8. Return to the Activate DNTU window, and then enter the activation key in the Activation Key field.

9. If you access Internet web sites through a proxy server, click I access the internet through a     proxy server, and enter its proxy address and port.
    Note: If your computer accesses the Internet through an authenticated proxy server, complete the

procedure for activating without Internet access instead.

10. Click Next.

11. Enter your email address and other registration information, and then click Next.


To license the software on a computer without Internet access:

1. Click Enter Licensing Information

2. Select This server does not have internet access, and then click Next.

3. Click Copy Unique Machine ID.

4. Paste the copied data into a text editor document.

5. Transfer the document to a computer with Internet access.

6. On the computer with Internet access, complete the following steps:

      a. Browse to http://www.solarwinds.com/customerportal/licensemanagement.aspx, and

    then log on to the portal with your SolarWinds customer ID and password.

      b. Navigate to your product, and then click Manually Register License

      c. If the Manually Register License option is not available for your product,

    contact SolarWinds customer support.

      d. Provide the Machine ID from Step 5, and then download your license key file.

7. Transfer the license key file to the NTU server.

8. Return to the Activate NTU window, browse to the license key file, and then click Next.


Managing your Open Issues in Licensing

For information about managing your licenses for SolarWinds products, including how to deactivate or reuse a license, see SolarWinds License Manager.

Open Issues in Licensing

Open Issues in Licensing

  • Applying Federal Information Processing Standards (FIPS) to a licensed NTU server invalidates the existing license. To reactivate your license, contact SolarWinds customer support.
  • If you enter the activation key from another SolarWinds product by mistake, the activation key for the other product is considered registered even though your actual product remains unlicensed. To return the activation key to your pool of unregistered licenses, contact SolarWinds customer support.

 

Release Notes for Version 8.0.1 – Released 4/26/12

Why Install this Version

This version of NTU provides the following improvements:

  • Version 8.0.1 of Mini Remote Control
  • Multiple bug fixes
  • Maintenance

Note: Starting with version 8.0, NTU imposes new licensing requirements. For additional information, see "Using the New Licensing System" in these release notes.

Fixed Issues in this Release

This release of DameWare NT Utilities includes the following fixes:

  • Mini Remote Proxy Service now reflects the correct version in Add/Remove Programs. (110853)
  • Fixed an issue that prevented NTU from showing event log details for managed computers. (113186)
  • Fixed an issue that prevented NTU from showing the correct Workstation Properties for managed computers. (113512)
  • The "Use DNS entry" option now allows MRC to display the fully qualified domain name for computers in the Remote Connect dialog. (108108)
  • Fixed an issue that prevented NTU from showing entities in Active Directory Users & Computers. (113275)
  • Fixed an issue that prevented MRC client agents that are installed using the Mini Remote Control Client Agent MSI Builder from being upgraded. (115110)
  • Fixed an issue that prevented NTU from showing Windows updates for managed computers running Windows Vista or later. (111750)
  • The "Select Domain" menu in the Explore Network utility now shows available domains in NTU.


Using the New Licensing System

After installing NTU Version 8.0 and higher, you are prompted to enter the licensing information for your product. If you choose to start with the 14-day evaluation, you can access the Licensing Information options by opening Start > All Programs > SolarWinds > DameWare NT Utilities 8.0 > Enter License Information on the computer you want to license.

To evaluate the software without a license, click Continue Evaluation.
To license the software on a computer with Internet access:

1. Click Enter Licensing Information.

2. Select I have internet access and an activation key.

3. Click the http://www.solarwinds.com/customerportal link to access the customer portal on the SolarWinds web site.

4. Log on to the portal using your SolarWinds customer ID and password.

5. Click License Management on the left navigation bar.

6. Navigate to your product, choose an activation key from the Unregistered Licenses section, andthen copy  the activation key.

7. If you cannot find an activation key in the Unregistered Licenses section, contact SolarWinds customer support.

8. Return to the Activate DNTU window, and then enter the activation key in the Activation Key field.

9. If you access Internet web sites through a proxy server, click I access the internet through a proxy server, and enter its proxy address and port. Note: If your computer accesses the Internet through an authenticated proxy server, complete the procedure for activating without Internet access instead.

10. Click Next.

11. Enter your email address and other registration information, and then click Next.


To license the software on a computer without Internet access:

1. Click Enter Licensing Information

2. Select This server does not have internet access, and then click Next.

3. Click Copy Unique Machine ID.

4. Paste the copied data into a text editor document.

5. Transfer the document to a computer with Internet access.

6. On the computer with Internet access, complete the following steps:

a. Browse tohttp://www.solarwinds.com/customerportal/licensemanagement.aspx,
and then log on to the portal with your SolarWinds customer ID and password.

b. Navigate to your product, and then click Manually Register License.

c. If the Manually Register License option is not available for your product,
contact SolarWinds customer support.

d. Provide the Machine ID from Step 5, and then download your license key file.

7. Transfer the license key file to the NTU server.

8. Return to the Activate NTU window, browse to the license key file, and then click Next.

 

Managing your Open Issues in Licensing

For information about managing your licenses for SolarWinds products, including how to deactivate or reuse a license, see SolarWinds License Manager.

Open Issues in Licensing

  • Applying Federal Information Processing Standards (FIPS) to a licensed NTU system invalidates the existing license. To reactivate your license, contact SolarWinds customer support.
  • If you enter the activation key from another SolarWinds product by mistake, the activation key for the other product is considered registered even though your actual product remains unlicensed. Deactivate the misallocated activation key to return it to your pool of unregistered licenses.

To return a misallocated activation key to your pool of unregistered licenses:

1. Navigate tohttp://solarwinds.s3.amazonaws.com/solarwinds/Release/LicenseManager/LicenseManager.zip.

2. Unzip the downloaded file, and then run LicenseManager.exe.

3. Start the License Manager from the SolarWinds Program group.

4. Select the products you want to deactivate on this computer.

5. Click Deactivate.

6. Click Deactivate again to confirm your selection.

Note: Deactivated licenses are now available for activation on a new computer.

DameWare Version 9 Product History

$
0
0

DameWare Remote Support Version 9.0.0 Release Notes - 9/7/12


DameWare NT Utilities (NTU) is now DameWare Remote Support (DRS). These release notes provide additional guidance for DRS version 9.0.


Why Install this Version

This version of DRS provides the following improvements:

  • Version 9.0 of Mini Remote Control:
  • Intel vPro Support:
  • Support for Silent Installs:
  • Multiple bug fixes:

Notes:

  • If you are upgrading to DRS version 9.0 from a version earlier than 8.0, apply your SolarWinds license after you upgrade. For additional information, see "Using the New Licensing System" in these release notes.
  • Starting with version 9.0, you may notice a change in how your license looks in the SolarWinds customer portal. This change is solely to facilitate backend processing, and does not affect your license count or pricing.

Resolved Issues

DameWare Remote Support version 9.0 resolves the following issues in earlier versions:

  • NTU v8.x crashes when you close the Shutdown window.
  • The Servers node in NTU v8.x enumerates the same server repeatedly when expanded.
  • DameWare Exporter in NTU v8.x crashes when you export to a non-existent folder.
  • The Download SolarWinds License Manager link in the host Start menu does not work on Windows Server 2003 or Windows XP hosts in v8.x.


Known Issues

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.


U3 Mode is not a valid licensing option with the new licensing system

Previously, NTU users were able to license the product in "U3 Mode", which allowed them to run the application from a USB drive. This functionality is not currently compatible with our licensing system, but we are investigating a resolution for a future release.


End of Life Policy

In order to continue to drive innovation and new functionality into our products, SolarWinds must transition customers from legacy versions of software to our current versions. Please review the following support schedule:

  • 9/13/2012: End-of-Life announcement (EoL) – Customers on DameWare v6.9 or older should begin transitioning to DameWare 9.0.
  • 12/12/2012: End-of-Life (EoL) – SolarWinds will no longer provide technical support for SolarWinds DameWare v6.9 or older.


Using the New Licensing System

After installing NTU or DRS version 8.0 or higher, you are prompted to enter the licensing information for your product. If you choose to start with the 14-day evaluation, you can access the Licensing Information options by opening Start > All Programs > SolarWinds > DameWare Remote Support 9.0 > Enter License Information on the computer you want to license.


To evaluate the software without a license, click Continue Evaluation.


To license the software on a computer with Internet access:

  1. Click Enter Licensing Information.
  2. Select I have internet access and an activation key.
  3. Click the http://www.solarwinds.com/customerportal link to access the customer portal on the SolarWinds web site.
  4. Log on to the portal using your SolarWinds customer ID and password.
  5. Click License Management on the left navigation bar.
  6. Navigate to your product, choose an activation key from the Unregistered Licenses section, and then copy the activation key.
  7. If you cannot find an activation key in the Unregistered Licenses section,contact SolarWinds customer support.
  8. Return to the Activate DRS window, and then enter the activation key in the Activation Key field.
  9. If you access Internet web sites through a proxy server, click I access the internet through aproxy server, and enter its proxy address and port.
  10. Note: If your computer accesses the Internet through an authenticated proxy server, complete the procedure for activating without Internet access instead.
  11. Click Next.
  12. Enter your email address and other registration information, and then click Next.


To license the software on a computer without Internet access:

  1. Click Enter Licensing Information.
  2. Select This server does not have internet access, and then click Next.
  3. Click Copy Unique Machine ID.
  4. Paste the copied data into a text editor document.
  5. Transfer the document to a computer with Internet access.
  6. On the computer with Internet access, complete the following steps:

a. Browse to http://www.solarwinds.com/customerportal/licensemanagement.aspx, and then log on to the portal with your SolarWinds customer ID and password.

b. Navigate to your product, and then click Manually Register License.

c. If the Manually Register License option is not available for your product, contact SolarWinds customer support.

d. Provide the Machine ID from Step 5, and then download your license key file.

7. Transfer the license key file to the DRS server.

8. Return to the Activate DRS window, browse to the license key file, and then click Next.


Managing your Open Issues in Licensing

For information about managing your licenses for SolarWinds products, including how to deactivate or reuse a license, see SolarWinds License Manager.

Open Issues in Licensing

  • Applying Federal Information Processing Standards (FIPS) to a licensed NTU server invalidates the existing license. To reactivate your license, contact SolarWinds customer support.
  • If you enter the activation key from another SolarWinds product by mistake, the activation key for the other product is considered registered even though your actual product remains unlicensed. To return the activation key to your pool of unregistered licenses, contact SolarWinds customer support.

 

 

DameWare Remote Support Version 9.0.1 Release Notes


DameWare NT Utilities (NTU) is now DameWare Remote Support (DRS). These release notes provide additional guidance for DRS version 9.0.1.


Why Install this Version

This version of DRS provides the following improvements:

  • Windows 8 Support:You can now install DRS on computers running the latest Windows desktop operating system. DRS also connects to remote hosts running Windows 8.
  • Version 9.0.1 of Mini Remote Control:This release includes the latest version of DameWare MRC. For additional information, see the DameWare MRC release notes.
  • Intel vPro Support:Both DRS and MRC now support Intel vPro hardware enabled with Active Management Technology (AMT). In DRS, power on, power off, or restart remote vPro systems even when they are powered off. For additional information, see KB400112.
  • Support for Silent Installs:Both DRS and MRC now include command-line arguments to support installing and licensing the products silently. For additional information, see KB400113.
  • Multiple bug fixes:For additional information, see "Resolved Issues" in these release notes.

Notes:

  • If you are upgrading to this version from a version earlier than 8.0, apply your SolarWinds license after you upgrade. For additional information, see "Using the New Licensing System" in these release notes.
  • Starting with version 9.0, you may notice a change in how your license looks in the SolarWinds customer portal. This change is solely to facilitate backend processing, and does not affect your license count or pricing.


Resolved Issues

DameWare Remote Support version 9.0.1 resolves the following issues in earlier versions:

  • NTU v8.x and DRS v9.0 crashes when you use the Move function in the Active Directory node.
  • NTU v8.x crashes when you close the Shutdown window.
  • The Servers node in NTU v8.x enumerates the same server repeatedly when expanded.
  • DameWare Exporter in NTU v8.x crashes when you export to a non-existent folder.
  • The Download SolarWinds License Manager link in the host Start menu does not work on Windows Server 2003 or Windows XP hosts in v8.x.


Known Issues


Remote systems running Windows Vista or later do not show a popup on log off or shutdown.
If you send a log off or shutdown command from DRS to a remote computer running Windows Vista or later, the remote system completes the request but does not display a notification to the remote user. To resolve this issue, enable interactive services on the remote system. For additional information, see Interactive Services on msdn.microsoft.com.


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.


U3 Mode is not a valid licensing option with the new licensing system.
Previously, NTU users were able to license the product in "U3 Mode," which allowed them to run the application from a USB drive. This functionality is not currently compatible with our licensing system, but we are investigating a resolution for a future release.


End of Life Policy

In order to continue to drive innovation and new functionality into our products, SolarWinds must transition customers from legacy versions of software to our current versions. Please review the following support schedule:

  • 9/13/2012: End-of-Life announcement (EoL) – Customers on DameWare v6.9 or older should begin transitioning to DameWare 9.0.
  • 12/12/2012: End-of-Life (EoL) – SolarWinds will no longer provide technical support for SolarWinds DameWare v6.9 or older.


Using the New Licensing System

After installing NTU or DRS version 8.0 or higher, you are prompted to enter the licensing information for your product. If you choose to start with the 14-day evaluation, you can access the Licensing Information options by opening Start > All Programs > SolarWinds > DameWare Mini Remote Control 9.0 > Enter License Information on the computer you want to license.


To evaluate the software without a license,click Continue Evaluation.


To license the software on a computer with Internet access:

1. Click Enter Licensing Information.

2. Select I have internet access and an activation key.

3. Click the http://www.solarwinds.com/customerportal link to access the customer portal on the SolarWinds web site.

4. Log on to the portal using your SolarWinds customer ID and password.

5. Click License Management on the left navigation bar.

6. Navigate to your product, choose an activation key from the Unregistered Licenses section, and then copy the activation key.

7. If you cannot find an activation key in the Unregistered Licenses section,SolarWinds customer support.

8. Return to the Activate MRC window, and then enter the activation key in the Activation Key field.

9. If you access Internet web sites through a proxy server, click I access the internet through a proxy server, and enter its proxy address and port.
Note: If your computer accesses the Internet through an authenticated proxy server, complete the procedure for activating without Internet access instead.

10. Click Next.

11. Enter your email address and other registration information, and then click Next.



To license the software on a computer without Internet access:

1. Click Enter Licensing Information.

2. Select This server does not have internet access, and then click Next.

3. Click Copy Unique Machine ID.

4. Paste the copied data into a text editor document.

5. Transfer the document to a computer with Internet access.

6. On the computer with Internet access, complete the following steps:

a. Browse to http://www.solarwinds.com/customerportal/licensemanagement.aspx, and then log on to the portal with your SolarWinds customer ID and password.

b. Navigate to your product, and then click Manually Register License.

c. If the Manually Register License option is not available for your product,contact SolarWinds customer support.

d. Provide the Machine ID from Step 5, and then download your license key file.

7. Transfer the license key file to the MRC server.

8. Return to the Activate DRS window, browse to the license key file, and then click Next.


 

Managing your Open Issues in Licensing

For information about managing your licenses for SolarWinds products, including how to deactivate or reuse a license, see SolarWinds License Manager


Open Issues in Licensing

  • Applying Federal Information Processing Standards (FIPS) to a licensed NTU server invalidates the existing license. To reactivate your license, contact SolarWinds customer support.
  • If you enter the activation key from another SolarWinds product by mistake, the activation key for the other product is considered registered even though your actual product remains unlicensed. To return the activation key to your pool of unregistered licenses, contact SolarWinds customer support.

Exporting Disabled AD Accounts

$
0
0

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


Original Post

by blackpool6 on Fri Apr 08, 2011 8:36 am

I want to start using NT Utlities and the exporter here at work. I have a need to export the user account information on a quarterly basis. This is for SOX auditing purposes.
Overall I have no problems with the software, except one:

How do you export the
accountsand show which accountsare disabled? I know this is some sort of shared attribute field but I am wondering if the exporter has a way to handle it?

Thank you.

 


Re:
ADDisabledAccounts

by blackpool6 on Thu Apr 14, 2011 2:09 pm

No hints at all? I notice that if I explore the domain that it indicates which users are locked out and which ones are disabled.
Is there a way I can export that view?

 

Re: ADDisabledAccounts

by blackpool6 on Mon Apr 25, 2011 6:52 am

Tap Tap Tap
Is this thing on????

No one else needs or would use this? Is it posted somewhere else? I tried to search but found nothing.

I see Bryan constantly updating posts but nothing here.

 


Re:
ADDisabledAccounts

by DawgBone on Tue Apr 26, 2011 4:22 pm

My experience with Exporter is pretty...well.....non-existent...buuuuutttttt

I just did one on my
AD DC, and I used the standard properties... It tells me some good stuff 

like...


<User>
<UserName>dividingbyzero</UserName>
<FullName>dividingbyzero</FullName>
<Comment/>
<UserComment/>
<HomeDir/>
<HomeDirDrive/>
<ScriptPath/>
<Profile/>
<LogonTo>\\*</LogonTo>
<LastLogon>9/12/2008 3:23:14 PM</LastLogon>
<LastLogoff>-1</LastLogoff>
<BadPwCount>0</BadPwCount>
<NumLogons>434</NumLogons>
<PwExpires>-1</PwExpires>
<PwExpired>No</PwExpired>
<NoExpirePwd>Yes</NoExpirePwd>
<Disabled>Yes</Disabled>
<LockedOut>No</LockedOut>
<NoPwRequired>No</NoPwRequired>
<UserCantChgPw>Yes</UserCantChgPw>
<RAS>No</RAS>
<RASCallback/>
<SetByCaller/>
<CallbackNo/>
<PwAgeInDays>1463</PwAgeInDays>
<PwLastChg>4/24/2007 2:25:34 PM</PwLastChg>
</User>

 

Re: ADDisabledAccounts

by blackpool6 on Tue Apr 26, 2011 8:48 pm

Thank you!!!
I used the standard properties instead of the
AD export and I see all that I will ever need. Last logon, locked out, disabled, etc.

Perfect!!

Thanks Dawg Bone

 

Re: ADDisabledAccounts

by auley on Mon Jan 30, 2012 2:28 am

I haven't seen or noticed such behavior, it might be some scripts set in the background to do this based on the criteria.It can be the behavior of script cell phone spy software to disable and enable the account

 

Re: ADDisabledAccounts

by Lisa098 on Fri Feb 03, 2012 2:02 am

You can use any valid LDAP filter. Other option is to select an unused attribute and stamp them with “DoNotSync” value and exclude them based on this attribute value.

Usually AdminDisplayName and AdminDescription attributes are not in use.

Need info concerning using DameWare over the internet

$
0
0

Note:  This is a topic brought over from the old DameWare Forums which are no longer active.  To continue the discussion, please comment on this document.

 

 

NeedinfoconcerningusingDamewareovertheinternet

by saladdin on Tue Aug 05, 2008 7:19 am

Sorry would like to know if there is a way to use dameware to support multiple offices ( different companies) overtheinternet without the use of VPN? some sort of gateway system maybe were a gateway is setup at the customer office and all i need to do is setup a connection to it.

 

Re: NeedinfoconcerningusingDamewareovertheinternet

by Marty on Tue Aug 05, 2008 11:45 am

Hi,

This topic is actually covered in our online Knowledgebase. I've included a link here for your convenience to detailed documentation that should address this subject:

Establishing a Remote connection
overtheInternet
http://www.dameware.com/support/kb/article.aspx?ID=300093

I hope this helps

 

Marty Bonvillain
Support Staff


Re:
NeedinfoconcerningusingDamewareovertheinternet

by petergriffin on Sat Jan 23, 2010 5:19 am

Thanks for the help Marty.

Harry Head
Naturopathic Healer

 

 

Re: NeedinfoconcerningusingDamewareovertheinternet

by mjarcos on Thu Mar 25, 2010 5:20 am

Hi

I
need to use all DameWare Utilities overinternet, not only Miniremote Control.

Is it possible?

Thanks

 

 

Re: NeedinfoconcerningusingDamewareovertheinternet

by zwilliamson on Thu Mar 25, 2010 7:51 am

Not without major security risks. Most of the other features in DNTU use native Windows APIs, so exposing them to the public internet would cause a huge security issue.

 

 

Re: NeedinfoconcerningusingDamewareovertheinternet

by mjarcos on Thu Mar 25, 2010 11:27 am

thanks for answering so fast.

 

 

Re: NeedinfoconcerningusingDamewareovertheinternet

by deni80 on Sat May 14, 2011 4:28 am

Hi Marty,

I was looking for this
info, thanks for sharing this, mate!


__________________________________________________
Deni B

 

 

 

Re: NeedinfoconcerningusingDamewareovertheinternet

by david49 on Fri Feb 03, 2012 2:47 pm

Hi marty

Thanks for
the link to the detailed documentation, this cleared
a few things up for me.

Kind Regards

Wake-on-LAN Issue

$
0
0

Note:  This topic was brought over from the old DameWare Forums which are no longer active.  To continue this discussion, comment on this document.



WakeOnLanissue

by pvanwelt on Tue Jul 10, 2007 8:51 am

Hi!

i'm using Dameware for some time now and it's a great tool to work with.
But i can't
wake any system with the WOL feature.

When i use a dos tool "mc-wol.exe" (downloaded from the internet)
on the machine it doeswake-up.
Trying again with dameware it doesn't.

Can anybody help me out ?

 

Re: WakeOnLanissue

by bryan on Thu Jul 12, 2007 6:18 pm

Honestly, we use it all the time over here and it works great for us. So it could possibly be the Port that you're using or maybe even the type of Broadcast (i.e. directed vs general). Because according to the MC-WOL documentation they are also sending WOL "Magic Packet" requests, which is exactly what DNTU is using.

Did you select
Wake Single or Wake Batch in DNTU? And what port did you specify?
Also, what is your command line for the MC-WOL utility?

MC-WOLMAC would be a general broadcast equivalent to DNTU's Wake Batch feature, which broadcasts to the entire subnet.

MC-WOLMAC /a Broadcast Address would be a directed broadcast equivalent to DNTU's WakeSingle feature, and would only be sent to the broadcast (multicast) address for that specific LANsegment where the destination computer is located. So withn DNTU you would also specify any IP-Address from the same subnet as this remote machine, and also the subnet mask for that segment, then click on the Check button to calculate the Broadcast Address for that LANsegment.

Additionally, the default port used by DNTU's WOL functionality is
32767, but you can specify any valid port. So you just have to use a port that's not blocked by any of your routers/firewalls. Many products even use port 0 (zero).

I hope this helps
.

Bryan Brinkman
Support Engineer

 

 

Re: WakeOnLanissue

by pvanwelt on Fri Jul 13, 2007 4:28 am

Normally i use : mc-wol [MAC] which works perfect.

I also tried mc-wol MAC /a broadcast which doesn't work.


In dameware i tried WakeSingle (port0) and (port 32767) which both don't work.
Also tried
wake batch which also doesn't work.

So the only thing that works is : mc-wol [MAC]

 


Re:
WakeOnLanissue

by bryan on Fri Jul 13, 2007 8:00 am

Thanks for the additional info.

OK, so you are just basically broadcasting to all machines
on your same subnet, which is equivalent to DNTU's Wake Batch. So I would have to believe this is just a port issue.

Try using port 65535 instead of 32767, which appears to be the default UDP port MC-WOL uses.

But you should also be able to use DNTU's
Wake Single feature as well, unless for some reason your router eats the packet and doesn't forward it back to the machine. Use any IP-Address from this subnet, then 255.255.255.0 (for a full Class C subnet) then click on Check which should calc a Broadcast Address of 192.168.xxx.255 for your current subnet. Then change the port to 65535 and click Wake. If that doesn't work, then also try multiple packets.

This should also be exactly the same as: MC-WOL /a 192.168.xxx.255

Bryan Brinkman
Support Engineer

 

 

Re: WakeOnLanissue

by andrepalma on Sat Jan 10, 2009 12:48 pm

Hi there, i've been start working with DNTU, and it seems to be very powerfull so far.

At the moment and i dont get a way to get the WOL working
on my computers. I have some computer in differents subnets, separated by VPN through them.
For example i have a computer that has the
machine1:
ip 10.15.11.240,
subnet mask 255.255.255.0
gateway 10.15.11.250.

That are linked to the subnet where i am, that is
Machine2:
ip 10.1.10.160
subnet mas 255.255.255.0
gateway 10.1.10.250

This subnets are fisically separated and linked throw VPNs

So from the machine2 i cant send the wol magic packet to machine1.

Even in the same subnet, the one in the machine2, the wol doesnt work like it should.. sometimes it works, sometimes it not...

Another thing, do you know why the
wakeonlan feature of each favorite machine that we add doesnt save the mac address.
For example, i add a favorite machine by ip, and the list, if open in the + it brings me the whole features available for that machine, the last one is
wakeonlan, but if i open that it dont have the information for that computer, it just has the information from the last computer or computers that i was to wake up... so i think that it could be a thing to get better or is anything that i was doing wrong.

I would appreciate help from you that you have much more experience from me.

Thank you very much,
Best regards,

André Palma

 

 

Re: WakeOnLanissue

by misga on Wed Jul 21, 2010 2:16 pm

Make sure to use your correct subnet mask, for me it was generating 255.255.255.0 but we areon a /16 so i had to manually change it to 255.255.0.0 and then click "Check" again. Also it generates the mac address in the incorect forma, example; 00 00 00 00 00 00 It has to be 00-00-00-00-00-00(use dashes instead of spaces). For us the port didnt seem to matter 0 worked just fine.

Observe users desktop with their knowledge

$
0
0

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


Observe
user'sdesktopwiththeirknowledge?

by lizard90048 on Wed Aug 08, 2007 2:28 pm

Hello,

I'm an administrator in a environment
with both Macs and PCs.

On the Mac side, we use a great program called Apple Remote
Desktop which allows us toobserve a user's screen without them knowing - Nothing pops up on their screen telling them they're being watched.
This comes in handy when we're doing HR and network abuse investigations.

Is there any way to accomplish the same thing
with Dameware for the PCs (running XP)?
For reference, I'm running Mini Remote 6.4.0.1.

Thanks!

-Ian, Los Angeles


Re:
Observeuser'sdesktopwith thier knowledge?

by bryan on Wed Aug 08, 2007 2:39 pm

Hi IAN,

I guess you meant to say "without"
their knowledge, right ? 

Yes, our software can be configured to not show the SysTray icon and not notify the user upon connection, provided you have already registered your installation of the Mini Remote Control software on your local machine. Because disabling those notification features is the only limitation while the software is still running in Evaluation Mode. So you can disable these notifications, but only after your local copy of the MRC software has been registered properly.

Therefore, even if you disable these settings when you deploy the Client Agent Service to your remote machines, these Notification settings will be ignored when you connect until your local copy of the Mini Remote Control software is properly registered. Once your local copy of the software has been properly registered (i.e. you purchase a license and enter that information into the MRC software) you will be able to suppress these notification features.

Basically, the only limitations in Eval Mode are:

1. Notify Dialog displays the text "Evaluation" when you connect, and cannot be closed.
2. SysTray icon cannot be hidden.
3. All options are made available on the SysTray icon's right-click context menu.

===========================

Outside of the software not being registered locally, you just have to configure the MRC Client Agent Service properly to not show these Notification features during the install the Service on the remote machine, because the default settings are to notify the user when someone connects. So I suggest you try this out on a test machine so you can become familiar
with how these features operates, before you use it in a production environment.

Settings within the MRC Client Agent on the Remote Machine:

These settings are stored in the DWRCS.INI configuration file by default, but there is also an option to store these settings in the Registry instead.

1. To not show the SysTray icon, disable the "Enable SysTray icon" setting on the Additional Options Tab.
2. To not show the Notify dialog during a connection, disable the "Notify on Connection" setting on the Notify Dialog Tab.
3. To not show the File Transfer Menu when someone right-clicks on a file or folder, disable the "Enable Simple File Transfer (SFT)" setting on the Simple File Transfer Tab.

Also, just FYI, the DWRCS.INI file is not copied to the remote machine each time you make a connection to that remote machine, only during service installation, and then only if you enabled the "Copy configuration file DWRCS.INI" setting during the install process. Whenever you are prompted to install the Client Agent on a remote machine, you will always have either a "Settings" or "Install Options" button on the dialog. Clicking this button will allow you to configure the Settings that will be sent within the DWRCS.INI file to the remote machine. However, also make sure you enable the "Copy configuration file DWRCS.INI" setting as well. Otherwise the DWRCS.INI file will not be sent to the remote machine and the Service will start
with a set of default settings (or possibly a previous DWRCS.INI file from a previous connection), not with your custom settings that you just defined.

Please also keep in mind that the DWRCS.INI configuration file is never copied to the remote machine during an upgrade or downgrade of the Client Agent. Once again, the DWRCS.INI file is only copied to the remote machine during Service installation, and then only if you have the "Copy configuration file DWRCS.INI" setting enabled. This functionality also requires full Administrator rights on the remote machine, because full Administrator rights are required to install, start, stop, remove, or even upgrade/downgrade the Mini Remote Client Agent Service.

Therefore, once the Client Agent is already installed & running on the remote machine, in order to change the settings you will either have to:

1. Remove & Reinstall the Client Agent
with the correct settings, and also enable the "Copy configuration file DWRCS.INI" setting during the reinstall.
-OR-
2. Manually copy over a new DWRCS.INI file to the remote machine, then stop & restart the Service for the new settings to take effect.
-OR-
3. Connect to the remote machine, then select View / Remote Server Settings and make any necessary changes.
-OR-
4. Use the NT utilities software's Services View to batch remove & reinstall the Client Agent on your remote machines.

How to Install the Mini Remote Client Agent Service on Several Machines at the Same Time
http://www.dameware.com/support/kb/article.aspx?ID=100002

If the Client Agent Service is not installed on the remote machine, then when you connect you should be prompted
with a dialog stating "The Mini Remote Client Agent is not installed on the remote machine. Would you like to install it?". At this point you can select the Install Options button and make sure the "Copy configuration file DWRCS.INI" setting is enabled". Otherwise the DWRCS.INI file will not be copied to the remote machine and the Service could startup using old settings from a left-over DWRCS.INI file. The "Permission Required" setting is located on the Additional Options Tab.

Settings within the MRC Application on your local machine:

1. You can enable the View Only feature so no cursor or mouse movements are sent to the remote machine accidentally.
2. By default, for performance reasons, all
desktop effects (i.e. Wallpaper, Font Smoothing, etc...) will be turned off when you connect. So you probably want to turn off these features as well.

Both of these settings are unique to each individual Saved Host Entry (select a Host Entry and click the Settings button), so they can be different for every machine in your host list. But I suggest you also modify these same settings on the Default Host Properties dialog (View / Default Host Properties). This way when you create a new Saved Host Entry, all these settings will be inherited automatically by default.

However, one other thing to note is when the remote machine is running multiple monitors. Because Microsoft actually has some issues
with multi-monitors, mirror drivers, & bitmaps (wallpaper) in Operating Systems prior to Vista. So the wallpaper will always be disabled when connecting to a remote machine with multiple monitors using the Mirror Driver. Microsoft has corrected these issues in the Vista O/S, but more than likely will never be fixed in XP and prior. However, if this is the case, then simply disable the “Use MRC Mirror Driver” checkbox on this Saved Host Entry before you click on Connect.

So again I suggest you try this out on a test machine so you can become familiar
with how the software operates, before you use it in a production environment.

I hope this information helps.

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


Re:
Observeuser'sdesktopwiththeirknowledge?

by YNHH on Fri Aug 24, 2007 10:30 am

I'd like to turn this around and ask for just the opposite.

I need to make sure that if a remote user connects, then they cannot do a stealth connection. That is, there is no real way that a remote support person can make a connection without the MRC notification. This is a privacy policy driven need.

Ideally there would be the capability to do a challenge/response. That is, the remote user attempts to make a connection and the remote PC user has to approve it.

Then in the case where a machine does not have the agent deployed, can I set it up and then lock down the feature set so the technician cannot set the deployed ini file

Also, as to licensing cost, do we pay for the user tool, or for the agent. That is, if I pre deploy the agent to all 4,000 PCs do I need to pay separately for those agents or I just pay for the MRC licenses?

Please feel free to have one of your licensing specialists contact me via e-mail.

Thanks

Al


Re:
Observeuser'sdesktopwiththeirknowledge?

by bryan on Tue Sep 11, 2007 3:05 pm

Hi YNHH,

The only way to truly lock this down is to not grant these users Administrator rights within the O/S security on that remote machine.

Just FYI, we are also investigating what it will take to add "Server Side configuration" functionality within a future version the software. What I mean is that you would have the ability to store the settings for your Client Agents on a completely separate machine, a sort of "configuration server". That way, you would have greater flexibility to lock down the settings, because even though someone may have local Admin rights on this specific machine, they may not have Admin rights on the configuration server, hence they could not make changes to the config. Unfortunately, I just cannot make you any promises when this functionality may be available.

But in the meantime, as a possible work-around the MRC Client Agent Service also has the ability to store it's settings in the Registry on the remote machine instead of the DWRCS.INI file. Therefore, once any settings have been enabled on the remote machine, removing & reinstalling the Service or copying a new version of the DWRCS.INI file will have no affect on the settings.
[HKEY_LOCAL_MACHINE\Software\DameWare Development]

The easiest way I can think of to easily implement the "Use Registry for all Settings" key across several machines is to use the new MRC Client Agent Service MSI Builder to build you a Microsoft Installer Package (MSI). The DameWare MRC Client Agent MSI builder allows you to build custom MSI packages (including all settings, INI or Registry) to deploy the MRC Client Agent in your environment. These MSI packages can then be sent to your clients (or even distributed via Group Policies within Corporate Environments, etc...) via any of your existing distribution methods.

I hope this helps.

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


Re:
Observeuser'sdesktopwiththeirknowledge?

by pverdieu007 on Fri Jan 16, 2009 6:28 pm

Hello Brian

Any update on that "Server side config" ? Can it work
with several versions of dameware? Any idea of an ETA?

Tkx & Regards,

Pascal


Re:
Observeuser'sdesktopwiththeirknowledge?

by Marty on Tue Jan 20, 2009 11:07 am

Hi Pascal,

Thanks for the post.

Unfortunately we can't provide any type of ETA for the many new features we are currently working on for future releases. We apologize for any inconvenience.

Marty Bonvillain
Support Staff
DameWare Development, LLC.
http://www.dameware.com


Re:
Observeuser'sdesktopwiththeirknowledge?

by Ghostantin on Mon Jun 22, 2009 4:45 am

I had made all the setings explained in this topic about "invisible" connection to users , but everytime i connect the screen blinks once ( and when i disconnect it also blinks ). Is it any posibility to remove that blink so it can be 100% invisible connection ?

Thanks.

PS We are not trying to spy on users but it is handy for network abuse investigations. I am currently the sys admin of a company
with ~200 domain users.



Later Edit : If i deselect the "Use MRC`s Mirror Driver if avaible" in the remote connect menu when i connect to the client the screen doesn't blink but the mouse cursor is continuously blinking. Any solutions ? Thanks in advance.


Re:
Observeuser'sdesktopwiththeirknowledge?

by bryan on Mon Jun 22, 2009 9:44 am

Sounds like the O/S is doing this when the Mirror Driver is enabled/disabled.

Try turning off Mirror Driver (uncheck use MRC Mirror Driver checkbox, before clicking on Connect).

Also toggle "Disable Show Transparent Windows" toobar button (4th from the end), which is only available when not using the Mirror Driver.

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



Re:Observeuser'sdesktopwiththeirknowledge?

by Ghostantin on Wed Jun 24, 2009 6:08 am

Yes . when i turn off the MRC Mirror Driver and i toggle Disable Show Transparent Windows it makes no blinks , and it is 100% invisible.

Thanks for help. 

P.S. If you ever come in Romania you have a beer from me 


Re:
Observeuser'sdesktopwiththeirknowledge?

by ironmountain on Fri May 07, 2010 1:59 pm

This a very nice write up! Just have one question though, is there a way to rename the process and/or service that shows up in the Remote User's Task Manager? I would like it to be hidden or renamed. The user would still have the ability to Stop the Process and thus break the connection.

We have some users that are "Mal-ware Paranoid" and stop processes that they don't recognize. So if it does not show, or if it can be renamed to something else, that would be wonderful.

I went under program files where the Dameware Application lives, and tried renaming the dwrcc.exe to something else in hopes that when it was copied over the file(s) would use the "new" name. I was thinking it would still pick up that file regardless of the file name, it did not work. I was thinking it was looking at the file contents itself, but in actuality it was referencing the file name and when it was not found it aborted the process during mini remote installation.

Lance


Re:
Observeuser'sdesktopwiththeirknowledge?

by flowlineadmin on Tue Oct 04, 2011 8:39 am

I followed the instructions but I seem to have one issue. When I connect to a Windows 7 computer, the client's desktop turns black. Is there a way I can connect without affecting theirdesktop?

Also, is there a way for me to move a mouse pointer on
theirdesktop without them seeing theirpointer move?


Thank you!


Icon will not show

$
0
0

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

 

 

 



Icon
willnotshow

 

by ti0101 on
Wed May 21, 2008 3:56 am

 

hi ya
i am having these issues:
Icon does not show.jpg
on a client that i am trialing the software with

any ideas what is causing it, and how to resolve it?

 

Re: Iconwillnotshow

by ti0101 on
Wed May 21, 2008 3:57 am

 

edit -
says
"The MRC Tray
Icon was unable to
communicate with the MRC Client Agent. The Client Agent Service may
not be running?
MRC tray
icon process will now exit.

  

Re: Iconwillnotshow

by Marty on
Thu May 22, 2008 10:46 am

 

Hi ti0101,
This is a normal error if the MRC SysTray
icon (DWRCST.EXE) process is unable to communicate with the MRC Client Agent Service (DWRCS.EXE)for any reason. What version of the software application are you using and what version of the client agent service is installed and running on the remote machine?

What Operating System and Service pack level is each machine (local and remote) running, and how did you install the client agent service, with an MSI package or "on the fly" when you first attempted to connect?

Thanks for your feedback, it is appreciated.

Marty Bonvillain
Support Staff
DameWare Development, LLC.
http://www.dameware.com

Re: Iconwillnotshow

by stefstew on
Fri Oct 17, 2008 9:59 am

 

I am getting the exact same error on several of our machines. Our users are great at sending emails when they get errors and this one is very annoying. Operating system WIN XP, Service Pack 2, agent service created "on the fly"....

 

Re: Iconwillnotshow

by astr0wiz on
Wed Oct 29, 2008 9:36 am

 

  1. Hello. I have been using the Mini Remote Control app for several years and I just updated to version 6.8.0.1. During a test, I encountered this same problem.

    Now, for my company, this is a HUGE issue. I rely solely on the Mini Remote Control to test and fix remote kiosks (small PCs that run Windows and Java apps). With this problem, I now cannot use the Dameware product, because these kiosks are visible to our customers and a warning popup window at every kiosk would certainly end my tenure at this company. I'd like to stay.

    So here is the vital information:

    1) All the remote machines have an earlier version of the Mini Control Client.

    2) All the remote machines are running Windows XP SP2.

    3) All the remote machines were given the client "on the fly".

    4) The test machine was upgraded to 6.8.0.1 "on the fly" and it shows this problem.I have
    not tested this on a client after using the MSI. I wasn't sure if the MSI would properly upgrade the
    client app.

    My company is very large and I cannot afford to use the upgrade to connect to a remote kiosk that
    will be seen by a customer. For this reason, I am going to send an email directly to Dameware support in the hopes that an answer can be provided as quickly as possible.

 

Re: Iconwillnotshow

by bryan on
Mon Dec 01, 2008 12:36 pm

 

Update:
This customer had written directly to our Support staff as well, and as it turns out these were Kiosk machines and there were running a Shell Replacement call EZSHELL, which most likely did
not have a "System Tray" like Windows Explorer does.

They had also upgraded from an older 5.x version of the software, which means they also needed to obtain new licenses that were compatible with version 6.x of the software, and then register their local copy of the software using their new v6.x licenses.

This is significant because they were currently running in Evaluation Mode which means that all the notification features within the MRC Client Agent Service on the remote machine
will be turned on (i.e Notify on Connection dialog, MRC SysTray icon, & MRC SysTray Icon's right-click menu) when they connect, regardless of the Settings within the MRC Client Agent Service on this remote machine. Disabling those notification features is a limitation while the software is running in Evaluation Mode.
Therefore, since this replacement SHELL did
not have a SysTray, but our SysTray icon was trying to be displayed, this caused the error dialog to be displayed.

The resolution in this case was to register their local copy of the software,then make sure they disabled the MRC SysTray
icon within the Client Agent on the remote machine, since there
was no System Tray in this replacement shell.

I hope this helps.

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

Re: Iconwillnotshow

by bryan on
Tue Dec 02, 2008 10:53 am

Another Update:
Another user wrote to support with the same exact error, and they were also running a Shell replacement product. Their product was called PowerFuse, which also does
not have a System Tray.
Once they hid the MRC System Tray
icon by disabling the "Enable SysTray Icon" setting within the Client Agent Service they no longer received this error message.

Best Regards,

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


Re: Iconwillnotshow
by chicken5948 on
Thu Dec 04, 2008 11:41 am

 

I am getting this same message on a client PC. They are running Windows XP SP3, we are using DW version 6.8.0.1.

I have removed the service from this PC, but the error continues. Any thoughts?

 

Re: Iconwillnotshow

by bryan on
Thu Dec 04, 2008 2:49 pm

 

How did you remove the Service? Manually via the instructions on our website? Via the Mini Remote Control program's interface? Or possibly by some other means outside of our software?

If the "DameWare Mini Remote Control" Service is truly no longer listed as an installed Service, then see if the following key still exists in the Registry. If this key still exists after the Service has been properly removed, then you can just delete it:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
"DameWare MRC Agent"="C:\\Windows\\system32\\DWRCST.exe"

 

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

Re: Iconwillnotshow

by IMMTHelpdesk on
Thu May 07, 2009 8:48 pm

 

Hi,
We are using DameWare 6.8.1.4 having since upgraded from a previous version and are getting complaints from clients saying that they too are getting the same error message:

The MRC Tray
Icon was unable to communicate with the MRC Client Agent. The Client Agent Service may not be running?

MRC Tray
Icon process will now exit.
[Initialize Desktop]


We have 5 registered copies of this software for each of administrators (of which I am one) and have been installing / upgrading the client service as we have needed to remote to their machines. It appears to only be a problem on machines that are running the new verison of the client serivce.
I have noticed the following:
- I have logged onto the services MMC and the MRC service is running correctly.

- The error message only appears when the users first log onto their machines.

- The error does
not affect any type of usability of Dameware when we are trying to log onto affected machines.

- We are
not using any kind of shell replacement software.

- Our users are running Mixed XP SP2 & SP3 and Windows Vista 32Bit Business.

This isnt a large issue for us at the moment as the software still works fine, it is mainly an annoyance for the users, that we need to get resolved.


Re:
Iconwillnotshow

by TerraMedics on
Sat Aug 15, 2009 2:44 am

 

Did this issue get resolved. It's happening with with 6.8.1.4 on Vista SP2 when logged in as a regular user with admin privileges. The MRC tray icon disapears and transferring files to remote clients does not work unless logged in as the main administrator. This defies the purpose of Vista security. changing the MRC service log in credetnials did not help. Although the icon issue may not be critical, the file transfer issue is definitely a trunoff since the user must log in as administrator to be able to send files to remote clients.

Thanks,
Denise

Re: Iconwillnotshow

by theviper21 on
Wed Oct 28, 2009 7:41 am

 

I am curious if this has been resolved as well. I have a lot of users that are running XP SP2/SP3 and get the error on startup. We have around 100 licenses for DW MRC and I am running the latest version of the client, 6.8.1.4.
The only way I have gotten the error to stop on a user's PC is to remove the remote control utility from startup. However, every time I reconnect it gets added back to startup.
Any further follow up on this from support would be appreciated. Thanks!

connecting to a vista pc it always requires users permission

$
0
0

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

 

connectingtoavistapcitalwaysrequiresuserspermission

by mmenzie on Sat Sep 15, 2007 9:29 am

Hello,

I have
a couple of vista test machines on our network. they are not joined to our domain and are in there own local workgroup. by default vista diables the administrator acct. and i have leftit disabled. i created two users on the machines, one regular and one with admin privledges. when i try to use the MRC to connect to these machines italways asks the user if they are going to allow the connection even when i try to connect using the acct i created with admin rights. this cause me a lot of headaches cause since these are test machines there is usually no user sitting at them, so i have to go to the machine so i can allow the connection. i don't have tis issue connectingto any of my xp/2000/2003 pc's and servers. so what am i doing wrong????

 

Re:connectingtoavistapcitalwaysrequiresuserspermission

by bryan on Mon Sep 17, 2007 11:00 am

Hi mmenzie,

Please provide us with some additional information so we can more intelligently assit you.

- Is this
a Microsoft UAC (User Account Control) permission dialog? Or is this a Mini Remote Control "Waiting for Client to Accept Connection" permission dialog? Perhaps even send us ascreen shot of this dialog.
- Which version of the MRC software are you currently running?
- Which version of the MRC Client Agent Service is installed on the remote machine?
- Is the remote machine running
a 64-bit version of Vista, or 32-bit?
- Also, which flavor of
Vista are they running (Ultimate, Business, etc...)?
- Exactly how was the MRC Client Agent Service installed on this remote machine? Via
a MSI package? Manually? etc..
- Have you also checked on the remote machine
to make sure the "Permission Required" setting is not enabled within the MRC Client Agent Service (on the Additional Settings Tab)?

Please send us all this information for review.

However, you might also want
to try removing the MRC Client Agent Service from the remote machine. Then build a new Vista 32-bit MSI package via the DameWare Installer Tool (DWRCSMSI.EXE), included in your DameWare installation folder. Also make sure toto reset all the Authentication Types options to Default on the General Tab, and make sure the "PermissionRequired" setting is not enabled on the Additional Settings tab, when building your MSI package.

Your feedback is appreciated.

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

Re:connectingtoavistapcitalwaysrequiresuserspermission

by mmenzie on Mon Sep 17, 2007 12:09 pm

Bryan wrote:Is this a Microsoft UAC (User Account Control) permission dialog? Or is this a Mini Remote Control "Waiting for Client to Accept Connection" permission dialog? Perhaps even send us ascreen shot of this dialog.


It is the MRC "waiting for client to accept"
Bryan wrote:- Which version of the MRC software are you currently running?

I am running MRC 6.6.1.1
Bryan wrote:- Which version of the MRC Client Agent Service is installed on the remote machine?
The version is 6.6.1.1
Bryan wrote:- Is the remote machine running a 64-bit version of Vista, or 32-bit?
it is a 32bit version of windows vista

Bryan wrote:- Also, which flavor of Vista are they running (Ultimate, Business, etc...)?


Vista Ultimate
Bryan wrote:- Exactly how was the MRC Client Agent Service installed on this remote machine? Via a MSI package? Manually? etc..
IT was done via .msi package

Bryan wrote:- Have you also checked on the remote machine to make sure the "Permission Required" setting is not enabled within the MRC Client Agent Service (on the Additional Settings Tab)?
Yes i did check that as well

Last edited by mmenzie on Sun Oct 28, 2007 11:00 am,
edited 2 times in total.

Re:connectingtoavistapcitalwaysrequiresuserspermission

by mmenzie on Sun Oct 28, 2007 10:57 am

no help for my issues??

 

Re:connectingtoavistapcitalwaysrequiresuserspermission

by bryan on Mon Oct 29, 2007 11:30 am

Hello mmenzie,
Honestly,
it sounds like you haven't configured the MRC Client Agent Service properly. However, you might also want to do some additional reading on Vista and the new UAC security model, because Microsoft has made extensive changes in Vista.
Also, just FYI, even though you think you're created an account with Admin rights, under Microsoft's UAC (User Account Control) security in
Vista this account is treated like any other regular user
account when you login. UAC splits the user's access token into two pieces (user portion, full admin portion), and you only receive your full Admin token when you request something that
requires elevated rights, and even then it's only elevated within that specific window. Then you're back to being a regular user again. The only account that isn't UAC enabled is the true
"Administrator" account.
Vista also disables this account by default, but you can re-enable it again.

However, I would suggest you remove & reinstall the MRC Client Agent on the remote machine, but do
it via our MSI builder instead. This will guarantee the Service is installed correctly:

First download & install the current version of our software from the website (v6.6.2.0). Next, build
a new MSI package to install the MRC Client Agent Service on this Vista machine using the DameWare MSI builder. After you configure and build the new MSI package, run the MSI pacakge on the Vista machine to install the Service. Now try your connection again. This should take care of this behavior.

I hope this helps.

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


Re:connectingtoavistapcitalwaysrequiresuserspermission

by slburke on Tue Dec 04, 2007 11:05 am

It doesn't appear that this was resolved either way (yes it can be done/no it can't).....I have had to disable UAC (wich we don't want) in order to get this functionality that exists in all other versions of Windows that I support.
So for the moment have removed
Vista from my environment.

It surprises me that the developers are telling us "I don't think you have MRC agent configured correctly". The same configuration that works under XP SHOULD work
under
Vista. I mean it's only a checkbox to say "don't ask for permission". Have the developers tried on Vista machines and KNOW that it works with UAC enabled?

Can anyone with
Vista based machines verify if the following from Microsoft would correct the issue?
http://support.microsoft.com/kb/937624

 

Re:connectingtoavistapcitalwaysrequiresuserspermission

by bryan on Tue Dec 04, 2007 12:45 pm

It doesn't appear that this was resolved either way (yes it can be done/no it can't)

 

There are no known issues connectingtoVista machines, and it's definitely possible to connecttoVista without requiring permission. However, Administrator vs non-Administrator credentials, as well as the "Permission Required" setting within the MRC Client Agent Service on the remote machine will determine if you require permissionto connect to this machine using our software.

Also, have you checked for DWMRCS entries in Application Event log on the remote machine
tosee exactly how you're authenticating to this remote machine (Administrator vs. Regular User)? Because non-Admins cannot connect toa remote machine without requiring explicit permissionfrom the Desktop User. Please send the entire text from these entries to our support team for review.

I have had to disable UAC (wich we don't want) in order to get this functionality that exists in all other versions of Windows that I support.

 

What exactly are you trying to do? Because provided the MRC Client Agent Service is already installed & running on your remote Vista machines, then you shouldn't have any problems simply making a connection, provided you're connecting via Administrator credentials. However, youwill not be able to remotely install, remove, start, or stop the MRC Client Agent Service toaremote machine running Vista with UAC enabled. These requests will be blocked by the O/S itself and it's beyond our control. Therefore, simply pre-install the MRC Client Agent Service on these remote Vista machines and you shouldn't have any issues.
However, that's also why we created the DameWare MSI Builder in version 6.x of the software, because the easiest and most efficient way
to install the MRC Client Agent Service on all your remote
machines is by building
a MSI package via the new DameWare MRC Client Agent MSI Builder (DWRCSMSI.EXE), which allows you to build custom MSI packages (including all settings, INI or Registry) to deploy the MRC Client Agent in your environment. These MSI packages can then be sent to your clients (or even distributed via Group Policies within Corporate Environments,
etc...) via any of your existing distribution methods. Using the MSI Builder
toinstall the Client Agent Servcie also ensures that the MRC Client Agent Service is installed & configured properly for the designated O/S.

The same configuration that works under XP SHOULD work under Vista. I mean it's only acheckbox to say "don't ask for permission".

 

This is a fundamentally flawed statement for many different reasons.

    • First,
           the ability
      to connect without requiring permission is determined by more that just the "Permission Required" checkbox, and it's the same for all Operating  Systems, not justVista. Regardless of the "Permission Required" checkbox, non-Admins will always requirepermissionto connect. So you have to make sure you're authenticating to this remote machine as an
           Administrator not
      a non-Admin, or you will always require permission.

 

    • Second,
           this is exactly the functionality of
      Vista's UAC security model, which means even though you thinking you're logging in as an Administrator, you're really not any longer. UAC splits your Access Token into two separate parts, an Administrator portion and a non-Admin portion. When you login, you always receive  the non-Admin portion of your token. Only when you request something that requires Admin rights will UAC prompt you for elevation, and only then will you receive your full Administrator portion of your token (and only within that
           specific window/process). Once that window is closed you're right back
      tobeing a non-Admin again.

      Have the developers tried on Vista machines and KNOW that it works with UAC enabled?

      YES. We have done extensive testing on Vista, and our entire support staff are all running Vistaon their machines as well, and we don't have any issues connectingto remote machines runningVista with UAC enabled without requiring permission.

      However, if you're still having issues
      connectingto remote machines running Vista, then send as much information as possible to our support staff, and they will be happy to assist you in resolving this behavior.

      Also keep in mind that only version 6.x of the software & Client Agent is supported on
      Vista.

      I hope this helps.


      Bryan BrinkmanSupport Engineer

      DameWare Development, LLC.http://www.dameware.com



      Re:connectingtoavistapcitalwaysrequiresuserspermission

      by slburke on Tue Dec 04, 2007 1:41 pm

      First, I hope I didn't sound like I was trying to beat up on anyone...grin

      Now I will answer your responses as best I can however I have no output
      to show or event logs as like I said I removed the offending machines from our environment.

      Bryan wrote:However, Administrator vs non-Administrator credentials, as well as the "Permission Required" setting within the MRC Client Agent Service on the remote machine will determine if you
      require
      permissionto connect to this machine using our software.


      Exactly, all users that use MRC here are either LOCAL administrators (on all workstations) or DOMAIN administrators.

      Bryan wrote:

      I have had to disable UAC (wich we don't want) in order to get this functionality that exists in all other versions of Windows that I support.

      What exactly are you trying to do?
      Remote control aVista machine.

      Bryan wrote:Because provided the MRC Client Agent Service is already installed & running on your remoteVista machines, then you shouldn't have any problems simply making a connection,
      provided you're
      connecting via Administrator credentials. However, you will not be able to remotely install, remove, start, or stop the MRC Client Agent Service toa remote machine running Vistawith UAC enabled. These requests will be blocked by the O/S itself and it's beyond our control. Therefore, simply pre-install the MRC Client Agent Service on these remote Vista machines and you shouldn't have any issues.


      Exactly, I agree, your statement SHOULD be true. But it is not. I tried installing remotely (which was blocked, matches your statement). However I also transferred the files locally to the
      machine and did
      a manual install as well with same result of user at remote machine being asked for permission (read UAC prompt).

      Bryan wrote:However, that's also why we created the DameWare MSI Builder in version 6.x of the software, because the easiest and most efficient way to install the MRC Client Agent Service on all your remote machines is by building a MSI package via the new DameWare MRC Client Agent MSI Builder (DWRCSMSI.EXE), which allows you to build custom MSI packages (including all settings, INI or Registry) to deploy the MRC Client Agent in your environment. These MSI packages can then be sent to your clients (or even distributed via Group Policies within Corporate Environments,
      etc...) via any of your existing distribution methods. Using the MSI Builder
      toinstall the Client Agent Servcie also ensures that the MRC Client Agent Service is installed & configured properly for the designated O/S.


      This did not work either.

      Bryan wrote: The same configuration that works under XP SHOULD work under Vista. I mean it's only acheckbox to say "don't ask for permission".
      This is a fundamentally flawed statement for many different reasons.

    • First,
           the ability
      to connect without requiring permission is  determined by more that just the "Permission Required" checkbox, and it's the same for all Operating  Systems, not just Vista. Regardless of
           the "
      Permission Required"  checkbox, non-Admins willalways require permissionto connect. So you have to make sure you're  authenticatingto this remote machine as an  Administrator not a non-Admin, or you will always requirepermission.
    • Second,
           this is exactly the functionality of
      Vista's UAC security model, which means even though you thinking you're logging in as an Administrator, you're  really not any longer. UAC splits your Access Token into two separate  parts, an Administrator portion and anon-Admin  portion. When you login, you always receive  the non-Admin portion of your token. Only when you request something
           that
      requires Admin rights will UAC prompt you for elevation, and only then will you receive  your full Administrator portion of your token (and only within that  specific window/process). Once that window is closed you're right  back to being a non-Admin again.

 

How can this be a flawed statement?

      • First,
             all that's being done is transferring the same exact dwrcs.ini file
        to the Vistamachines that are on the  2000/XP/2003 machines.

 

      • Second,
             You originally stated that this behavior with the UAC does not happen. Now you say
        it does. I'm talking about UAC prompting. The desired result is that if I connect as an Admin, UAC should not prompt the user on the "remote" machine.

Bryan wrote:

 

Have the developers tried on Vista machines and KNOW that it works with UAC enabled?

YES. We have done extensive testing on Vista, and our entire support staff are all running Vistaon their machines as well, and we don't have any issues connectingto remote machines running Vista with UAC enabled without requiring permission.

 

So you are saying that if no one is sitting at the remote machine,you can remote control theVista machine,no problem? Well, I cannot because UAC is waiting for someone at the remote
computer
to click "OK". On my end I see "Waiting for client to accept connection" dialog from MRC. After a while the connection times out with a "remote control was denied", as if someone at
the remote computer clicked "Deny".

Bryan wrote:Also keep in mind that only version 6.x of the software & Client Agent is supported on Vista.

 

Using version 6.6.2.1

Bryan wrote:I hope this helps.

not yet (grin)

 

Re:connectingtoavistapcitalwaysrequiresuserspermission
by Roger on
Tue Dec 04, 2007 2:11 pm

 

Could have been a mistype,but in your last comment you say "Well, I cannot because UAC is waiting for someone at the remote computer to click "OK". On my end I see "Waiting for clientto accept connection" dialog from MRC." But, before you said it was MRC's prompt on the remote end waiting for OK. If it is UAC, then there is nothing MRC can do about it. One quick test would be checking to prompt in MRC and see if you get two prompts.

One thing
to try is to see if in fact the ini setting/file you deploy actually got there. Maybe itwas unable to copy or at the time the option may have been unchecked, etc...although you deployed by msi, so hopefully that shouldn't be an issue. I'd still connect toit and say ok to the prompt, then go to view menu and look at the settings on the remote machine/server and be sure they match what you expect. Specifically, on mine I have- General Tab= Allow Encrypted Windows logon and Must have logon local rights...although you could try without just in case that account can't logon locally, etc. Then on Access tab I have Only Admin to connect and the bottom 3 checks. You can try turning off only admin to connect or Permission required check at the bottom and see if that makes a difference.
I haven't used
it, but it sounds like from the description you can take off the bottom 3 checks and gain access at the logon/locked prompt since no one is logged on (which sounds like what you describe) it would then let you in. Non-Admin with a user logged in remote sounds like italwaysrequirespermission, and admin can be required if you have it checked in the Additional Settings Tab...so lots of layers of security there.

 

Last edited by Roger on
Tue Dec 04, 2007 2:17 pm, edited 1 time in total.

 

Re:connectingtoavistapcitalwaysrequiresuserspermission
by Roger on
Tue Dec 04, 2007 2:16 pm

 

While we are on the options for the Non-Admin users...that had me confused initially at first too since that bottom section doesn't have a header saying these setting apply toNon-Admin, itjust gives a description and assumes you read the whole paragraph and realize the bottom 3 checks are for Other/Non-Admin accounts not specified above. The paragraph would also look
better if left aligned and indented in
a little. I didn't get that creative in my photo though.

Re:
connectingtoavistapcitalwaysrequiresuserspermission

by mmenzie on
Tue Dec 04, 2007 2:18 pm

well i have to agree with slburke on this one. i used the MSI builder to build the client and ran iton my vista machine and i double checked, even triple checked all the settings before i built itand when i try and connect to my vista machine i see "waiting for permission" and sure enough if i walk over to my vista box it is still sitting there waiting for someone to accept or deny. i have done all the things in this post that was suggested.

 

Re: connectingtoavistapcitalwaysrequiresuserspermission
by Roger on Tue Dec 04, 2007 2:55 pm

If you did what I just posted too, only other suggestion would be maybe post the ini that is on the actual Vista Box. That is, if it isn't selected to store settings in the registry, then you would need to export those.

 

Re: connectingtoavistapcitalwaysrequiresuserspermission
by slburke on
Tue Dec 04, 2007 4:53 pm

 

Roger wrote:Could have been a mistype, but in your last comment you say "Well, I cannot because UAC is waiting for someone at the remote computer to click "OK". On my end I see "Waiting for clientto accept connection" dialog from MRC." But, before you said it was MRC's prompt on the remote end waiting for OK. If it is UAC, then there is nothing MRC can do about it. One quick test would be checking to prompt in MRC and see if you get two prompts.

 

What I was saying that on my end I see response from MRC "waiting for client to accept connection" (whatever the actual MRC message is). On the remote machine, the UAC prompt is waiting. All this meaning that I shouldn't see a prompt from MRC and the remote user shouldn't see a prompt from UAC.

Roger wrote:One thing to try is to see if in fact the ini setting/file you deploy actually got there.

 

I am manually placing the files on the remote computer since I can't do a "push" install because of UAC. So yes the ini setting/file is there.

 

Re: connectingtoavistapcitalwaysrequiresuserspermission

by slburke on
Tue Dec 04, 2007 4:57 pm

Roger wrote:If you did what I just posted too, only other suggestion would be maybe post the ini that is on the actual Vista Box. That is, if it isn't selected to store settings in the registry, then you would need to export those.

Settings aren't stored in the registry in version 5 or 6 of Dameware anymore (right?)

 

Re: connectingtoavistapcitalwaysrequiresuserspermission
by slburke on
Tue Dec 04, 2007 5:01 pm

 

Roger wrote:Then on Access tab I have Only Admin to connect and the bottom 3 checks. You can try turning off only admin to connect or Permission required check at the bottom and see if that makes a difference.

The options on the Access tab are a non-issue as Administrators are not affected by it, and there are no "NON-Admins" attempting to use the application in my environment.

 

Re: connectingtoavistapcitalwaysrequiresuserspermission
by Roger on Tue Dec 04, 2007 5:19 pm

 

Is this the prompt you see? If so then follow the instructions there to get rid of it without turning off UAC.
http://www.computerperformance.co.uk/vista/ConsentPromptBehavior.htm

Other than that you are correct that the access Tab shouldn't matter if the user is in fact admin. The additional settings tab would matter though, so make sure
it is good. If the remote PC is
giving the UAC figuring out why would be the best thing. I haven't done much with
Vista yet for these and numerous other reasons...including a way documented on many sites for actually removing the admin account and completely locking yourself out. I have used this type of protection on other OS like Ubuntu and Suse, and Vista's copy is less than adequate. What exactly does the UAC box
want permissions
to do anyway? MRC should be just doing a passthrough login and not needing settings change, unless for some reason when it asks if the account is amember of the admin group Vista thinks it is requesting permissions??? Post the text/screenshot of the box if possible. One thing if this is the case would be maybe trying the other options on the Access
tab like making
a group for the account and selecting it as a group, so it isn't just testing for admin and causing the prompt.

If nothing else works, the link above sounds like
it gives a Yes to All to the prompts. If it still asks for a password on the major stuff it would work for me and not have UAC disabled...

 

Re: connectingtoavistapcitalwaysrequiresuserspermission

by slburke on
Tue Dec 04, 2007 5:42 pm

 

Roger wrote:Is this the prompt you see? If so then follow the instructions there to get rid of it without turning off UAC.
http://www.computerperformance.co.uk/vista/ConsentPromptBehavior.htm

That be the one... Now there is another link on that page something to the effect of "Behavior of the elevation prompt...." That has a section titled "Local policy - Elevate without  rompting" (Domain joined only). That looks promising, can someone try that out. I don't have any Vistamachines at the moment because of this issue, but would like to know if this works. BUT, itlooks like the only thing that can be done on aVista machine NOT on a domain is to disable UAC altogether.

 

Re: connectingtoavistapcitalwaysrequiresuserspermission

by mmenzie on
Wed Dec 05, 2007 8:19 am

 

Roger wrote:Is this the prompt you see? If so then follow the instructions there to get rid of it without turning off UAC.
http://www.computerperformance.co.uk/vista/ConsentPromptBehavior.htm


thats not the promp i am getting. i actually get the one from the dameware remote asking the user
to grant permission for some one to remote in

 

Re: connectingtoavistapcitalwaysrequiresuserspermission

by Roger on Wed Dec 05, 2007 12:26 pm

I don't know what else to say on this one. For the UAC prompt, it would be nice to see/know specifically what it is asking permissions for in the prompt, and did you try the registry key setting
ConsentPromptBehaviorAdmin
to 0 to see if the box goes away? For the MRC prompt, if you are logging on with the admin account I'd verify the Additional Settings Tab on the Remote box...not your
machine or the default settings. Posting the actual ini file from the
Vista box would be helpful too.

Other than that, Bryan mentioned they have all
Vista machines in their environment and they worked. My only questions would be-
1. Are they all working with UAC on?
2. Are they all
Vista Ultimate?
3. Were they tested in both
a workgroup and NT/AD network?

If the answers
to all 3 of those are yes, then it still sounds like a configuration thing. Going bya "I triple checked it" can't always be 100%. I can look at a piece of code I wrote for hours and never figure out the bug causing it not to work, but hand it over for a 2nd set of eyes to look at and they may find it in 2min. If the exact files/settings/msi file is used on all machines andVista is
the only one with problems, then
it sounds like Vista needs tweaked.

Vista is a whole new beast and probably the worst initial releases M$ has made...yet people are bending over backward to support it. Both my anti-virus and firewall are pretty much useless and not getting any real updates for a month or more now just because they decided to supportVista and dropped all advanced features and any OS other than XP and Vista. They dumbed downa perfectly good piece of software just to be "compatible" with that garbage. In my opinion itneeds to be the other way around...they need to fix Vista and make/allow itto work properly. Until they do, there are lots of things to tweak and make it work.

Re: connectingtoavistapcitalwaysrequiresuserspermission

by slburke on
Wed Dec 05, 2007 1:36 pm

 

Roger wrote:I don't know what else to say on this one. For the UAC prompt, it would be nice to see/know specifically what it is asking permissions for in the prompt, and did you try the registry key setting ConsentPromptBehaviorAdmin to 0 to see if the box goes away? For the MRC prompt, if you are logging on with the admin account I'd verify the Additional Settings Tab on the Remote box...not your
machine or the default settings. Posting the actual ini file from the
Vista box would be helpful too.

Roger wrote:Other than that, Bryan mentioned they have all Vista machines in their environment and they worked. My only questions would be-
1. Are they all working with UAC on?
2. Are they all
Vista Ultimate?
3. Were they tested in both
a workgroup and NT/AD network?

don't forget the biggest question...Is there any interaction ATALL by the remote user?
Roger wrote:If the answers to all 3 of those are yes, then it still sounds like a configuration thing. Going by a "I triple checked it" can't always be 100%.

Again, in my case, all that was done was to take VALID configuration that is on every other machine in my environment and move ittoaVista machine. So I would say that it's definitely 100%.


Re:
connectingtoavistapcitalwaysrequiresuserspermission

by bryan on
Wed Dec 05, 2007 3:38 pm

Hey Everybody,
Many thanks for everyone's contributions on this post. I think we just need
to take a step back here, and we should be able to get this resolved. Because I really want to help you get this resolved, and there is no reason you shouldn't be able to connect without requiring permission.

OK, from everything that everyone is including below this is definitely
a MRC Permission Prompt and not a UAC prompt, and there are only two ways the MRC software will ask for permission.
1.
Permission Required is enabled on the remote machine, either in the DWRCS.INI file or in the Registry.
2. You are
connecting with non-Admin rights, in which case you will require permission.
That's
it. There are no other settings to ask the user for permission.
With regard
to non-Admin rights, I know you said there are no non-Admin users. However, you have to remember how UAC works, because all users (even Administrators) are treated as non-Admins under UAC. That is, except the "Administrator" account which is disabled by default underVista. The "Administrator" account is not UAC enabled, and therefore it's always considered an Administrator, with or without UAC.

You also stated below you took the same configuration from your other machines and applied
itto this Vista machine. Does this mean you took your MSI file you created for NT/2000/XP/2003 and used itto install under Vista as well? Because that may be part of your issue. If you look in the MSI builder, Vista has it's own build because Vista is fundamentally different that these other MS Operating Systems when UAC is enabled. Just as an example, Vista no longer supports Interactive Services. So you MSI file for NT/2000/XP/2003 will install the MRC Service to Interact with the Console, whereas, if you create aVista Build that flag is no longer set.

Also, which authentication method are you using
to connect? Also since this is Vista, make sure the "Must have Locally Logon Rights" checkbox is not enabled under the Allowed authentication methods on the remote machine.
If this still doesn't resolve this behavior for you, please make sure you don't have any settings stored in the Registry on the remote machine. Because if the settings are being retrieved from the Registry, then the DWRCS.INI file will be ignored.

[HKEY_LOCAL_MACHINE\Software\DameWare Development\DWRCS\Settings]

If the "Use Registry for all Settings" value is set
to dword:00000001, then your Client Agent settings are being retrieved from here instead. You can set itto dword:00000000 or make the necessary changes in the Registry for Permission Required.
Your feedback is greatly appreciated.

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

Re: connectingtoavistapcitalwaysrequiresuserspermission

by Roger on
Wed Dec 05, 2007 4:12 pm

 

Ahh, so does the Logon Locally being off tell itto just check the group and not actually logon and try to test for admin since it will be a plain user in that case due to UAC? That sounds valid. I never noticed the Service was Interactive. I'm guessing that is to access the Task Tray menu. So, in Vista is it not possible to have the menu in the Tray then? I never had much luck writinga Service to be
Interactive, they usually end up crashing on Windows Shutdown.

Re: connectingtoavistapcitalwaysrequiresuserspermission


by bryan on
Wed Dec 05, 2007 4:25 pm


Hey Roger,

Not exactly. Only the "Must be
a member of .." features really check group membership. The software just does a different type of logon with or without the "Must have locally logon rights" checkbox enabled. For Vista, you basically don't want that checkbox enabled, however, the MSI builder should already take care of that for you, provided you select Vista as the Target O/S.

Also, I believe the "Interact with Desktop" setting in the Service Properties had more
to do with acquiringthe screen information, not really the SysTray icon. For example, take a XP machine and reconfigure the Service to not Interact with the Desktop. Then when you connect you will just get a Black Screen in your MRC window. So we basically had to do things a completely
different way in
Vista, but it actually works very well under Vista.

Best Regards,

Bryan Brinkman
Support Engineer

DameWare Development, LLC.
http://www.dameware.com

Re: connectingtoavistapcitalwaysrequiresuserspermission

by auto on
Wed Jan 02, 2008 6:55 pm


You stated that it is a workgroup setup. Apparently VIsta security has an additional setting so that a matching local administrator username and password on both PCs does NOT automatically allow access toa remote administrative share. I haven't had a chance to test this but it may explain the issue you are experiencing.

Set - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy
to 1(DWORD).

To do this:

- Click start

- Type: Regedit

- Press Enter

- Browse
to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system

- Right-click
a white area in the right pane

- Click New

- Click Dword Value

- Type: LocalAccountTokenFilterPolicy

- Press Enter

- Double-click LocalAccountTokenFilterPolicy

- Type: 1

- Press enter

- Restart your computer

Auto

Re: connectingtoavistapcitalwaysrequiresuserspermission

 

by wcabello on
Sun Jan 27, 2008 7:55 pm

Hello Brian, It seems that this problem is an on-going problems with usersconnecting remotelytoVista computers. I also have tried all of the suggestions and I have not secceeded yet either. The blue windows still pops up saying waiting authorization from the user (local person in that computer). I modified the registry as suggested, restarted the computer and it does not do the
trick either. Have you or anybody in Dameware can solve this issue once for all and provide
afinal solution to their customers. Thanks

Re: connectingtoavistapcitalwaysrequiresuserspermission

by bryan on
Tue Jan 29, 2008 6:50 pm

Hello wcabello,
Not really. I still have not been able
to reproduce this behavior, and outside of this post I also haven't had any other users write to me in Support with this behavior on Vista.

However, I believe you also wrote
to support directly as well, and the reason this is not working for you is because version 5.x is not supported on Vista. You must be running version 6.x of the software both locally & remotely in order to support Vista.

Best Regards,

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

Re: connectingtoavistapcitalwaysrequiresuserspermission

by revolutn on
Thu Jan 31, 2008 12:28 am

OK.
I've read the entire thread, all 3 pages.
Here's what I can tell you.
I made MRC work with
aVista home premium pc tonight,without doing anything to UAC at all.
Here's what I did.
I downloaded the latest latest 6.7.0.2.

I used MSI builder
to make an installation package for Vista32bit.

I chose PROPRIETARY CHALLENGE RESPONSE for authentication type. put in
a user name and password (since I wouldn't have an account on the target remote clientpc)

I emailed the msi package
to the recepient and they ran the installation.

I configured the router
to pass traffic on 6129 to their nat'd lan ip.

I told the end client
to be ready to give me permission if they were prompted.

I put in their public IP address in the host window. changed the authentication type
to proprietary and supplied the credentials i created above.
clicked connect.

On the remote side, the client accepted the UAC request.

I was connected without further ado or incident.

Now,
it may well be that 6.7.0.2 addresses some issue that was present in 6.2.x.x, but this was not as difficult as I feared after reading this thread.

I will confirm later if I can eastablish subsequent unattended connections at
a later time, but I've disconnected and reconnected several times in the same session, boot cycle without the user being prompted to do anything.

Hope this information and my experience helps some of the struggling peeps on this thread.

Rev

Re: connectingtoavistapcitalwaysrequiresuserspermission

by bryan on
Thu Jan 31, 2008 4:35 am

Hi Rev,

Many, many, many thanks for your feeback. This is exactly how
it's supposed to work,and exactly how it has worked for all6.x versions of the software, without having to alter UAC at all. So, like you, I'm not sure why others are having so much trouble, because it should not be that difficult.

However, I did find out why the previous poster had issue with permissions on
Vista, and it was because he was running version 5.x of the software,which is not supported on Vista.

Thank you again for posting this information about your experiences.
It's nice when someone other than the support guy can back this upas well .

Best Regards,

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

Re: connectingtoavistapcitalwaysrequiresuserspermission

by bobbyb on
Mon Mar 17, 2008 7:50 am

I've also gotten this to work with Vista Home Premium, but as a heads up, I have seen what you are talking about. It matters what logon method you are using, use the proprietery challenge/response method,not the windows logon. If you use the other method, the administrative rights come into play. If you use the proprietery method, it doesn't have any issues.

Also, when I set
it up, I could connect without any UAC popping up. Period. However, if I chose another authentication method, it would pop up the UAC. As long as you do the right method, you shouldn't have a problem.

Install/Uninstall software remotely

$
0
0

Note:  This is a topic brought over from DameWare Forums which has been closed.  If you wish to engage in this discussion, just comment on this document.
by INFOSDEA on
Thu Jul 19, 2007 4:04 am

 

A great feature would be the possibility to install/uninstallsoftwareremotely !

 

Re: Install/Uninstallsoftwareremotely

by bryan on
Mon Jul 23, 2007 8:25 am

I agree, this would be a cool feature, and we have actually talked about adding this functionality into the software. I just cannot make any promises when or if this feature can be added.

 

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

 

Re: Install/Uninstallsoftwareremotely

by odin568 on
Tue Sep 11, 2007 1:41 am

yes this would be cool!
would it also be possible to search in all added clients of dameware favorite-list for a
softwareand uninstall it automaticly - like google earth, toolbar, ......
this would save us much time at work

 


Re: Install/Uninstallsoftwareremotely

by groupesm on
Mon Nov 24, 2008 3:21 pm

this would indeed rock

   
Re: Install/Uninstallsoftwareremotely

by Marty on
Wed Nov 26, 2008 12:09 pm

 

Duly noted!
Thanks for the input.

 

Marty Bonvillain
Support Staff
DameWare Development, LLC.
http://www.dameware.com

Re: Install/Uninstallsoftwareremotely

by creative on
Mon Feb 23, 2009 3:31 pm

 

good idea

 

Re: Install/Uninstallsoftwareremotely

by mmenzie on
Thu Sep 02, 2010 8:31 am

 

hello all. i have been a faithful user of Dameware for years and i love it. i see this thread has not been updated in over a year. i would like to revive this thread and also request that this be added as a feature. i as i type this am searching for a way to uninstall a program from a users computerremotely and silently. i use dameware for everything else i think i should be able to use it for that too... but alas... we can't.

Please oh please, mighty dameware developers.... please add this funtionality!!!! and if anyone out there has a suggestion on what i can do while i wait for dameware dev's to
do this to do what i am requesting now.... please let me know.

Thanks
Mike

 

Re: Install/Uninstallsoftwareremotely

by dane on
Tue Sep 28, 2010 6:59 am

 

Having the a ability to remotely install and uninstall software would be a definite plus for Dameware NT. In fact, as a new user of Dameware NT, I was suprised to find that this function was not included in the suite of tools that the program offers.

Right now, I have to use a freeware program (ManagePC) to remotly
install/uninstall.

 

Re: Install/Uninstallsoftwareremotely
by j0shu4 on
Tue Nov 09, 2010 3:40 pm

 

Actually, from what I've seen in my very limited playing around with the demo, it does have that ability through System Tools. Basically it boils down to using psexec in a custom made script, which is called from the System Tools menu. We use Hyena where I work (which does this in the same manner), but we're looking into purchasing NTU. This was one of our key
requirements and it can do it. Now doing this on multiple machines at once, instead of one by one, I'm not sure if it can do that. I haven't found a way to run a System Tool against multiple PC's yet.

 

Re: Install/Uninstallsoftwareremotely
by mmenzie on
Tue Nov 09, 2010 3:51 pm

 

well there are people (myself included) that do not know how to write custom scripts like you mentioned. so having a tool that can do that without needing that knowledge is what i think i am asking for here.

Re: Install/Uninstallsoftwareremotely
by mro on
Wed Nov 10, 2010 4:30 am

 

I'd suggest that DameWare implement the feature to select multiple machines and run System Tools script against them in a future version of DNTU and above from that add a section to the website (or forum) where users can share their System Tools scripts.

 

Re: Install/Uninstallsoftwareremotely
by j0shu4 on
Wed Nov 10, 2010 10:40 am

@ mmenzie:

I realize that. What I was doing was pointing out that there is a way before it is implemented. Considering the age of this thread, it's been a while and I was wanting to help. The scripts that I mentioned are bat scripts, which is pretty easy to learn. Let me give you an example of how to install Firefox...

CODE: SELECT ALL

 

Cd Cd Windows\System32

psexec \\%1 -u username -p password -c -s -f
\\server_name\share_name\FirefoxSetup3.6.12.exe -ms


There's only 3 lines in this code. The 4th line is wrapped and should only have a space between -f and \\.

All you need to do is have psexec copied into your c:\windows\system32 folder. The hardest part about this is learning what switch (-ms in this case) allows for a silent install. It changes with each exe/msi.

 

Re: Install/Uninstallsoftwareremotely

by j0shu4 on
Wed Nov 10, 2010 10:43 am

 

mro wrote:I'd suggest that DameWare implement the feature to select multiple machines and run System Tools script against them in a future version of DNTU and above from that add a section to the website (or forum) where users can share their System Tools scripts.

That would be an awesome idea. One thing you mentioned mro, and something that I'm trying to figure out... Can you not run system tool scripts against multiple machines? I've been trying to figure this out and can't seem to get it to work.

 

Re: Install/Uninstallsoftwareremotely
by mro on
Thu Nov 11, 2010 4:46 am

 

j0shu4 wrote:That would be an awesome idea. One thing you mentioned mro, and something that I'm trying to figure out... Can you not run system tool scripts against multiple machines? I've been
trying to figure this out and can't seem to get it to work.


Currently this doesn't work. I think DameWare has to modify DNTU in two ways:
- support multiple selection in the browser pane and
- store each selected computer in an array (for support of the %MACHINE%variable)

Hopefully this can be implemented easily or is already implemented in the next version of DNTU...

Regarding my suggestion to share different System Tools scripts I'd like to know what the mods think about that. Awaiting your kind reply!

Re: Install/Uninstallsoftwareremotely

by mmenzie on
Thu Nov 11, 2010 8:25 am

mro wrote:

 

j0shu4 wrote:Regarding my suggestion to share different System Tools scripts I'd like to know what the mods think about that. Awaiting your kind reply!

i think that is an excellent idea and should be implemented on the forms!!!! great idea!!

 

Re: Install/Uninstallsoftwareremotely

by Hormel on
Fri Jul 29, 2011 1:15 pm

 

Agreed awesome idea! 

Seeing the wrong version number in your DameWare information ? (version 10)

$
0
0

Hello Everyone,

 

I would like to address a small issue with the DameWare interface that we are aware and in the process of resolving.

For all of you currently running version 10 of either DameWare Mini Remote Control or DameWare Remote Support.

you might have taken a look at your about screen and been a little confused

 

"Why does my newly upgraded version 10 show that it is licensed with version [DRS 9 or DMRC9] ?"

 

For example here are two screenshots of both DameWare Remote Support and Mini Remote Control that are fully registered and running version 10.0.0.372 perfectly.

 

 

vc5UfVg.jpgmqmx9zw.jpg

 

 

The two screenshots above while seem abnormal, are perfectly normal behavior for our current licensing model and version 10 installation.

 

There are two sections you need to check to ensure everything is as intended

The top which displays the version type and copyright information

and the section in-between the "This product is licensed to: DameWare xxxxx" and Purchase and Sync buttons

In this blacked out area of the screenshots you should see your activation key followed by your SWID

Please ignore the area stating either [DMRC9] or [DRS9]

 

We realize that this might not be the most logical, intuitive, or visually appealing way to display this information but we promise that we are working on streamlining the user interface in future versions of DameWare

Seeing the wrong version number in your DameWare information ? (version 10)

$
0
0

Hello Everyone,

 

I would like to address a small issue with the DameWare interface that we are aware and in the process of resolving.

For all of you currently running version 10 of either DameWare Mini Remote Control or DameWare Remote Support.

you might have taken a look at your about screen and been a little confused

 

"Why does my newly upgraded version 10 show that it is licensed with version [DRS 9 or DMRC9] ?"

 

For example here are two screenshots of both DameWare Remote Support and Mini Remote Control that are fully registered and running version 10.0.0.372 perfectly.

 

 

vc5UfVg.jpgmqmx9zw.jpg

 

 

The two screenshots above while seem abnormal, are perfectly normal behavior for our current licensing model and version 10 installation.

 

There are two sections you need to check to ensure everything is as intended

The top which displays the version type and copyright information

and the section in-between the "This product is licensed to: DameWare xxxxx" and Purchase and Sync buttons

In this blacked out area of the screenshots you should see your activation key followed by your SWID

Please ignore the area stating either [DMRC9] or [DRS9]

 

We realize that this might not be the most logical, intuitive, or visually appealing way to display this information but we promise that we are working on streamlining the user interface in future versions of DameWare

DameWare Version 9 Product History

$
0
0

DameWare Remote Support Version 9.0.0 Release Notes - 9/7/12


DameWare NT Utilities (NTU) is now DameWare Remote Support (DRS). These release notes provide additional guidance for DRS version 9.0.


Why Install this Version

This version of DRS provides the following improvements:

  • Version 9.0 of Mini Remote Control:
  • Intel vPro Support:
  • Support for Silent Installs:
  • Multiple bug fixes:

Notes:

  • If you are upgrading to DRS version 9.0 from a version earlier than 8.0, apply your SolarWinds license after you upgrade. For additional information, see "Using the New Licensing System" in these release notes.
  • Starting with version 9.0, you may notice a change in how your license looks in the SolarWinds customer portal. This change is solely to facilitate backend processing, and does not affect your license count or pricing.

Resolved Issues

DameWare Remote Support version 9.0 resolves the following issues in earlier versions:

  • NTU v8.x crashes when you close the Shutdown window.
  • The Servers node in NTU v8.x enumerates the same server repeatedly when expanded.
  • DameWare Exporter in NTU v8.x crashes when you export to a non-existent folder.
  • The Download SolarWinds License Manager link in the host Start menu does not work on Windows Server 2003 or Windows XP hosts in v8.x.


Known Issues

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.


U3 Mode is not a valid licensing option with the new licensing system

Previously, NTU users were able to license the product in "U3 Mode", which allowed them to run the application from a USB drive. This functionality is not currently compatible with our licensing system, but we are investigating a resolution for a future release.


End of Life Policy

In order to continue to drive innovation and new functionality into our products, SolarWinds must transition customers from legacy versions of software to our current versions. Please review the following support schedule:

  • 9/13/2012: End-of-Life announcement (EoL) – Customers on DameWare v6.9 or older should begin transitioning to DameWare 9.0.
  • 12/12/2012: End-of-Life (EoL) – SolarWinds will no longer provide technical support for SolarWinds DameWare v6.9 or older.


Using the New Licensing System

After installing NTU or DRS version 8.0 or higher, you are prompted to enter the licensing information for your product. If you choose to start with the 14-day evaluation, you can access the Licensing Information options by opening Start > All Programs > SolarWinds > DameWare Remote Support 9.0 > Enter License Information on the computer you want to license.


To evaluate the software without a license, click Continue Evaluation.


To license the software on a computer with Internet access:

  1. Click Enter Licensing Information.
  2. Select I have internet access and an activation key.
  3. Click the http://www.solarwinds.com/customerportal link to access the customer portal on the SolarWinds web site.
  4. Log on to the portal using your SolarWinds customer ID and password.
  5. Click License Management on the left navigation bar.
  6. Navigate to your product, choose an activation key from the Unregistered Licenses section, and then copy the activation key.
  7. If you cannot find an activation key in the Unregistered Licenses section,contact SolarWinds customer support.
  8. Return to the Activate DRS window, and then enter the activation key in the Activation Key field.
  9. If you access Internet web sites through a proxy server, click I access the internet through aproxy server, and enter its proxy address and port.
  10. Note: If your computer accesses the Internet through an authenticated proxy server, complete the procedure for activating without Internet access instead.
  11. Click Next.
  12. Enter your email address and other registration information, and then click Next.


To license the software on a computer without Internet access:

  1. Click Enter Licensing Information.
  2. Select This server does not have internet access, and then click Next.
  3. Click Copy Unique Machine ID.
  4. Paste the copied data into a text editor document.
  5. Transfer the document to a computer with Internet access.
  6. On the computer with Internet access, complete the following steps:

a. Browse to http://www.solarwinds.com/customerportal/licensemanagement.aspx, and then log on to the portal with your SolarWinds customer ID and password.

b. Navigate to your product, and then click Manually Register License.

c. If the Manually Register License option is not available for your product, contact SolarWinds customer support.

d. Provide the Machine ID from Step 5, and then download your license key file.

7. Transfer the license key file to the DRS server.

8. Return to the Activate DRS window, browse to the license key file, and then click Next.


Managing your Open Issues in Licensing

For information about managing your licenses for SolarWinds products, including how to deactivate or reuse a license, see SolarWinds License Manager.

Open Issues in Licensing

  • Applying Federal Information Processing Standards (FIPS) to a licensed NTU server invalidates the existing license. To reactivate your license, contact SolarWinds customer support.
  • If you enter the activation key from another SolarWinds product by mistake, the activation key for the other product is considered registered even though your actual product remains unlicensed. To return the activation key to your pool of unregistered licenses, contact SolarWinds customer support.

 

 

DameWare Remote Support Version 9.0.1 Release Notes


DameWare NT Utilities (NTU) is now DameWare Remote Support (DRS). These release notes provide additional guidance for DRS version 9.0.1.


Why Install this Version

This version of DRS provides the following improvements:

  • Windows 8 Support:You can now install DRS on computers running the latest Windows desktop operating system. DRS also connects to remote hosts running Windows 8.
  • Version 9.0.1 of Mini Remote Control:This release includes the latest version of DameWare MRC. For additional information, see the DameWare MRC release notes.
  • Intel vPro Support:Both DRS and MRC now support Intel vPro hardware enabled with Active Management Technology (AMT). In DRS, power on, power off, or restart remote vPro systems even when they are powered off. For additional information, see KB400112.
  • Support for Silent Installs:Both DRS and MRC now include command-line arguments to support installing and licensing the products silently. For additional information, see KB400113.
  • Multiple bug fixes:For additional information, see "Resolved Issues" in these release notes.

Notes:

  • If you are upgrading to this version from a version earlier than 8.0, apply your SolarWinds license after you upgrade. For additional information, see "Using the New Licensing System" in these release notes.
  • Starting with version 9.0, you may notice a change in how your license looks in the SolarWinds customer portal. This change is solely to facilitate backend processing, and does not affect your license count or pricing.


Resolved Issues

DameWare Remote Support version 9.0.1 resolves the following issues in earlier versions:

  • NTU v8.x and DRS v9.0 crashes when you use the Move function in the Active Directory node.
  • NTU v8.x crashes when you close the Shutdown window.
  • The Servers node in NTU v8.x enumerates the same server repeatedly when expanded.
  • DameWare Exporter in NTU v8.x crashes when you export to a non-existent folder.
  • The Download SolarWinds License Manager link in the host Start menu does not work on Windows Server 2003 or Windows XP hosts in v8.x.


Known Issues


Remote systems running Windows Vista or later do not show a popup on log off or shutdown.
If you send a log off or shutdown command from DRS to a remote computer running Windows Vista or later, the remote system completes the request but does not display a notification to the remote user. To resolve this issue, enable interactive services on the remote system. For additional information, see Interactive Services on msdn.microsoft.com.


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.


U3 Mode is not a valid licensing option with the new licensing system.
Previously, NTU users were able to license the product in "U3 Mode," which allowed them to run the application from a USB drive. This functionality is not currently compatible with our licensing system, but we are investigating a resolution for a future release.


End of Life Policy

In order to continue to drive innovation and new functionality into our products, SolarWinds must transition customers from legacy versions of software to our current versions. Please review the following support schedule:

  • 9/13/2012: End-of-Life announcement (EoL) – Customers on DameWare v6.9 or older should begin transitioning to DameWare 9.0.
  • 12/12/2012: End-of-Life (EoL) – SolarWinds will no longer provide technical support for SolarWinds DameWare v6.9 or older.


Using the New Licensing System

After installing NTU or DRS version 8.0 or higher, you are prompted to enter the licensing information for your product. If you choose to start with the 14-day evaluation, you can access the Licensing Information options by opening Start > All Programs > SolarWinds > DameWare Mini Remote Control 9.0 > Enter License Information on the computer you want to license.


To evaluate the software without a license,click Continue Evaluation.


To license the software on a computer with Internet access:

1. Click Enter Licensing Information.

2. Select I have internet access and an activation key.

3. Click the http://www.solarwinds.com/customerportal link to access the customer portal on the SolarWinds web site.

4. Log on to the portal using your SolarWinds customer ID and password.

5. Click License Management on the left navigation bar.

6. Navigate to your product, choose an activation key from the Unregistered Licenses section, and then copy the activation key.

7. If you cannot find an activation key in the Unregistered Licenses section,SolarWinds customer support.

8. Return to the Activate MRC window, and then enter the activation key in the Activation Key field.

9. If you access Internet web sites through a proxy server, click I access the internet through a proxy server, and enter its proxy address and port.
Note: If your computer accesses the Internet through an authenticated proxy server, complete the procedure for activating without Internet access instead.

10. Click Next.

11. Enter your email address and other registration information, and then click Next.



To license the software on a computer without Internet access:

1. Click Enter Licensing Information.

2. Select This server does not have internet access, and then click Next.

3. Click Copy Unique Machine ID.

4. Paste the copied data into a text editor document.

5. Transfer the document to a computer with Internet access.

6. On the computer with Internet access, complete the following steps:

a. Browse to http://www.solarwinds.com/customerportal/licensemanagement.aspx, and then log on to the portal with your SolarWinds customer ID and password.

b. Navigate to your product, and then click Manually Register License.

c. If the Manually Register License option is not available for your product,contact SolarWinds customer support.

d. Provide the Machine ID from Step 5, and then download your license key file.

7. Transfer the license key file to the MRC server.

8. Return to the Activate DRS window, browse to the license key file, and then click Next.


 

Managing your Open Issues in Licensing

For information about managing your licenses for SolarWinds products, including how to deactivate or reuse a license, see SolarWinds License Manager


Open Issues in Licensing

  • Applying Federal Information Processing Standards (FIPS) to a licensed NTU server invalidates the existing license. To reactivate your license, contact SolarWinds customer support.
  • If you enter the activation key from another SolarWinds product by mistake, the activation key for the other product is considered registered even though your actual product remains unlicensed. To return the activation key to your pool of unregistered licenses, contact SolarWinds customer support.

Exporting Disabled AD Accounts

$
0
0

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


Original Post

by blackpool6 on Fri Apr 08, 2011 8:36 am

I want to start using NT Utlities and the exporter here at work. I have a need to export the user account information on a quarterly basis. This is for SOX auditing purposes.
Overall I have no problems with the software, except one:

How do you export the
accountsand show which accountsare disabled? I know this is some sort of shared attribute field but I am wondering if the exporter has a way to handle it?

Thank you.

 


Re:
ADDisabledAccounts

by blackpool6 on Thu Apr 14, 2011 2:09 pm

No hints at all? I notice that if I explore the domain that it indicates which users are locked out and which ones are disabled.
Is there a way I can export that view?

 

Re: ADDisabledAccounts

by blackpool6 on Mon Apr 25, 2011 6:52 am

Tap Tap Tap
Is this thing on????

No one else needs or would use this? Is it posted somewhere else? I tried to search but found nothing.

I see Bryan constantly updating posts but nothing here.

 


Re:
ADDisabledAccounts

by DawgBone on Tue Apr 26, 2011 4:22 pm

My experience with Exporter is pretty...well.....non-existent...buuuuutttttt

I just did one on my
AD DC, and I used the standard properties... It tells me some good stuff 

like...


<User>
<UserName>dividingbyzero</UserName>
<FullName>dividingbyzero</FullName>
<Comment/>
<UserComment/>
<HomeDir/>
<HomeDirDrive/>
<ScriptPath/>
<Profile/>
<LogonTo>\\*</LogonTo>
<LastLogon>9/12/2008 3:23:14 PM</LastLogon>
<LastLogoff>-1</LastLogoff>
<BadPwCount>0</BadPwCount>
<NumLogons>434</NumLogons>
<PwExpires>-1</PwExpires>
<PwExpired>No</PwExpired>
<NoExpirePwd>Yes</NoExpirePwd>
<Disabled>Yes</Disabled>
<LockedOut>No</LockedOut>
<NoPwRequired>No</NoPwRequired>
<UserCantChgPw>Yes</UserCantChgPw>
<RAS>No</RAS>
<RASCallback/>
<SetByCaller/>
<CallbackNo/>
<PwAgeInDays>1463</PwAgeInDays>
<PwLastChg>4/24/2007 2:25:34 PM</PwLastChg>
</User>

 

Re: ADDisabledAccounts

by blackpool6 on Tue Apr 26, 2011 8:48 pm

Thank you!!!
I used the standard properties instead of the
AD export and I see all that I will ever need. Last logon, locked out, disabled, etc.

Perfect!!

Thanks Dawg Bone

 

Re: ADDisabledAccounts

by auley on Mon Jan 30, 2012 2:28 am

I haven't seen or noticed such behavior, it might be some scripts set in the background to do this based on the criteria.It can be the behavior of script cell phone spy software to disable and enable the account

 

Re: ADDisabledAccounts

by Lisa098 on Fri Feb 03, 2012 2:02 am

You can use any valid LDAP filter. Other option is to select an unused attribute and stamp them with “DoNotSync” value and exclude them based on this attribute value.

Usually AdminDisplayName and AdminDescription attributes are not in use.


Need info concerning using DameWare over the internet

$
0
0

Note:  This is a topic brought over from the old DameWare Forums which are no longer active.  To continue the discussion, please comment on this document.

 

 

NeedinfoconcerningusingDamewareovertheinternet

by saladdin on Tue Aug 05, 2008 7:19 am

Sorry would like to know if there is a way to use dameware to support multiple offices ( different companies) overtheinternet without the use of VPN? some sort of gateway system maybe were a gateway is setup at the customer office and all i need to do is setup a connection to it.

 

Re: NeedinfoconcerningusingDamewareovertheinternet

by Marty on Tue Aug 05, 2008 11:45 am

Hi,

This topic is actually covered in our online Knowledgebase. I've included a link here for your convenience to detailed documentation that should address this subject:

Establishing a Remote connection
overtheInternet
http://www.dameware.com/support/kb/article.aspx?ID=300093

I hope this helps

 

Marty Bonvillain
Support Staff

 


Re:
NeedinfoconcerningusingDamewareovertheinternet

by petergriffin on Sat Jan 23, 2010 5:19 am

Thanks for the help Marty.

Harry Head
Naturopathic Healer

 

 

Re: NeedinfoconcerningusingDamewareovertheinternet

by mjarcos on Thu Mar 25, 2010 5:20 am

Hi

I
need to use all DameWare Utilities overinternet, not only Miniremote Control.

Is it possible?

Thanks

 

 

Re: NeedinfoconcerningusingDamewareovertheinternet

by zwilliamson on Thu Mar 25, 2010 7:51 am

Not without major security risks. Most of the other features in DNTU use native Windows APIs, so exposing them to the public internet would cause a huge security issue.

 

 

Re: NeedinfoconcerningusingDamewareovertheinternet

by mjarcos on Thu Mar 25, 2010 11:27 am

thanks for answering so fast.

 

 

Re: NeedinfoconcerningusingDamewareovertheinternet

by deni80 on Sat May 14, 2011 4:28 am

Hi Marty,

I was looking for this
info, thanks for sharing this, mate!


__________________________________________________
Deni B

 

 

 

Re: NeedinfoconcerningusingDamewareovertheinternet

by david49 on Fri Feb 03, 2012 2:47 pm

Hi marty

Thanks for
the link to the detailed documentation, this cleared
a few things up for me.

Kind Regards

Wake-on-LAN Issue

$
0
0

Note:  This topic was brought over from the old DameWare Forums which are no longer active.  To continue this discussion, comment on this document.



WakeOnLanissue

by pvanwelt on Tue Jul 10, 2007 8:51 am

Hi!

i'm using Dameware for some time now and it's a great tool to work with.
But i can't
wake any system with the WOL feature.

When i use a dos tool "mc-wol.exe" (downloaded from the internet)
on the machine it doeswake-up.
Trying again with dameware it doesn't.

Can anybody help me out ?

 

Re: WakeOnLanissue

by bryan on Thu Jul 12, 2007 6:18 pm

Honestly, we use it all the time over here and it works great for us. So it could possibly be the Port that you're using or maybe even the type of Broadcast (i.e. directed vs general). Because according to the MC-WOL documentation they are also sending WOL "Magic Packet" requests, which is exactly what DNTU is using.

Did you select
Wake Single or Wake Batch in DNTU? And what port did you specify?
Also, what is your command line for the MC-WOL utility?

MC-WOLMAC would be a general broadcast equivalent to DNTU's Wake Batch feature, which broadcasts to the entire subnet.

MC-WOLMAC /a Broadcast Address would be a directed broadcast equivalent to DNTU's WakeSingle feature, and would only be sent to the broadcast (multicast) address for that specific LANsegment where the destination computer is located. So withn DNTU you would also specify any IP-Address from the same subnet as this remote machine, and also the subnet mask for that segment, then click on the Check button to calculate the Broadcast Address for that LANsegment.

Additionally, the default port used by DNTU's WOL functionality is
32767, but you can specify any valid port. So you just have to use a port that's not blocked by any of your routers/firewalls. Many products even use port 0 (zero).

I hope this helps
.

Bryan Brinkman
Support Engineer

 

 

Re: WakeOnLanissue

by pvanwelt on Fri Jul 13, 2007 4:28 am

Normally i use : mc-wol [MAC] which works perfect.

I also tried mc-wol MAC /a broadcast which doesn't work.


In dameware i tried WakeSingle (port0) and (port 32767) which both don't work.
Also tried
wake batch which also doesn't work.

So the only thing that works is : mc-wol [MAC]

 

 


Re:
WakeOnLanissue

by bryan on Fri Jul 13, 2007 8:00 am

Thanks for the additional info.

OK, so you are just basically broadcasting to all machines
on your same subnet, which is equivalent to DNTU's Wake Batch. So I would have to believe this is just a port issue.

Try using port 65535 instead of 32767, which appears to be the default UDP port MC-WOL uses.

But you should also be able to use DNTU's
Wake Single feature as well, unless for some reason your router eats the packet and doesn't forward it back to the machine. Use any IP-Address from this subnet, then 255.255.255.0 (for a full Class C subnet) then click on Check which should calc a Broadcast Address of 192.168.xxx.255 for your current subnet. Then change the port to 65535 and click Wake. If that doesn't work, then also try multiple packets.

This should also be exactly the same as: MC-WOL /a 192.168.xxx.255

Bryan Brinkman
Support Engineer

 

 

Re: WakeOnLanissue

by andrepalma on Sat Jan 10, 2009 12:48 pm

Hi there, i've been start working with DNTU, and it seems to be very powerfull so far.

At the moment and i dont get a way to get the WOL working
on my computers. I have some computer in differents subnets, separated by VPN through them.
For example i have a computer that has the
machine1:
ip 10.15.11.240,
subnet mask 255.255.255.0
gateway 10.15.11.250.

That are linked to the subnet where i am, that is
Machine2:
ip 10.1.10.160
subnet mas 255.255.255.0
gateway 10.1.10.250

This subnets are fisically separated and linked throw VPNs

So from the machine2 i cant send the wol magic packet to machine1.

Even in the same subnet, the one in the machine2, the wol doesnt work like it should.. sometimes it works, sometimes it not...

Another thing, do you know why the
wakeonlan feature of each favorite machine that we add doesnt save the mac address.
For example, i add a favorite machine by ip, and the list, if open in the + it brings me the whole features available for that machine, the last one is
wakeonlan, but if i open that it dont have the information for that computer, it just has the information from the last computer or computers that i was to wake up... so i think that it could be a thing to get better or is anything that i was doing wrong.

I would appreciate help from you that you have much more experience from me.

Thank you very much,
Best regards,

André Palma

 

 

Re: WakeOnLanissue

by misga on Wed Jul 21, 2010 2:16 pm

Make sure to use your correct subnet mask, for me it was generating 255.255.255.0 but we areon a /16 so i had to manually change it to 255.255.0.0 and then click "Check" again. Also it generates the mac address in the incorect forma, example; 00 00 00 00 00 00 It has to be 00-00-00-00-00-00(use dashes instead of spaces). For us the port didnt seem to matter 0 worked just fine.

connecting to a vista pc it always requires users permission

$
0
0

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

 

connecting to a vista pc it always requires users permission

by mmenzie on Sat Sep 15, 2007 9:29 am

 

Hello,

I have a couple of vista test machines on our network. they are not joined to our domain and are in there own local workgroup. by default vista diables the administrator acct. and i have leftit disabled. i created two users on the machines, one regular and one with admin privledges. when i try to use the MRC to connect to these machines it always asks the user if they are going to allow the connection even when i try to connect using the acct i created with admin rights. this cause me a lot of headaches cause since these are test machines there is usually no user sitting at them, so i have to go to the machine so i can allow the connection. i don't have tis issue connecting to any of my xp/2000/2003 pc's and servers. so what am i doing wrong????


Re: connecting to a vista pc it always requires users permission

by bryan on Mon Sep 17, 2007 11:00 am

 

Hi mmenzie,

Please provide us with some additional information so we can more intelligently assit you.

- Is this a Microsoft UAC (User Account Control) permission dialog? Or is this a Mini Remote Control "Waiting for Client to Accept Connection" permission dialog? Perhaps even send us ascreen shot of this dialog.
- Which version of the MRC software are you currently running?
- Which version of the MRC Client Agent Service is installed on the remote machine?
- Is the remote machine running a 64-bit version of Vista, or 32-bit?
- Also, which flavor of Vista are they running (Ultimate, Business, etc...)?
- Exactly how was the MRC Client Agent Service installed on this remote machine? Via a MSI package? Manually? etc..
- Have you also checked on the remote machine to make sure the "Permission Required" setting is not enabled within the MRC Client Agent Service (on the Additional Settings Tab)?

Please send us all this information for review.

However, you might also want to try removing the MRC Client Agent Service from the remote machine. Then build a new Vista 32-bit MSI package via the DameWare Installer Tool (DWRCSMSI.EXE), included in your DameWare installation folder. Also make sure to to reset all the Authentication Types options to Default on the General Tab, and make sure the "PermissionRequired" setting is not enabled on the Additional Settings tab, when building your MSI package.

Your feedback is appreciated.

 

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


Re: connecting to a vista pc it always requires users permission

by mmenzie on Mon Sep 17, 2007 12:09 pm

 

Bryan wrote:Is this a Microsoft UAC (User Account Control) permission dialog? Or is this a Mini Remote Control "Waiting for Client to Accept Connection" permission dialog? Perhaps even send us ascreen shot of this dialog.


It is the MRC "waiting for client to accept"
Bryan wrote:- Which version of the MRC software are you currently running?

I am running MRC 6.6.1.1
Bryan wrote:- Which version of the MRC Client Agent Service is installed on the remote machine?
The version is 6.6.1.1
Bryan wrote:- Is the remote machine running a 64-bit version of Vista, or 32-bit?
it is a 32bit version of windows vista

Bryan wrote:- Also, which flavor of Vista are they running (Ultimate, Business, etc...)?


Vista Ultimate
Bryan wrote:- Exactly how was the MRC Client Agent Service installed on this remote machine? Via a MSI package? Manually? etc..
IT was done via .msi package

Bryan wrote:- Have you also checked on the remote machine to make sure the "Permission Required" setting is not enabled within the MRC Client Agent Service (on the Additional Settings Tab)?
Yes i did check that as well

Last edited by mmenzie on Sun Oct 28, 2007 11:00 am,
edited 2 times in total.

 

Re: connecting to a vista pc it always requires users permission

by mmenzie on Sun Oct 28, 2007 10:57 am

 

no help for my issues??

 

Re: connecting to a vista pc it always requires users permission

by bryan on Mon Oct 29, 2007 11:30 am

 

Hello mmenzie,
Honestly, it sounds like you haven't configured the MRC Client Agent Service properly. However, you might also want to do some additional reading on Vista and the new UAC security model, because Microsoft has made extensive changes in Vista.
Also, just FYI, even though you think you're created an account with Admin rights, under Microsoft's UAC (User Account Control) security in Vista this account is treated like any other regular user
account when you login. UAC splits the user's access token into two pieces (user portion, full admin portion), and you only receive your full Admin token when you request something that requires elevated rights, and even then it's only elevated within that specific window. Then you're back to being a regular user again. The only account that isn't UAC enabled is the true
"Administrator" account. Vista also disables this account by default, but you can re-enable it again.

However, I would suggest you remove & reinstall the MRC Client Agent on the remote machine, but do it via our MSI builder instead. This will guarantee the Service is installed correctly:

First download & install the current version of our software from the website (v6.6.2.0). Next, build a new MSI package to install the MRC Client Agent Service on this Vista machine using the DameWare MSI builder. After you configure and build the new MSI package, run the MSI pacakge on the Vista machine to install the Service. Now try your connection again. This should take care of this behavior.

I hope this helps.

 

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

 

Re: connecting to a vista pc it always requires users permission

by slburke on Tue Dec 04, 2007 11:05 am

 

It doesn't appear that this was resolved either way (yes it can be done/no it can't).....I have had to disable UAC (wich we don't want) in order to get this functionality that exists in all other versions of Windows that I support.
So for the moment have removed Vista from my environment.

It surprises me that the developers are telling us "I don't think you have MRC agent configured correctly". The same configuration that works under XP SHOULD work
under Vista. I mean it's only a checkbox to say "don't ask for permission". Have the developers tried on Vista machines and KNOW that it works with UAC enabled?

Can anyone with Vista based machines verify if the following from Microsoft would correct the issue?
http://support.microsoft.com/kb/937624


Re: connecting to a vista pc it always requires users permission

by bryan on Tue Dec 04, 2007 12:45 pm

 

It doesn't appear that this was resolved either way (yes it can be done/no it can't)


There are no known issues connecting to Vista machines, and it's definitely possible to connectto Vista without requiring permission. However, Administrator vs non-Administrator credentials, as well as the "Permission Required" setting within the MRC Client Agent Service on the remote machine will determine if you require permission to connect to this machine using our software.

Also, have you checked for DWMRCS entries in Application Event log on the remote machine tosee exactly how you're authenticating to this remote machine (Administrator vs. Regular User)? Because non-Admins cannot connect to a remote machine without requiring explicit permissionfrom the Desktop User. Please send the entire text from these entries to our support team for review.

I have had to disable UAC (wich we don't want) in order to get this functionality that exists in all other versions of Windows that I support.

What exactly are you trying to do? Because provided the MRC Client Agent Service is already installed & running on your remote Vista machines, then you shouldn't have any problems simply making a connection, provided you're connecting via Administrator credentials. However, youwill not be able to remotely install, remove, start, or stop the MRC Client Agent Service to aremote machine running Vista with UAC enabled. These requests will be blocked by the O/S itself and it's beyond our control. Therefore, simply pre-install the MRC Client Agent Service on these remote Vista machines and you shouldn't have any issues.
However, that's also why we created the DameWare MSI Builder in version 6.x of the software, because the easiest and most efficient way to install the MRC Client Agent Service on all your remote
machines is by building a MSI package via the new DameWare MRC Client Agent MSI Builder (DWRCSMSI.EXE), which allows you to build custom MSI packages (including all settings, INI or Registry) to deploy the MRC Client Agent in your environment. These MSI packages can then be sent to your clients (or even distributed via Group Policies within Corporate Environments,
etc...) via any of your existing distribution methods. Using the MSI Builder toinstall the Client Agent Servcie also ensures that the MRC Client Agent Service is installed & configured properly for the designated O/S.

The same configuration that works under XP SHOULD work under Vista. I mean it's only acheckbox to say "don't ask for permission".


This is a fundamentally flawed statement for many different reasons.
◦First,
     the ability to connect without requiring permission is determined by more that just the "Permission Required" checkbox, and it's the same for all Operating  Systems, not justVista. Regardless of the "Permission Required" checkbox, non-Admins will always requirepermission to connect. So you have to make sure you're authenticating to this remote machine as an
     Administrator not a non-Admin, or you will always require permission.

 

◦Second,
     this is exactly the functionality of Vista's UAC security model, which means even though you thinking you're logging in as an Administrator, you're really not any longer. UAC splits your Access Token into two separate parts, an Administrator portion and a non-Admin portion. When you login, you always receive  the non-Admin portion of your token. Only when you request something that requires Admin rights will UAC prompt you for elevation, and only then will you receive your full Administrator portion of your token (and only within that
     specific window/process). Once that window is closed you're right back tobeing a non-Admin again.

Have the developers tried on Vista machines and KNOW that it works with UAC enabled?

YES. We have done extensive testing on Vista, and our entire support staff are all running Vistaon their machines as well, and we don't have any issues connecting to remote machines runningVista with UAC enabled without requiring permission.

However, if you're still having issues connecting to remote machines running Vista, then send as much information as possible to our support staff, and they will be happy to assist you in resolving this behavior.

Also keep in mind that only version 6.x of the software & Client Agent is supported on Vista.

I hope this helps.

 

Bryan BrinkmanSupport Engineer

DameWare Development, LLC.http://www.dameware.com

 

Re: connecting to a vista pc it always requires users permission
by slburke on Tue Dec 04, 2007 1:41 pm


First, I hope I didn't sound like I was trying to beat up on anyone...grin

Now I will answer your responses as best I can however I have no output to show or event logs as like I said I removed the offending machines from our environment.

Bryan wrote:However, Administrator vs non-Administrator credentials, as well as the "Permission Required" setting within the MRC Client Agent Service on the remote machine will determine if you
require permission to connect to this machine using our software.

Exactly, all users that use MRC here are either LOCAL administrators (on all workstations) or DOMAIN administrators.

 

Bryan wrote:

I have had to disable UAC (wich we don't want) in order to get this functionality that exists in all other versions of Windows that I support.

What exactly are you trying to do?
Remote control a Vista machine.

 

Bryan wrote:Because provided the MRC Client Agent Service is already installed & running on your remoteVista machines, then you shouldn't have any problems simply making a connection,
provided you're connecting via Administrator credentials. However, you will not be able to remotely install, remove, start, or stop the MRC Client Agent Service to a remote machine running Vistawith UAC enabled. These requests will be blocked by the O/S itself and it's beyond our control. Therefore, simply pre-install the MRC Client Agent Service on these remote Vista machines and you shouldn't have any issues.

Exactly, I agree, your statement SHOULD be true. But it is not. I tried installing remotely (which was blocked, matches your statement). However I also transferred the files locally to the
machine and did a manual install as well with same result of user at remote machine being asked for permission (read UAC prompt).

 

Bryan wrote:However, that's also why we created the DameWare MSI Builder in version 6.x of the software, because the easiest and most efficient way to install the MRC Client Agent Service on all your remote machines is by building a MSI package via the new DameWare MRC Client Agent MSI Builder (DWRCSMSI.EXE), which allows you to build custom MSI packages (including all settings, INI or Registry) to deploy the MRC Client Agent in your environment. These MSI packages can then be sent to your clients (or even distributed via Group Policies within Corporate Environments,
etc...) via any of your existing distribution methods. Using the MSI Builder toinstall the Client Agent Servcie also ensures that the MRC Client Agent Service is installed & configured properly for the designated O/S.

This did not work either.

 

Bryan wrote: The same configuration that works under XP SHOULD work under Vista. I mean it's only acheckbox to say "don't ask for permission".
This is a fundamentally flawed statement for many different reasons.


◦First,
     the ability to connect without requiring permission is  determined by more that just the "Permission Required" checkbox, and it's the same for all Operating  Systems, not just Vista. Regardless of
     the "Permission Required"  checkbox, non-Admins willalways require permission to connect. So you have to make sure you're  authenticatingto this remote machine as an  Administrator not a non-Admin, or you will always requirepermission.
◦Second,
     this is exactly the functionality of Vista's UAC security model, which means even though you thinking you're logging in as an Administrator, you're  really not any longer. UAC splits your Access Token into two separate  parts, an Administrator portion and anon-Admin  portion. When you login, you always receive  the non-Admin portion of your token. Only when you request something
     that requires Admin rights will UAC prompt you for elevation, and only then will you receive  your full Administrator portion of your token (and only within that  specific window/process). Once that window is closed you're right  back to being a non-Admin again.


How can this be a flawed statement?
■First,
     all that's being done is transferring the same exact dwrcs.ini file to the Vistamachines that are on the  2000/XP/2003 machines.

 

■Second,
     You originally stated that this behavior with the UAC does not happen. Now you sayit does. I'm talking about UAC prompting. The desired result is that if I connect as an Admin, UAC should not prompt the user on the "remote" machine.

Bryan wrote:

 

Have the developers tried on Vista machines and KNOW that it works with UAC enabled?

YES. We have done extensive testing on Vista, and our entire support staff are all running Vistaon their machines as well, and we don't have any issues connecting to remote machines running Vista with UAC enabled without requiring permission.


So you are saying that if no one is sitting at the remote machine,you can remote control theVista machine,no problem? Well, I cannot because UAC is waiting for someone at the remote
computer to click "OK". On my end I see "Waiting for client to accept connection" dialog from MRC. After a while the connection times out with a "remote control was denied", as if someone at
the remote computer clicked "Deny".

Bryan wrote:Also keep in mind that only version 6.x of the software & Client Agent is supported on Vista.


Using version 6.6.2.1

Bryan wrote:I hope this helps.

not yet (grin)

 

Re: connecting to a vista pc it always requires users permission
by Roger on
Tue Dec 04, 2007 2:11 pm

 

Could have been a mistype,but in your last comment you say "Well, I cannot because UAC is waiting for someone at the remote computer to click "OK". On my end I see "Waiting for clientto accept connection" dialog from MRC." But, before you said it was MRC's prompt on the remote end waiting for OK. If it is UAC, then there is nothing MRC can do about it. One quick test would be checking to prompt in MRC and see if you get two prompts.

 

One thing to try is to see if in fact the ini setting/file you deploy actually got there. Maybe itwas unable to copy or at the time the option may have been unchecked, etc...although you deployed by msi, so hopefully that shouldn't be an issue. I'd still connect to it and say ok to the prompt, then go to view menu and look at the settings on the remote machine/server and be sure they match what you expect. Specifically, on mine I have- General Tab= Allow Encrypted Windows logon and Must have logon local rights...although you could try without just in case that account can't logon locally, etc. Then on Access tab I have Only Admin to connect and the bottom 3 checks. You can try turning off only admin to connect or Permission required check at the bottom and see if that makes a difference.


I haven't used it, but it sounds like from the description you can take off the bottom 3 checks and gain access at the logon/locked prompt since no one is logged on (which sounds like what you describe) it would then let you in. Non-Admin with a user logged in remote sounds like it always requires permission, and admin can be required if you have it checked in the Additional Settings Tab...so lots of layers of security there.


Last edited by Roger on
Tue Dec 04, 2007 2:17 pm, edited 1 time in total.


Re: connecting to a vista pc it always requires users permission
by Roger on
Tue Dec 04, 2007 2:16 pm


While we are on the options for the Non-Admin users...that had me confused initially at first too since that bottom section doesn't have a header saying these setting apply to Non-Admin, itjust gives a description and assumes you read the whole paragraph and realize the bottom 3 checks are for Other/Non-Admin accounts not specified above. The paragraph would also look
better if left aligned and indented in a little. I didn't get that creative in my photo though.

 

Re: connecting to a vista pc it always requires users permission

by mmenzie on
Tue Dec 04, 2007 2:18 pm

 

well i have to agree with slburke on this one. i used the MSI builder to build the client and ran iton my vista machine and i double checked, even triple checked all the settings before i built itand when i try and connect to my vista machine i see "waiting for permission" and sure enough if i walk over to my vista box it is still sitting there waiting for someone to accept or deny. i have done all the things in this post that was suggested.

 

Re: connecting to a vista pc it always requires users permission
by Roger on Tue Dec 04, 2007 2:55 pm

 

If you did what I just posted too, only other suggestion would be maybe post the ini that is on the actual Vista Box. That is, if it isn't selected to store settings in the registry, then you would need to export those.


Re: connecting to a vista pc it always requires users permission
by slburke on
Tue Dec 04, 2007 4:53 pm


Roger wrote:Could have been a mistype, but in your last comment you say "Well, I cannot because UAC is waiting for someone at the remote computer to click "OK". On my end I see "Waiting for clientto accept connection" dialog from MRC." But, before you said it was MRC's prompt on the remote end waiting for OK. If it is UAC, then there is nothing MRC can do about it. One quick test would be checking to prompt in MRC and see if you get two prompts.


What I was saying that on my end I see response from MRC "waiting for client to accept connection" (whatever the actual MRC message is). On the remote machine, the UAC prompt is waiting. All this meaning that I shouldn't see a prompt from MRC and the remote user shouldn't see a prompt from UAC.


Roger wrote:One thing to try is to see if in fact the ini setting/file you deploy actually got there.

 

I am manually placing the files on the remote computer since I can't do a "push" install because of UAC. So yes the ini setting/file is there.


Re: connecting to a vista pc it always requires users permission

by slburke on
Tue Dec 04, 2007 4:57 pm


Roger wrote:If you did what I just posted too, only other suggestion would be maybe post the ini that is on the actual Vista Box. That is, if it isn't selected to store settings in the registry, then you would need to export those.

Settings aren't stored in the registry in version 5 or 6 of Dameware anymore (right?)


Re: connecting to a vista pc it always requires users permission
by slburke on
Tue Dec 04, 2007 5:01 pm

 

Roger wrote:Then on Access tab I have Only Admin to connect and the bottom 3 checks. You can try turning off only admin to connect or Permission required check at the bottom and see if that makes a difference.

The options on the Access tab are a non-issue as Administrators are not affected by it, and there are no "NON-Admins" attempting to use the application in my environment.


Re: connecting to a vista pc it always requires users permission
by Roger on Tue Dec 04, 2007 5:19 pm


Is this the prompt you see? If so then follow the instructions there to get rid of it without turning off UAC.
http://www.computerperformance.co.uk/vista/ConsentPromptBehavior.htm

Other than that you are correct that the access Tab shouldn't matter if the user is in fact admin. The additional settings tab would matter though, so make sure it is good. If the remote PC is
giving the UAC figuring out why would be the best thing. I haven't done much with Vista yet for these and numerous other reasons...including a way documented on many sites for actually removing the admin account and completely locking yourself out. I have used this type of protection on other OS like Ubuntu and Suse, and Vista's copy is less than adequate. What exactly does the UAC box
want permissions to do anyway? MRC should be just doing a passthrough login and not needing settings change, unless for some reason when it asks if the account is amember of the admin group Vista thinks it is requesting permissions??? Post the text/screenshot of the box if possible. One thing if this is the case would be maybe trying the other options on the Access
tab like making a group for the account and selecting it as a group, so it isn't just testing for admin and causing the prompt.

If nothing else works, the link above sounds like it gives a Yes to All to the prompts. If it still asks for a password on the major stuff it would work for me and not have UAC disabled...

 

Re: connecting to a vista pc it always requires users permission

by slburke on
Tue Dec 04, 2007 5:42 pm

 

Roger wrote:Is this the prompt you see? If so then follow the instructions there to get rid of it without turning off UAC.
http://www.computerperformance.co.uk/vista/ConsentPromptBehavior.htm

 

That be the one... Now there is another link on that page something to the effect of "Behavior of the elevation prompt...." That has a section titled "Local policy - Elevate without  rompting" (Domain joined only). That looks promising, can someone try that out. I don't have any Vistamachines at the moment because of this issue, but would like to know if this works. BUT, itlooks like the only thing that can be done on a Vista machine NOT on a domain is to disable UAC altogether.

 

Re: connecting to a vista pc it always requires users permission

by mmenzie on
Wed Dec 05, 2007 8:19 am

 

Roger wrote:Is this the prompt you see? If so then follow the instructions there to get rid of it without turning off UAC.
http://www.computerperformance.co.uk/vista/ConsentPromptBehavior.htm

 

thats not the promp i am getting. i actually get the one from the dameware remote asking the user to grant permission for some one to remote in


Re: connecting to a vista pc it always requires users permission

by Roger on Wed Dec 05, 2007 12:26 pm


I don't know what else to say on this one. For the UAC prompt, it would be nice to see/know specifically what it is asking permissions for in the prompt, and did you try the registry key setting
ConsentPromptBehaviorAdmin to 0 to see if the box goes away? For the MRC prompt, if you are logging on with the admin account I'd verify the Additional Settings Tab on the Remote box...not your
machine or the default settings. Posting the actual ini file from the Vista box would be helpful too.

Other than that, Bryan mentioned they have all Vista machines in their environment and they worked. My only questions would be-
1. Are they all working with UAC on?
2. Are they all Vista Ultimate?
3. Were they tested in both a workgroup and NT/AD network?

If the answers to all 3 of those are yes, then it still sounds like a configuration thing. Going bya "I triple checked it" can't always be 100%. I can look at a piece of code I wrote for hours and never figure out the bug causing it not to work, but hand it over for a 2nd set of eyes to look at and they may find it in 2min. If the exact files/settings/msi file is used on all machines andVista is
the only one with problems, then it sounds like Vista needs tweaked.

Vista is a whole new beast and probably the worst initial releases M$ has made...yet people are bending over backward to support it. Both my anti-virus and firewall are pretty much useless and not getting any real updates for a month or more now just because they decided to supportVista and dropped all advanced features and any OS other than XP and Vista. They dumbed downa perfectly good piece of software just to be "compatible" with that garbage. In my opinion itneeds to be the other way around...they need to fix Vista and make/allow it to work properly. Until they do, there are lots of things to tweak and make it work.

 

Re: connecting to a vista pc it always requires users permission

by slburke on
Wed Dec 05, 2007 1:36 pm

 

Roger wrote:I don't know what else to say on this one. For the UAC prompt, it would be nice to see/know specifically what it is asking permissions for in the prompt, and did you try the registry key setting ConsentPromptBehaviorAdmin to 0 to see if the box goes away? For the MRC prompt, if you are logging on with the admin account I'd verify the Additional Settings Tab on the Remote box...not your
machine or the default settings. Posting the actual ini file from the Vista box would be helpful too.

Roger wrote:Other than that, Bryan mentioned they have all Vista machines in their environment and they worked. My only questions would be-
1. Are they all working with UAC on?
2. Are they all Vista Ultimate?
3. Were they tested in both a workgroup and NT/AD network?

 

don't forget the biggest question...Is there any interaction ATALL by the remote user?
Roger wrote:If the answers to all 3 of those are yes, then it still sounds like a configuration thing. Going by a "I triple checked it" can't always be 100%.

Again, in my case, all that was done was to take VALID configuration that is on every other machine in my environment and move it to a Vista machine. So I would say that it's definitely 100%.


Re: connecting to a vista pc it always requires users permission

by bryan on

Wed Dec 05, 2007 3:38 pm

 

Hey Everybody,
Many thanks for everyone's contributions on this post. I think we just need to take a step back here, and we should be able to get this resolved. Because I really want to help you get this resolved, and there is no reason you shouldn't be able to connect without requiring permission.

OK, from everything that everyone is including below this is definitely a MRC Permission Prompt and not a UAC prompt, and there are only two ways the MRC software will ask for permission.
1. Permission Required is enabled on the remote machine, either in the DWRCS.INI file or in the Registry.
2. You are connecting with non-Admin rights, in which case you will require permission.
That's it. There are no other settings to ask the user for permission.
With regard to non-Admin rights, I know you said there are no non-Admin users. However, you have to remember how UAC works, because all users (even Administrators) are treated as non-Admins under UAC. That is, except the "Administrator" account which is disabled by default underVista. The "Administrator" account is not UAC enabled, and therefore it's always considered an Administrator, with or without UAC.

You also stated below you took the same configuration from your other machines and applied itto this Vista machine. Does this mean you took your MSI file you created for NT/2000/XP/2003 and used it to install under Vista as well? Because that may be part of your issue. If you look in the MSI builder, Vista has it's own build because Vista is fundamentally different that these other MS Operating Systems when UAC is enabled. Just as an example, Vista no longer supports Interactive Services. So you MSI file for NT/2000/XP/2003 will install the MRC Service to Interact with the Console, whereas, if you create a Vista Build that flag is no longer set.

Also, which authentication method are you using to connect? Also since this is Vista, make sure the "Must have Locally Logon Rights" checkbox is not enabled under the Allowed authentication methods on the remote machine.
If this still doesn't resolve this behavior for you, please make sure you don't have any settings stored in the Registry on the remote machine. Because if the settings are being retrieved from the Registry, then the DWRCS.INI file will be ignored.

[HKEY_LOCAL_MACHINE\Software\DameWare Development\DWRCS\Settings]

If the "Use Registry for all Settings" value is set to dword:00000001, then your Client Agent settings are being retrieved from here instead. You can set it to dword:00000000 or make the necessary changes in the Registry for Permission Required.
Your feedback is greatly appreciated.

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


Re: connecting to a vista pc it always requires users permission

by Roger on
Wed Dec 05, 2007 4:12 pm

 

Ahh, so does the Logon Locally being off tell it to just check the group and not actually logon and try to test for admin since it will be a plain user in that case due to UAC? That sounds valid. I never noticed the Service was Interactive. I'm guessing that is to access the Task Tray menu. So, in Vista is it not possible to have the menu in the Tray then? I never had much luck writinga Service to be
Interactive, they usually end up crashing on Windows Shutdown.

 


Re: connecting to a vista pc it always requires users permission
by bryan on
Wed Dec 05, 2007 4:25 pm


Hey Roger,

Not exactly. Only the "Must be a member of .." features really check group membership. The software just does a different type of logon with or without the "Must have locally logon rights" checkbox enabled. For Vista, you basically don't want that checkbox enabled, however, the MSI builder should already take care of that for you, provided you select Vista as the Target O/S.

Also, I believe the "Interact with Desktop" setting in the Service Properties had more to do with acquiringthe screen information, not really the SysTray icon. For example, take a XP machine and reconfigure the Service to not Interact with the Desktop. Then when you connect you will just get a Black Screen in your MRC window. So we basically had to do things a completely
different way in Vista, but it actually works very well under Vista.

 

Best Regards,

Bryan Brinkman
Support Engineer

DameWare Development, LLC.
http://www.dameware.com


Re: connecting to a vista pc it always requires users permission

by auto on
Wed Jan 02, 2008 6:55 pm


You stated that it is a workgroup setup. Apparently VIsta security has an additional setting so that a matching local administrator username and password on both PCs does NOT automatically allow access to a remote administrative share. I haven't had a chance to test this but it may explain the issue you are experiencing.

Set - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy to 1(DWORD).

To do this:

- Click start

- Type: Regedit

- Press Enter

- Browse to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system

- Right-click a white area in the right pane

- Click New

- Click Dword Value

- Type: LocalAccountTokenFilterPolicy

- Press Enter

- Double-click LocalAccountTokenFilterPolicy

- Type: 1

- Press enter

- Restart your computer

Auto

 

Re: connecting to a vista pc it always requires users permission

by wcabello on
Sun Jan 27, 2008 7:55 pm

 

Hello Brian, It seems that this problem is an on-going problems with users connecting remotelyto Vista computers. I also have tried all of the suggestions and I have not secceeded yet either. The blue windows still pops up saying waiting authorization from the user (local person in that computer). I modified the registry as suggested, restarted the computer and it does not do the
trick either. Have you or anybody in Dameware can solve this issue once for all and provide afinal solution to their customers. Thanks

 

Re: connecting to a vista pc it always requires users permission

by bryan on
Tue Jan 29, 2008 6:50 pm

 

Hello wcabello,
Not really. I still have not been able to reproduce this behavior, and outside of this post I also haven't had any other users write to me in Support with this behavior on Vista.

However, I believe you also wrote to support directly as well, and the reason this is not working for you is because version 5.x is not supported on Vista. You must be running version 6.x of the software both locally & remotely in order to support Vista.

 

Best Regards,

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

 

Re: connecting to a vista pc it always requires users permission

by revolutn on
Thu Jan 31, 2008 12:28 am

 

OK.
I've read the entire thread, all 3 pages.
Here's what I can tell you.
I made MRC work with a Vista home premium pc tonight,without doing anything to UAC at all.
Here's what I did.
I downloaded the latest latest 6.7.0.2.

I used MSI builder to make an installation package for Vista32bit.

I chose PROPRIETARY CHALLENGE RESPONSE for authentication type. put in a user name and password (since I wouldn't have an account on the target remote clientpc)

I emailed the msi package to the recepient and they ran the installation.

I configured the router to pass traffic on 6129 to their nat'd lan ip.

I told the end client to be ready to give me permission if they were prompted.

I put in their public IP address in the host window. changed the authentication type to proprietary and supplied the credentials i created above.
clicked connect.

On the remote side, the client accepted the UAC request.

I was connected without further ado or incident.

Now, it may well be that 6.7.0.2 addresses some issue that was present in 6.2.x.x, but this was not as difficult as I feared after reading this thread.

I will confirm later if I can eastablish subsequent unattended connections at a later time, but I've disconnected and reconnected several times in the same session, boot cycle without the user being prompted to do anything.

Hope this information and my experience helps some of the struggling peeps on this thread.

Rev

 

Re: connecting to a vista pc it always requires users permission

by bryan on
Thu Jan 31, 2008 4:35 am

 

Hi Rev,

Many, many, many thanks for your feeback. This is exactly how it's supposed to work,and exactly how it has worked for all6.x versions of the software, without having to alter UAC at all. So, like you, I'm not sure why others are having so much trouble, because it should not be that difficult.

However, I did find out why the previous poster had issue with permissions on Vista, and it was because he was running version 5.x of the software,which is not supported on Vista.

Thank you again for posting this information about your experiences. It's nice when someone other than the support guy can back this upas well .

Best Regards,

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

 

Re: connecting to a vista pc it always requires users permission

by bobbyb on
Mon Mar 17, 2008 7:50 am

 

I've also gotten this to work with Vista Home Premium, but as a heads up, I have seen what you are talking about. It matters what logon method you are using, use the proprietery challenge/response method,not the windows logon. If you use the other method, the administrative rights come into play. If you use the proprietery method, it doesn't have any issues.

Also, when I set it up, I could connect without any UAC popping up. Period. However, if I chose another authentication method, it would pop up the UAC. As long as you do the right method, you shouldn't have a problem.

Install/Uninstall software remotely

$
0
0

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


by INFOSDEA on
Thu Jul 19, 2007 4:04 am


A great feature would be the possibility to install/uninstall software remotely !

 

Re: Install/Uninstall software remotely

by bryan on
Mon Jul 23, 2007 8:25 am

 

I agree, this would be a cool feature, and we have actually talked about adding this functionality into the software. I just cannot make any promises when or if this feature can be added.

 

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


Re: Install/Uninstall software remotely

by odin568 on
Tue Sep 11, 2007 1:41 am

 

yes this would be cool!
would it also be possible to search in all added clients of dameware favorite-list for a softwareand uninstall it automaticly - like google earth, toolbar, ......
this would save us much time at work

 

Re: Install/Uninstall software remotely

by groupesm on
Mon Nov 24, 2008 3:21 pm

 

this would indeed rock

   
Re: Install/Uninstall software remotely

by Marty on
Wed Nov 26, 2008 12:09 pm

 

Duly noted!
Thanks for the input.

 

Marty Bonvillain
Support Staff
DameWare Development, LLC.
http://www.dameware.com


Re: Install/Uninstall software remotely

by creative on
Mon Feb 23, 2009 3:31 pm

 

good idea


Re: Install/Uninstall software remotely

by mmenzie on
Thu Sep 02, 2010 8:31 am

 

hello all. i have been a faithful user of Dameware for years and i love it. i see this thread has not been updated in over a year. i would like to revive this thread and also request that this be added as a feature. i as i type this am searching for a way to uninstall a program from a users computerremotely and silently. i use dameware for everything else i think i should be able to use it for that too... but alas... we can't.

Please oh please, mighty dameware developers.... please add this funtionality!!!! and if anyone out there has a suggestion on what i can do while i wait for dameware dev's to
do this to do what i am requesting now.... please let me know.

Thanks
Mike

 

Re: Install/Uninstall software remotely

by dane on
Tue Sep 28, 2010 6:59 am

 

Having the a ability to remotely install and uninstall software would be a definite plus for Dameware NT. In fact, as a new user of Dameware NT, I was suprised to find that this function was not included in the suite of tools that the program offers.

Right now, I have to use a freeware program (ManagePC) to remotly install/uninstall.

 


Re: Install/Uninstall software remotely
by j0shu4 on
Tue Nov 09, 2010 3:40 pm

 


Actually, from what I've seen in my very limited playing around with the demo, it does have that ability through System Tools. Basically it boils down to using psexec in a custom made script, which is called from the System Tools menu. We use Hyena where I work (which does this in the same manner), but we're looking into purchasing NTU. This was one of our key
requirements and it can do it. Now doing this on multiple machines at once, instead of one by one, I'm not sure if it can do that. I haven't found a way to run a System Tool against multiple PC's yet.

 


Re: Install/Uninstall software remotely
by mmenzie on
Tue Nov 09, 2010 3:51 pm


well there are people (myself included) that do not know how to write custom scripts like you mentioned. so having a tool that can do that without needing that knowledge is what i think i am asking for here.

 

Re: Install/Uninstall software remotely
by mro on
Wed Nov 10, 2010 4:30 am

 

I'd suggest that DameWare implement the feature to select multiple machines and run System Tools script against them in a future version of DNTU and above from that add a section to the website (or forum) where users can share their System Tools scripts.

 

Re: Install/Uninstall software remotely


by j0shu4 on
Wed Nov 10, 2010 10:40 am

 

@ mmenzie:

I realize that. What I was doing was pointing out that there is a way before it is implemented. Considering the age of this thread, it's been a while and I was wanting to help. The scripts that I mentioned are bat scripts, which is pretty easy to learn. Let me give you an example of how to install Firefox...

CODE: SELECT ALL


Cd Cd Windows\System32

psexec \\%1 -u username -p password -c -s -f
\\server_name\share_name\FirefoxSetup3.6.12.exe -ms


There's only 3 lines in this code. The 4th line is wrapped and should only have a space between -f and \\.

All you need to do is have psexec copied into your c:\windows\system32 folder. The hardest part about this is learning what switch (-ms in this case) allows for a silent install. It changes with each exe/msi.

 


Re: Install/Uninstall software remotely

by j0shu4 on
Wed Nov 10, 2010 10:43 am

 

mro wrote:I'd suggest that DameWare implement the feature to select multiple machines and run System Tools script against them in a future version of DNTU and above from that add a section to the website (or forum) where users can share their System Tools scripts.

That would be an awesome idea. One thing you mentioned mro, and something that I'm trying to figure out... Can you not run system tool scripts against multiple machines? I've been trying to figure this out and can't seem to get it to work.

 

Re: Install/Uninstall software remotely
by mro on
Thu Nov 11, 2010 4:46 am

 

j0shu4 wrote:That would be an awesome idea. One thing you mentioned mro, and something that I'm trying to figure out... Can you not run system tool scripts against multiple machines? I've been
trying to figure this out and can't seem to get it to work.

Currently this doesn't work. I think DameWare has to modify DNTU in two ways:
- support multiple selection in the browser pane and
- store each selected computer in an array (for support of the %MACHINE%variable)

Hopefully this can be implemented easily or is already implemented in the next version of DNTU...

Regarding my suggestion to share different System Tools scripts I'd like to know what the mods think about that. Awaiting your kind reply!


Re: Install/Uninstall software remotely

by mmenzie on
Thu Nov 11, 2010 8:25 am

mro wrote:


j0shu4 wrote:Regarding my suggestion to share different System Tools scripts I'd like to know what the mods think about that. Awaiting your kind reply!

i think that is an excellent idea and should be implemented on the forms!!!! great idea!!

 

Re: Install/Uninstall software remotely

by Hormel on
Fri Jul 29, 2011 1:15 pm

 

Agreed awesome idea!

Icon will not show

$
0
0

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


Icon will not show
by ti0101 on
Wed May 21, 2008 3:56 am

 

hi ya
i am having these issues:

on a client that i am trialing the software with

any ideas what is causing it, and how to resolve it?

 

Re: Icon will not show

by ti0101 on
Wed May 21, 2008 3:57 am

 

edit -
says
"The MRC Tray Icon was unable to
communicate with the MRC Client Agent. The Client Agent Service may not be running?
MRC tray icon process will now exit.

 

Re: Icon will not show

by Marty on
Thu May 22, 2008 10:46 am

 

Hi ti0101,
This is a normal error if the MRC SysTray icon (DWRCST.EXE) process is unable to communicate with the MRC Client Agent Service (DWRCS.EXE)for any reason. What version of the software application are you using and what version of the client agent service is installed and running on the remote machine?

What Operating System and Service pack level is each machine (local and remote) running, and how did you install the client agent service, with an MSI package or "on the fly" when you first attempted to connect?

Thanks for your feedback, it is appreciated.

 

Marty Bonvillain
Support Staff
DameWare Development, LLC.
http://www.dameware.com

 

Re: Icon will not show

by stefstew on
Fri Oct 17, 2008 9:59 am

 

I am getting the exact same error on several of our machines. Our users are great at sending emails when they get errors and this one is very annoying. Operating system WIN XP, Service Pack 2, agent service created "on the fly"....

 

Re: Icon will not show

by astr0wiz on
Wed Oct 29, 2008 9:36 am


A.Hello. I have been using the Mini Remote Control app for several years and I just updated to version 6.8.0.1. During a test, I encountered this same problem.

Now, for my company, this is a HUGE issue. I rely solely on the Mini Remote Control to test and fix remote kiosks (small PCs that run Windows and Java apps). With this problem, I now cannot use the Dameware product, because these kiosks are visible to our customers and a warning popup window at every kiosk would certainly end my tenure at this company. I'd like to stay.

So here is the vital information:

1) All the remote machines have an earlier version of the Mini Control Client.

2) All the remote machines are running Windows XP SP2.

3) All the remote machines were given the client "on the fly".

4) The test machine was upgraded to 6.8.0.1 "on the fly" and it shows this problem.I have not tested this on a client after using the MSI. I wasn't sure if the MSI would properly upgrade the
client app.

My company is very large and I cannot afford to use the upgrade to connect to a remote kiosk that will be seen by a customer. For this reason, I am going to send an email directly to Dameware support in the hopes that an answer can be provided as quickly as possible.

 

Re: Icon will not show

by bryan on
Mon Dec 01, 2008 12:36 pm

 

Update:
This customer had written directly to our Support staff as well, and as it turns out these were Kiosk machines and there were running a Shell Replacement call EZSHELL, which most likely didnot have a "System Tray" like Windows Explorer does.

They had also upgraded from an older 5.x version of the software, which means they also needed to obtain new licenses that were compatible with version 6.x of the software, and then register their local copy of the software using their new v6.x licenses.

This is significant because they were currently running in Evaluation Mode which means that all the notification features within the MRC Client Agent Service on the remote machine will be turned on (i.e Notify on Connection dialog, MRC SysTray icon, & MRC SysTray Icon's right-click menu) when they connect, regardless of the Settings within the MRC Client Agent Service on this remote machine. Disabling those notification features is a limitation while the software is running in Evaluation Mode.
Therefore, since this replacement SHELL did not have a SysTray, but our SysTray icon was trying to be displayed, this caused the error dialog to be displayed.

The resolution in this case was to register their local copy of the software,then make sure they disabled the MRC SysTray icon within the Client Agent on the remote machine, since there
was no System Tray in this replacement shell.

I hope this helps.

 

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

 

Re: Icon will not show

by bryan on
Tue Dec 02, 2008 10:53 am

 

Another Update:
Another user wrote to support with the same exact error, and they were also running a Shell replacement product. Their product was called PowerFuse, which also does not have a System Tray.
Once they hid the MRC System Tray icon by disabling the "Enable SysTray Icon" setting within the Client Agent Service they no longer received this error message.

 

Best Regards,

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

 

Re: Icon will not show
by chicken5948 on
Thu Dec 04, 2008 11:41 am


I am getting this same message on a client PC. They are running Windows XP SP3, we are using DW version 6.8.0.1.

I have removed the service from this PC, but the error continues. Any thoughts?


Re: Icon will not show

by bryan on
Thu Dec 04, 2008 2:49 pm


How did you remove the Service? Manually via the instructions on our website? Via the Mini Remote Control program's interface? Or possibly by some other means outside of our software?

If the "DameWare Mini Remote Control" Service is truly no longer listed as an installed Service, then see if the following key still exists in the Registry. If this key still exists after the Service has been properly removed, then you can just delete it:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
"DameWare MRC Agent"="C:\\Windows\\system32\\DWRCST.exe"

 

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

 

Re: Icon will not show
by IMMTHelpdesk on
Thu May 07, 2009 8:48 pm

 

Hi,
We are using DameWare 6.8.1.4 having since upgraded from a previous version and are getting complaints from clients saying that they too are getting the same error message:

The MRC Tray Icon was unable to communicate with the MRC Client Agent. The Client Agent Service may not be running?

MRC Tray Icon process will now exit.
[Initialize Desktop]

We have 5 registered copies of this software for each of administrators (of which I am one) and have been installing / upgrading the client service as we have needed to remote to their machines. It appears to only be a problem on machines that are running the new verison of the client serivce.
I have noticed the following:
- I have logged onto the services MMC and the MRC service is running correctly.

- The error message only appears when the users first log onto their machines.

- The error does not affect any type of usability of Dameware when we are trying to log onto affected machines.

- We are not using any kind of shell replacement software.

- Our users are running Mixed XP SP2 & SP3 and Windows Vista 32Bit Business.

This isnt a large issue for us at the moment as the software still works fine, it is mainly an annoyance for the users, that we need to get resolved.


Re: Icon will not show

by TerraMedics on
Sat Aug 15, 2009 2:44 am

 

Did this issue get resolved. It's happening with with 6.8.1.4 on Vista SP2 when logged in as a regular user with admin privileges. The MRC tray icon disapears and transferring files to remote clients does not work unless logged in as the main administrator. This defies the purpose of Vista security. changing the MRC service log in credetnials did not help. Although the icon issue may not be critical, the file transfer issue is definitely a trunoff since the user must log in as administrator to be able to send files to remote clients.


Thanks,
Denise

 

Re: Icon will not show

by theviper21 on
Wed Oct 28, 2009 7:41 am

 

I am curious if this has been resolved as well. I have a lot of users that are running XP SP2/SP3 and get the error on startup. We have around 100 licenses for DW MRC and I am running the latest version of the client, 6.8.1.4.
The only way I have gotten the error to stop on a user's PC is to remove the remote control utility from startup. However, every time I reconnect it gets added back to startup.
Any further follow up on this from support would be appreciated. Thanks!

Viewing all 25 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>