Terminal Services and ini file errors

[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

 

[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

 

[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
>