You can use these command line options to take advantage of features that are not settable via the GUI in VNCScan.  Here’s how:

1. Open the main program preferences from the toolbar
2. Select the “Support Files” section
3. Add your command lines in the textbox designated for the switches

You can get your own copy of VNCScan at http://www.bozteck.com/vncscan

You can use these scripts in VNCscan to remotely manage your computers.  Here’s how:

1. From the main menu, click Tools
2. Click “Scripting and Commands”
3. Click “Remote Script Manager”
4. Click on the “New Script” button
5. Give the script a name
6. Paste the script into the big textbox under the word “Variables”
7. Edit the script to meet your needs
8. Include any files that your script will call for
9. Save and close the script

You can execute that script on a remote computer by:

1. Select a computer or computers in a managed group
2. From the Managed Groups toolbar,  choose “Remote Scripts”
3. Select your script from the dropdown

It’s very difficult to get all of the systems on your network updated because it requires Administrator permissions to apply the updates.  There aren’t any inexpensive tools for pushing these updates out so I will show you how to do this using Bozteck VNCScan.

Here are the steps in a nutshell:

1. Download the flash player distribution from here
2. Create the script in the Script Manager
3. Add the flash install file to the script window
4. Ensure that you have access permissions to the remote computer(s)
5. Select the computers that you’d like to deploy the script to
6. Select the script from the dropdown
7. Watch it work

Downloading Flash Player

You can download the scriptable Flash player from http://www.adobe.com/products/flashplayer/fp_distribution3.html.  For this tutorial, we’re going to download the Internet Explorer executable.

Create the script

Open the script manager using the Tools => "Scripts and Commands” menu as shown below:

From the window below, choose “New Script”

In the new script window,enter the script title and optionally a folder to group it in as well as any notes on the deployment and then choose to include a file.

Browse to the install_flash_player_10_active_x.exe file that you downloaded to choose it.  You will see the path to the file below:

When the script is executed on the remote computer, the path to the included file will be %systemdrive%\temp\vncscan\install_flash_player_10_active_x.exe.  Any files that you attach to script this way are always stored there.  You’ll need to reference that location by using that in the path of the file that you’re calling.  See the screen shot below:

%systemdrive%\temp\vncscan\\install_flash_player_10_active_x.exe /silent

Choose “Save and Close” to return back to the main window.

Deploy the script

We need to start by ensuring that the administrative access to the remote computer has been set.  One way to do this on a per-computer basis is to right-click the computer and choose properties; and then flip to the “Windows Login” tab.  Enter the Administrator username and password that is valid on the remote computer.  If you’re not on a domain, just leave the domain field at %HOST%.

Now, select the computer in the Managed List.  Now, click on the “Remote Scripts” and choose your new script.

The window below will pop up and the software will be deployed:

Keeping Up to Date

You can keep this script up to date easily because Adobe always names the file the same every time.  Simply return to the website and download the latest version, remove the one in the script, and then add this new download.  Simply re-deploy and you’re up to date!

This guide will describe the procedures and various options when deploying VNC on your network 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.

Getting Started

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)

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.

FIG 1.1

Required Settings

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.

FIG 1.2

Connection Options

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.

FIG 1.3

Performance Options

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.

Special Options

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.

Custom

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.

FIG 2.0

Now, type in the workstation name, then hit the button that says “Resolve From HostName”

FIG 2.1

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”

FIG 2.3

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.

FIG 2.4

FIG 2.5

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.

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.

Learn how to remotely enable RDP Terminal Services on remote computers using VNCScan!

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!

Bozteck VENM Console can deploy UltraVNC with session level encryption enabled. This is recommended in network environments where you fear that your VNC session may be “sniffed” from the network and replayed back without your knowledge. The risk of someone successfully doing this on your LAN is very low as it does require a moderately high level of “hacker skill”. Some networks, however, need extra protection even against low risk attacks such as this.

This document will explain the principles behind the VENM supported UltraVNC encryption as well as how to deploy and enable it from the console. The skill level to use this information successful varies. If you simply accept the safe defaults, the skill level required is low. If you choose to make modifications such as creating a custom rc4.key file, the skill level required is much higher.

