Using DameWare Development software in conjunction with Windows Vista & Server 2008.

Honestly, there are many users that are going to run into strange issues trying to using the software under Vista, most often because they are not familiar with Microsoft's new UAC (User Account Control) Security Model in Vista. So you are going to run into these same exact issues no matter what remote administration software you use, and even when trying to access these remote machines via your Operating System itself (completely outside of our software). Did you try to access the Admin$ share on this remote Vista machine via a Command Prompt, within your O/S (i.e. Net Use \\RemoteMachine\Admin$) ? Because you will receive the same exact behavior. Also, just FYI, the only reason RDP works is because RDP's Client Agent is already pre-installed within the Operating System itself. If you had to push out it's Client Agent the you would run into these same issues with authentication.

Therefore, you will really need to take some time to learn more about Microsoft's Vista Operating System, the new Windows Firewall in Vista, and also the new User Account Control Security Model included in Vista. Otherwise you will continue to run into problems trying to access any remote Vista machines, with or without our software. But what you also need to understand is that DNTU & MRC are Administrative Tools, and therefore they should be run using Administrator rights. However, here are some temporary work-arounds:

1. Use "the built-in Administrator" or "Domain\Administrator" account to remotely install, remove, start, or stop the MRC Client Agent Service on these remote machines (or even connect). These two specific accounts are not UAC enabled, and therefore are not affected (or altered) by the new UAC Security Model.

2. Pre-install the MRC Client Agent Service on these remote Vista machines.

6.x versions prior to 6.2 included some temporary MSI packages within your DameWare installation directory on your local machine that you can send to the user on the remote machine, which will automatically install version 6.x of the Mini Remote Client Agent Service on their machine. The files are DWRCS95.MSI (95/98/Me), DWRCS32.MSI (NT/2000/XP/2003), & DWRCSVista32.MSI (Vista 32-bit). These were only temporary MSI packages and would only install with default settings.

However, version 6.2 and above now includes the DameWare Mini Remote Client Agent MSI package builder, which allows you to create custom MSI packages to perform the install of the Client Agent and also include and customized DWRCS.INI & Registry settings.

Also, just FYI, after you install v6.x of the MRC Client Agent Service on the remote machine, once the Agent starts up it should automatically create a port exception in the Windows Firewall under Vista (or XP) for the specified TCP port used to make a connection (default is TCP 6129). But make note this does not open the ports required to remotely install, remove, start, or stop the MRC Client Agent Service, only the port used for communication. In order to remotely install, remove, start, or stop the MRC Client Agent Service on a remote machine running Vista, you would have to enable & configure the following Windows Firewall Exceptions: UDP 137(Name), UDP 138 (Datagram), TCP 139 (Session), & TCP 445 (Direct Hosting), and also the Remote Administration Exception. You also have to make sure you configure these exceptions under the correct profile as well: Public, Private, or Domain. But you would also have to temporarily disable the new UAC Security Model under Vista as well.

3. Temporarily disable the Windows Firewall, and also the UAC Security Model under Vista (which will require a reboot). Then you should be able to access the Admin$ share on the remote machine. Once you have access to the Admin$ share on the remote machine within your O/S itself, you should also be able to remotely install, remove, start, or stop the MRC Client Agent Service as well.

Requirements & Important Notes:

1. Version 6.0 or above of the NT Utilities or Mini Remote Control software is required to connect to a remote machine running Windows Vista.

2. The Mini Remote Client Agent Service must already be installed & running on the remote Vista machine. This can be done via the new MSI package for the Client Agent Service. Otherwise UAC must be disabled to remotely install, start, stop, or remove the MRC Client Agent Service under Vista.

Known Issues:

1. When attempting to connect to a remote machine running Vista, you may receive a Winsock 10060 error, if the machine has gone into Power Save or "Stand-by" mode. This is actually a known issue with Vista, due to it's new Power Management features, and it's default Power Management settings. These new Power Management settings actually shut down the whole machine, including the NIC, and our software has no way to wake it. You can also search the Net about Vista and Power Management and you will find tons of information about this behavior.

Therefore, as a possible work-around, you would either have to:

- Physically move the mouse or hit a key on the keyboard on the remote machine itself. Then wait for the NIC to wake up again.

- Or you may be able to enable the "Allow this device to wake the Computer" setting on the Power Management Tab for the properties of the NIC on this remote machine (see attached).

- Or simply adjust the default power management settings for your Vista Machines, so the NIC isn't turned off.

Also, just FYI, if you search out on the internet about Vista and Power Management, you should fine hundreds of articles with users having nightmares with these new power management settings in Vista.

2. Connecting to a remote machine running Vista using a Mirror Driver will cause the Vista WDM to temporarily disable Aero on the remote machine. This will place the remote machine in Vista Basic mode. Unfortunately, this behavior is out of our control and is a feature of the Vista Operating System itself. However, the WDM will re-enable "composition" upon disconnecting.

Microsoft also recommends the use of Mirror Drivers under Vista, to ensure maximum access to the O/S and underlying applications. Mirror Drivers are basically Kernel Mode Video Drivers, and they receive a copy of the Display without interacting with the actual desktop. In other words, Mirror Drivers don't have to scrape the screen. "Chained drivers" sit between the computer and the display and can alter information before it is received by the display.

3. UAC ( User Account Control) security Model.

4. Windows Firewall with Advanced Features configuration.

5. The Warning Border options in MRC are not supported under Vista, and will be disabled.

6. Reverse Connection from Vista when Client Agent running as an Application (does not matter if RunAs Admin). Administrator will not have the ability to answer any UAC prompts. Client Agent must be installed as a Service for this to work.

7. Microsoft Windows Network portion of the Broswer may be blank when running the software on Vista, due to blocked ports, etc... (UAC & Firewall)

8. DNTU's Shutdown View may fail with a 1300 error under Vista "http://blogs.msdn.com/aaron_margosis/archive/2006/01/27/518214.aspx" "ERROR_NOT_ALL_ASSIGNED" Not all privileges or groups referenced are assigned to the caller. SeShutdownPrivilege not held in user part of your token. Use RunAsAdmin or Login As Administrator

9. DNTU's Shutdow View many not show programs & logged in users. Resolved in v6.4 and above. Requires new version of DNTUS26.EXE on remote machine.

10. "Net Send" and the "Messenger" Service have been removed in Vista. Therefore, DNTU's Net Send View will not work under Vista (Error 50: Not Supported)

11. Shell Menu issues

12. Auto-tuning (throttling) between Vista and 2003 Server could cause Vista to act slow.

http://robgarrett.com/cs/blogs/software/archive/2006/12/31/vista-firefox-2-slow-network.aspx

Note, turning off auto-tuning on the server will not produce undesirable performance. Up to recently, most (if not all) clients connecting to Windows 2003 did so without requesting auto-tuning. By default, Windows 2003 will not enable auto-tuning unless it is requested by the client - Vista!! Disabling auto-tuning with this registry change will assume XP like behavior.

The synopsis is that their appears to be a problem with Vista being too smart for it's own good, with the addition of the "Receive Window Auto-Tuning Level" setting in the TCP/IP stack. Disabling this setting fixed the timeout problem in FF2 and Windows Live Writer on my machine.