The latest version of Bozteck VNCScan can deploy UltraVNC 1.1.8 to computers on your network running Windows 8. To accomplish this, we’ve added a new version in your list of profiles named “UltraVNC 1.1.8”.
The UltraVNC 1.1.8 version was specifically designed for Windows 8 so it should not be deployed to Windows 7 or earlier. For those version, you could follow the same steps in this article but choose “UltraVNC” instead.
Step 1 – Create A Profile
- From the main program window, choose “VNC Deployment Editor”
- In the Bozteck VNC Deployment Profile Selector, click the “New Profile” button.
- In the Bozteck VNC Deployment Profile Editor, give the profile a descriptive name, select UltraVNC 1.1.8 from the dropdown shown below and set the server password that you would like with this deployment profile.
- If you would like to add encryption or include Windows authentication with this deployment package, you can do so under the “UltraVNC Settings” tab.
- Press “Save” and close back to the main VENM Console window
Step 2 – Deploy Your Profile
- If there are already computers in a managed group, you can select one or more. If this is a fresh install of VNCScan, you can either fill a managed group with computers from a scan or you can add computers manually from the deployment tool. Either way, you would click on “Deploy VNC” to get started.
- Make sure that the desktop firewall is OFF on the remote computer. Firewalls will prevent the console from connecting to the LAN computer to deploy UltraVNC.
- In the “Bozteck Deployment Tool”, add the computer(s) that you are deploying to and fill out any other information that is pertinent to your environment.
- Press the “Deploy” button
- First, the script will remove any existing version of VNC from the computer and then it will deploy the new version.
If you’ve installed UltraVNC, RealVNC, or VNCScan lately, you were likely greeted with this scary window:
Microsoft has made great strides in security since the original release of Windows XP. In later service packs, they turned the firewall on by default, built security measures into Internet Explorer, and disabled unneeded services.
More recently, Microsoft released their own consumer antivirus product named Security Essentials. Being an Information Security professional, it’s hard for me to be upset with Microsoft throwing warnings like this when software that enables remote access to your computer is installed.
Being the software author of a program that is used legitimately by thousands of you across the globe to manage your business and school networks. this message is also quite frustrating! It looks scary … and red; two things that we are conditioned as IT Professionals to squash like a cockroach.
Is UltraVNC a threat to your network?
Like any remote management software, the answer lies in how you manage the software. VNCScan is an excellent tool for this because it can be used to audit where VNC and RDP is enabled on your network and remove it if needed. It also allows you to take control of misconfigured VNC installations by deploying a secured profile using encryption and Windows or Active Directory authentication.
The first time that you run VNCScan, create a managed group, then scan your networks IP range, you may be surprised to find rogue VNC installations on your network installed by end users. Over time, the background scanner can discover other installations as they appear and even email you when they are found.
The bottom line is that VNC is a great network management tool that is relied upon by millions of IT professionals every day. If you lose control of the tool, however, it can be a nightmare to secure. VNCScan is your key to preventing that on your network.
It’s your network. Take control of it with VNCScan!
Bozteck takes pride in making complicated tasks simple. That has been the philosophy behind VNCScan for the past 13 years. We’re making some really COOL changes to the product to do just that.
When the first versions of our VNC Manager were released way back in 1999, the data was stored in a Microsoft Access database. Despite the popular (and often justified) opinion of Microsoft’s Access database, there are some applications that use data “just right” for that platform and VNCScan was one of them.
After frustrations with requiring multiple runtimes for Access, the decision was made to move the data to an XML format. A lot of code was written to manage that process smoothly on the thousands of existing VNCScan installs deployed all over the globe. The XML format has been working pretty well over the past 10 years but there are some pretty serious issues that the time has come to address.
Issues with XML Databases
The largest sacrifice of moving to XML was the ability to share one set of data with many administrators. When the back end was database driven, multiple computers could pull from the same data at the same time with very good performance and reliability. After moving to flat XML files, doing so often led to groups disappearing and data files that became corrupted so badly that it prevented the program from starting up. We had to remove any support for sharing data with XML. because of this.
For example, if John and Mike both point their VNCScan consoles at the same data location, they will constantly be stepping on each others changes. An XML file must be read into memory, modified, then placed back onto the disk as a complete file (overwriting whatever is there).
If John reads the data into his console, then Mike makes a change to the group, and then John makes a different change to HIS copy of the group, Johns change will wipe out Mikes change even if they change different properties of the group. If they both try to write their changes simultaneously, they end up with a corrupted XML file.
The Great Database Debate
A while back, I made a blog post asking opinions of using an Access back end verses using a Microsoft SQL Server back end. I received a lot of emails with great responses from so many of you!
On one hand, the Access database format needs to be compacted and repaired from time to time to get rid of orphaned data and “white space” in the database. It also does not do well with a lot of threads hitting it at the same time.
On the other hand, Access is a very portable database format that requires no runtime (any more) to use in your program and holds up well with the type of data accesses that VNCScan performs. I’ve also taken performance heavily into consideration with each line of code that I have written to mitigate any “over use” of the database.
If we were to use a SQL database, we would need to deploy the Microsoft SQL runtimes (MSDE) or require that every customer has a SQL server on premises. For the style of data that VNCScan employs, both of those options seemed like overkills at this point.
The initial database version of VNCScan will be backed by a Microsoft Access database. The code was written in a way that will make it VERY easy to port it to a SQL database in the near future. While we have tested VNCScan extensively on the Access database, we will be watching “wide eyed” for any indication that the platform isn’t good enough.
I believe that by June, we will have a version that will have a choice between Access and SQL. We’re only releasing the first version as Access based to cure the ills that plague the XML. Even with its shortcomings, Access databases are a hundred times better than XML.
We are in the final stages of “dog fooding” the database version. That means that we’re using it internally so that we feel any hardships before the beta testers do.
Within the next day or so, you will see a bog post with instructions and a link to try the beta. I strongly suggest that you back up your <My Documents>\VNCScan folder before installing the beta.
- Updated to the latest version of UltraVNC for remote deployment
- Redesigned much of the interface to make things even more intuitive. You can see a screen shot of the new form here.
- Added a button to the main form common tasks to enable RDP Remote Desktop on computers remotely
- Rewrote the XML data handling engine to improve performance when navigating data in the application
- We all hate bugs so we killed a bunch of them
- MUCH more room for the RDP tab. By default, the RDP sessions take advantage of the increased real estate.
The latest release of VNCScan (2011.3.27) has started the move from the old UltraVNC msrc4plugin_noreg.dsm encryption plugin to the newer and more supported SecureVNCPlugin.dsm.
The main reason for this move was the lack of 64 bit support in the old plugin as well as its requirement for a manually generated RC4 encryption key to be shared at both ends of the connection.
VNCScan has historically done a pretty good job at making this seamless for our users but it’s a lot of extra work around code that can finally see it’s sunset.
What this means for you
If you are currently using VNCScan to deploy UltraVNC with encryption enabled, chances are you’re using the old msrc4 type of encryption. To take advantage of the new higher security, you will need to edit the deployment profile that you used when deploying it the first time or create a new one from scratch. You will, then, need to deploy that new profile to the computers who you want to secure.
Here, I will walk you through creating a brand new profile and deploying it to a computer.
Step 1 – Create the profile
1. Launch the profile editor
2. Create a new profile
3. Give the profile a name and a password. Make sure that UltraVNC is selected
4. Choose the SecureVNC encryption plugin. Make sure that the checkbox is set for Encryption
5. Save the profile then close out of the profile selector
6. Select the computers that you want to deploy this profile to, then choose “Deploy to selected” from the dropdown menu
7. Make sure that your new profile is selected in the deployment window and that you have supplied an Administrator level username and password on the remote systems. Press Go to complete the deployment
Once the deployment has completed, you should be able to connect to the remote computers and see the following in the title bar of the viewer:
It is worth pointing out how VNCScan tells the vncviewer.exe to use the encryption plugin while connecting because that is typically the thing that trips people up from time to time.
When the deployment tool is completed, it locates the computer in VNCScan and sets some properties for it that can be viewed by right-clicking the computer (in VNCScan) and choosing “Computer Properties”.
The most important settings for this to work right are shown below.
As you can see, these must match the settings for the deployment profile that you used when deploying. Eventually the MSRC4 plugin will completely go away so you will want to do this to all of your computers soon.
Please leave comments and suggestions for these changes below.
Update: The latest releases of VNCScan no longer require this work around for CTRL + ALT + DEL (SUPER). It is supported natively.
UltraVNC has had some pretty big issues with sending the CTRL + ALT + DEL combination to Windows 7 when UAC (User Access Control) is turned off (or on in some cases). We have heard from many users that sending this sequence has no effect on the remote computer.
To date, the developers at UltraVNC have not released a fixed version for this. We’re impatient around here so we decided to create our own working fix and release it in VNCScan Enterprise Network Manager version 2010.9.21.
The updated deployment tool adjusts settings on the remote system during deployment to fix this issue. This means that if you ever toggle UAC on the remote system for any reason, you will need to re-deploy UltraVNC to it using the deployment tool in VNCScan. For most people, this is a “set it and forget it” feature in Windows so.
You may also need to deploy again if you have deployed UltraVNC in the past with previous versions of VNCScan or if you installed UltraVNC manually. Those previous versions do not have knowledge of this work around and the settings were not toggled.
If you do turn UAC on or off after you have deployed UltraVNC to the computer, you will need to first reboot the desktop, then deploy UltraVNC to it again using the deployment tool inside VNCScan.
While this is an exciting development for users of VNCScan, I know that this isn’t the best fix in the world. It’s the best that we can do until the great developers at UltraVNC release an officially patched release of their server software.
Steps for changing UAC on a computer
- Turn on or off UAC using the control panel applet
- Deploy UltraVNC to the computer
- Reboot the computer
You can download the latest release here.
This guide will describe the procedures and various options when deploying VNC on your network to Windows XP, Windows 7, and Windows Server using the tools in VNCScan Enterprise Network Manager (VENM). We’ll move through each of the screens and give an overview of each of the settings and what they do. We’ll conclude with a look at what happens during the deployment process behind the scenes.
System Requirements for VNC Push Installs
· The remote computer must be running Windows 2000 or greater
· The Remote Registry must be started on the remote computer (in some configurations, this is disabled by default and needs to be set to “Automatic”)
· In Windows XP, Simple File Sharing needs to be disabled.
· There must be no firewall enabled that is blocking the typical file sharing ports.
· Administrator access to remote computers must be either granted to the account you are logged in as or supplied in the deployment tool at the time of deployment.
VNCScan uses the concept of “Deployment Profiles” to group settings for the remote server. Instead of choosing options such as the server password, VNC version, and various other settings every time that you deploy VNC, you can create names profiles that contain all of this information; ready to be used on any computer on your network quickly.
These profiles are created using the Profile Editor. The easiest way to get to this tool is the toolbar under the Managed Groups tab (Fig 1.0)
The Profile Editor
Using the Profile Editor, you can create new profiles or edit existing ones. We’ll start by creating a new profile called “UltraVNC with MS Login”. To start, click on the button that says “New Profile” as seen below.
Let’s take a moment to look at all of the options on the first tab of the deployment profile editor in the image below (FIG 1.2).
· Profile Name – This is what will be used to reference this profile when it’s time to deploy VNC Remote Screen Sharing to a networked computer.
· VNC Version – You have the option of deploying 4 different versions of VNC; UltraVNC, TightVNC, RealVNC Freeware, or UltraVNC Legacy. UltraVNC is the default and most compatible with modern operating systems. This is the official version that is best supported in VNCScan.
· The server password must always be set no matter what other settings you choose in the editor.
· The TightVNC Read-Only password will be enabled if you are deploying TightVNC and wish to enable a second password for read-only access to the remote desktop.
· VNC Port – this is the port that VNC will listen on for a connection. If you alter this, you will need to make sure to edit the computer or group properties in VNCScan to connect on the correct port.
· Java Port – optionally, VNC Server has a built in java web client. If you set the port to 0 it will disable this server.
The connection options are optional and work fine as the defaults for most scenarios. If you’d like to modify them, here’s what they do:
· Authorized Host Connections – this allows you to say who can or cannot establish a connection to the remote server based upon IP address. You can get more information about the AuthHosts here,
· Disconnect Actions allow you to do certain actions on the remote computer upon disconnect such as log off or lock the workstation
· When checked, you can make the server ask the logged on user for permission before connecting.
· The next checkbox compliments the one mentioned above by automatically accepting the connection if the logged on user doesn’t respond after x number of seconds.
· For performance reasons, you can also choose to remove the remote desktop wallpaper, pattern, or user interface effects while remotely connected.
There are additional performance options listed below. Things operate fine at their defaults. Changing them can get a bit more geeky and should be done with care.
· Use VNC Hooks… – That will use “hooks” into the operating system to detect which areas of the screen has changed and need to be updated in the viewer. This just gives a little better quality with screen updates. The downside is the increase of CPU required at the remote computer.
· Poll the whole screen – this will poll the entire screen for updates on each cycle instead of just the foreground window(s). As expected, it can cause a performance hit on the remote computer.
· Filter Events that have no effect – This filters out changes on the remote system that aren’t visible on the monitor. I’d leave that checked unless there’s a specific need to uncheck it.
· Sharing – This determines at the server level what happens if two different consoles attempt to remote control the desktop at the same time.
o Always Shared – no matter what setting the connected client(s) have set, the server will override them and allow the desktop to be shared by all connections
o Never share – no matter what setting the connected client(s) have set, the server will override them and disallow the desktop to be shared by all connections
o Use Client Defaults – This lets the client settings decide. If the connecting client is set to disallow sharing, all existing connections will be dropped in favor of the newly connecting client.
· Accept Pointer Events – to accept mouse input from the connected clients or not
· Accept Keyboard Events – to accept keyboard input from the connected clients or not
· Accept clipboard Updates – When checked, anything copied to and from the clipboard at either computer is passed through the VNC connection to the remote computer. If this is enabled, be careful of what you copy into the clipboard while in a VNC session.
· Send Clipboard Updates – this controls whether anything copied to the clipboard on the server is sent back to the client’s clipboard for pasting.
· Clipboard events affect the screen saver – If enabled, the screen saver will be disrupted on the server if the client copies something to their clipbard
· Disable local inputs – This will disable the remote servers keyboard and mouse while someone is connected to the server.
Here’s where we can set some things that are specific to UltraVNC along with other settings that you may be interested in.
· Disable Tray Icon – This hides the VNC icon on the remote computer. Normally, while the service is running, there’s a little icon by the clock that gives information about the server and allows users to change settings. Hiding the icon can take away the temptation to tamper.
· Allow users to shut down VNC – When this is checked and the user right-clicks the icon in the task bar for the server mentioned above, the option to shut down the server will be grayed out.
· Allow users to change and access settings – When this is checked and the user right-clicks the icon in the task bar for the server mentioned above, the option to open the settings window for the server will be grayed out.
· Use DSM Encryption – This is specific to UltraVNC. It enables encryption for the IP traffic between the server and the viewer. This happens using a shared private key file. If the server is deployed with this check box checked, it will refuse connections from any viewer that is not configured for encryption with the same private key. More information on this is here.
· MS Authentication – This is also specific to ULtraVNC. It will ignore the password configured in the “Required Settings” tab and use Windows authentication to control the connection instead. The ACL lingo is explained here.
The custom section of the profile editor is getting a little out dated. In older versions of VNC, settings were stored in the registry. Now they are most stored in a file in the same folder as the server. If you’re still deploying older registry based VNC versions, this section could come in handy to you.
You can add custom registry keys to the remote computer during the deployment using this screen. If you chose UltraVNC DSM encryption in the previous tab, a path will be specified here to the rc4.key private key file that will be used on the server end. If you’ve created your own key, be sure that the same key file is in the folder where your vncviewer.exe is located. Again, more information on this can be found here.
That’s it! Save your settings and you’re ready to deploy it to a workstation.
Deploying the Profile
We’re going to start with the premise that the computer you are wishing to deploy VNC remote desktop to is not already added to a group in your console. We’ll start by right-clicking a group and choosing to register a new computer manually.
Now, type in the workstation name, then hit the button that says “Resolve From HostName”
You can optionally enter any other information in this dialog but this is all that is required to continue. Press the OK button to return to the main window.
Click the “VNC Deployment” toolbar and select “Deploy to Selected”
The following window is displayed (FIG 2.4). Let’s go over some of the options that you see here.
· Selected Computers – these are the computers selected to have VNC deployed to
· Deploy Profile – this is the profile of settings to be applied to the selected computers once VNC has been pushed to them. Look familiar?
· Add computers to group – Once the push process has been initiated, the computer(s) will be added to the group selected
· Use alternative login credentials – This will be the user account used to access the remote computer and its registry. Make sure that it’s a user account with administrative access to each computer in the selected computers list.
· Do not copy start menu icons – this prevents the icons for VNC server from showing up on the remote computer’s start menu
· Deploy UltraVNC video driver – When checked, the push script will attempt to install the UltraVNC performance enhancing video driver on the remote system. Be aware that Windows Vista, 7, and server 2008 have driver signing restrictions that may cause a prompt to show up on the remote computer during deployment.
You’re done! If everything went right, you should be able to connect to the remote computer and remote control it by simply double-clicking on the computer in the main window.
If you’ve been having problems with your groups and computers reverting to the default upon the previous update, this version should resolve that issue. I apologize for the rough process in the last version upgrade. Measures have been put into place to prevent this from happening again. Please let us know if you experience any problems with this new version.
Just as a reminder, you should always make a good backup of your data before upgrading to new versions.
We’ve posted the latest release of Bozteck VNCScan Enterprise Network Manager (VENM) to our downloads page today!
If you saw that there was a version 2010.2.3 and downloaded it before we could correct the error, you probably downloaded a (less than stable) beta version instead of this release. Please re-download the update to be sure that you’re on the stable code base.
We’ve done some more work to make moving your data files around much easier. You can modify the root location (the folder that contains the data, profiles, and jobs folders) in the main program preferences in the “Support Files” section.
If you’re moving the data to somewhere on the same volume, you can simply hit the “Change” button and browse to a folder where you want them to be. When prompted, let the program move the files for you into that location.
If you’re moving to a network location or another volume, manually create that destination folder and copy the data, profiles, and jobs folders into that new destination folder. After this is completed, follow the steps above and answer “No” when asked if the program should move the files for you.
- Fixed the Windows Logon (mslogon) in UltraVNC fo x64 – When pushing a deployment of UltraVNC to a remote x64 system, the mslogonacl.exe tool was refusing to apply the correct permissions. This has been fixed.