This document is for Admins who want to customize the encryption, get to know how it works at a lower level, or are having DSM errors when connecting to an encrypted server. Anyone else can skim through or read this document as they wish.

Basic Principles

vncviewer.exe –> {RC4.KEY} ===> (Network) ===> {RC4.KEY} ==> [msrc4plugin_noreg.dsm] –> winvnc.exe

There are two key files that are fundamental to UltraVNC session level encryption and they are “msrc4plugin_noreg.dsm” and “rc4.key”. These will be refered to as the DSM and KEY files respectively through the rest of this document.

When a vncviewer.exe file wants to talk to an UltraVNC server that is set to use encryption, it starts by looking for it’s copy of the KEY file. If found, it encrypts it’s connection attempt using the data in the KEY file. It, then, sends a connection request to the remote server using this encrypted mode of communication that would seem like garbage to anything else on the network.

On the other end, the server hears a connection being requested. Because it is also configured to require encryption, it consults it’s copy of the KEY file and uses the data in the KEY file to decrypt the communication request coming from the viewer. If the keys match up, the data is correctly deciphered and the two commence communication in this encrypted tunnel.

If the keys do not match, the connection attempt is rejected and the viewer presents an error to the user stating that possible reasons could include the failure to find a DSM file and a few other suggestions. The error message is vague but it pretty much just means that either:

• The remote server is not configured for encryption but you are sending an encrypted request
• The server is configured to require encryption but you are sending an unencrypted request
• Both ends are configured for encryption but the KEY files do not match

More About the KEY and DSM Files (Server End)

The DSM file is a plug-in to the winvnc.exe service file. For reference, the winvnc.exe is the actual server executable for UltraVNC that is deployed to the remote computers and installed as a service. The DSM file must reside in the same folder as the winvnc.exe file. Don’t worry too much about that because the Bozteck VNC Deployment Tool does that work for you. When the DSM file is in the same folder as the winvnc.exe file and the configuration for the server has been properly set, the server will attempt to encrypt communication for any client that attempts to connect to it.

The KEY file also must reside in the same folder as the winvnc.exe file. The Deployment Tool also make sure that this happens as long as you do not modify things too much. If you simply tell the Profile Editor to enable encryption, it takes the KEY file that is located in c:\fastpush\vnc7\ultra and copies it to your Deployment Profile’s folder for easy deployment every time that you push that profile out to a computer.

Because this KEY file must match the KEY file on the Viewer end, it is best practice to only use one KEY file for your entire network. You do not gain sufficient security advantage by using multiple KEY files to make up for the headache required to keep them all straight and matched up. If you choose to generate a new KEY file, you must push that new KEY file out to each and every computer on your network that has encryption enabled to ensure proper connectivity.

By default, the UltraVNC Server is installed to either “C:\Program Files\orl\vnc” or “C:\Program Files\ultravnc” depending on the version of UltraVNC you are using. If you choose to distribute the KEY file using some method other than a VNC Push from VENM, it must in somehow make it’s way into that path on the remote computer end. Again, the VNC Push from VENM does this for you.

More About the KEY and DSM Files (Viewer End)

The KEY file is required to be in the same folder as the vncviewer.exe file. This KEY file must be an exact copy of the KEY file that is located at the server end as described above. By default, VENM uses the vncviewer.exe located in “C:\Program Files\Bozteck\VNCScan Console .NET” or whatever location you have installed VENM to.

You have the ability to customize the location of your vncviewer.exe file using either the main preferences (Support Files section), group properties (VNC Settings section), or the computer properties (VNC Settings section). If you choose to modify the location of the vncviewer.exe file, you need to make sure that a copy of your RC4.KEY file is moved with it.

Creating Custom KEYs

The Profile Editor has a button in the “Customs” section that allows you to generate a new key. This is an advanced level function and should never really need to be done in normal circumstances. To my knowledge, there has never been a tool released that allows someone to decrypt an encrypted UltraVNC stream for later playback. You should only need to generate a custom key if this is ever done. The KEY file does not control who can access you server. It only controls the way that the session is encrypted. You will still need to authenticate with the remote server using your password even if the KEY files match up.

