If you are sharing your VNCScan database among multiple computers, be sure to use this proceedure when upgrading:

1. Update one copy of VNCScan to the latest release but don’t launch it yet
2. Close ALL other users out of VNCscan
3. Run VNCScan on the newly upgraded computer
4. Upgrade all of the rest of the users of VNCScan

This procedure is required so that if there are any updates to the database structure, the newly upgraded version has full control of the database to apply them upon first run.

Twitter This

UserName: Password:

Overview

This video shows you how to share your VNCScan data with your co-workers.  I also touch on the new data import tool.

Twitter This

UserName: Password:

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.

Historical Overview

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 Future

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.

The Beta

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.

Twitter This

UserName: Password:

If you would like to beta test, you can download it here.

Twitter This

UserName: Password:

In the pilot episode of the new Windows Unwrapped show, we demonstrated how to virtualize VNCScan into a single portable executable that you can carry with you on a thumb drive.  Check it out here! 

Twitter This

UserName: Password:

Summary

You can effectively backup all of your VNCScan data by backing up your <My Documents>\VNCScan folder as long as you have installed it with files in their default location.   Restoring the files to that same location will get you back up and running again quickly after a reinstall of VNCScan.

Don’t just rely upon the backup/restore feature in VNCScan.  Everyone should back up the files to an offline media to avoid slow corruption issues that are a risk for any data driven application such as VNCScan. 

How VENM Stores Data

Most data in VNCScan centers around the groups.xml file. This means that most other data resides in the same folder as this file. When you change the location of the groups.xml file in the main VNCScan preferences, much of the other data follows suit.

The default location for VNCScan data is under your “My Documents” folder inside a subfolder of “VNCScan\data”. If you browse that folder with Windows Explorer, you will see a lot of XML files.

There are a few key files that have special meaning. Here they are with their functions:

· Settings.xml – This file holds all of the initial settings for the console. It contains any customized file locations such as an alternate location for the groups.xml along with anything else 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.

For instance, if you have a group named “Default”, it would be listed in the groups.xml as well as have its own file named default.xml to hold it’s computers. It is separated out like this to improve performance.

· ConnectionLogs.xml – This holds the connection logs for each computer. It resides in the same folder as the groups.xml and moves with it.

· Computername_maint.xml – The Computername is any computer name with a maintenance log. These files store the maintenance logs for the computers.

Note: There is also a file called settings.xml located in the VNCScan program folder. That file should be backed up and restored with the rest of your data.

Other folders worth noting under ‘My Documents\VNCScan’ are:

· Jobs – Stores all of the remote scripts and their settings

· Profiles – Stores all of your VNC deployment profiles and their settings

Backing Up Your Data

These are the default folder locations that you should be backing up regularly:

· ‘My documents\VNCScan’

· ‘C:\Program Files\Bozteck\VNCScan Console .NET’

· ‘C:\fastpush’

Restoring Your Data

1. Close the VNCScan console and any open VNC sessions

2. Restore the data from your backup into the proper locations

3. Launch VNCScan Console.

Twitter This

UserName: Password:

VNCScan version 2011.3.14 has been uploaded.  You can get it here.

This is mainly a bug fix version but there were also some behind-the-scenes structures added that will make way for some upcoming feature releases.  We’re excited about what’s coming down the line!  More to come soon …

Twitter This

UserName: Password:

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

1. Turn on or off UAC using the control panel applet
2. Deploy UltraVNC to the computer
3. Reboot the computer

You can download the latest release here.

Twitter This

UserName: Password:

One of our users has created a website to share his scripts.  There are some really useful ones up there so it may be worth your time to browse them.

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

Twitter This

UserName: Password:

Adobe Flash Player has been the target of many security attacks lately due to its inherent security flaws.  Adobe updates the Flash player frequently. 

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!

Twitter This

UserName: Password: