Terminal Services and ini file errors

[Guest Richard Tracy]

Hello, we are having a wierd issue, I will describe to the best of my

ability. We have an application that pulls an ini file from the users

homedrive\windows directory. This ini file holds the information for the

application to be able to successfully connect to the database. This

application works with no issues for our users that are using workstations.

The application works 95% of the time in our terminal services enviroment,

but for some users they will get none of the information or sometimes they

will get pieces of the information but not all of it. This is a windows 2000

terminal server enviroment with about 15 users per server, but we have been

able to re-create the error on a server that has no users on it. We also

have a windows 2003 terminal services enviroment that we are currently

testing and if I point a failed user to the Windows 2003 enviroment the

problem goes away. Yes I agree the obvious solution is to move the users to

a Windows 2003 enviroment, but we can not do that yet due to some application

incombatibilities. Here are some things we have tried

 

1. Added maxcmds, maxmpxct, and maxworkitems to the registry with values of

2048, 2048, and 8096 respectfully thinking we had a netbios issue

2. Added the hotfix for the MS06-051 security patch and this had no affect

3. Dropped the load for the servers from 15 users per to 8 users per with

no change

 

It does not appear to be a load issue, we are also doing folder redirection

for the desktop and my documents to the users home dirve with no issues, also

our file servers are 2003 and also host our DFS share and some other shares

which are not having any issues.

This isssue is currently driving us crazy and any help or direction would be

greatly appreciated

 

Richard Tracy

[Guest TP]

Re: Terminal Services and ini file errors

 

Hi Richard,

 

Please examine your 2000 TS server and gather information:

 

- Check that the program's ini file exists in the server's

C:\WINNT (substitute your SystemRoot folder if not C:\WINNT)

 

- Check the name, modify date/time, and contents

 

- Check the following registry location for a REG_DWORD

entry matching the ini file name (without .ini):

 

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\IniFiles

 

Does an entry exist? If it exists, what is the hexadecimal value?

 

- Check the following registry location for a REG_DWORD

entry matching the ini file name (including the .ini):

 

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\IniFile Times

 

Does an entry exist?

 

When a user has a problem, examine the contents of the ini

file located in their homedrive windows folder. Does it

contain the correct settings?

 

When a user has a problem, run Process Monitor while

logged on to the server as an admin. Have the user open

up the application and then look at process monitor to see

where it is pulling the ini file from. Filtering is helpful to

limit the data you have to look through.

 

Process Monitor

 

http://www.microsoft.com/technet/sysinternals/utilities/processmonitor.mspx

 

Are the users using the same ini file when logging on from

their workstations? If yes, are there any conflicting settings

between the two? Is the same user account ever running

the app via a workstation *and* via the TS?

 

Using the same ini for workstations and the TS could cause

problems if you are not careful.

 

Would it be acceptable to overwrite all of the user copies

of the program's ini with a new master copy? You can

do this using the following steps:

 

1. Log on as an admin (with no other users logged on)

2. Switch to install mode

3. Open up the app and change settings as needed

4. Close the application

5. Edit the app's ini file in C:\WINNT\ using notepad (this

is optional step, in case you want to manually make a change)

6. Save the file and close notepad

7. Switch back to execute mode

8. Have users logon and run the application, verify that they

have a fresh copy of the ini copied to their homedrive windows

 

Thanks.

 

-TP

 

Richard Tracy wrote:

> Hello, we are having a wierd issue, I will describe to the best of my

> ability. We have an application that pulls an ini file from the users

> homedrive\windows directory. This ini file holds the information for

> the application to be able to successfully connect to the database.

> This application works with no issues for our users that are using

> workstations. The application works 95% of the time in our terminal

> services enviroment, but for some users they will get none of the

> information or sometimes they will get pieces of the information but

> not all of it. This is a windows 2000 terminal server enviroment

> with about 15 users per server, but we have been able to re-create

> the error on a server that has no users on it. We also have a

> windows 2003 terminal services enviroment that we are currently

> testing and if I point a failed user to the Windows 2003 enviroment

> the problem goes away. Yes I agree the obvious solution is to move

> the users to a Windows 2003 enviroment, but we can not do that yet

> due to some application incombatibilities. Here are some things we

> have tried

>

> 1. Added maxcmds, maxmpxct, and maxworkitems to the registry with

> values of 2048, 2048, and 8096 respectfully thinking we had a netbios

> issue

> 2. Added the hotfix for the MS06-051 security patch and this had no

> affect

> 3. Dropped the load for the servers from 15 users per to 8 users per

> with no change

>

> It does not appear to be a load issue, we are also doing folder

> redirection for the desktop and my documents to the users home dirve

> with no issues, also our file servers are 2003 and also host our DFS

> share and some other shares which are not having any issues.