If you do choose to create a custom KEY file, pressing this button is the easiest way to make sure that everything is placed in the correct locations for easy deployment. You may need to manually copy the new KEY file to the location where your vncviewer.exe resides, however. The newly generated key is always placed in c:\fastpush\vnc7\ultra.

Conclusion

I hope that this was a good in-depth overview of how the UltraVNC encryption works and how it interacts within the Bozteck VNCScan Enterprise Network Manager (VENM).

Bozteck VENM Console makes it very easy to deploy many versions of the VNC (Virtual Network Computing) remote control software to desktops and servers on your network.

With VENM, you simply create a template of settings called a Deployment Profile, select some computers, and choose to deploy VNC to them from the toolbar. Using the settings in your Deployment Profile, VNC is copied onto the remote computers, the services are installed and started, and you are ready to remote control the desktops!

Security and Authentication

Because this tool is copying files to secured ares of the hard disk over the network, you do need to know the credentials of a valid Administrator level user for the remote computer(s). If the computers are joined to a domain, you can typically use the domain administrator account.

If the computer is not a member of an Active Directory domain, you simply use the local administrator username and password. You will see in the instructions below how to specify this using the %HOST% variable.

You can enter and save these login credentials in the group properties if you’d like. You can do this by right-clicking a group and choosing to view it’s properties. You can save them in the section called “Remote Login Settings”. You can also simply enter them in every time that you choose to deploy a computer.

Firewalls

Files are being transferred over the network and commands to start and stop services are traveling about. This requires that any firewalls be adjusted to allow for this.

The deployment process requires that TCP port 445 is open on each computer. In addition, it would be a good idea to allow TCP and UDP ports 138 and 139. These are the standard Windows filesharing ports.

The deployment script will open any additional ports required by VNC for you.

Step-By-Step

Select The Deployment Editor

Choose to create a new profile

Fill in the desired settings
Note: only version and password are required
Choose to Deploy VNC from the ToolBar

Bozteck VENM Console includes a powerful remote screen capturing feature. This feature does not require that VNC or any other remote screen sharing software be installed in order to work. There are a few system requirements on the remote computer end, however.

Those requirements are as follows:

• UnFirewalled ports 443 (TCP) and 139 (UDP, TCP)
• Remote Registry service running
• Administrative priviledges on the remote computer
• Windows 2000, XP, Vista, or Windows 7

Because of these requirements, it is “best practice” to use this feature on computers that are on your LAN or within reach of your VPN. For security reasons, it is not advisable to use this feature over the open Internet.

You can supply the Administrator level access required to make this feature work in either the main VNCScan preferences, the group properties, or the computer properties. The choice depends upon the scope that you wish to apply.

Feature Set

• Resizable – You can resize the thumbnail by adjusting the slider in the toolbar
• Adjustable Interval – You can adjust the interval using a dropdown box of predefined timings or type in your own number. The intervals are measured in minutes. You can enter a decimal number to take snapshots in times less than one minute. If you manually enter a timing, it is applied when you press .
• Archive Screen Captures – You can archive your screen captures for later viewing. The location of these archives can be changed by clicking on the “Folders” button on the toolbar.
• Connect to VNC – You can connect to VNC right from the thumbnail. The connection options are taken from the computer entry settings in VNCScan.

What To Look Out For

• The “Please Wait Screen” – This screen is the start image for a new screen capture session. It is normal for it to still be visible even after the progress bar has cycled a couple of times. If it is still the only image being displayed for a computer even after the progress bar has cycled more than three times, you may want to check the permissions settings for the computer.

  You can test this out by attempting to access the c$ share of the remote computer. You can do this by clicking on your Start button and choosing “Run”. In the textbox, type \\\c$ (where is the name or IP address of the remote computer).

• Black Screen Capture – This is shown if the remote computer is sitting at the login screen and nobody is logged into the computer.

Video Example

Download video