VNCScan Network Troubleshooting (Part 1)
By Bozteck
Introduction
VNCScan is a powerful tool that can you can use to administer most aspects of computer management. The vast majority of our feedback says that we’ve done a great job so far of making the tool as intuitive and easy to use as possible for a program with this large of a feature set. We’ve looked at how competing products have bloated their options to almost usability and have been trying hard not to let that happen to VNCScan.
With that being said, there are some common pitfalls that you can run into with any application that needs to access remote computers in an administrative role and this article series is here to help you though some of the most common of them.
If you have a suggestion for this series on VNCScan Network Troubleshooting, please leave a comment. I read them every day.
Access Denied
This is probably one of the most common support requests that we see here. There are a lot of causes for getting an “Access Denied” error when deploying VNCScan, running scripts, or performing the many other remote Windows management tasks. Some of these may seem like a no-brainer to you while others may be unexpected.
Set your Administrative account in VNCScan.
Let’s start by making sure that you have supplied Administrative credentials to VNCScan for it to use when connecting to remote computers. Even if you are currently logged into your computer as a Domain Admin, it’s still a good idea to tell VNCScan what username and password to use when running scripts because it needs to pass those credentials to commands that don’t necessarily run under the context of the currently logged in user.
If you would like to use your domain admin username/password, the best place to put this into VNCScan would be the main program preferences.
You can fine tune this by overriding this username and password in the group properties as well as the individual computer properties.
Multiple Connections Error 1219
This problem may be affecting your ability to log in even if you don’t see the actual error message. You may simply get something that says “Access Denied” when in reality, it’s happening because you’ve already logged into the remote workstation with an account that doesn’t have administrative access.
Here’s how to test that:
- Open a Command Prompt window on your computer
- Type:
NET USE \\ComputerName\c$ /user:administrativeaccount password
Replace ComputerName with the name of the remote computer
Replace administrativeaccount with your administrator username
Replace password with your actual password - Hit Enter and make note of the result
If you get an Access Denied, then the username that you are using is not administrative on the remote system. You’ll need to stop there and resolve that problem before moving forward. If you get an error that reads “Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again”, you have already connected to a shared resource on that remote computer using a username other than the one that you are attempting to use with VNCScan. You can see your list of connections by switching back to that Command Prompt window and simply typing NET USE then hitting Enter. That will show you something like this: U:\>net use Status Local Remote Network —————————————————————————– If the above connections were made with my normal user account and I try to deploy VNC to \\dell_200, I will likely get denied access even though I am supplying VNCScan a domain admin account. This is simply a limitation of SMB connections in Windows. Lucky for us, there is a work around for this problem. As it turns out, Windows only keeps track of this login-to-workstation relationship on a per-computername basis. This means that you can simply re-authenticate with the remote computer using the IP Address instead of the hostname and it will let you connect twice to the same computer with different credentials! We’ve placed a checkbox just for this in VNCScan. It’s in the main program preferences right here: As with most of the settings in VNCScan, you can override this in the group properties as well as the individual computer properties.
New connections will not be remembered.
OK U: \\dell_200\Steveb Microsoft Windows Network
OK W: \\dell_200\Apps Microsoft Windows Network
OK X: \\dell_200\Groups Microsoft Windows Network
OK Z: \\dell_200\express Microsoft Windows Network
Other tricks around this include assigning multiple DNS names to a computer on your DNS Server or simply using the /DELETE switch for NET USE to delete the preexisting connection. NET USE /? will give full details on how to use this command.
Conclusion
Well, that’s it for this article. In the next article, we will discuss firewall ports and other network related connectivity issues that may come into play.
I look forward to reading all of your comments and suggestions for this topic.
Data Files, Folders, and Locations
By Bozteck
The recent changes in VNCScan has revealed some confusion regarding the data files, their locations, and what they all do. For a historical primer, you may want to start with this blog post.
Key Data Folders
The data files are stored in three key folders;
- Data – Stores all of your program settings, group settings, and computer settings.
- Jobs – Stores all of your remote scripts. Each script job has a subfolder named after that job. That subfolder contains all of the files required to push and execute that job on a remote computer.
- Profiles – Stores all of your VNC deployment profiles. Each deployment profile gets a subfolder named after it.
- The Root
- All three of these key folders must be stored with in the same Root folder. By default, the Root folder is “My Documents\VNCScan”.
- The first time that VNCScan runs, it checks the registry key “HKEY_CURRENT_USER\Software\VNCScan\SettingsDataPath” for the path to the root location.
- If that registry key holds no data or if the path doesn’t exist, it will create the required folders at the default location and start fresh with new data.
- The Key Files
Both of the following files must reside in the Data folder:
· Settings.xml – This file holds all of the initial settings for the console. This file stores anything that is global to the application.
· Groups.xml – This holds all of your group names along with their settings. You will find XML files in the same folder named after the group names, also. These files hold the computers and their settings.
New Ping Features in 2009.4.9 Release
By Bozteck
We’ve had a lot of request for the ability to automatically reconnect to computers when they are rebooted. A majority of the requests were resolved with the implementation of the background scanner and the actions that can be performed when the scanner detects that the computer is alive.
To take this a step further, we’ve modified the ping window that happens when you right-click a computer and choose “Ping Computer”. Instead of just opening a command window with the standard ping command running, we’ve designed our own. We’ve done this in order to bring you an exciting new feature – automatically running commands or connecting when a computer responds for X number of consecutive pings.
Here’s a quick video showing how: http://screencast.com/t/CqJI7YhE
Download the latest version here!
More False Positives from McAfee
By Bozteck
McAfee Antivirus is falsely detecting VNC remote control software as a malware and deleting it upon detection. This is causing a major problem for a lot of remote management tools that rely upon this popular open source software to operate.
If you are using McAfee on your network, you can use the following detection log as a checklist of files that need to be added to your “exclusion list” inside your antivirus properties.
You may also want to look into your McAfee settings for ways to change the default action from DELETE to LOG. We’ve notified McAfee of this problem and are awaiting a response. If this problem is affecting you, please contact them at vendor_questions@mcafee.com.
9/19/2008 11:30:01 AM Scan Started BMSANWS4LZ13D1\SYSTEM (managed) VirusScan 8.5 on demand friday scan
9/19/2008 11:36:51 AM Deleted SYSTEM C:\FASTPUSH\VNC7\REALVNC4\LOGMESSAGES.DLL RemAdm-VNCView(Remote Admin Tool)
9/19/2008 11:36:51 AM Deleted SYSTEM c:\fastpush\vnc7\realvnc4\logmessages.dll RemAdm-VNCView(Remote Admin Tool)
9/19/2008 11:36:52 AM Deleted SYSTEM C:\FASTPUSH\VNC7\REALVNC4\VNCCONFIG.EXE RemAdm-VNCView(Remote Admin Tool)
9/19/2008 11:36:52 AM Deleted SYSTEM c:\fastpush\vnc7\realvnc4\vncconfig.exe RemAdm-VNCView(Remote Admin Tool)
9/19/2008 11:36:52 AM Deleted SYSTEM C:\FASTPUSH\VNC7\REALVNC4\WINVNC4.EXE RemAdm-VNCView(Remote Admin Tool)
9/19/2008 11:36:52 AM Deleted SYSTEM c:\fastpush\vnc7\realvnc4\winvnc4.exe RemAdm-VNCView(Remote Admin Tool)
9/19/2008 11:36:52 AM Deleted SYSTEM C:\FASTPUSH\VNC7\REALVNC4\WM_HOOKS.DLL RemAdm-VNCView(Remote Admin Tool)
9/19/2008 11:36:52 AM Deleted SYSTEM c:\fastpush\vnc7\realvnc4\wm_hooks.dll RemAdm-VNCView(Remote Admin Tool)
9/19/2008 11:36:53 AM Deleted SYSTEM C:\FASTPUSH\VNC7\ULTRA\WINVNC.EXE RemAdm-VNCView(Remote Admin Tool)
9/19/2008 11:36:53 AM Deleted SYSTEM c:\fastpush\vnc7\ultra\winvnc.exe RemAdm-VNCView(Remote Admin Tool)
Error: Could not write to [path]\vncscan.cmd
By Bozteck
We’ve had a few reports of the error:
Error writing to “C:\users\[username]\appdata\roaming\bozteck\vncscan console.net\2008.8.6.231\vncscan.cmd
This error occurrs when the beyondexecv2.exe is missing from the program folder. The quick way to fix this is to do an add/remove of vncscan and then run the setup again.
The manual fix for this is to copy the beyondexecv2.exe file from c:\fastpush\vnc7\utils folder into the “C:\Program Files\Bozteck\VNCScan Console .NET” folder.
Error: Multiple connections to a server or shared … are not allowed.
By Bozteck
You may get an error stating: “Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed” when deploying VNC to remote computers or running scripts remotely.
Information
This error goes way back to the early days of Windows networking and it’s shameful that Microsoft hasn’t corrected it, yet. A Windows computer can connect to a network resource such as a remote share only once with a single set of credentials.
For example, if I log onto the domain as bozteck\steveb and map a drive to \\server1\share1 using that account, I can not later issue a command to connect to \\server1\share2 supplying alternate user credentials in the command line. My computer can only authenticate me against \\server1 once. If I try, I will get the error above.
The Work Around
There’s a simple way to trick Windows into thinking that \\server1 is a completely different machine, allowing you to authenticate against it a second time. If the IP address for \\server1 is 10.1.1.1, you simply reference it by that IP address of \\10.1.1.1\share2 and pass it the set of credentials required to connect. Windows treats \\server1 and \\10.1.1.1 as completely different machines!
You can do this in VNCScan in a few locations depending on the scope that you wish to apply. Most people just do it globally in the main program preferences.
There’s an option there labeled, “Use IP address instead of HostName”. Checking this box will allow you to get around this error. There is a similarly worded checkbox in both the group properties and computer properties.
Maybe some day Microsoft will widen up this limitation but until then, this should get you by.
Disabling Firewalls for Management
By Bozteck
I’ve had a lot of requests for a way to disable XP firewalls on the network or at least open up the required ports to remotely manage the computers. If your workstations are protected by a NAT translating router with a decent firewall built into it, there is typically little need for the XP desktop firewall to be running on them.
If you have the XP firewall enabled, there’s very little that you can do in the way of remote management for these PC’s. Fortunately, there are was to automate the configuration of the XP firewalls on your network depending on what type of a network you are using.
Login Script Method
The easiest way to do this is with a login script. If your company is using a directory services such as Novel or Active Directory, you can create a script that runs each time that a user logs in. You can use this script to open the required firewall ports.
We run into a problem, however, if the user that is logging in does not have local administrative rights on his PC. This is required to modify the settings. For this, we can employ a nice piece of freeware called CPAU. Using this tool, you can do a run-as style command to make it go. Alternatively, you can use a tool such as Admin Script Editor to compile your script into an executable that runs under a specific security account. There are other tools that can do this and feel free to add them in the comments section if you would.
Active Directory Startup Script Method
You can also run the script using Active Directory’s group policy for the machine account. This script runs under the context of the machine’s system account and does not need to be elevated by tools such as CPAU. You can do this in the Group Policy Editor under “Windows Settings => Scripts => Startup”.
The following is a script that will open the required ports on the XP firewall:
netsh firewall set portopening udp 445 WindowsNetworking enable all
netsh firewall set portopening tcp 139 WindowsNetworking enable all
netsh firewall set portopening udp 137 WindowsNetworking enable all
netsh firewall set portopening udp 138 WindowsNetworking enable all
netsh firewall set portopening tcp 5900 VNC enable all
netsh firewall set portopening tcp 5800 VNC-HTTP enable all
Group Policy Method
You can set these options using Active Directory’s Group Policy, also. You can access this in the Group Policy Editor by navigating to “Computer Configuration => Administrative Templates => Network => Network Connections => Windows Firewall”.
Extra Notes
As a side note, if you choose to use a scripting tool such as Admin Script Editor to compile your script, you can also choose to distribute it directly to the end users so that they can execute it themselves.
Make sure that you also disable Simple File Sharing on the remote computers. That can be just as much of a barrier to remote administration as the firewall. I’ll make a post about that one soon.
Error When Scanning Groups
By Bozteck
The above error was being thrown for some users when scanning for VNC in certain groups. This was happening due to a bug in the module that checked to see who was logged into the remote computer.
This has been fixed and a new release had been placed at http://www.vncscan.com/vs/download.htm
Categories
- Announcements (8)
- Backup (1)
- Blog (2)
- General (9)
- how-to (19)
- howto (2)
- podcast (1)
- Polls and Opinions (3)
- Releases (14)
- Support (1)
- Troubleshooting (8)
- Uncategorized (12)
- Updates (2)
- Videos (3)
- VNC Deployment (1)
- White Papers (1)



April 3rd, 2011
