We are upgrading our Windows 2000 server to a 64-bit Windows 2008 server.  The new one has been configured so that there's a host, called JAMIARAHOST, within which is the virtual server, called DC01.  Connecting to these, and also within the same machine, is a virtual Windows 7 computer (all our workstations are being upgraded from XP to 7).

I'm using Remote Desktop to connect to the server and the virtual Win 7 machine.

A folder off of the DC01 C: drive has been created, called Data, which is where I've installed Sesame on DC01 (we're trying to keep C: out of the reach of users).  The program and data reside in a folder called Sesame, which has been mapped to drive G:

The program runs fine as a server.  Also on the desktop I've put a client shortcut, which connects to the server just fine with the following startup switch:

C:\Sesame\Program\sesame.exe -Client DC01 -system_id "SCOTT" -ini_file G:\Sesame\Miara\1150-950-sesame.ini MIARA.db 

So that's all cool.  Server is running, and on the server I can fire up a Client.

Switching to the virtual Win 7 machine I encounter problems.  Sesame has been installed on its C: drive and runs, but I cannot connect to the server.  I've tried every variation of the startup switch I can think of, but I'm clearly missing something.  Any idea how I should proceed?  As usual, your help is immensely appreciated.

Success.  Received - 4, Fail = 0, Average 3ms.

Thanks Ray.  I will run this by the tech's who are working with me on the new server and see what I can do.

TCP ports 20,000 and 20,001 on the Server. Client side will use 2 TCP ports that are going to be assigned to us at Runtime by the system.

-Ray

ENVIRONMENT VARIABLES!  I had totally forgotten environment variables.

OK, so now Sesame Server starts up.  I start Sesame Server with a batch file that runs Sunlock on all the databases before starting up.

Sesame client on the server starts up, and the server window shows 1 of 10, cool.

On the workstation I can connect to the server but immediately get the message "The application is locked and may currently be in use."  If I close the app on the server client, Sesame client on the workstation fires right up and opens the DB.

Puzzled.  I'm going to play with Sunlock, see what happens.

Sunlocking each of my databases allowed the workstation client to open correctly.  YAY!

I'm not sure why the batch file failed to do so.

Yep, that was it.  Until I put C:\Sesame\Program in the server's Path environment variables, the license file was not being read.  So when I started up a client on the server, Sesame Server read 1 of 1, and then when I fired up a client on the workstation, of course the file was locked.  I'm carefully tweaking every path now and everything seems to be working fine.  Thanks for your help Ray.