> This isssue is currently driving us crazy and any help or direction

> would be greatly appreciated

>

> Richard Tracy

[Guest Richard Tracy]

Re: Terminal Services and ini file errors

 

Thank you for the reponse. One of the issues is that the ini file is

specific to he user so it is different fior each user. I have also checked

the INI file from a failing users login and the INI file contained all the

information. I have also found that we have another application that uses

the homedrive\windows directory and that fails at the same time as the other

application and when one application works they both work.

 

Here is some of the other information you requested

 

For this registry key I only have entries for system.ini and win.ini

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal

Server\Compatibility\IniFiles

 

There is an entry for the INI file

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal

Server\Install\IniFile Times

 

It appears that the other application that is fialing at the same time is

using the win.ini file in the homedrive\windows directory. Also with a user

that is failing if we delete the h:\windows directory and run either

application it creates the h:\windows directory and creates the files. We

have also noticed tha at times it pulls some of the info out of the INI file

but not all of it.

 

One other thing, these are windows 2000 servers, if a user is failing we can

point the users at our windows 2003 test enviroment and it works without any

other changes, and then if we point them back to our windows 2000 enviroment

it continues to fail.

 

"TP" wrote:

> Hi Richard,

>

> Please examine your 2000 TS server and gather information:

>

> - Check that the program's ini file exists in the server's

> C:\WINNT (substitute your SystemRoot folder if not C:\WINNT)

>

> - Check the name, modify date/time, and contents

>

> - Check the following registry location for a REG_DWORD

> entry matching the ini file name (without .ini):

>

> HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\IniFiles

>

> Does an entry exist? If it exists, what is the hexadecimal value?

>

> - Check the following registry location for a REG_DWORD

> entry matching the ini file name (including the .ini):

>

> HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\IniFile Times

>

> Does an entry exist?

>

> When a user has a problem, examine the contents of the ini

> file located in their homedrive windows folder. Does it

> contain the correct settings?

>

> When a user has a problem, run Process Monitor while

> logged on to the server as an admin. Have the user open

> up the application and then look at process monitor to see

> where it is pulling the ini file from. Filtering is helpful to

> limit the data you have to look through.

>

> Process Monitor

>

> http://www.microsoft.com/technet/sysinternals/utilities/processmonitor.mspx

>

> Are the users using the same ini file when logging on from

> their workstations? If yes, are there any conflicting settings

> between the two? Is the same user account ever running

> the app via a workstation *and* via the TS?

>

> Using the same ini for workstations and the TS could cause

> problems if you are not careful.

>

> Would it be acceptable to overwrite all of the user copies

> of the program's ini with a new master copy? You can

> do this using the following steps:

>

> 1. Log on as an admin (with no other users logged on)

> 2. Switch to install mode

> 3. Open up the app and change settings as needed

> 4. Close the application

> 5. Edit the app's ini file in C:\WINNT\ using notepad (this

> is optional step, in case you want to manually make a change)

> 6. Save the file and close notepad

> 7. Switch back to execute mode

> 8. Have users logon and run the application, verify that they

> have a fresh copy of the ini copied to their homedrive windows

>

> Thanks.

>

> -TP

>

> Richard Tracy wrote:

> > Hello, we are having a wierd issue, I will describe to the best of my

> > ability. We have an application that pulls an ini file from the users

> > homedrive\windows directory. This ini file holds the information for

> > the application to be able to successfully connect to the database.

> > This application works with no issues for our users that are using

> > workstations. The application works 95% of the time in our terminal

> > services enviroment, but for some users they will get none of the

> > information or sometimes they will get pieces of the information but

> > not all of it. This is a windows 2000 terminal server enviroment

> > with about 15 users per server, but we have been able to re-create

> > the error on a server that has no users on it. We also have a

> > windows 2003 terminal services enviroment that we are currently

> > testing and if I point a failed user to the Windows 2003 enviroment

> > the problem goes away. Yes I agree the obvious solution is to move

> > the users to a Windows 2003 enviroment, but we can not do that yet

> > due to some application incombatibilities. Here are some things we

> > have tried

> >

> > 1. Added maxcmds, maxmpxct, and maxworkitems to the registry with

> > values of 2048, 2048, and 8096 respectfully thinking we had a netbios

> > issue

> > 2. Added the hotfix for the MS06-051 security patch and this had no

> > affect

> > 3. Dropped the load for the servers from 15 users per to 8 users per

> > with no change

> >

> > It does not appear to be a load issue, we are also doing folder

> > redirection for the desktop and my documents to the users home dirve

> > with no issues, also our file servers are 2003 and also host our DFS

> > share and some other shares which are not having any issues.

> > This isssue is currently driving us crazy and any help or direction

> > would be greatly appreciated

> >

> > Richard Tracy

>