Windows 2000 was available in stores as of the 17th February 2000. Although we are unlikely to see many immediate upgrades from NT4, there will no doubt come a time in the not so distant future when CS/3 will be running on Windows 2000 Servers. So far, no major problems that would prevent the relatively easy upgrade from NT4 to Windows 2000 have been identified. Please note that testing is ongoing and this document will be upgraded to reflect any problems which may be identified in the future.

Upgrading from one operating system to another can be problematic and this document assumes that the Microsoft upgrade has worked correctly. We also assume that the user reasons for upgrading are appropriate and that any hardware related issues have been taken into consideration.

The scenario, in summary, is therefore that the user has decided to upgrade from NT4 to Windows 2000 and that their existing CS/3 application is operational. Having upgraded from NT4 to Windows 2000 Server (or greater), the customer expectation is that the existing CS/3 application will continue to operate without any further action. This is entirely reasonable and achievable.

There are very few changes required on the Server side. Generally speaking, fully Windows 2000 Accredited products are required to be installed under the 'Program Files' sub-directory. This is never the case with a CS/3 application which usually sits off the root directory, e.g. 'c:\csserver'. Be aware that CS/3 systems that use BTRIEVE components (currently all versions of CS/3 over NT use BTRIEVE for 'non-database' file access) cannot be Installed into the 'Program Files' directory on a Windows 2000 machine because BTRIEVE cannot handle the spaces in the 'Program Files' directory name.

Assuming that the customer wishes to keep the existing NT4 directory structure (and you would need a pretty good reason to decide against this!), the only considerations you will need to take into account are as follows:

1. What ACCOUNT is being used to run the INETD service?
2. What GUI FORMS methodology is being used and where do the forms reside physically?

There are three common practices when it comes to the INEID service account. If the user is using Extended Security (this is not the standard recommendation and as such, should rarely be the case), then the INETD account will be using the 'Local System Account'. If this is the case, no further action is need with regards to the INETD service account.

The second, and probably most common, account used in conjunction with the INEID service is the 'Domain Administrator Account'. Again, if this is the case, no further action is required, but you should be aware that changing the Domain Administrator password can result in the INETD service not being able to start successfully.

For above reason, it is recommended that a dedicated Domain Account is set up (called, for example, 'cs3inetd') and use this account in conjunction with INETD. If you use this method, you will need to make sure that the account belongs to the Domain Admins global group. Under NT4, you could use an account that had the explicit user right to 'log on as a service' and then belong to the Domain Users global group, but this does not appear to be sufficient under Windows 2000. You will have to make sure that the account used is a member of the Domain Admins global group. The benefit of using this approach is that the INETD service will run without interruption even when the customer's IT department changes its core list of passwords, as they should be doing on a regular basis.

There are three common practices when it comes to the GUI Forms too. Customers can elect to run Form Server, implement local forms on each client PC, or implement a shared forms directory on the server.

If you are running Form Server you will need to make sure that an appropriate account is being used in conjunction with this service (see INETD paragraph above).

If you are using local forms (and most people don't because of the administration and maintenance overhead) you will need to make sure that the forms directory has the appropriate permissions on each client. Note that Windows 2000 accredited products require installation into the 'Program Files' directory. CS/3 GUI Clients are usually installed off the root directory, e.g. 'c:\cscllent'. This is not a problem unless the local forms are located under the 'csclient' directory under 'Program Files'. Windows 2000 Users do not by default have read/write access to the 'Program Files' directory. The GUI client requires that the forms directory has read/write permissions associated with it, so if you do decide to implement local forms on each client, make sure the forms directory sits off the root, e.g. 'c:\forms'.

The final method, which is still the most common, is to create a form directory on the Server and share it for all GUI Clients to connect to. If you are using this method, again, make sure that the forms sit off the root, e.g. 'c:\forms' and that all Cs/3 users have read\write permissions to this directory and those beneath it.

You are probably used to being prompted to install client programs on your PC into the 'Program Files' directory. This is fairly standard practice and Microsoft will in future only grant Windows 2000 accreditation to products that install into this directory. As mentioned above, the CS/3 GUI Client usually installs off the root of the chosen drive, and this is not due to change as far as we are aware.

If you want to Install the GUI client Into the 'Program Files' directory you must make sure that the Domain User that is logging on to the PC belongs to a group that has read/write access to the 'Program Files' directory if that is where the local forms are located. Since the vast majority of Clients get their forms from a central location such as a shared directory on a server or a dedicated Form Server, this is not usually a problem. If storing local forms under the 'Program Files' directory is an absolute requirement, there are several options, all of which Involve giving the Domain User that Is going to access CS/3 greater control over their own PC. This may conflict with the customer's security policy, and is not recommended. You may see cosmetic changes to the GUI Client after upgrading from NT4 to Windows 2000, but the upgrade should not have a negative Impact on previously installed GUI Clients In general. The changes you may see include slight variations in colours, shading effects, and screen re-drawing in our experience. Certain Windows 2000 desktop themes may also prove unsuitable in combination with the GUI Client. If you experience post upgrade problems with GUI Clients that worked before the Server was upgraded, you should make sure that INETD has started and Is running successfully, that the forms retrieval method used Is appropriate and functioning correctly (see above re: read/write access to forms directory), and that name resolution is still working correctly. To eliminate name resolution, you can use the Server IP address rather than it's host name at the Client PC. You can also install a subset of GUI forms locally on the Client PC to rule out network and remote form retrieval problems. If you have fallen victim to remote form retrieval problems, you may not always receive error messages alerting you to this fact, and the client will look like it is hanging, even though it is merely waiting for a form (that it cannot access) to load.

Be aware that some earlier versions of the CS/3 Installshield check service pack versions. These checks are not appropriate for Windows 2000 as there are no service packs available for this product as yet (service pack 1 is on it's way though). The check should not halt the successful installation over Windows 2000. We recommend running version 3.1 or later on all Windows 2000 based systems. Independent benchmarking tests of Windows 2000 show improvements in performance over Windows NT Server, but Sage Tetra cannot guarantee improved performance as a result of upgrading from a previous version of Windows.

Benchmarks have shown that performance improvements vary between upgraded systems and fresh installations. See the IT press for the latest news on benchmarking.